Sobre a Amostra de Pedido Síncrono IMS

A amostra de Pedido Síncrono IMS usa o nó IMSRequest. Para obter uma visão geral de como esse nó funciona e é configurado, consulte IBM Information Management System (IMS) na documentação do WebSphere Message Broker.

A amostra usa a transação Exibir Todas as Faturas (DSPALLI), que é uma transação de amostra do IMS geralmente instalada em um sistema IMS. Verifique com o seu administrador de sistema se ela está instalada antes de você tentar usar essa amostra. A transação DSPALLI pode ser configurada para executar um programa REXX (DFSSAM07) ou um programa COBOL (DFSSAM7) para recuperar detalhes sobre faturas. Embora esses programas desempenhem a mesma função e produzam os mesmos dados lógicos, eles possuem formatos físicos diferentes no cabo (por exemplo, campos de tamanhos diferentes e segmentos extras). Por padrão, o DSPALLI está configurado para usar o REXX. Você pode alterar o DSPALLI para usar o COBOL, mas você deve também compilar e conectar o programa COBOL porque ele não é enviado construído por completo. Essa amostra trabalha com ambos os programas. Use a versão REXX para introdução e para entendimento de como projetar fluxos de mensagens que usam o nó pedido. Entretanto, a versão COBOL executa-se mais rapidamente do que a versão REXX.

O fluxo de amostra exibe como um fluxo de mensagem WebSphere Message Broker pode ser projetado para interagir com um sistema IMS. Os dois elementos seguintes são importantes para considerar ao interagir com o IMS: É importante entender a distinção entre esses dois elementos porque a mensagem IMS em si não contém apenas dados a serem processados, mas também informação estrutural sobre o tamanho dos dados (dados LLZZ no início de cada segmento na mensagem), e metadados sobre como os dados devem ser processados (a transação ou nome do comando é a primeira parte dos dados). Para obter uma explicação sobre a estrutura dessas mensagens, consulte IBM Information Management System (IMS).

O nó IMSRequest fornece conectividade para o IMS Connect e permite a opção do modo cometer e nível de sincronização no qual a transação é executada. Na amostra, essas propriedades estão configuradas para valores padrão: o modo cometer é send_then_commit e o nível de sincronização é confirm. Esses valores são tipicamente usados ao desempenhar um pedido síncrono. O nó espera receber uma árvore de mensagens que possa serializar em uma mensagem IMS com LLZZ já configurado e roteia o fluxo de bits de resposta do IMS para o analisador configurado na guia Análise de Mensagem de Resposta do nó Request.

Estruturas de mensagem usadas pelo DSPALLI

A transação DSPALLI que é usada nessa amostra requer uma mensagem de entrada de segmento único e cria uma mensagem de saída de vários segmentos. O número de segmentos que são produzidos na saída pode variar dependendo do processamento no programa. Ao usar a versão REXX do programa, uma mensagem de êxito tem cinco segmentos no começo da mensagem que forma um cabeçalho, e um segmento por fatura sendo exibido. A versão COBOL tem três segmentos seguidos pelas faturas. Você pode diferenciar entre os dois formatos devido ao terceiro segmento do formato REXX não possuir dados e o formato COBOL conter dados. As informações nesse tópico referem-se apenas à versão COBOL, a menos que a versão REXX seja especificada, porque a maioria dos aplicativos são escritos em COBOL ao invés de REXX, e devido ao WebSphere Message Broker suportar a importação de copybooks COBOL, os quais facilitam o desenvolvimento do conjunto de mensagens necessário. Quando uma falha ocorre, apenas um segmento existirá na resposta do DSPALLI, a qual contém a causa da falha.

As estruturas de COBOL para a versão de COBOL estão contidas no programa SRC DFSSAM7. As estruturas são definidas aqui para cada segmento que o programa usa. Os três segmentos principais que essa amostra usa são:

Estruturas de dados para outros segmentos também existem nesse programa, mas elas são estruturas do cabeçalho que não são relevantes para essa amostra e, portanto, não precisam ser importadas. Aqueles segmentos podem permanecer sem análise, assim como o LL mais o resto dos dados.

O segmento TERM-IN-AREA é como muitos outros segmentos de entrada de transações que são pré-fixados pela transação:

006010 01 TERM-IN-AREA.                                               00350000
006020 02 CHAR-COUNT PICTURE S99 COMPUTATIONAL. 00360000
006030 02 FILLER PICTURE S99 COMPUTATIONAL. 00370000
006040 02 TRANS-CODE PICTURE X(7). 00380000
006050 02 MESSAGE-TEXT-START PICTURE X(125). 00380000

As estruturas chave são:

A mensagem de saída com êxito é feita de três seções de cabeçalho e uma seção de detalhes de repetição:

