Sobre a Amostra Mapa de Mensagens

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.

Manipulando Montagem Completa de Mensagens

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.

Montagem de Propriedades

Montagem de Propriedades

A montagem de mensagem do WebSphere Message Broker inclui quatro itens, que estão numerados na figura:

  1. a pasta LocalEnvironment;
  2. a pasta Propriedades;
  3. grupo Message Headers da camada de transporte;
  4. a carga útil ou corpo da mensagem.

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.

Retornar ao Início da Página.

>Controlando o Processamento do Fluxo de Mensagens com um Mapa

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.

Fluxo de Mensagens Route To Label

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:

Mapa de Mensagens Route To Label

Nesta amostra:

Retornar ao Início da Página.

Copiar Todos os Cabeçalhos

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.

Copiar Todos os Cabeçalhos

Retornar ao Início da Página.

Propriedades do Mapeamento

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:

Modelo Propriedades

  1. Formato físico da mensagem
  2. Camada de transporte "Qualidade de Serviço"
  3. Informações do caminho de resposta
  4. Tópico publicar/assinar

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.

Retornar ao Início da Página.

Mapeando Cabeçalhos

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.

  1. O agrupamento do MQ inclui os cabeçalhos MQMD e MQRFH2. Observe que esta é a definição da estrutura do cabeçalho; em tempo de execução um mapa manipula analisadores de origem automaticamente. Para o destino MQRFH2 o mapa seleciona dinamicamente o analisador MQRFH2 em intermediários versão 5 e o analisador MQRFH2C de alto desempenho em intermediários versão 6.
    Todo o recebimento de dados ESQL de um mapa de mensagens que mapeia o cabeçalho MQRFH2 (como oposição a copiá-lo utilizando a cópia do recurso de todos os cabeçalhos) precisa ser configurado com o nome do analisador correto para este cabeçalho.
  2. O agrupamento do HTTP inclui todos os cabeçalhos padrão; outros cabeçalhos HTTP são ignorados. Se você precisa processar cabeçalhos HTTP customizados, você precisará configurar um nó Compute ESQL para chamar o mapa, conforme descrito abaixo.
  3. O agrupamento do JMS incluir os cabeçalhos JMS padrões. Para processar versões customizadas você deve definir o cabeçalho JMS customizado em um conjunto de mensagens e configurar um nó Compute ESQL para chamar o mapa, conforme descrito abaixo.
Modelo de Cabeçalhos

Retornar ao Início da Página.

Criando Várias Mensagens de Saída

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:

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.

Retornar ao Início da Página.

Criando Várias Mensagens de Saída para um Campo de Repetição

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.

Repetição em Batch

Retornar ao Início da Página.

Criando Várias Mensagens de Saída para uma Mensagem de Entrada Multiparte

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.

Repetição em Batch

Retornar ao Início da Página.

Criando Várias Mensagens de Saída para Entradas Não Repetidas

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.

Repetição em Batch

Retornar ao Início da Página.

Classificando, Agrupando ou Intercalando Campos em uma Mensagem

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:

Classificando Com Chaves Conhecidas Previamente

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.

Classificando com Chaves de um Banco de Dados

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:

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.

Retornar ao Início da Página.

Chamando um Mapa de um ESQL

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...:

Criando um Submapa no Assistente Novo Mapa de Mensagens

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. sourcePaths 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.

Retornar ao Início da Página.

Utilizando um Mapa de Mensagem em um Cenário Agregado

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.

Retornar ao Início da Página.

Cenários de Esquemas XML

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.

Retornar ao Início da Página.

Elementos Curingas

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.

Mensagem de Envelope Multipartes

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.

Mensagem Contendo Multipartes

Retornar ao Início da Página.

Herança de Tipo

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.

Retornar ao Início da Página.

Grupos de Substituição

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.

Retornar ao Início da Página.

Grupos de Modelos de Repetição

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.

Retornar ao Início da Página.

Ícone Página Principal   Voltar para Home da Amostra