Omma Data (Aqtiva)

Modelo de integración

El proceso consta de la petición de forma periódica a Aqtiva de las reglas vivas existentes desde una determinada fecha y los resultados de las mismas. Se enviará a Anjana esa información para actualizar los datasets asociados a los dataformats informados así como las reglas asociadas a ellos.

Para que el proceso funcione correctamente se deben crear unos atributos predefinidos en la plantilla del dataset y crear un nuevo tipo de entidad Aqtiva_Rule también con unos atributos predefinidos en el que se almacenarán los datos relativos a las reglas de Aqtiva (metadatos y resultados).

Plantilla Dataset

Los atributos que hay que añadir a la plantilla del dataset son los siguientes:

Plantilla AQTIVA_RULE

Para poder contener la información relativa a las reglas ejecutadas se necesita crear la entidad nativa AQTIVA_RULE que contendrá el metadato relativo a las mismas junto con los resultados aplicados.

Para ello es necesario crear una plantilla con los siguiente atributos:

El plugin no tiene ninguna ARI definida ya que no se va a poder hacer extracción, sampleo ni gobierno activo de estructuras. La comunicación se desencadena directamente desde el Plugin hacia Anjana con los datos a actualizar.

Credenciales requeridas

Las credenciales para acceder a Aqtiva están almacenadas en el fichero de configuración en base64 y serán proporcionadas por Aqtiva. El plugin irá a buscar la siguiente configuración:

totplugin:
  connection:
name: dev
technology:
   auth:
           client-id: <clientId a sustituir>
           secret: <secret a sustituir>

Despliegue

Se ha de seguir el manual genérico del despliegue de plugins.

Doc: Anjana Data 4.4 - DOC - Tot despliegue de plugins

Configuración

En la Configuración técnica y en Tot despliegue de plugins hay algunas directrices.

Existe un YAML de ejemplo para facilitar la configuración en Nexus / com / anjana / documentation (necesario login previo) con explicaciones de las propiedades y valores por defecto.

Este plugin puede conectarse a varias instancias de la misma tecnología, también se puede ver el YAML de ejemplo.

Se necesita la instalación de certificado de Aqtiva:

• Se obtiene de la URL que hay configurada en el YAML de la API de Aqtiva.

• Se sube a la máquina contenedora de la instancia del plugin.

• Se registra el certificado subido con el comando “keytool”, teniendo en cuenta que en el primer parámetro hay que poner la versión de Java que usa (sacada del descriptor de servicio del plugin):

keytool -trustcacerts -keystore "<path_to_jdk>/jre/lib/security/cacerts" -storepass changeit -importcert -alias <alias_to_be_stored> -file "<path_to_certificate/certificate.crt"

El certificado usa DNS y no IP, por lo que la propiedad “totplugin.aqtiva.auth.url” marcada en en el YAML debe de ser un DNS.

Tot

Tot persiste el momento de la última ejecución correcta para poder hacer posteriormente una consulta más acotada de los datos de Aqtiva. Esto se realiza en el esquema tot de BD, en la tabla plugin_execution, cuyos campos son:

• name como nvarchar(255) Primary Key

• date como timestamp

Kerno

Para mostrar el valor del campo AqtivaRuleExecutionResultsView en las reglas una vez se ejecutan en Aqtiva es necesario tener una plantilla configurada en el yml de kerno en la variable anjana.aqtiva.template_result_view. Como la variable es un ENRICHED_TEXT_AREA, se puede poner texto plano y etiquetas HTML para formatearlo de la manera que se quiera.

El valor de las variables debe estar entre {{ }} como se muestra en el siguiente ejemplo.