A amostra analisa apenas a seção de detalhes e deixa as seções de cabeçalho sem análise. A seção seguinte, Construindo um conjunto de mensagens MRM para DSPALLI, mostra como essa análise pode ser atingida no MRM. A amostra a seguir mostra as primeiras poucas linhas do segmento DETAIL-OUT; para a estrutura completa, consulte DFSSAM7.
010010 01 DETAIL-OUT.                                                 00900000
010020 02 DO-CHAR-CNT PICTURE S99 VALUE +84 COMP. 00910000
010030 02 FILLER PICTURE S99 VALUE +0 COMP. 00920000
010050 02 DO-LINE-CNT PICTURE Z9. 00930000
010055 02 FILLER PICTURE X VALUE '.'. 00940000
010060 02 FILLER PICTURE XX VALUE SPACES. 00950000
As estruturas chave são: O segmento final que a amostra usa é REJECT-MESSAGE, o qual ocorre quando a transação possui um problema em conseguir os detalhes de fatura (normalmente devido a um número de peça inválido):
015010 01 REJECT-MESSAGE.                                              01450000
015020 02 REJ-CHAR-CNT PICTURE S99 COMPUTATIONAL. 01460000
015030 02 FILLER PICTURE S99 COMPUTATIONAL VALUE +0. 01470000
015050 02 FILLER PICTURE X(8) VALUE '.PART = '. 01480000
015060 02 REJ-PN PICTURE X(16) VALUE SPACES. 01490000
015070 02 REJECT-REASON PICTURE X(110). 01500000
As estruturas chave são:

Construindo um conjunto de mensagens MRM para DSPALLI

Todas as estruturas de dados que são necessárias para o DSPALLI estão contidas no programa DFSSAM7. A primeira etapa na construção de um conjunto de mensagens MRM é importar as estruturas necessárias em um conjunto de mensagens usando o importador COBOL. As etapas são:

  1. Crie um novo conjunto de mensagens que tenha um formato físico binário referido como COBOL.
  2. Expanda o novo conjunto de mensagens, clique com o botão direito do mouse na pasta Definição de mensagem, e clique em Novo > Arquivo de definição de mensagem a partir do > arquivo COBOL.
  3. Navegue para localizar o arquivo DFSSAM7.cbl (qualquer um dos dois obtidos a partir de seu próprio sistema ou extraídos a partir do DFSSAM7).
  4. Clique em Avançar para exibir a tela Seleção de Mensagem e de Estrutura. Inclua as três estruturas TERM-IN-AREA, DETAIL-OUT e REJECT-MESSAGE na seção Importar Estrutura.
  5. Selecione as caixas de opção próximas ao TERM-IN-AREA e REJECT-MESSAGE para que os tipos de mensagem sejam criados para esses elementos. DETAIL-OUT não é um tipo de mensagem por si só, porque ele é apenas uma parte da mensagem de resposta. Não altere quaisquer outras opções.
  6. Clique em Próximo, em seguida clique em Concluir . Uma nova definição de mensagem referida como DSPALLI é criada e que contém dois tipos de mensagem: msg_TERMINAREA e msg_TERMINAREA.
A transação DSPALLI pode retornar estruturas diferentes com base no que acontece no programa (por exemplo, caso um erro ocorra). Para tratar essa situação, a amostra primeiramente analisa a resposta com uma estrutura geral, a qual quebra-a em segmentos, em seguida analisa-a novamente com a estrutura correta assim que ela tenha identificado qual estrutura usar. Para construir a estrutura de propósito geral (a qual pode ser usada para qualquer resposta de uma transação IMS), desempenhe as seguintes etapas:
  1. Abra a definição de mensagem DSPALLI no editor, clique com o botão direito do mouse em Mensagens e clique em Incluir mensagem.
  2. Nomeie a nova mensagem msg_IMSMessage.
  3. Clique com o botão direito do mouse em Tipos e clique em Incluir Tipo Complexo.
  4. Nomeie o tipo segmentType.
  5. Inclua um novo elemento chamado IMSSegment para msg_IMSMessage do tipo segmento. Assegure que possua um valor máx. de ocorrências igual a -1 (ilimitado).
  6. Inclua dois elementos locais para o tipo: um chamado LL e o outro chamado ZZdata. O campo LL deve ter um tipo de dados de int e o campo ZZdata deve ter um tipo de dados de string.
    Estrutura da IMSMessage
  7. Selecione o campo ZZdata e comute de Visão Geral para Propriedades.
  8. Altere a representação física COBOL de Extensão para Referência de Extensão.
  9. Configure o campo Referência de Extensão para LL.
  10. Selecione Referência de Extensão Inclusa porque o campo LL é da extensão de todo o segmento, incluindo o LL e o ZZ. Formato físico da mensagem IMS

Você pode agora usar o tipo de mensagem msg_IMSMessage para analisar qualquer mensagem de resposta IMS em segmentos individuais (mas não para analisar os segmentos por si mesmos). A amostra usa esse tipo de mensagem para analisar o retorno da resposta do sistema IMS e, em seguida, com base no número e tamanho dos segmentos, analisá-lo novamente com um outro tipo de mensagem.

