Diagrama de Sequência Lógica

O diagrama de sequência a seguir é útil para entender a funcionalidade de Análise de Arquivo. A classe personalizada deve implementar as interfaces Java FileParser e FileParser2 descritas no jar SGG D1 para serem qualificadas como um analisador de arquivo. Para obter mais informações, consulte Interface FileParser e Interface FileParser2.

Este diagrama de sequência ilustra a funcionalidade Analisador de Arquivo.

Quando o Adaptador de Arquivo encontra um arquivo no diretório de entrada, instancia e chama GFP, que, por sua vez, inicia uma interação com o Analisador de Arquivo. A interação pode ser categorizada nas seguintes três fases:

  1. Instanciação e Inicialização

    • setProcessor()

    • setInputStream()

    • setStartPosition()

  2. Transação

    • getPosition()

    • getNextStream()

  3. Tratamento de Exceções

    • getCurrentInputPortion()

Fase de Instanciação e de Inicialização

O GFP é instanciado e recebe um Fluxo de Entrada quando um arquivo chega no diretório de entrada. Nesse ponto, uma instância do FP é instanciada. Certos métodos, conforme especificado acima, são chamados no FP para inicializar.

Fase de Transação

Depois de o FP ter sido inicializado, o GFP usa a instância do FP para gerar a estrutura de XML Simples. Isso acontece com a chamada do método getNextStream() no FP.

Em cada chamada, o FP retorna exatamente um XML simples. As chamadas do FP continuam, até que NULO seja retornado do FP. NULO indica o fim do arquivo e uma indicação de que a análise está concluída para um arquivo específico. O GFP para de chamar getNextStream() para um arquivo de entrada específico, quando recebe um NULO do FP.

O FP usa o fluxo de entrada do arquivo para ler o arquivo em partes. Poderia ler byte por byte ou linha por linha, mas no fim de cada chamada de método getNextStream() teria lido apenas o suficiente para criar uma estrutura de XML simples. Por exemplo, em um arquivo de entrada, se houvesse dados suficientes para apenas um XML Simples, a primeira chamada para getNextStream() retornaria um XML Simples e a próxima retornaria NULO. Mas se houvesse mais de uma, chamadas getNextStream() continuariam retornando estruturas XML Simples para cada parte de entrada, até que o fim do arquivo seja atingido.

Fase de Tratamento de Exceção

O tratamento de exceção dentro do FP pode ser categorizado em duas fases: Reativa e Recuperação:

Fase Reativa

Essa fase envolve pegar uma exceção e relatá-la para o GFP. Ela é atingida chamando o método saveInvalidRow() no GFP (this.fileProcessor).

Observe que, quando ocorre uma exceção, nenhuma análise adicional é feita e NULO é repassado de getNextStream().

Se houver falha em retornar NULO, erros como "Resultado bom e ruim retornado pelo Analisador de Arquivo" podem ser encontrados no registro do servidor do Weblogic.

Quando uma exceção é relatada para o GFP, ela faz três coisas:

  1. Cria uma carga útil de XML D1-PayloadErrorNotif e a passa para o fluxo de mensagens do OSB. A mensagem é publicada na Fila de Notificações do PPS interno do projeto OSB BASE.

  2. Ela incrementa a variável "ocorreu erro de transação" chamando o método do utilitário dentro do jar D1. Todos os erros que ocorrem durante a análise de um arquivo são capturados e relatados pela mensagem D1-PayloadSummary, que é, novamente, publicada na Fila de Notificações.

  3. Finalmente, cria um arquivo de dados com o diretório do erro com a parte de dados brutos que é lida quando o erro ocorreu. Também cria um arquivo RFD (Rejected File Descriptor, Descritor de Arquivo Rejeitado). A parte da entrada bruta está disponível utilizando o método getCurrentInputPortion(), que é discutido a seguir.

Conforme observado na imagem acima, o método saveInvalidRow() utiliza três parâmetros de entrada:

  1. A posição na qual a análise foi iniciada. Será escrito em um arquivo RFD. Isso é útil para identificar o local de um erro no arquivo de entrada.

  2. Os dados brutos que serão escritos no arquivo de dados do erro. Deve estar no mesmo formato que o arquivo de entrada e deve conter dados que são lidos desde que a chamada do método getNextStream() foi iniciada. Permitirá correção de dados com problema e colocará o arquivo "corrigido" em uma pasta de entrada para reprocessamento adicional.

  3. A mensagem de erro que é relatada na mensagem D1-PayloadErrorNotif. Observe que o conteúdo da mensagem de erro tem que ser definido pelo desenvolvedor do analisador de arquivo.

Fase de Recuperação

Essa fase não deve ser confundida com a recuperação de uma exceção tratada discutida acima. Esse caso ocorre quando a análise de arquivo é completamente interrompida por falha de energia ou interrupção da rede.

Preparação para recuperação: O GFP mantém um índice interno para a posição de leitura atual do arquivo. Isso é conseguido pelo GFP chamando o método getPosition() no FP, antes de cada chamada do método getNextStream().

Esta captura de tela mostra como o método getPosition() é chamado por GFP.

Recuperação: No caso de uma interrupção e posterior restauração, o GFP define a posição inicial no Analisador de Arquivo. Por exemplo, se a falha tivesse ocorrido no byte 415, a posição inicial seria definida como 415, para que o FP comece a ler a partir desse ponto e não de 0. O valor 415 pode ser mencionado como o ponto de recuperação.

Esta captura mostra como o GFP define a posição inicial no Analisador de Arquivo.

Quando o analisador de arquivo começar a analisar novamente, duas coisas devem ocorrer para garantir que ele comece a analisar a partir do ponto de recuperação:

  1. Armazene o ponto de recuperação no campo startPosition.

  2. Incorpore ignorar lógica para iniciar o ponteiro a partir do ponto de recuperação.