AqtivaRecordEnvirontmentLastExec: {{AqtivaRecordEnvirontmentLastExec}}<br>AqtivaRecordIdLastExec: {{AqtivaRecordIdLastExec}}<br>AqtivaRecordNumInLastExec: {{AqtivaRecordNumInLastExec}}<br>AqtivaRecordNumOutLastExec: {{AqtivaRecordNumOutLastExec}}<br>AqtivaRecordNumOkLastExec: {{AqtivaRecordNumOkLastExec}}<br>AqtivaRecordNumKoLastExec: {{AqtivaRecordNumKoLastExec}}<br>AqtivaDQILastExec: {{AqtivaDQILastExec}}<br>AqtivaRecordLevelLastExec: {{AqtivaRecordLevelLastExec}}<br>AqtivaRecordMessageLastExec: {{AqtivaRecordMessageLastExec}}<br>AqtivaRuleLastExecDate: {{AqtivaRuleLastExecDate}}

 Quedando el resultado de la siguiente manera

Funcionamiento

Plugin Aqtiva

El plugin dispone de un batch que se ejecutará según la configuración especificada. El proceso que ejecuta consta de 3 partes:

Última fecha de ejecución

El proceso obtiene la última fecha de ejecución sobre la que realizar la petición a Aqtiva. Para ello hace una petición a un endpoint en Tot que le da está información. Si la respuesta de Tot es correcta se comprueba el delta configurado y, si existe, se aplica siendo ésta la fecha resultante al hacer la petición.

Si la fecha devuelta por Tot no fuera correcta, ya sea porque no está establecida todavía o porque se ha producido un error, la fecha resultante será la fecha actual menos un año.

Sincronización de metadatos entre Aqtiva y Anjana

Recupera los datos vivos de Aqtiva desde una fecha determinada y todos los datos de Anjana relacionados con Aqtiva. Esta fecha de petición de los datos debe ser una fecha antigua para que Aqtiva devuelva todas las reglas vivas que existen. Se ha definido una propiedad de configuración donde se puede establecer esta fecha y si no existiera se utilizará 1-ene-1970. Una vez obtenidos procesa los datos de ambos orígenes para calcular aquellas reglas que hay que expirar, crear o modificar.

Una vez procesada toda esta información se enviará a Anjana para su sincronización de metadatos. Si no se produce ningún error se pasa a la sincronización de resultados.

Sincronización de resultados

A partir de los metadatos a sincronizar para obtener las reglas que hay que tener en cuenta, se inicia el proceso pidiendo los resultados a Aqtiva a partir de la fecha obtenida en el primer paso.

De los resultados a aplicar (excluyendo aquellas reglas que en la sincronización de metadatos han resultado a expirar) generamos 2 tipos de resultados:

• Resultado de datasources a nivel de dataformat. Agrupando por dataformat, datasource y qualityPoint todas las reglas tendrán el mismo valor así que se sincroniza en Anjana el correspondiente a la regla más nueva en Aqtiva.

• Resultado a nivel de reglas. Añadimos el listado de reglas a sincronizar.

Si hubiera algún problema podemos verificar los logs de Aqtiva donde se puede identificar claramente el proceso aquí mencionado

Endpoints disponibles

• POST /api/aqtiva/synchronize/rules. Se encarga de realizar el proceso completo de sincronización del metadatado de Aqtiva. Por un lado sincroniza el metadatado actualizando y expirando según los datos de Anjana y Aqtiva y para finalizar sincroniza los resultados según esos datos de actualización.

• POST /synchronize/rules/metadata. Se encarga de sincronizar los resultados del metadatado en Anjana según el payload pasado de sincronización de metadatado.

• GET /synchronize/metatada. Se encarga de sincronizar el metadatado en Anjana con los datos de Aqtiva según el filtro pasado (fecha de inicio del proceso).

Tot

Tot va a actuar como un proxy entre el plugin de Aqtiva y Kerno. El único trabajo que hace es que, cuando se termina la petición de los resultados, si todo ha ido bien (no se ha producido ninguna excepción), persiste en base de datos la fecha del momento actual.

Enpoints disponibles

• GET /internal/v4/anjana/aqtiva/lastExecution. Se encarga de obtener la última ejecución del plugin de Aqtiva.

