WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Como o Broker Processa Arquivos

O broker lê arquivos com os nós FileInput, FTEInput, CDInput e FileRead e grava arquivos com os nós FileOutput, CDOutput e FTEOutput.

O WebSphere Message Broker pode ler mensagens dos arquivos e gravar mensagens nos arquivos, no sistema de arquivos local, ou em um sistema de arquivos de rede que é local para o broker. O seguinte lista os nós que fornecem essa capacidade e as permissões de acesso necessárias para os diretórios e arquivos nos quais eles operam:

Os nós FileInput, FileOutput e FileRead herdam as permissões designadas ao ID do usuário e ao grupo do broker. Consulte a documentação do seu sistema operacional para obter detalhes sobre como configurar permissões e o impacto no acesso a arquivos.

Você pode usar os nós FTEInput e FTEOutput para receber ou enviar arquivos para um destino em uma rede WebSphere MQ File Transfer Edition.

É possível usar os nós CDInput e CDOutput para receber ou enviar arquivos para um destino em uma rede do IBM® Sterling Connect:Direct.

Um arquivo, ou um registro dentro de um arquivo, é análogo a uma mensagem em uma fila. O diretório que contém o arquivo é análogo a uma fila de mensagens.

Como o broker lê um arquivo no início de um fluxo

O nó FileInput processa mensagens que são lidas a partir de arquivos. O nó FileInput pesquisa, em um diretório de entrada especificado (no sistema de arquivos conectado ao broker), os arquivos que atendem aos critérios especificados. O nó também pode procurar recursivamente os subdiretórios do diretório de entrada. Arquivos que atendam aos critérios são processados por ordem de idade, ou seja, os mais antigos são processados primeiro, independentemente de onde aparecerem na estrutura de diretório. Opcionalmente, os arquivos de um servidor FTP ou SFTP remoto podem ser movidos para o diretório local sempre que o diretório deve ser varrido. É possível localizar o arquivo necessário especificando um nome do arquivo explícito ou um padrão de nome do arquivo que inclua caracteres curingas. Se o arquivo estiver bloqueado, ele será ignorado durante a varredura de diretório. Também é possível excluir arquivos da leitura especificando um padrão de exclusão de arquivo. Se os arquivos são processados ou ignorados é determinado, em primeiro lugar, de acordo com o nome do arquivo ou o padrão e, em segundo lugar, de acordo com o padrão de exclusão do arquivo.

O nó FileInput cria um subdiretório mqsitransitin no diretório de entrada. O subdiretório mqsitransitin mantém e bloqueia os arquivos de entrada enquanto eles estão sendo processados. O broker lê o arquivo e propaga a mensagem ou as mensagens, usando o conteúdo do arquivo.

Se um grupo de execução que processa arquivos neste diretório de entrada for removido, verifique o subdiretório mqsitransitin para obter arquivos parcialmente processados ou não processados. Retorne todos os arquivos ao diretório de entrada e remova o prefixo UUID do grupo de execução dos nomes de arquivo, de modo que eles possam ser processados por um grupo de execução diferente. Para obter informações adicionais sobre o subdiretório mqsitransitin, consulte Como Múltiplos Nós de Arquivos Compartilham o Acesso a Arquivos no mesmo Diretório.

No nó FileInput, é possível especificar como os registros se derivam do arquivo. O conteúdo de um arquivo pode ser interpretado como:
  • Um único registro (arquivo inteiro)
  • Registros separados, cada um com comprimento fixo (registros de comprimento fixo)
  • Registros separados, cada um delimitado por um delimitador especificado (registros delimitados)
  • Registros separados que são reconhecidos por um analisador especificado (sequência de registros do analisador)

Após o arquivo ter sido processado com êxito, ele é excluído do sistema de arquivos ou movido para um subdiretório de archive do diretório (local) especificado.

Depois que o último registro do arquivo tiver sido processado com sucesso, o terminal End of Data do nó FileInput é conectado no fluxo de mensagem e uma mensagem de Fim de Dados é propagada para o terminal End of Data. A mensagem de Fim de Dados consiste em uma mensagem BLOB vazia e uma estrutura LocalEnvironment.File, e ela permite que o processamento de final do fluxo explícito seja executado em outra parte do fluxo de mensagem.

A mensagem (ou mensagens) propagada do arquivo pode ser usada como entrada para qualquer fluxo de mensagem e nó de saída. É possível criar um fluxo de mensagens que receba mensagens de arquivos e gere mensagens para clientes que utilizem qualquer um dos transportes suportados para conectar ao intermediário.

Sempre que uma mensagem é propagada a partir de um arquivo, o nó FileInput armazena informações sobre o arquivo na árvore de mensagem LocalEnvironment.File. Essas informações incluem o deslocamento do registro da mensagem no arquivo que está sendo processado e o número do registro nesse arquivo. Além disso, quando um curinga é usado em um padrão de nome de arquivo, os caracteres correspondidos no nome do arquivo são colocados no elemento WildcardMatch da árvore de ambiente local.

Se o arquivo voltar, ou um arquivo for deixado no subdiretório mqsitransitin porque o processamento falhou, remova o prefixo de UUID do grupo de execução do nome do arquivo e mova-o de volta para o diretório de entrada. É feita uma nova tentativa de processamento automaticamente, iniciando no primeiro registro no arquivo.

