Flujos de Notificación

Cuando el GBDS realiza operaciones de registro (enroll) y actualización (update), se envían notificaciones a endpoints designados para informar sus resultados. La entidad responsable de este flujo se llama Notificador.

Este documento describe algunos flujos de notificación durante operaciones de registro y actualización.

Para información adicional sobre flujos de notificación durante control de secuencia y control de calidad, consulte la documentación de control de secuencia y control de calidad.

Todas las notificaciones enviadas por el Notificador son HTTP POST a un endpoint configurado (http://<endereço>:<porta>), conteniendo un objeto JSON. El modelo del JSON para cada notificación se presenta a continuación.

El endpoint que recibirá la notificación debe ser implementado individualmente para cada sistema.

Transacción Aceptada

Todas las transacciones asíncronas recibidas serán encoladas. Tras el procesamiento, se envía una notificación informando que la operación fue completada.

El mensaje de notificación será como en el ejemplo a continuación:

{
	"operation": "<operação>",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}

Las posibles operaciones en este paso son: ENROLL, UPDATE, o SEARCH.

El notificador puede devolver estados diferentes, según el tipo de transacción que se esté realizando. Los posibles estados finales son:

Operación	Estado
Enroll/Update	ENROLLED, FAILED
Search	MATCH, NOT_MATCH, FAILED, PERSON_NOT_FOUND

El estado FAILED ocurre siempre que una transacción sea abortada o no pueda finalizarse.

El estado PERSON_NOT_FOUND ocurre cuando se recibe una búsqueda 1:1, pero el perfil de referencia no existe para la clave proporcionada.

En algunos casos, el GBDS identifica transacciones que no pueden finalizarse y requieren intervención. Estos casos generan diferentes estados y están descritos en las secciones a continuación.

Transacción Enviada para Revisión Manual

En los casos en que el GBDS identificó problemas relacionados con el control de secuencia o control de calidad, y la transacción fue enviada a revisión manual, se enviará una notificación indicando que el registro está pendiente, como en el ejemplo a continuación:

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "PENDING"
}

Para información adicional sobre flujos de notificación durante control de secuencia y control de calidad, consulte la documentación de control de secuencia y control de calidad.

Consulte el Manual del MIR para mayores detalles sobre la resolución de transacciones enviadas a revisión manual.

Transacción con Excepción Biométrica

Si se genera una excepción al procesar la transacción, la transacción entrante será enviada al tratamiento de excepciones para su análisis. En este caso, se envía la notificación informando que la transacción causó una excepción, como se muestra en el ejemplo a continuación:

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "EXCEPTION"
}

Las notificaciones generadas por operaciones de Actualización (Update) no alteran el campo operation, y la sección "operation": "ENROLL" será igual para operaciones de registro y actualización.

Consulte el Manual del ETR para mayores detalles sobre el tratamiento de excepciones.

Tratamiento de Excepciones

El proceso de tratamiento de excepciones generará diferentes notificaciones de acuerdo con las decisiones tomadas. Esta sección presenta los flujos de notificación en el tratamiento de excepciones.

Excepción de Registro - Mismos Dedos

Esta decisión confirma que las biometrías en los dos registros son de la misma persona, por lo tanto la transacción entrante falla y se descarta. El endpoint de notificación, en este caso, recibirá una notificación indicando la decisión de tratamiento de excepción seguida de otra indicando la falla en la transacción de registro, como se muestra a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "SAME_FINGERS"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "FAILED"
}

Excepción de Registro - Dedos Diferentes

Esta decisión indica que el resultado fue un falso positivo, por lo tanto el entrante y el registro de referencia contienen conjuntos biométricos distintos. En este caso, el registro se efectuará, y la notificación que describe el tratamiento de la excepción será seguida por otra que indique el registro exitoso, como se muestra a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "DIFFERENT_FINGERS"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}

Tratamiento de Excepción - Fusionar Transacciones

Esta opción confirma que las biometrías en ambos registros son de la misma persona, pero decide fusionar el contenido biográfico y biométrico de los dos registros. En este caso, el registro se efectuará, y la notificación que describe el tratamiento de la excepción será seguida por otra que indique el registro exitoso, como se muestra a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "MERGE_TRANSACTIONS"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}

Tratamiento de Excepción - Recolectar de Nuevo

Esta decisión indica que hubo un error en el registro entrante, y que las biometrías deben ser recolectadas de nuevo. En este caso, la transacción entrante fallará. La notificación que indica la decisión de tratamiento de la excepción será seguida por la notificación que indica la falla de la transacción de registro, como se muestra a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "RECOLLECT"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "FAILED"
}

Excepción de Actualización - Mismos Dedos

Esta decisión indica que el no emparejamiento fue un falso negativo, y las biometrías en los dos registros son de la misma persona. Por lo tanto, la transacción entrante se registra con éxito. El endpoint de notificación recibirá una notificación indicando el tratamiento de la excepción seguida por la notificación de éxito de la transacción de actualización, como se muestra a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "SAME_FINGERS"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}

Excepción de Actualización - Dedos Diferentes

Esta decisión confirma que las biometrías en los dos registros no son de la misma persona, por lo tanto la transacción entrante falla y se descarta. El endpoint de notificación recibirá una notificación del tratamiento de excepción seguida por la notificación de falla de la transacción de actualización, como en el ejemplo a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "DIFFERENT_FINGERS"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "FAILED"
}

Excepción de Actualización - Recolectar de Nuevo

Esta decisión indica que hubo error en la toma de la transacción entrante, y que las biometrías necesitan ser recolectadas de nuevo. La transacción entrante fallará, y el endpoint de notificación recibirá una notificación de la decisión de tratamiento de la excepción seguida por la notificación de la falla de la transacción entrante, como se muestra a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "RECOLLECT"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "FAILED"
}

Excepción de Actualización - Registro Incorrecto

Esta decisión indica que hay un error en el registro de referencia, y que dicho registro debe ser descartado y reemplazado por la transacción entrante. La notificación que describe el tratamiento de la excepción será seguida por la notificación de éxito de la transacción de actualización, como en el ejemplo a continuación:

{
	"operation": "TREAT_EXCEPTION",
	"tguid": "<tguid>",
	"status": "OK",
	"treatment": "INCORRECT_ENROLL"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}

Emparejamiento con Latente No Resuelta

Al realizar una búsqueda contra una base de latentes no resueltas, cualquier emparejamiento encontrado generará notificaciones de emparejamiento inverso de latente (Reverse latent match), conteniendo el UGUID de la latente no resuelta (UL, Unsolved Latent) emparejada. La transacción de registro o actualización procederá normalmente, siendo comparada con la base de referencia. Esta búsqueda normal puede resultar en conclusión normal o generar excepción. El ejemplo a continuación muestra las notificaciones recibidas en una situación de emparejamiento de latente no resuelta seguida de registro exitoso:

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "REVERSE_LATENT_MATCH",
	"uguid": "<uguid>"
}

{
	"operation": "ENROLL",
	"tguid": "<tguid>",
	"status": "ENROLLED"
}