¿Qué cambió en la liberación de la Pipeline referente a Registros?

Visión general

En este momento, este cambio en el procesamiento de registros se realizó por medio de un cambio de arquitectura de cómo se leen y graban los registros en el Clockin teniendo como ventaja la mejora de desempeño y resiliencia de los procesos de generación siguientes:

• Integración de los registros del dispositivo con el Clockin
• Generación de NSR 
• Generación de comprobantes (Proceso nuevo creado)
• Envío de comprobantes.
• Detección de fraude.

¿Cómo era antes?

En el modelo actual todo el procesamiento sigue estos pasos:

• Paso1:    el app mobile envía un registro a Carol
• Paso2:    el dato llega a Staging Table, como dato bruto sin ningún tratamiento.
• Paso3:    por medio de reglas de mapeo este dato se trata y transforma en una información lista para ser consumida por medio de consultas en los Data Models.

Ejemplo:

Al procesar un registro, el dato vuelve a la Staging Table, pasando nuevamente por una regla de tratamiento modificada y llegando al Data Model nuevamente.

¿Cómo será de aquí en adelante?

El nuevo formato utiliza conversión de datos entre las capas de los datos de la Plataforma utilizando códigos SQL en lugar de reglas de mapeos.

Solamente 3 Data Model presentan el nuevo procesamiento: Clock In Records, Fraud Analysis y Clock In Event Type.

Los otros continuarán en el modelo actual, muy pronto tendremos nuevas actualizaciones sobre estos. 

Para más detalles sobre el nuevo procesamiento, consulte el enlace.

¿Cómo realizar la actualización de este nuevo modelo?

Para que las nuevas configuraciones de procesamiento se actualicen en el entorno es necesaria la realización de

una actualización de la versión del Backoffice para la  12.1.22080007 por medio del proceso de actualización de versión del Backoffice

Nuevo proceso de generación de comprobante

Las tasks que tuvieron modificaciones fueron:

• generación de NSR.
• generación de comprobantes (job creado recientemente).
• envío de comprobantes.
• detección de fraude.

Para el usuario final, nada se modificó, mucho menos la funcionalidad de estas.

Solamente la generación de comprobantes fue separada de la generación de NSR. 

La generación de comprobantes por tratarse de una nueva Task, necesita programarse en agenda.

¿Cómo realizar la programación en agenda?

Haga clic en Carol Apps

Después en 'TOTVS RRHH Clock In Backoffice'

En la Solapa 'Process', encuentre el proceso 'generate_receipts'.

En la columna 'Last Run', haga clic en  'Edit'

Es posible programar en agenda para una ejecución Mensual / Semanal/ Diaria y de Hora en Hora

En este caso programamos en agenda para ejecutar a cada 20 minutos.

Después de la configuración es necesario hacer clic en Save, para grabar los ajustes realizados.

¿Cuáles son las principales ventajas?

Se muestran algunas ventajas en la utilización de este nuevo proceso:

•  Corrección de fallas en el proceso de generación de los NSR como falla en el secuenciamiento y duplicación de NSR y trabamiento de la ejecución.
• Reducción de tiempo de ejecución generación de los NSR.
• División de los procesos para facilitar el entendimiento de errores de ejecución.
• Fallas de trabamiento en el envío de SMS/E-mails y reenvío del mismo comprobante

Problemas y soluciones

Puntos para chequearse y confirmar si el entorno realmente está apto para el nuevo formato:

Problema 1: ¿Hay mapeos vinculados a los Data Models Clock IN Records, Clock In Event Type y Fraud Analysis? 

Para acceder a los Data Models, haga clic en el ítem del Menú lateral izquierdo.

Para evaluar es necesario visualizar la estructura de los Data Models creados, y evaluar si hay contenido en la sección "Mapped Connectors".

Vea los siguientes ejemplos.

Obs.: Si aún existieran mapeos vinculados a estos, es necesaria la apertura de ticket.

Problema 2: Los registros de los Data Models citados anteriormente deben provenir del nuevo formato, para verificar, basta visualizar la columna “Connector”.

En esta debe constar el contenido “Carol Explore” o el contenido venir en blanco. ¿Si no ocurriera, cómo proceder?

En el ejemplo siguiente traemos el Data Model "Fraud Analisys" (para los otros 2, el paso a paso es el mismo).

• Acceda al Data Model
• Haga clic en "Colunms and Views Options"
• Entre con la información de ''Connector'' y la columna se visualizará en el data Model

Obs.: Si la columna citada tuviera otro contenido, es necesaria la apertura de ticket.

Problema 3: ¿Cómo acceder a los registros de los data Models?

Por ahora no es posible visualizar los registros en la capa RT, esto se liberará muy pronto y esto no trae ningún impacto a los clientes.

Lo correcto, la visualización se realizará por el BQ.

Atención es necesario consolidar los datos antes de visualizarlos.

Problema 4: Con relación a estos procesos citados, si apareciera algún error, se sugiere la verificación de los logs creados de las tasks, habiendo necesidad se sugiere la creación de un ticket.

Para acceder a los logs de las tareas en la Plataforma Carol, es necesario acceder a Activity Management.

Haga clic en la Campana y después en View All.

En el ejemplo que traemos, la task es la de Generación de NSR.

Vemos que esta tiene Estatus ''Failed'', al hacer clic en esta, se abrirá un menú lateral derecho.

Al bajar por este, es posible ver el mensaje de error.

En este caso, es necesaria la apertura de ticket.

También tenemos las task de: AI Process: generate_receipts, y AI Process: fraud_detection.

Problema 5:.A partir de ahora no es indicado realizar la modificación de registros directamente por la Plataforma Carol, esto se debe a que el nuevo procesamiento no abarca los datos modificados en esta forma.

Entonces, lo que se modificó en la plataforma no se considerará.