Notification Flows
When GBDS performs enrollment and update operations, notifications are sent to designated endpoints to report their results. The entity responsible for this flow is called Notifier.
This document describes some notification flows during enrollment and update operations.
For additional information about notification flows during sequence control and quality control, consult the documentation of sequence control and quality control.
All notifications sent by the Notifier are HTTP POST to a configured endpoint (http://<address>:<port>), containing a JSON object. The JSON model for each notification is presented below.
The endpoint that will receive the notification must be implemented individually for each system.
Transaction Accepted
All asynchronous transactions received will be queued. After processing, a notification is sent indicating that the operation has been completed.
The notification message will be as in the example below:
{
"operation": "<operation>",
"tguid": "<tguid>",
"status": "ENROLLED"
}The possible operations in this step are: ENROLL, UPDATE, or SEARCH.
The notifier may return different statuses, depending on the type of transaction being performed. The possible final are:
Enroll/Update
ENROLLED, FAILED
Search
MATCH, NOT_MATCH, FAILED, PERSON_NOT_FOUND
The status FAILED occurs whenever a transaction is aborted or cannot be completed.
The status PERSON_NOT_FOUND occurs when a 1:1 search is received, but the reference profile does not exist for the provided key.
In some cases, GBDS identifies transactions that cannot be completed and require intervention. These cases generate different statuses and are described in the sections below.
Transaction Sent for Manual Review
In cases where GBDS identified issues related to sequence control or quality control, and the transaction was sent for manual review, a notification will be sent indicating that the enrollment is pending, as in the example below:
For additional information about notification flows during sequence control and quality control, consult the documentation of sequence control and quality control.
Consult the MIR Manual for more details on resolving transactions sent for manual review.
Transaction with Biometric Exception
If an exception is generated while processing the transaction, the incoming transaction will be sent to the exception handling for analysis. In this case, the notification is sent indicating that the transaction caused an exception, as shown in the example below:
Notifications generated by Update operations do not change the operation, and the section "operation": "ENROLL" will be the same for enrollment and update operations.
Consult the ETR Manual for more details on exception handling.
Exception Handling
The exception handling process will generate different notifications according to the decisions made. This section presents the notification flows in exception handling.
Enrollment Exception - Same Fingers
This decision confirms that the biometrics in the two records are of the same person, therefore the incoming transaction fails and is discarded. The notification endpoint, in this case, will receive a notification indicating the exception handling decision followed by another indicating the failure of the enrollment transaction, as shown below:
Enrollment Exception - Different Fingers
This decision indicates that the result was a false positive, therefore the incoming and reference records contain distinct biometric sets. In this case, the enrollment will be completed, and the notification describing the exception handling will be followed by another indicating successful enrollment, as shown below:
Exception Handling - Merge Transactions
This option confirms that the biometrics in both records are of the same person, but decides to merge the biographic and biometric content of the two records. In this case, the enrollment will be completed, and the notification describing the exception handling will be followed by another indicating successful enrollment, as shown below:
Exception Handling - Recollect
This decision indicates that there was an error in the incoming enrollment, and that the biometrics must be recollected. In this case, the incoming transaction will fail. The notification indicating the exception handling decision will be followed by the notification indicating the failure of the enrollment transaction, as shown below:
Update Exception - Same Fingers
This decision indicates that the non-match was a false negative, and the biometrics in the two records are of the same person. Therefore, the incoming transaction is successfully enrolled. The notification endpoint will receive a notification indicating the exception handling followed by the update transaction success notification, as shown below:
Update Exception - Different Fingers
This decision confirms that the biometrics in the two records are not of the same person, therefore the incoming transaction fails and is discarded. The notification endpoint will receive a notification of the exception handling followed by the update transaction failure notification, as in the example below:
Update Exception - Recollect
This decision indicates that there was an error in the collection of the incoming transaction, and that the biometrics need to be recollected. The incoming transaction will fail, and the notification endpoint will receive a notification of the exception handling decision followed by the notification of the incoming transaction failure, as shown below:
Update Exception - Incorrect Enrollment
This decision indicates that there is an error in the reference record, and that this record must be discarded and replaced by the incoming transaction. The notification describing the exception handling will be followed by the update transaction success notification, as in the example below:
Unresolved Latent Match
When performing a search against a database of unresolved latents, any matches found will generate reverse latent match notifications containing the UGUID of the matched unresolved latent (UL, Unsolved Latent). The enrollment or update transaction will proceed normally, being compared with the reference database. This normal search may result in normal completion or generate an exception. The example below shows the notifications received in a situation of an unresolved latent match followed by successful enrollment:
Last updated
Was this helpful?