01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

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:

• Remoção do processo que realiza a sincronização de documentos junto a SEFAZ, movendo este para processo no mde-worker;
• Criação de processo que encaminha pedidos de sincronização para uma fila de processamento para que o mde-worker realize essa consulta;
• 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;
• Revisão geral do fonte e ajustes para melhoria de estabilidade e performance.

MDE-WORKER

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

• Receber pedidos via fila de mensageria realizando sincronismo junto à SEFAZ e guardando os NSU's recebidos. Este processo encaminhará também para nova fila, processada pelo nfe-worker;
• 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.

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

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.

04. DEMAIS INFORMAÇÕES

• Não Há.

05. ASSUNTOS RELACIONADOS

• Não Há.