TOTVS Transmite

Páginas filhas
  • DSERTSS3-3705 - DT TRANSMITE - Refatorar Processos NF-e


01. DADOS GERAIS

Linha de Produto:

Linha Protheus

Segmento:

BackOffice

Módulo:TOTVS Transmite
Função:Não Há
País:Brasil
Ticket:Não Há
Requisito/Story/Issue (informe o requisito relacionado) :DSERTSS3-3705
Requisito/Story/Issue (informe o requisito relacionado) :


02. SITUAÇÃO/REQUISITO

Seguindo o trabalho realizado em algumas das API's, o objetivo dessa demanda é refatorar rotinas do projeto transmit-mde-worker relacionadas com o processo de sincronismo, com o intuito de evitar falhas na comunicação com a base de dados e garantir o registro adequado das NF-e recebidas sincronizadas.

Essa tarefa tem como escopo principal os serviços do projeto transmit-mde-worker, onde os pontos a guiar o desenvolvimento serão:

  • Manter a injeção de dependência da conexão do Mongo DB como Singleton;
  • Alterar a Injeção de dependência dos repositórios relacionados com o conceito Multitenancy para o modelo Scoped;
  • Garantir a abertura e fechamento das sessões com o Mongo DB;
  • Garantir a limpeza de memória de referências à objetos não mais utilizados pelas conexões;

03. SOLUÇÃO

A refatoração principal ocorreu no projeto transmit-nfe-domain, onde estão as classes e métodos utilizados no processo de sincronismo.

  • Implementação do novo modelo de repositório denominado BaseRepository, que já havia sido implementado nas API's portal-api e cte-api; 
  • Implementação de interface e classe no projeto transmit-framework para tratar o conceito de multitenancy nos serviços; 
  • Na injeção dos repositórios, a aplicação passou a instanciar a classe ContextMultitenancy respeitando o Tenant recebido na requisição via mensageria ou sessão TNF das chamadas, para devido posicionamento na base de dados do cliente;
  • Criação de novo modelo NFeRepository que herda do BaseRepository, para utilização nos fluxos que estão no escopo desta tarefa;
  • Injeção de dependência para as novas classes de repositório utilizando o modelo Scoped, que passará a criar um objeto em cada requisição recebida no serviço, realizando o posicionamento do repositório no banco de dados correspondente;
  • Preenchimento de propriedade durante a injeção de dependência do serviço de mensageria, para que seja possível identificar o nome do Pod no painel de conexões do Message Broker, facilitando o troubleshooting.

04. DEMAIS INFORMAÇÕES

  • Não Há.

05. ASSUNTOS RELACIONADOS

  • Não Há.