O nó de FTEInput recebe arquivos da rede WebSphere MQ File Transfer Edition. O broker lê o arquivo e propaga a mensagem ou as mensagens, usando o conteúdo do arquivo. Depois de um nó de FTEInput processar um arquivo, o arquivo é excluído. Para obter detalhes sobre as informações que o nó de FTEInput fornece no ambiente local, consulte Usando Variáveis de Ambiente Locais com Nós de Arquivo.

O nó de CDInput recebe arquivos da rede IBM Sterling Connect:Direct. O broker lê o arquivo e propaga a mensagem ou as mensagens, usando o conteúdo do arquivo. Depois que um nó CDInput processa um arquivo, o arquivo é excluído. Para obter detalhes sobre as informações que o nó de CDInput fornece no ambiente local, consulte Usando Variáveis de Ambiente Locais com Nós de Arquivo.

O nó FileRead pode ler um arquivo inteiro, ou um registro único, nominado. Um uso comum do nó FileRead é rotear ou enriquecer as mensagens com base no conteúdo do arquivo. Ao desenvolver o fluxo de mensagens, você pode especificar o nome e o local do arquivo a ser lido. Você pode substituir esses valores no tempo de execução com base no conteúdo de uma mensagem. O nó FileRead lê um arquivo no meio de um fluxo de mensagens.

O nó FileRead complementa os nós FileInput e FileOutput existentes.

Como o broker lê um arquivo do meio de um fluxo

O nó FileRead bloqueia arquivos quando eles estão sendo lidos e não move os arquivos para um subdiretório para lê-los. Os arquivos podem ser lidos de modo completo ou separado nos registros, da mesma maneira que o nó FileInput. Após o arquivo ter sido processado pelo nó FileRead, ele poderá ser excluído, arquivado ou ser deixado inalterado.

Como o Intermediário Grava um Arquivo

Os nós FileOutput, CDOutput e FTEOutput gravam mensagens em arquivos no sistema de arquivos do broker. Quando uma mensagem é recebida no terminal In do nó, ela cria e grava um arquivo como uma série de um ou mais registros. Um registro é gravado em um arquivo para cada mensagem recebida. O nome do arquivo é especificado por um padrão de nome do arquivo no nó ou um nome do arquivo explícito que é especificado no nó ou derivado da mensagem.

É possível especificar como os registros são acumulados nos arquivos:
  • Um único registro (arquivo inteiro). O arquivo que é criado consiste em um registro.
  • Registros concatenados (registros não modificados). Os registros não são preenchidos em nenhum comprimento necessário e não são separados por um delimitador.
  • Registros de comprimento uniforme (registros de comprimento fixo). Os registros que são mais curtos do que o comprimento especificado são preenchidos até o comprimento especificado.
  • Registros separados (registros delimitados). Os registros são terminados ou separados por um delimitador especificado.
O fluxo de mensagens informa ao nó de saída que não há mais registros a gravar enviando uma mensagem para seu terminal Finish File. O arquivo é fornecido no destino apropriado:
  • FileOutput: o arquivo é então movido para o diretório de saída especificado.

    Opcionalmente, o arquivo pode ser movido para um diretório em um servidor FTP ou SFTP remoto. O servidor é identificado pela propriedade Servidor Remoto e Porta no nó. Como alternativa, você pode substituir a propriedade de nó configurando um valor no ambiente local (consulte Substituições do Ambiente Local para o servidor remoto no nó FileOutput).

  • FTEOutput: o arquivo é enviado ao agente de destino na rede do WebSphere MQ File Transfer Edition.
  • CDOutput: O arquivo é enviado para a rede do IBM Sterling Connect:Direct.

Se o nó de saída produzir um único registro a partir do arquivo (arquivo inteiro), o arquivo será movido imediatamente para o diretório de saída sem precisar que uma mensagem seja propagada ao terminal Finish File. Neste caso, qualquer mensagem enviada o terminal Finish File do nó não tem efeito em nenhum arquivo, mas a mensagem ainda é propagada para um fluxo de mensagem anexado ao terminal End of Data.

Como os Dados São Anexados ao Final de um Arquivo Local

Há dois métodos de anexação a um arquivo local usando o nó FileOutput:
  • O primeiro método é gravar diretamente no diretório de saída. Cada registro gravado é anexado imediatamente ao arquivo especificado. O conteúdo do arquivo pode ser lido durante a gravação dos dados no arquivo. A ação Concluir Arquivo não é efetivada, a menos que sejam usadas opções de FTP. Se as opções de FTP forem usadas, a ação Concluir Arquivo transferirá o arquivo para a máquina remota.
  • O segundo método é migrar dados do arquivo no diretório mqsitransit. Os registros são coletados no arquivo. Se existir um arquivo no diretório de saída quando a ação Concluir Arquivo ocorrer, o arquivo será movido para o diretório de trânsito e os dados serão anexados ao final desse arquivo. O arquivo será retornado para o diretório de saída e os novos dados ficarão então visíveis para um aplicativo.

Na guia FTP, se Reter arquivo local e Migrar dados no diretório de trânsito estiverem selecionados, Ação se o arquivo existir ocorrerá na ação Concluir Arquivo.

Como os Dados São Anexados no Final de um Arquivo Remoto

O nó FileOutput constrói um arquivo no diretório de saída ou no diretório mqsitransit. Na guia FTP, se Ação se existir arquivo remoto for configurado como Anexar, quando a ação Concluir Arquivo ocorrer, o arquivo será transferido para a máquina remota usando o verbo Anexar do FTP. Os dados são anexados ao final do arquivo remoto ou, se o arquivo não existir, ele será criado.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:43


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ac55280_