• POST /internal/v4/anjana/aqtiva/synchronize. Se encarga de obtener el metadatado de Aqtiva almacenado en Anjana.

• PATH /internal/v4/anjana/aqtiva/synchronize. Se encarga de dirigir la petición a Kerno de la actualización del metadatado.

• /internal/v4/anjana/aqtiva/result. Se encarga de dirigir la petición a Kerno para actualizar los resultados de los objetos en Anjana relativos a Aqtiva. También se encarga de guardar la fecha de última actualización cuando no se ha producido ningún error.

Kerno

Kerno va a procesar los datos que le envíe el plugin según cada proceso.

Actualización de metadatos

En este caso tiene dos funciones, por un lado obtener el metadato existente en Anjana que esté relacionado con algún dataformat (esto es, aquellos datasets que tengan un atributo dataformat en su plantilla con valor), y por otro, hacer efectiva esa actualización deprecando objetos y creando reglas necesarias.

• Cuando tenga que expirar datasources obtendrá los datasets en los que está relacionado y eliminará ese resultado de la lista de resultados del dataset.

• Cuando tenga que expirar dataformats se obtendrán los datasets asociados y se actualizarán los atributos que contienen la relación entre datasets y reglas

  • AqtivaQRulesArray del dataset se elimina la regla a expirar

  • AqtivaAnjanaDatasets de la regla se deja a vacío

• Cuando tenga que expirar dataformats se obtendrán los datasets asociados y se borrarán el valor de ciertos atributos del dataset:

  • AqtivaIdDataFormat

  • AqtivaDataFormatName

  • AqtivaKPILastUpdateDate

  • AqtivaDataQualityDatasourceLevel

• Las reglas a expirar se ponen en estado DEPRECATED y se asigna al atributo expirationDate (fecha de expiración) el momento actual de ejecución para que se expire cuando toque (siguiente batch de expiración). Si este atributo no estuviera asignado en la template se mostrará un log por consola indicando la incidencia pero se permitirá guardar la regla como deprecada.

• De las reglas a crear se comprueba si existe o no. Si existe se actualiza los datos con la información que venga del plugin y si no existe se crea una regla nueva asociándose al dataset correspondiente.

Actualización de resultados

• Se procesan los resultados a nivel de datasource y a nivel de regla. Para los datasources se obtienen los datasets asociados a los dataformats a actualizar y se añade en el atributo de resultados los distintos valores pasados. Este proceso añade o modifica, no tiene que borrar ninguno.

• Se procesan los resultados a nivel de regla. Para cada regla se agrupan los resultados según el dataformat e identificador de la regla mostrando el listado de resultados de las ejecuciones para esa regla. Existe una particularidad con estos resultados y es que se utiliza un atributo que contendrá el valor “técnico” de los resultados y otro atributo que contendrá el valor visual del mismo. Este proceso añade o modifica, no tiene que borrar ningún resultado.

Si hubiera algún problema podemos verificar los logs de Kerno donde se puede identificar claramente el proceso aquí mencionado:

Endpoints disponibles

• POST /internal/v4/metadata/aqtiva/synchronize. Se encarga de obtener el metadatado relativo a Aqtiva que existe en Anjana. Se puede pasar un filtro pensado para dar soporte a la paginación aunque en esta versión no se está usando. Se ha generado de base para futuros desarrollos si hiciera falta.

• PATCH /internal/v4/metadata/aqtiva/synchronize. Se encarga de realizar la sincronización del metadatado de Aqtiva en Anjana según los valores pasados creando las reglas necesarias, asociándolo a los datasets y deprecando los objetos necesarios.

• PATCH /internal/v4/metadata/aqtiva/result. Se encarga de actualizar los resultados (a nivel de datasource en los datasets y a nivel de distintas ejecuciones en reglas) del metadatado de Aqtiva existente en Anjana según los valores pasados.