Os mapas de amostra demonstram os padrões de design que implementam uma variedade de cenários de intermediários. O design das ferramentas do mapa de mensagens permite que estes padrões de design sejam combinados juntos como padrões compostos. Isto permite mapas de mensagens para cenários complexos "to be authored" por padrões de design de montagem para cenários mais simples juntos. Os arquivos da amostra não foram planejados para serem implementáveis.
Os arquivos de amostra para processamento de montagens completas de mensagens estão localizados na pasta message_assembly no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
Uma montagem de mensagem é uma combinação de todos os cabeçalhos e corpo ou carga útil da mensagem. Os nós Mapping, DataInsert, DataUpdate, DataDelete e Extract em um fluxo de mensagem sempre manipula uma montagem completa de mensagem. Isto significa que o mapeamento para estes nós sempre mostra um modelo de montagem de mensagem como as origens e destinos de um mapa.
Existem dois modelos de montagem de mensagens no WebSphere Message Broker: o modelo simplificado Propriedades e o modelo completo Cabeçalhos. Escolha o modelo que corresponda aos requisitos de seu cenário. A figura à esquerda mostra o modelo Propriedades de uma montagem de mensagem e a figura à direita mostra o modelo Cabeçalhos.
A montagem de mensagem do WebSphere Message Broker inclui quatro itens, que estão numerados na figura:
Você pode configurar um fluxo de mensagens para executar um pulo Route To Label depois de um dos nós de mapeamento, isto é útil em cenários com roteamento baseado em conteúdo intra-fluxos.
Três cenários comuns são implementados nesta amostra:
Em todos os casos, o corpo ou a carga útil da mensagem aparece como o último item na montagem da mensagem.
Utilize o elemento labelName
de montagem da mensagem para controlar o roteamento
de uma mensagem depois de um nó de mapeamento. Isto é útil em cenários onde você deseja
selecionar os próximos nós do fluxo de mensagens para continuar o processamento a partir de
um mapa.
A figura a seguir mostra o arquivo RouteToLabelUsingMap.msgflow do fluxo de mensagens da amostra configurado com o nó Mapping, nó Route To Label e diversos nós Label de destino. As etiquetas de destino dos nós Label
são configuradas para serem iguais aos seus nomes.
Para selecionar qual nó Label processa a mensagem de saída, o mapa
deve especificar a propriedade Label Name do nó Label. O arquivo de mapeamento da amostra SetLabelNodeLabelName.msgmap manipula isso ao utilizar uma linha if
com duas condition
e um else
:
Nesta amostra:
$source/rtl:body/content
iguais a zero
serão processadas pelo recebimento de dados dos nós de fluxo a partir do nó Label
Target1;$source/rtl:body/content
maior do que
zero serão processadas pelo recebimento de dados dos nós de fluxo a partir do nó Label Target2;Freqüentemente um mapa foca exclusivamente no corpo de uma mensagem. Neste cenário, todos os cabeçalhos devem ser copiados sem alteração pelo mapa.
Utilize o modelo Propriedades para copiar sem alterar todos os cabeçalhos. Quando você seleciona o modelo de montagem de mensagem simplificado Propriedades, todos os cabeçalhos de mensagens, exceto a pasta Propriedades são copiados, na mesma ordem e sem alteração.
Uma vez que você criou um mapa de mensagens Properties, mapeie o elemento complexo $source/Properties
ao elemento complexo $target/Properties
. Isto causará a cópia da pasta Propriedades sem alteração da origem para o destino, junto com todos os outros cabeçalhos sem alteração.
A imagem abaixo mostra o arquivo de amostra CopyAllHeaders.msgmap configurado para copiar todos os cabeçalhos (incluindo Propriedades) sem alteração.
O modelo Propriedades ativa vários cenários de intermediários sem ter que lidar com a complexidade do mapeamento de vários cabeçalhos. Propriedades refina a maioria dos atributos de cabeçalho mais importantes para o MQ Series e para o analisador MRM e os apresenta em um pacote único. Além do cenário Copiar Todos os Cabeçalhos, utilize o modelo Propriedades em situações onde o MQ Series é a camada de transporte e o MRM é o analisador do corpo da mensagem. Estes atributos podem ser categorizados como:
Uma coisa a ser lembrada é que todos os campos em um modelo Propriedades
devem ser configurados. Se você precisar configurar qualquer campo único, por exemplo,
MessageFormat
para selecionar o formato de ligação da mensagem de saída, configure ou copie também os outros valores na pasta Propriedades
. Qualquer campo não configurado explicitamente não será copiado para a mensagem de saída.
O modelo Cabeçalhos
fornece a habilidade de mapear cabeçalhos selecionados
em adição às propriedades. Observe que o modelo Cabeçalhos
não suporta
o recurso "copiar todos os cabeçalhos": qualquer cabeçalho que não seja
mapeado explicitamente não será criado como parte do destino.
Os Cabeçalhos são categorizados como cabeçalhos MQMD, MQ, HTTP e JMS. Utilize o
modelo Cabeçalhos
para cenários JMS, SOAP sobre JMS e HTTP. Utilize
o modelo Cabeçalhos
para cenários do MQ quando o modelo
Propriedades
não fornecer o controle necessário.
Compute
ESQL para chamar o mapa,
conforme descrito abaixo.Compute
ESQL para chamar
o mapa, conforme descrito abaixo.Os arquivos de amostra para vários cenários de mensagens de saída estão localizados na pasta multiple_output no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
A regra básica para criar várias mensagens de saída é declarar, implicitamente
ou explicitamente, várias linhas $target
.
Várias linhas podem ser declaradas implicitamente utilizando uma linha for
.
Ao utilizar uma linha for
, zero ou mais mensagens de saída serão criadas,
uma por item de origem fornecido como a origem da linha for
.
Várias mensagens de saída podem também ser criadas ao incluir explicitamente
mais de um destino utilizando o menu Incluir Origens e Destinos. Cada destino criará uma mensagem de saída. Você pode combinar linhas for
com vários destinos, se cada item em uma origem cria várias mensagens de saída em si mesmo.
Existem vários cenários onde ele é útil para configurar um mapa de mensagens para várias mensagens de saída. Alguns dos cenários são:
Neste cenário, uma mensagem única é transformada em diferentes mensagens com destino a sistemas de informações corporativos diferentes ou de outra forma contém vários campos de repetição que são melhor processados individualmente;
Uma mensagem multipartes é uma mensagem modelada utilizando intermediários com o recurso mensagem multipartes, que permite mensagens em diferentes formatos de ligação ou mesmo dicionários diferentes serem combinados em uma única mensagem em batch.
Uma mensagem de origem contém dados que precisam ser transformados em mensagens separadas para vários sistemas EIS. Campos individuais sem repetição precisam ser combinados para criar várias mensagens de saída;
Uma mensagem de origem contém um campo de repetição (talvez uma fatura) que precisa ser transformado em várias mensagens de saída com base no valor do campo (talvez um identificador do parceiro comercial).
As ferramentas do mapa de mensagens tornam fáceis a geração de várias mensagens
de saída: tudo que é requerido é especificar montagem de várias mensagens de destino ou
incluir uma montagem da mensagem de destino em uma linha for
.
Os arquivos de amostra para este cenário estão localizados na pasta multiple_output no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
Tudo que é requerido para criar várias mensagens de saída para um campo
de origem de repetição é incluir a montagem da mensagem de destino em uma
linha for
que opere na origem de repetição.
O mapa de mensagens da amostra repeating_source.msgmap converterá um campo de repetição em uma montagem de mensagem de origem em um fluxo de montagens de mensagens no fluxo de mensagens chamado. O repeating_source.msgmap agrupa a linha $target
em uma linha for
para criar várias montagens de mensagens
de saída, uma para cada entrada de repetição. Para cada montagem, a pasta Propriedades é copiada, o que significa que o comportamento copiar todos os cabeçalhos é utilizado. Em seguida, em cada montagem da mensagem de saída, um único rtl:body
é copiado.
Os arquivos de amostra para este cenário estão localizados na pasta multipart_messages no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
Como para campos de repetição, tudo que é requerido para criar várias mensagens
de saída para uma repetição de mensagem de origem multiparte é incluir a montagem
da mensagem de destino em uma linha for
que opera na repetição da
definição da mensagem multiparte.
A diferença chave entre mensagens multipartes e um campo de repetição regular
é que uma mensagem multiparte é definida por um grupo de conteúdo local com um
modelo de conteúdo open
ou open-defined
(uma extensão de intermediários para Esquema XML), enquanto um campo de repetição é definido por um
elemento.
Ao invés de introduzir uma construção do mapa de mensagens diferente para uma mensagem multiparte, o grupo de conteúdo é tratado como se o seu conteúdo estivesse em um curinga do esquema XML. Criar um mapa para um elemento curinga do esquema XML requer a utilização de um submapa chamado.
Como a amostra mostra, os elementos curinga são mapeados através da utilização de um submapa específico do elemento. De fato, o curinga ou elemento "unknown" é convertido para um elemento "known" por um submapa chamado.
O arquivo de amostra para este cenário é nonrepeating_source.msgmap localizado na pasta multiple_output no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
A técnica para produzir várias mensagens é a mesma independentemente se a origem está
ou não se repetindo. Neste caso, várias linhas
$target
são explicitamente declaradas pelo mapa. Cada linha de destino
declarada criará uma mensagem de saída. Em cenários de repetição, várias
montagens foram declaradas implicitamente pelas linhas
for
que continham as montagens de destino e que criaram uma
montagem de saída por item no for
.
Os arquivos de amostra para este cenário estão localizados na pasta sorting no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens. Existem duas variações sobre este tema:
Classificar ou agrupar quando os valores da chave para classificação são conhecidos enquanto a autoria do mapa é ilustrada pelo arquivo sorting.msgmap. Três valores de campo possíveis são classificados em três mensagens separadas utilizando o padrão de design Criando Várias Mensagens de Saída para Entrada Não Repetida.
Freqüentemente é necessário calcular as quantidades totais ou contagens de registros depois que uma mensagem única é transformada em várias mensagens. Isto precisa ser tratado por uma segunda etapa, no arquivo total.msgmap. O fluxo de mensagens sort.msgflow ilustra como conectar dois nós de mapeamento para conseguir este resultado.
O arquivo da amostra é sorting_dynamic.msgmap. Esta amostra é quase igual à Classificando com Chaves Conhecidas Previamente, a diferença principal é que o mapa precisa ir ao banco de dados para obter a lista das chaves válidas. As etapas no mapa são os seguintes:
$db:select
é utilizada para obter a lista de chaves de
um banco de dados.for
processa cada item de
$db:select
em ordem. for
selecionada é uma
outra linha for
, desta vez é escolhido cada registro na origem
em ordem.if
e uma linha condition
filtram as duas linhas for
, de modo que apenas as linhas
que correspondam às chaves produzam uma mensagem de saída.$target
cria as mensagens de saída,
uma para cada valor chave exclusivo que está no banco de dados e na mensagem de origem.Como no exemplo anterior, isto ainda não é suficiente para ter uma mensagem de saída correta, e o mapa total.msgmap precisará novamente ser chamado para calcular os totais por mensagem de saída.
Os arquivos de amostra estão na pasta esql_calling_msgmap no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
A amostra mostra como chamar um mapa de ESQL. Nossa expectativa é que os usuários
chamarão submapas ao invés de mapas principais. Um submapa é qualquer mapa de mensagens que é planejado para ser chamado de um outro mapa ou de um ESQL. Você cria um submapa no Assistente Novo Mapa de Mensagens (Arquivo>Novo>Mapa de Mensagens
) ao selecionar o botão de rádio Este mapa é
chamado de um outro mapa...:
A esperada assinatura ESQL para a chamada de um submapa é:
submapName( sourcePath1, [sourcePath2, [...]] [targetPath, ] InputLocalEnvironment [, OutputLocalEnvironment])
Ao menos um parâmetro sourcePath
está sempre presente;
isto representa a entrada do sistema de mensagens que está direcionando o nó do fluxo de mensagens.
sourcePath
s são variáveis REFERENCE
ESQL que são
inicializadas para referenciar o nó da árvore de origem antes de chamar o mapa
de mensagens.
targetPath
é uma variável opcional REFERENCE
ESQL
que referencia o nó da árvore raiz do destino. Ela deve ser inicializada
antes da chamada do mapa de mensagens. targetPath
é
opcional e se um mapa de mensagens não tiver parâmetro de destino, então o mapa
não criará qualquer sistema de mensagens de saída. Isto é utilizado para mensagens para cenários de bancos de dados relacionais, aonde os mapas são chamados a partir de nós de Banco de Dados
ESQL.
InputLocalEnvironament e OutputLocalEnvironment são as variáveis
REFERENCE
ESQL inicializadas para os nomes de correlação do nó
ESQL associado. Mapas de mensagens são implementados como procedimentos de escopo do esquema,
desta forma eles não podem acessar os nomes de correlação diretamente.
O código de amostra inicializa os parâmetros requeridos e chama o mapa.
Os arquivos de amostra estão na pasta esql_calling_msgmap no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
O padrão básico do ESQL chamando um mapa foi implementado. O código
MODULE
ESQL foi escrito para inicializar as pastas
Propriedades
e Cabeçalhos
, criar as referências
necessárias e chamar o mapa.
O mapa constrói uma mensagem de saída única a partir de todas as pastas do nó
Aggregate
(Request1, Request2,
etc). Uma vez que o MODULE
ESQL cuida das propriedades e cabeçalhos,
tudo que resta a fazer é copiar o conteúdo de
LocalEnvironment.Aggregate.AgregateRequestFolderName
para a mensagem de saída.
Estes cenários de amostra mostram o padrão de design para transformar modelos de Esquemas XML que utilizam curingas, extensões e restrições de tipos, substituição de grupos e grupos de modelo de conteúdo em um mapa de mensagens.
Os arquivos de amostra para o processamento de elementos e atributos curinga estão localizados na pasta multipart_messages no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
Elementos curinga são manipulados pela chamada de um submapa. No submapa, o nome do elemento
está hardcode atribuído. Para processar nomes de elementos diferentes a partir do mesmo
curinga, utilize linhas if
, condition
,
e else
.
A amostra implementa um cenário de campo de repetição simples, mas levemente mais complexo onde a origem de repetição é modelada como uma mensagem multipartes de intermediários. A mensagem multipartes é manipulada como um elemento curinga pelas ferramentas do mapa. Os curingas são manipulados chamando um submapa para o nome do elemento correto.
No primeiro mapa, a montagem da mensagem de destino está contida em uma
linha for
. A linha for
opera sobre uma mensagem
multipartes de repetição contida pela mensagem de origem única.
A restrição da montagem de destino na linha for
significa
que as montagens de mensagens de destino completas serão colocadas na saída, uma por mensagem
multipartes de entrada na origem. O primeiro mapa de mensagens também contém um mapeamento
para a mensagem curinga que suporta mensagens multipartes. Este mapeamento chama um
submapa, que deve retornar uma definição completa do elemento que o curinga representa.
No segundo mapa, nós vemos que o elemento de mensagem curinga foi restringido a ser
um elemento rtl:body
. Neste submapa, a origem e o destino são os mesmos,
e a origem é copiada profundamente para criar o destino.
O arquivo de amostra para este cenário é type_to_substitutiongroup.msgmap e está localizado na pasta xmlschema no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
No editor do mapa de mensagens, 'pastas' especiais na árvore de origem e de destino são utilizadas para mostrar os tipos de combinações válidos. O nome da pasta é especializações para tipo base. Dentro da pasta são mostrados os elementos combinados com toda a derivação não abstrata de um tipo base. Cada uma destas representações de elemento concretas contém seu conteúdo completo, com todos os atributos possíveis seguidos por todos os elementos válidos. Essencialmente, a árvore mostra os elementos XML diferentes que o modelo do esquema XML descreve.
Na amostra do mapa de mensagens, a origem é descrita utilizando um modelo de Esquema XML
que permite as alternativas extensionType1
e extensionType2
.
Cada uma destas alternativas podem ser mapeadas individualmente para o destino.
Hierarquias da extensão do tipo podem ser combinadas com modelos de opção, grupos de substituição, etc., ainda que a amostra evite esta complexidade.
O arquivo de amostra para este cenário é type_to_substitutiongroup.msgmap e está localizado na pasta xmlschema no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.
No editor do mapa de mensagens, 'pastas' especiais na árvore de origem e de destino são utilizadas para mostrar os elementos válidos utilizando a substituição de combinações de grupos. O nome da pasta é substituições para elemento principal. Dentro da pasta são mostrados os nomes de elementos diferentes combinados com toda a derivação não abstrata para o tipo base. Cada uma destas representações de elemento concretas contém seu conteúdo completo, com todos os atributos possíveis seguidos por todos os elementos válidos. Essencialmente, a árvore mostra os elementos XML diferentes que o modelo do esquema XML descreve.
Na amostra do mapa de mensagens, o destino é descrito utilizando um modelo de Esquema XML
que permite as alternativas Substitute1
e Substitute2
para o elemento HeadElement
abstrato. Cada uma destas alternativas pode ser mapeada individualmente para a origem.
Grupos de substituição podem ser combinados com hierarquias de tipos, ainda que a amostra evite esta complexidade.
Os arquivos da amostra para este cenário estão localizados na pasta modelgroups no projeto Fluxos de Mensagens da Amostra do Mapa de Mensagens.