Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

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.

Exibindo image.png

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.

...


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 Modified

...




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

Image Modified


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 Modified 
      •  
        • Depois:
      •          Image Modified
      •  
        • 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 da implementação e estimativa de horas. 

        • Erros colaterais.
        • Quebras no robô por conta do indRetif.
        • Problemas com cenários já controlados.
        • Teste de todos os cenários. 
        • 2 Semanas de codificação.
        • 2 semanas de teste com cenários envolvendo as linhas (geração da tag indRetif com todas as possibilidades do evento de afastamento)
        • .

...


  • 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><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 generica genérica eliminando a necessidade de duas funções na mesma rotina.

...

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

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 da implementação e estimativa de horas. 


6. Riscos e esforço da implementação

  1. Riscos
    1. Erros colaterais.
    2. Quebras no robô por conta

...

    1. do indRetif.
    2. Problemas com cenários já controlados.
    3. Teste de todos os cenários.
  1. Esforço para eventos periódicos, não periódicos e S-2230:
    1. 2 Semanas de codificação.
    2. 2 semanas de teste com cenários

...

    1. envolvendo as linhas (geração da tag indRetif com todas as possibilidades do evento de afastamento).
  1. Esforço para eventos de tabela :
    1. 3 dias por fonte.
    2. 4 dias de teste ( geração da tag de "

...

    1. inclusão e alteração").