1. Fluxos de Notificação do GBDS 4

Quando o GBDS realiza operações de cadastro (enroll) e atualização (update), notificações são enviadas para endpoints designados para informar seus resultados. A entidade responsável por este fluxo é chamada Notificador.

Este documento descreve alguns fluxos de notificação durante operações de cadastro e atualização.

See also

Para informações adicionais sobre fluxos de notificação durante controle de sequência e controle de qualidade, consulte a documentação de controle de sequência e controle de qualidade.

Note

Todas as notificatções enviadas pelo Notificador são HTTP POST para um endpoint configurado (http://<endereço>:<porta>), contendo um objeto JSON. O modelo do JSON para cada notificação está apresentado abaixo.

Warning

O endpoint que receberá a notificação deve ser implementado individualmente para cada sistema.

1.1. Transação Aceita

Todas as transações assíncronas recebidas serão enfileiradas. Após o processamento, uma notificação é enviada informando que a operação foi concluída.

A mensagem de notificação será como no exemplo abaixo:

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

Note

As possíveis operações neste passso são: ENROLL, UPDATE, or SEARCH.

Note

O notificador pode retornar status diferentes, conforme o tipo de transação sendo realizada. Os possíveis status finais são:

Operação	Status
Enroll/Update	ENROLLED, FAILED
Search	MATCH, NOT_MATCH, FAILED, PERSON_NOT_FOUND

O status FAILED ocorre sempre que uma transação for abortada our não puder ser finalizada.

O status PERSON_NOT_FOUND ocorre quando uma busca 1:1 é recebida, mas o perfil de referência não existe para a chave fornecida.

Em alguns casos, o GBDS identifica transações que não podem ser finalizadas e necessitam de intervenção. Estes casos geram diferentes status e estão descritos nas seções abaixo.

1.2. Transação Enviada para Revisão Manual

Nos casos em que o GBDS identificou problemas relacionados ao controle de sequência ou controle de qualidade, e a transação foi enviada para revisão manual, uma notificação será enviada indicando que o cadastro está pendente, como no exemplo abaixo:

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

See also

Para informações adicionais sobre fluxos de notificação durante controle de sequência e controle de qualidade, consulte a documentação de controle de sequência e controle de qualidade.

See also

Consulte o Manual do MIR para maiores detalhes sobre resolução de transações enviadas para revisão manual.

1.3. Transação com Exceção Biométrica

Se uma exceção for gerada ao processar a transação, a transação entrante será enviada ao tratamento de exceções para análise. Neste caso, a notificação é enviada informando que transação causou uma exceção, como mostrado no exemplo abaixo:

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

Note

Notificações geradas por operações de Atualização (Update) não alteram o campo “operation”, e a seção "operation": "ENROLL" será igual para operações de cadastro e atualização.

See also

Consulte o Manual do ETR para maiores detalhes sobre tratamento de exceções.

1.3.1. Tratamento de Exceções

O processo de tratamento de exceções gerará diferentes notificações de acordo com as decisões tomadas. Esta seção apresenta os fluxos de notificação no tratamento de exceções.

1.3.1.1. Exceção de Cadastro - Mesmos Dedos

Esta decisão confirma que as biometrias nos dois registros são da mesma pessoa, portanto a transação entrante falha e é descartada. O endpoint de notificação, neste caso, receberá uma notificação indicando a decisão de tratamento de exceção seguida de outra indicando a falha na transação de cadastro, como mostrado abaixo:

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

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

1.3.1.2. Exceção de Cadastro - Dedos Diferentes

Esta decisão indica que o resultado foi um falso positivo, portanto o entrante e o registro de referência contêm conjuntos biométricos distintos. Neste caso, o cadastro será efetivado, e a notificação descrevendo o tratamento da exceção será seguida por outra indicando o cadastro bem-sucedido, como mostrado abaixo:

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

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

1.3.1.3. Tratamento de Exceção - Fundir Transações

Esta opção confirma que as biometrias em ambos registros são da mesma pessoa, mas decide fundir o conteúdo biográfico e biométrico dos dois registros. Neste caso, o cadastro será efetivado, e a notificação descrevendo o tratamento da exceção será seguida por outra indicando o cadastro bem-sucedido, como mostrado abaixo:

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

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

1.3.1.4. Tratamento de Exceção - Recoletar

Esta decisão indica que houve um erro no cadastro entrante, e que as biometrias devem ser recoletadas. Neste caso, a transação entrante falhará. A notificação indicando a decisão de tratamento da exceção será seguida pela notificação indicando a falha da transação de cadastro, como mostrado a seguir:

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

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

1.3.1.5. Exceção de Atualização - Mesmos Dedos

Esta decisão indica que o não-casamento foi um falso negativo, e as biometrias nos dois registros são da mesma pessoa. Portanto, a transação entrante é cadastrada com sucesso. O endpoint de notificação receberá uma notificação indicando o tratamento da exceção seguida pela notificação de sucesso da transação de atualização, como mostrado abaixo:

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

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

1.3.1.6. Exceção de Atualização - Dedos Diferentes

Esta decisão confirma que as biometrias nos dois registros não são da mesma pessoa, portanto a transação entrante falha e é descartada. O endpoint de notificação receberá uma notificação do tratamento de exceção seguida pela notificação de falha da transação de atualização, como no exemplo abaixo:

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

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

1.3.1.7. Exceção de Atualização - Recoletar

Esta decisão indica que houve erro na coleta da transação entrante, e que as biometria precisam ser recoletadas. A transação entrante falhará, e o endpoint de notificação receberá uma notificação da decisão de tratamento da exceção seguida pela notificação da falha da transação entrante, como mostrado abaixo:

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

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

1.3.1.8. Exceção de Atualização - Cadastro Incorreto

Esta decisão indica que há um erro no registro de referência, e que este registro deve ser descartado e substituído pela transação entrante. A notificação descrevendo o tratamento da exceção será seguida pela notificação de sucesso da transação de atualização, como no exemplo abaixo:

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

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

1.4. Casamento com Latente Não Resolvida

Ao realizar uma busca contra uma base de latentes não resolvidas, quaisquer casamentos encontrados gerarão notificações de casamento reverso de latente (Reverse latent match), contendo o UGUID da latente não resolvida (UL, Unsolved Latent) casada. A transação de cadastro ou atualização prosseguirá normalmente, sendo comparada com a base referência. Esta busca normal pode resultar em conclusão normal ou gerar exceção. O exemplo abaixo mostra as notificações recebidas em uma situação de casamento de latente não resolvida seguida de cadastro bem-sucedido:

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

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