# Fluxos de Notificação 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. {% hint style="info" %} 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](/integracao-do-gbds/qualitycontrol.md). {% endhint %} {% hint style="info" %} Todas as notificações enviadas pelo Notificador são HTTP POST para um endpoint configurado (`http://:`), contendo um objeto JSON. O modelo do JSON para cada notificação está apresentado abaixo. {% endhint %} {% hint style="warning" %} O endpoint que receberá a notificação **deve ser implementado individualmente** para cada sistema. {% endhint %} ## 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: ```json { "operation": "", "tguid": "", "status": "ENROLLED" } ``` {% hint style="info" %} As possíveis operações neste passo são: `ENROLL`, `UPDATE`, or `SEARCH`. {% endhint %} 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. ## 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: ```json { "operation": "ENROLL", "tguid": "", "status": "PENDING" } ``` {% hint style="info" %} 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](/integracao-do-gbds/qualitycontrol.md). {% endhint %} {% hint style="info" %} Consulte o Manual do MIR para maiores detalhes sobre resolução de transações enviadas para revisão manual. {% endhint %} ## 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: ```json { "operation": "ENROLL", "tguid": "", "status": "EXCEPTION" } ``` {% hint style="info" %} 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. {% endhint %} {% hint style="info" %} Consulte o Manual do ETR para maiores detalhes sobre tratamento de exceções. {% endhint %} ### 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. #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "SAME_FINGERS" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "FAILED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "DIFFERENT_FINGERS" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "MERGE_TRANSACTIONS" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "RECOLLECT" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "FAILED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "SAME_FINGERS" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "DIFFERENT_FINGERS" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "FAILED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "RECOLLECT" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "FAILED" } ``` #### 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: ```json { "operation": "TREAT_EXCEPTION", "tguid": "", "status": "OK", "treatment": "INCORRECT_ENROLL" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` ## 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: ```json { "operation": "ENROLL", "tguid": "", "status": "REVERSE_LATENT_MATCH", "uguid": "" } ``` ```json { "operation": "ENROLL", "tguid": "", "status": "ENROLLED" } ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.griaule.com/integracao-do-gbds/notifier.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.