...

Atualmente, as integrações via XML do TAF estão apresentando inconsistências nos padrões. Alguns eventos seguem as regras do indRetif corretamente, enquanto outros não estão em conformidade com essas regras. É importante garantir que todas as integrações estejam em conformidade com os padrões estabelecidos para evitar problemas futuros. Recomenda-se revisar e ajustar os eventos que não estão respeitando as regras do indRetif, garantindo consistência em todas as integrações via XML do TAF.

3. Novo padrão sugerido

Uma análise técnica foi realizada para abordar a questão dos eventos que estão fora do padrão em relação ao indRetif. A análise teve como objetivo identificar as alterações necessárias para adequar esses eventos aos padrões estabelecidos. Recomenda-se aplicar as alterações propostas para corrigir os eventos que não estão em conformidade e garantir que todos os eventos sigam corretamente as regras do indRetif. Isso ajudará a manter a consistência e a conformidade nas integrações via XML do TAF.

...

5. Proposta de Implementação

...

• Alteração do evento S-2230 para aceitar o indRetif igual a 1 quando o evento não estiver transmitido. (Aceitar indRetif igual a 2, apenas para eventos transmitidos)

Para o evento S-2230 no cenário utilizando o tafkey como maneira de inclusão já temos um padrão em relação ao indRetif que é representado pela variável nOpc.

 Hoje no ambiente do taf quando realizamos a inclusão com indRetif com o valor '1' o nOpc tende a ser 3 e indRetif com o valor '2' ser nOpc tende a ser 4, logo se realizarmos uma inclusão para se comportar como alteração deveremos mudar o nOpc para 4.

 Para realizar a alteração podemos utilizar a função padrão FTafVlOpe, que valida se a operação pode ser realizada na integração.

Image Added

Na função TAFregStat iremos realizar a mudança do nOpc de acordo com a regra que foi estabelecida.

Image Added

Para a implementação da mudança do nOpc funcionar corretamente, deveremos antes da chamada da função FTafVldOpe.

• • • • Eliminar qualquer mudança de nOpc antes da chamada da função FTafVldOpe, assim como validações que impliquem na mudança do mesmo.
      • Consequentemente irá ocorrer alteração na montagem da chave do afastamento, sua busca hoje em alguns cenários está redundante
      •                    
    •            Antes : 
      • Image Added 
    •  
      • Depois:
    •          Image Added
    •  
      • Melhorar a busca de registros já na base.
      • Eliminar avisos de erro que não são necessários por conta de ser responsabilidade da FTafVldOpe.

Riscos e esforço da implementação

1. 1. 1. 1. Riscos

            1. Erros colaterais.
            2. Quebras no robô por conta do indRetif.
            3. Problemas com cenários já controlados.
            4. Teste de todos os cenários.

         2. Esforço para o evento S-2230:

            1. 2 Semanas de codificação equivalente a 80 horas.
            2. 2 semanas de teste com cenários envolvendo as linhas (geração da tag indRetif com todas as possibilidades do evento de afastamento) equivalente a 80 horas.

• Alteração de todos os eventos para aceitar o indRetif igual a 1 quando os eventos não estiverem transmitidos. (Aceitar indRetif igual a 2, apenas para eventos transmitidos).

Para os demais eventos como maneira de inclusão já temos um padrão em relação ao indRetif que é representado pela variável nOpc.

 Hoje no ambiente do taf quando realizamos a inclusão com indRetif com o valor '1' o nOpc tende a ser 3 e indRetif com o valor '2' ser nOpc tende a ser 4, logo se realizarmos uma inclusão para se comportar como alteração deveremos mudar o nOpc para 4.

 Para realizar a alteração podemos utilizar a função padrão FTafVlOpe, que valida se a operação pode ser realizada na integração.

Image Added

Na função TAFregStat iremos realizar a mudança do nOpc de acordo com a regra que foi estabelecida.

Image Added

Para a implementação da mudança do nOpc funcionar corretamente, deveremos antes da chamada da função FTafVldOpe.

• • • • Eliminar qualquer mudança de nOpc antes da chamada da função FTafVldOpe, assim como validações que impliquem na mudança do mesmo.
      • Eliminar avisos de erro que não são necessários por conta de ser responsabilidade da FTafVldOpe.

Riscos e esforço da implementação

1. 1. 1. 1. Riscos

            1. Erros colaterais.
            2. Quebras no robô por conta do indRetif.
            3. Problemas com cenários já controlados.
            4. Teste de todos os cenários.

         2. Esforço para os demais eventos :

            1. 1 Semana de codificação equivalente a 40 horas por evento em separado.
            2. 1 semana de teste com cenários envolvendo as linhas equivalente a 40 horas.

• Alteração dos eventos de tabela para aceitarem a tag de inclusão somente se o evento não estiver transmitido para o governo, a partir da transmissão uma alteração de um evento sobre uma mesma chave deve ser utilizado a tag de alteração. 

Utilizando o evento S-1010 como escopo de trabalho para alteração e levando em conta o comportamento do nOpc para eventos de tabela, quando utilizamos a tag de "<Inclusão>" o nOpc é igual a 3 e "Alteração" igual  a 4, terá que ser realizada as seguintes alterações.

Eliminação da função VldEvTab, hoje temos a validação da FTafVlOpe que pode ser usada de forma genérica eliminando a necessidade de duas funções na mesma rotina.

Image Added

Utilizar a função padrão FTafVlOpe que valida se a operação pode ser realizada na integração.

Image Added

Na função TAFregStat iremos realizar a mudança do nOpc de acordo com a regra que foi estabelecida.

Image Added

 Riscos e esforço da implementação

1. 1. 1. Riscos

         1. Erros colaterais.
         2. Quebras no robô por conta do indRetif.
         3. Problemas com cenários já controlados.
         4. Teste de todos os cenários.

      2. Esforço para eventos de tabela :

         1. 3 dias por fonte equivalente a 24 horas.
         2. 4 dias de teste ( geração da tag de "inclusão e alteração") equivalente a 32 horas.