O tipo de mensagem de erro msg_REJECTMESSAGE já foi definido para tratar das mensagens rejeitadas. O último tipo de mensagem que é necessário é o tipo de mensagem de êxito, o qual contém todos os segmentos DETAIL-OUT:

  1. Abra a definição de Mensagem DSPALLI no editor, clique com o botão direito do mouse em Mensagens, e clique em Incluir mensagem.
  2. Nomeie o novo tipo de mensagem msg_COBOLRESPONSE.
  3. Inclua dois elementos ao novo tipo: um chamado IMSSegment do tipo segmentType e outro chamado msg_DETAILOUT do tipo DETAILOUT.
  4. O IMSSegment deve ter uma ocorrência mínima e uma ocorrência máxima de 3 (para os três segmentos de cabeçalho que não foram analisados).
  5. O segmento msg_DETAILOUT deve ter ocorrências mínimas 0 e ocorrências máximas desvinculadas (-1). Estrutura de dados de resposta COBOL

Todas as estruturas de dados necessárias foram criadas. O fluxo de mensagens de amostra exibe como essas estruturas podem ser usadas para mapear documentos XML para pedidos IMS e, em seguida, para analisar as respostas IMS, as quais podem ser mapeadas de volta aos documentos XML.

Como Funciona o Fluxo de Mensagens

A função básica da amostra é pegar uma mensagem XML de uma fila do WebSphere MQ, transformá-la em um pedido IMS, executar a transação no IMS e formatar a resposta novamente para uma mensagem XML em um fila do WebSphere MQ. O diagrama a seguir mostra a aparência do fluxo de mensagens.

Fluxo de mensagens de pedido IMS

O processamento nó-por-nó é descrito na lista a seguir:

  1. O nó MQInput toma a mensagem da fila IMS_SYNC_REQUEST_IN1 e analisa-a com o analisador XML.
  2. O nó InputMapping mapeia a estrutura XML para a msg_TERMINAREA. O nó também calcula o valor LL, o qual não pode ser gerado automaticamente pelo tipo de mensagem.
  3. O nó Compute SaveMQMD salva o MQMD de forma que identificadores de mensagens e identificadores de correlação sejam salvos. (Esse nó pode ser omitido caso esteja usando outros transportes ou se os identificadores de mensagens e os identificadores de correlação não forem necessários na mensagem de resposta).
  4. O nó IMSRequest serializa os dados e envia os mesmos ao IMS para execução. O nó analisa o fluxo de bits em retorno pelo uso de tipo de mensagem genérica msg_IMSMessage, o qual divide o fluxo de bits em segmentos individuais.
  5. O Rejeitar? Nó Filtro conta o número de segmentos: se houver um segmento, a resposta é um erro; se houver mais do que um, ela é um sucesso.
  6. O subfluxo ProcessSuccessReponse causa a re-análise do fluxo de bits usando o formato msg_COBOLRESPONSE, e mapeia-o para tomar um formato XML.
  7. O subfluxo ProcessRejectResponse causa a re-análise do fluxo de bits usando o tipo de mensagem msg_REJECTMESSAGE, e mapeia-o para uma resposta XML.
  8. O nó RestoreMQMD Compute inclui o original MQMD.
  9. O nó MQOutput coloca a mensagem XML para enfileirar o IMS_SYNC_REQUEST_OUT1.
A parte mais importante do fluxo de mensagens é a análise da mensagem de resposta. Essa análise é complicada pelo fato de que as transações IMS não são fortemente classificadas e podem retornar qualquer número ou combinação de segmentos. O fluxo trata essa situação analisando primeiramente a resposta com um tipo de mensagem de segmento genérico, o qual trabalha para qualquer coisa que o nó IMSRequest possa retornar, em seguida, usando lógica em um nó Filtro (ou qualquer nó de roteamento) para enviar a mensagem para processamento dele, podendo analisá-lo novamente com um tipo bem conhecido. A lógica geral aqui pode ser usada com qualquer transação IMS, sustentado que as definições de segmento podem ser importadas (ou construídas manualmente) e alguns dados existem nos segmentos que auxiliam a identificar qual tipo de mensagem usar. O fluxo de mensagens usa nós ResetContentDescriptor para desempenhar a re-análise, mas a re-análise também pode ser desempenhada usando declarações ESQL.

Como um fluxo de mensagens trabalha com a versão REXX

A descrição precedente refere-se amplamente ao COBOL. O fluxo de mensagens também trabalha com a versão REXX do programa porque a versão REXX possui a mesma mensagem de entrada que o programa COBOL. A diferença principal está na mensagem de resposta. As duas principais diferenças entre as mensagens de resposta são:

A amostra, portanto, precisa de dois formatos de resposta: msg_COBOLRESPONSE e msg_REXXRESPONSE. A diferença principal entre esses formatos é que a versão REXX possui cinco segmentos de cabeçalho antes do segmento de detalhes. O segmento de detalhes é o mesmo, mas um novo formato físico REXX foi adicionado que negocia com diferentes tipos de dados. Quando analisando a resposta REXX, o tipo de mensagem msg_REXXRESPONSE com o formato REXX é usado.

Voltar para o Início da Amostra