[SOLAR] Estudo para avaliar a necessidade e complexidade de implementação no Govdoc de webhook para a assinatura
Data de elaboração | 02/08/2022. |
---|---|
Responsável pelo estudo |
|
Equipe do estudo | TURING |
Alvo | Sistema de Outorga e Licenciamento Ambiental de Rondônia (SOLAR) |
Origem |
|
Objetivo |
Avaliar possíveis opções para a implementação atualização em tempo real de detalhes do processo do SOLAR após assinatura de um documento no sistema GovDoc. |
Documentação correlata | |
Observações |
Webhook: é um recurso que possibilita o envio de dados em tempo real entre dois sistemas ou aplicativos distintos. |
1. Objetivo
Avaliar possíveis opções para a implementação atualização em tempo real de detalhes do processo do SOLAR após assinatura de um documento no sistema GovDoc.
2. Introdução
Quando um fiscal criar um parecer no processo o mesmo é redirecionado para o sistema GovDoc para preenchimento do documento e posteriormente a assinatura. Ao voltar para a tela de detalhes do processo dentro do SOLAR não é evidente para o usuário que a página precisa ser recarregada, para habilitar as ações que direcionam para as próximas etapas do processo.
Sendo assim existe a necessidade de um mecanismo que identifique que o documento já foi assinado e que recarregue a página de detalhes do processo.
3. Desenvolvimento
3.1 Resultado esperado
Descobrir a melhor forma de implementar uma função que atualize a página de detalhes do processo após a assinatura do documento no GovDoc.
3.2 Pesquisa
Em conversa com o time chegamos a conclusão que existem duas maneiras de fazer essa implantação, sendo elas:
1º Alternativa - Integração por Webhooks: Criar um serviço do tipo webhook na plataforma GovDoc, onde ao ser criado um novo documento através de integração de API seria fornecido o endereço de uma API de retorno, a qual o GovDoc deverá fazer uma chamada após assinatura do documento.
Para essa alternativa será necessário as seguintes alterações:
- Alterações no sistema GovDoc:
- Alterar a API no endpoint de criação de documentos para receber o endereço da API de retorno;
- Criar uma tabela de banco de dados para armazenar as Urls de Apis dos clientes;
- Criar uma tabela de banco de dados para armazenar qual documentos está atrelado com cada API;
- Alterar a rotina de alteração de status de um documento, para que, sempre que houver alterações no estado de um documento, realizar o envio dos detalhes para a API de retorno;
- Alterações no SOLAR:
- Criar uma API e endpoint que receberá o retorno com alteração de estado de documentos;
- Ao requisitar um novo documento ao GovDoc, enviar o endereço da API e endpoint que será aguardado o retorno de alteração de estado do documento;
- Implantar um sistema de Websockets para, ao receber o retorno do GovDoc, enviar uma notificação do back-end do SOLAR para o front-end. Considerando que a notificação deve ser enviada apenas para os clientes que estejam a tela aberta nos detalhes do processo, sugiro aqui usarmos a ferramenta SignalR para essa implantação;
- Alterar o front-end para receber eventos do websocket (SignalR);
- Adicionar ao front-end uma validação do evento recebido pelo websocket, quando for do tipo documento assinado e estiver na tela de detalhes, exibir um modal de atualização do processo;
- Criar uma modal no front-end para exibir para o usuário a mudança de estado do documento dando as opções de recarregar a página de detalhes ou manter como está, para que caso o usuário esteja fazendo alguma análise não atrapalhe o andamento da atividade.
2º Alternativa - Integração por Pooling: Alterar o front-end do SOLAR para criar um pooling na tela de detalhes do processo enquanto o processo estiver com status "Redigindo" fazer uma requisição em background para GovDoc e ao receber a resposta que o documento foi assinado pelo usuário exibir uma modal dando a opção de recarregar a página ou manter como está.
Para essa alternativa seria necessário as seguintes alterações:
- Alterações no SOLAR:
- Alterar o Front-end, tela de detalhes do processo, criando um looping de requisições a cada 1 minuto, quando o status do documento do parecer for "Redigindo", para solicitar o estado atual ao back-end do SOLAR.
- Criar um endpoint no Back-end do SOLAR que recebe o código do documento, verifica o estado do documento no GovDoc e retorna para o Front-end;
- Criar uma modal no Front-end que após receber a mudança de estado do documento é exibida para o usuário dando as opções de recarregar a página de detalhes ou manter como está, para que caso o usuário esteja fazendo alguma análise não atrapalhe o andamento da atividade.
4. Conclusão
Acreditamos que a integração entre os sistemas para retorno da informação de status de documentos pelo GovDoc é importante pois simplifica a usabilidade do sistema e torna mais fluido o processo e a experiência do cliente na plataforma.
Concluímos que a ambas as alternativas estudadas e apresentadas entregam um resultado satisfatório a nível de usabilidade para o cliente, entretanto podemos destacar pontos positivos e negativos a respeito de cada uma:
- 1º alternativa - Integração por Webhooks:
- Pontos Positivos:
- Só existe a comunicação entre as plataformas quando ocorre a alteração de estado do objeto, evitando consultas e requisições desnecessárias;
- Pontos Negativos:
- Esforço de desenvolvimento alto pois tem um nível alto de complexidade;
- Envolve alterações tanto nos sistemas GovDoc quando no sistema SOLAR;
- Necessidade de criação de estrutura de tabelas em base de dados e ferramentas de controle de estado.
- Pontos Positivos:
- 2º alternativa - Integração por Pooling
- Pontos Positivos:
- Oferece um caminho mais simples para a implantação;
- Esforço menor de desenvolvimento pois necessita apenas alterar apenas o projeto SOLAR;
- Pontos Negativos:
- Será feita uma maior quantidade de requisições para verificação de status de documento ao GovDoc, pois cada front-end que estiver aberto com um documento em estado "Redigindo" enviará uma requisição de tempos em tempo;
- Consequentemente maior consumo computacional;
- Pontos Positivos:
Nenhum comentário