Histórico da Página

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

...

O principal objetivo desta estória é, ao final, ter solucionado em definitivo os seguintes pontos:

• Estabilidade e resiliência dos serviços de sincronismo com a SEFAZ (mde-worker e mde-dispatcher), para NF-e recebidas;
• Não existir gargalo neste processamento, fazendo com que o tempo de consulta não ser maior do que 15 minutos após data estimada para próxima sincronização.

MDE-DISPATCHER

Será realizada mudança no serviço mde-dispatcher para remover dele a responsabilidade de sincronizar NF-e recebidas junto a SEFAZ. Este serviço receberá duas novas atribuições em contrapartida:

• Encaminhar pedidos de sincronização para uma fila de processamento para que o mde-worker realize essa consulta;
• Encaminhar pedidos de conversão de NSU's recebidos pelo sincronismo, para NF-e recebidas, para que o mde-worker realize essa ação.

Hoje esse serviço realiza leitura de repositório de dados buscando por sincronizações a realizar que já estejam aptas (estas são agendadas de 1 em 1 hora), e já realiza a comunicação com a SEFAZ. Este tipo de composição impede que este serviço seja escalado caso haja uma demanda alta, o que ocasiona um gargalo nas sincronizações. A ideia então é transformar o serviço em questão em um gerenciador das atividades a serem executadas pelo mde-worker. Além disso, melhorias e revisões de codificações serão realizadas para efeito de melhoria em estabilidade e performance.

MDE-WORKER

O serviço mde-worker, portanto, receberá duas atribuições:

• Processar os pedidos de sincronização realizando requisições junto à SEFAZ e guardando os NSU's recebidos;
• Processar os pedidos de conversão de NSU's transformando arquivo recebido pela SEFAZ em uma NF-e recebida dentro do TOTVS Transmite

Hoje esse serviço já realiza o segundo passo, porém, realizando o consumo dos NSU's diretamente do repositório de dados. Como trata-se de composição semelhante ao que tínhamos no mde-dispatcher, também este não podia ser escalado. Como nesta nova arquitetura o ponto de entrada não é mais uma base de dados e sim uma fila de mensageria a escala dos dois processos se torna possível, aumentando a performance do processo. Além disso assim como no serviço anterior, melhorias e revisões das codificações serão realizadas, visando além da performance a melhoria em estabilidade.

03. SOLUÇÃO

MDE-DISPATCHER

Realizou-se as mudanças no serviço mde-dispatcher:

1. Remoção do processo que realiza a sincronização de documentos junto a SEFAZ, movendo este para processo no mde-worker;
2. Criação de processo que encaminha pedidos de sincronização para uma fila de processamento para que o mde-worker realize essa consulta;
3. Criação de processo que encaminha pedidos de conversão de NSU's recebidos pelo sincronismo, para NF-e recebidas, para que o mde-worker realize essa ação;
4. Revisão geral do fonte e ajustes para melhoria de estabilidade e performance.

MDE-WORKER

Realizou-se as mudanças a seguir, no serviço mde-worker:

...

1. Criação de processo que recebe pedidos via fila de mensageria realizando sincronismo junto à SEFAZ e guardando os NSU's recebidos

...

1. ;
   1. Neste processo, caso a NSU seja um resumo, será encaminhada uma requisição, via mensageria, para a realização de ciência automática (fluxo existente que será movido do mail-worker para o nfe-worker nessa reestruturação);
2. Ajuste no processo que realiza a

...

1. conversão de NSU's, transformando arquivo recebido pela SEFAZ em uma NF-e recebida dentro do TOTVS Transmite.

Hoje esse serviço já realiza o segundo passo, porém, realizando o consumo dos NSU's diretamente do repositório de dados. Como trata-se de composição semelhante ao que tínhamos no mde-dispatcher, também este não podia ser escalado. Como nesta nova arquitetura o ponto de entrada não é mais uma base de dados e sim uma fila de mensageria a escala dos dois processos se torna possível, aumentando a performance do processo. Além disso assim como no serviço anterior, melhorias e revisões das codificações serão realizadas, visando além da performance a melhoria em estabilidade.

NFE-WORKER

O serviço mde-worker, portanto, receberá duas atribuições:

• Processar os pedidos de sincronização realizando requisições junto à SEFAZ e guardando os NSU's recebidos;
• Processar os pedidos de conversão de NSU's transformando arquivo recebido pela SEFAZ em uma NF-e recebida dentro do TOTVS Transmite

Realizou-se as mudanças a seguir, no serviço nfe-worker:

1. Criação de processo que recebe os pedidos de ciência automática, realizando requisição junto à SEFAZ, atualizando a NF-e recebida com o evento;
   1. Caso o retorno seja de sucesso, será encaminhada uma requisição, via mensageria, para realização de consulta por documento completo (fluxo existente que será movido do mail-worker para o nfe-worker nessa reestruturação);
2. Criação de processo que recebe os pedidos de obtenção de documento completo, realizando requisição junto à SEFAZ, atualizando a NF-e recebida caso a nota completa esteja disponível.

Este serviço está recebendo funções que dizem respeito a NF-e, como parte do trabalho de centralização de operações nos workers correspondentes ao documento fiscalHoje esse serviço já realiza o segundo passo, porém, realizando o consumo dos NSU's diretamente do repositório de dados. Como trata-se de composição semelhante ao que tínhamos no mde-dispatcher, também este não podia ser escalado. Como nesta nova arquitetura o ponto de entrada não é mais uma base de dados e sim uma fila de mensageria a escala dos dois processos se torna possível, aumentando a performance do processo. Além disso assim como no serviço anterior, melhorias e revisões das codificações serão realizadas, visando além da performance a melhoria em estabilidade.

04. DEMAIS INFORMAÇÕES

• Não Há.

05. ASSUNTOS RELACIONADOS

• Não Há.