Skip to main content

Quando há integração com dispositivos biométricos externos, o Accelero precisa administrar problemas-de-envio-de-templates e retries. Esse serviço cuida dos retries.

Como funciona a gestão de pendências

Toda vez que é enviado um template facial (por exemplo) para um dispositivo, acontece a seguinte lógica:

  • é enviada uma mensagem MQTT para o gateway com as devidas instruções;
  • é criado registro na tabela integrationpendencies dizendo algo como "às 10h30 foi enviado template da pessoa 123 para o facial 890".

Quando o gateway responde para o Accelero dizendo "deu tudo certo", esse registro é excluído da tabela.

Quando o gateway responde para o Accelero dizendo "algo deu errado", daí é feito um tratamento do erro (FacialEnrollErrorHandler, assunto pra outro artigo) e a linha é mantida na tabela (talvez com alguns dados/instruções a mais gerados durante esse tratamento específico).

Com isso, essa tabela pode ser entendida da seguinte forma:

Pendências/cadastros que foram enviados para dispositivos externos e que não temos confirmação de sucesso.

Retry

Por padrão, o Accelero tenta fazer reenvios de pendências lendo essa tabela. A lógica básica é a seguinte:

  • busca um punhado de pendências que foram criadas há mais de 30 segundos;
  • pra cada uma delas, reenvia a pendência pro gateway e atualiza a tabela "somando um" na quantidade de retries daquela pendência.
  • se já houve mais de 3 reenvios, deixa a pendência na tabela pra deixar registrado que houve problema, mas marca pra não tentar novamente.

Esse processo acontece de 20 em 20 segundos, e "um punhado" significa "até 10 mensagens, mas podem ser mais que 10 pendências" (<MOTIVOS TÉCNICOS>, vide explicação mais abaixo).

Quando há essa "desistência de reenvio porque já tentou 3 vezes" é emitido um evento EventHandler com os objetos da Pessoa e a IntegrationPendency:

Accelero::getEventHandler()->emitEvent('facial_enroll_giveup', $pes, $ipe);

Garbage collector

De 30 em 30 minutos esse serviço executa um GC pra limpar pendências órfãs. Pendências órfãs são aquelas cujo dispositivo externo foi excluído do sistema (a tabela não tem um PKey, portanto isso não acontece automaticamente).

Agrupamento de mensagens

Como a comunicação com os dispositivos externos é feita através de um gateway, o Accelero é "esperto o suficiente" pra perceber que às vezes é possível agrupar algumas mensagens na hora de fazer essa comunicação.

Por exemplo, ao invés de enviar para o gateway:

Cadastre Joãozinho cuja foto é base64... no facial 123

Cadastre Joãozinho cuja foto é base64... no facial 456

Cadastre Joãozinho cuja foto é base64... no facial 789

O Accelero pode enviar

Cadastre Joãozinho cuja foto é base64... nos faciais 123, 456 e 789.

Isso é muito importante porque o dado comum entre as mensagens é a foto, que é grande. Economiza-se muito tráfego de dados dessa forma.

Quando o IntegrationPendencyRetrier vai fazer o reenvio de pendências, ele tenta fazer esse agrupamento da melhor forma possível pra ser eficiente.

Isso significa, por exemplo, que se houver 10 dispositivos no sistema e 10 pendências de reenvio, todas da mesma pessoa, talvez seja possível no limite transformar essas 10 pendências em uma única mensagem

Por esse motivo são enviadas "até 10 mensagens, mas podem ser mais que 10 pendências" a cada iteração, pois uma mensagem pode conter várias pendências.