Projeto Interno

O objetivo deste guia é ajudar os membros da equipe a entender a composição do projeto e como nos organizamos para planejar, desenvolver, testar e documentar o TAF TSI.
A documentação oficial publicada para os clientes consta em TSI - TAF Service Integration.
O projeto consta no diretório: .../Master/Fontes/TAF/Integração/TSI, sendo composto por fontes na raiz (genéricos) , subpasta ERP (extração dos módulos do protheus) e subpasta TAF (APIS que fazem operações nas tabelas legados do TAF).
O controle com o nome dos fontes, descrição e analista que desenvolveram o TSI, fica disponível no google docs \Tabelas TAF.
Atualmente o pacote centralizador do TSI no AtuSx é o 009134 (release 33). Aqui tem a criação dos campos stamp nas tabelas do TAF e a criação da tabela de log V5R.
Pontos de melhorias, dúvidas ou discussões sobre a execução, podem ser colocados no dontpad do TSI, para posterior implementação, se necessário expor em review ou retrospectiva.

Divisão na execução

Quando é necessário criar um novo leiaute no TSI, precisamos trabalhar em alguns pontos, são eles:

Extração do ERP

Aqui é contemplado a regra de extração apenas do ERP Protheus, que em muito(s) casos a(s) regra(s) consta(m) nos extratores:

• extrator fiscal (...\Master\Fontes\Livros Fiscais\Extrator\ExtFisxTaf.prw),
• extrator financeiro(...\Master\Fontes\Adm\FINA989.prw) ou
• extrator contábil (...\Master\Fontes\Adm\ECD\CTBS001.prw e CTBS103.prw).

1. Entender e elaborar a regra de extração.
   
   

2. Nessa etapa são levantados todos os campos necessários na extração,  a planilha interna com o layout consta em google drive em Layout TAF.xlsx
   
   
3. Aqui também é necessário utilizar o pacote centralizador do TSI no atusx, para criar o campo STAMP na tabela legado do SIGATAF.
   
   
4. Conforme DOD dessa tarefa, aqui também é esperado a geração do JSON com o conteúdo dos campos do layout nas tags pré definidas para integração.
   
   
5. Controle do Stamp criado na Tabela do ERP e Mecanismo de validação do STAMP entre Protheus x TAF finalizado.

Integração ERP e TAF ( Json x Hash )

Etapa onde o layout já está sendo extraído pelo TSI (geração do json mencionado na etapa 4 da extração do ERP) e agora será construído a integração das informações para o TAF.

1. Construir Hash do JSON para o TAF pai, filho e netos (se houver), o modelo dos fontes com hash consta em TAF\Integração\TSI\TAF\WSTAFXXX.prw.
   
   
2. Realizar o processo de gravação dos dados através de um mecanismo que irá receber o JSON e realizar a integração com o TAF (motor cadastro básico TAFA565 ou motor pai, filho e netos TAFA585).
   
   Iremos instanciar o modelo do respectivo cadastro que será integrado e alimentá-lo com as informações extraídas do Protheus,
   após isso validar se o Commit foi possível, se sim grava o campo TAFSTAMP com o mesmo valor do STAMP trazido do Protheus
   para o respectivo evento ( precisa ser a última instrução da função ), caso não seja possível a integração gravar a tabela de "Erros de Integração TSI" (Tabela V5R),
   veja em estrura de log, os principais tipos a serem validados.
   
   ( Ponto de atenção: não é necessário instanciar o modelo a cada novo registro de integração ).
   
   Todo o processo acima precisa estar dentro de controle de transação, ou seja, se cair a conexão durante o processo
   o campo TAFSTAMP não será preenchido e o registro será reintegrado no novo processamento do TSI.
   
   Para auxiliar a equipe de suporte, ou na análise de um possível problema, devemos avaliar pontos onde é válido adicionar conouts (TAFCONOUT),
   para podermos rastrear de forma mais simples até onde o processamento chegou em caso de travamento, erros etc.
3. Colocar a rotina dentro do Schedule ( TAFA573 ).

Construção de APIS

Open API

Fontes e Tabelas

Processos

Estrutura HashMap

O hash é montado nos fontes que constam na pasta TAF\Integração\TSI\TAF (API TSI).
Para cada pai, possuímos o hash com informações genéricas para auxiliar na gravação do modelo.
Para cada tabela possuímos um hash com o "de/para" ( Tag x Campo).
Todos os hashs são estáticos, ou seja a estrutura é montada apenas no início do chamado do programa.

• Exemplo de Informações Genéricas
  
  HMSet( oHash, 'm_o_d_e_l_' , 'TAFA062' )
  HMSet( oHash, 'm_o_d_e_l_C_2_0_', 'MODEL_C20' )
  HMSet( oHash, 's_o_u_r_c_e_' , 'TAFA062' )
  HMSet( oHash, 'a_r_e_a_' , 'C20' )
  HMSet( oHash, 'o_r_d_e_r_' , 1 )
  HMSet( oHash, 'k_e_y_' , cKey )
  HMSet( oHash, 's_e_e_k_' , cSeek )
  HMSet( oHash, 't_a_g_i_d_' , 'invoiceId' )
  
  Para cadastros ou movimentos, na estrutura pai, filho e neto, existem as tags de o model, submodel e submodel2, exemplo na utilização da apuração de ICMS:
  HMSet(oHash, 'm_o_d_e_l_' , 'MODEL_C2S')
  HMSet(oHash, 's_u_b_m_o_d_e_l_' , {{'MODEL_C2T'/*model filho*/,'adjustmentApuration' /* tag filho*/, 'HashC2T()' /* hash filho*/ }} )
  HMSet(oHash, 's_u_b_m_o_d_e_l_2' , {{'adjustmentApuration'/* tag filho*/,'MODEL_T02'/*model neto*/,'accumulatedAdjust'/*tag neto*/, 'HashT02()' /*hash neto*/}} )
  
  
• Exemplo com "de/para"
  
  Apenas o campo:          SetHashKey(oHashC20, "taxDocumentNumber" ,"C20_NUMDOC" )
  Com consulta padrão:  SetHashKey(oHashC20, "participatingCode"         ,"C20_CODPAR#F3#")
  Tipo data:                      SetHashKey(oHashC20, "fiscalDocumentDate"      ,"C20_DTDOC#DT#" )

Estrutura LOG

Os erros são aglutinados e gravados em uma única linha na V5R substituindo o erro anterior caso exista.
Incluir VLDDATA para tratamento nos mesmos moldes do que foi feito no cadastro de nota fiscal.
Erros sendo gravados aglutinados por chave do cadastro;
Filial sendo gravada no campo V5R_CODFIL e não na V5R_REGCHAVE
Quando já existir um erro anterior para a chave o mesmo deve ser substituído pelo novo erro aglutinado encontrado;