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:
- A conexão e a interação com o IMS Connect
- A construção da mensagem IMS que é usada para acionar uma transação
IMS (ou comando)
É 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:
- TERM-IN-AREA. O segmento de entrada que contém o nome da
transação e dados a serem processados
- DETAIL-OUT. O segmento que é repetido para cada fatura e
contém os detalhes para cada fatura
- REJECT-MESSAGE. O segmento que é usado para retornar uma mensagem de
erro quando a transação falha em executar corretamente
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:
- CHAR-COUNT: O campo LL. O programa pode fornecer qualquer nome para esse campo
(neste caso, CHAR-COUNT) e é sempre o tipo de dados S99.
- FILLER: O campo ZZ. O programa nunca usa este campo
mas deve permitir para o espaço que o campo usa no fluxo de bits.
Nesta instância, o programa
identificou-o como um campo filler.
- TRANS-CODE: A transação executada para chamar esse programa. O estado de regras padrão deste campo é do tamanho do código de transação
mais um caractere para um espaço, a menos que a transação contenha oito
caracteres. No caso do DISAPPI, o campo é do tamanho da
transação sem um espaço. O MESSAGE-TEXT-START deve, portanto,
iniciar com um espaço.
- MESSAGE-TEXT-START: Os dados de entrada, que têm 125 bytes de comprimento. Programas diferentes podem ter um tamanho diferente para este campo. O
tamanho máximo é de 32 KB. Quando uma definição de mensagem está sendo construída no MRM, é possível configurar
a propriedade Unidades de Comprimento para Fim do Fluxo de Bits,
em vez de configurar um valor específico para o comprimento deste campo.
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:
- HEADER-1-AREA
- HEADER-2-AREA
- HEADER-3-AREA
- DETAIL-OUT
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:
- DO-CHAR-CNT: O campo LL. Nenhuma convenção de nomenclatura existe para este campo.
Este é um segmento
de tamanho de campo e, portanto, sempre possui um tamanho de 84, o qual simplifica a construção de
um tipo de mensagem que modela este formato.
- FILLER: O primeiro filler é usado para dados ZZ. Os outros fillers existem para formatação. Muitas transações
não possuem os fillers de formatação porque elas dependem
do
MFS para formatação a um terminal final. O nó IMSRequest sempre
negocia com os dados de transação que não tenham sido convertidos por MFS.
- DO-LINE-CNT: Os dados do primeiro aplicativo na estrutura DETAIL-OUT. Este campo fornece o número de linha do segmento de
detalhes (várias instâncias desse segmento podem existir).
- ...: e assim por diante para todos os outros campos de dados do aplicativo.
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:
- REJ-CHAR-CNT: O campo LL.
- FILLER: O primeiro filler é usado para dados ZZ. Os
outros fillers existem para formatação. Muitas transações
não possuem os fillers de formatação porque elas dependem do MFS para
formatação a um terminal final. O nó IMSRequest sempre negocia com os
dados de transação que não tenham sido convertidos por MFS.
- REJ-PN: O código de razão para a falha. Este campo não é usado pela amostra.
- REJECT-REASON: O texto de razão para a rejeiçã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:
- Crie um novo conjunto de mensagens que tenha um formato físico binário
referido como COBOL.
- 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.
- 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).
- 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.
- 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.
- 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:
- Abra a definição de mensagem DSPALLI no editor, clique com o botão direito do mouse em
Mensagens e clique em Incluir mensagem.
- Nomeie a nova mensagem msg_IMSMessage.
- Clique com o botão direito do mouse em Tipos e clique em
Incluir Tipo Complexo.
- Nomeie o tipo segmentType.
- 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).
- 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.

- Selecione o campo ZZdata e comute de Visão Geral para Propriedades.
- Altere a representação física
COBOL de Extensão para Referência de Extensão.
- Configure o campo Referência de
Extensão para LL.
- Selecione Referência de Extensão Inclusa porque
o campo LL é da extensão de todo o segmento, incluindo o LL e o ZZ.
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:
- Abra a definição de Mensagem DSPALLI no editor, clique com o botão direito do mouse em
Mensagens, e clique em Incluir mensagem.
- Nomeie o novo tipo de mensagem
msg_COBOLRESPONSE.
- Inclua dois elementos ao novo tipo: um chamado
IMSSegment do tipo
segmentType e outro chamado msg_DETAILOUT do tipo
DETAILOUT.
- 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).
- O segmento msg_DETAILOUT deve ter ocorrências mínimas 0 e
ocorrências máximas desvinculadas (-1).
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.

O processamento nó-por-nó é descrito na lista a seguir:
- O nó MQInput toma a mensagem da fila
IMS_SYNC_REQUEST_IN1 e analisa-a com o analisador XML.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- O nó RestoreMQMD Compute inclui o original MQMD.
- 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:
- O REXX possui cinco segmentos de cabeçalho antes da seção de detalhes.
- A versão REXX possui formatos físicos diferentes para cada um dos
campos de dados (mas o mesmo número e tipos de campos).
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