As mensagens entram no BizTalk através de uma porta lógica (portas de recepção ou Receive Port) que são compostas por 1 ou varias portas físicas (locais de recepção ou Receive Locations). Cada local de recepção possui uma configuração específica para um adaptador, como podemos verificar no exemplo seguinte:
Os mapas de BizTalk são representações gráficas de documentos XSLT (Extensible Stylesheet Language Transformation) que permitem efectuar, de forma simples e visual, transformações às mensagens XML.
Nota: Neste artigo vamos falar apenas nas transformações de semântica, ou seja, nos mapas de BizTalk.
Conforme a imagem a baixo demonstra, os mapas de BizTalk podem ser utilizados à entrada, nas orquestrações, ou nas portas de saída.
O editor de mapas, BizTalk Mapper Designer, possibilita efectuar transformações de mensagens XML complexas de forma visual e extremamente simples, expressas em associações gráficas de ligações (links) que definem as relações entre os vários elementos das mensagens.
As transformações num mapa podem ser definidas na forma de relações simples, como copiar um nome ou um endereço de um documento para outro. Podemos expressar uma cópia directa dos dados usando uma ligação, que é representada no BizTalk Mapper Designer como uma linha que liga os elementos da origem para os elementos de destino.
A grelha de mapeamento desempenha um papel crítico na definição de mapas, ela irá conter as ligações e functoids que irão controlar a forma como os dados de origem de uma mensagem são transformados numa mensagem de destino de acordo com o seu esquema.
Por defeito os mapas são criados com apenas uma página, com o nome “Page 1”, apesar das operação mais frequentes serem a de criação e renomeação, são 4 operações as operações que podemos efectuar sobre as páginas:
Quando estamos a efectuar uma transformação de mensagens são 5 as funcionalidades básicas que normalmente nos surgem:
Esta é a operação mais básica de todas as operações, onde pretendemos mover um valor da origem para um determinado destino, sem efectuarmos qualquer tipo de operação sobre os valores (cópia directa).
Concatenar diferentes valores da origem para um determinado elemento no esquema de destino é outra das operações quotidianas em transformações, para isso apenas necessitamos de:
Muitas das vezes não queremos simplesmente mover valores da origem para o destino, às vezes necessitamos de gerar a saída dos dados de acordo com certas condições. Podemos efectuar estas condições de muitas formas distintas através de functoids ou scripts customizados, aqui fica um exemplo: Testar se o valor na origem é uma string válida, se sim mapeá-la para o esquema de origem, para isso necessitamos:
Scripts customizados são utilizados normalmente em transformações mais complexas ou por forma a facilitar algumas condições. Basicamente existem dois cenários para utilizarmos esta functoid:
Em muitos cenários temos a necessidade de adicionar novos dados à mensagem final que não existem na mensagem de origem. É normal encontrarem situações em que, com base em alguns dados existentes na mensagem de origem, necessitaremos de consultar um sistema externo, por exemplo base de dados, por forma a adquirimos mais informações para preencher os dados necessários na mensagem final.
Os mapas podem tornar-se extremamente complexos, dificultando assim a sua leitura e manutenção.
As páginas permitindo organizar os mapas, especialmente os mais complexos, em subdivisões lógicas de mapeamentos. Esta funcionalidade já foi descrita anteriormente.
Nas versões anteriores do produto, por defeito, era apresentado a query XPATH se uma ligação fosse estabelecida a uma functoid:
Na fase de desenvolvimento, temos ao dispor 3 funcionalidades, incluídas no Visual Studio, que nos permite testar e validar os mapas:
Deveremos testar o nosso mapa de uma forma continua, não apenas no final do desenvolvimento, mas sempre que necessário ou quando um bloco de transformação importante seja concluído.
Esta opção permite-nos validar a estrutura do mapa. Podemos desta forma inspeccionar e analisar o código XSLT gerado pelo compilador, fornecendo-nos informações adicionais de como os mapas funcionam assim como mais uma outra opção de depuração (debug).
Esta opção permite-nos efectuar a depuração (debug) de mapas e assim identificar e corrigir problemas complexos de mapeamento na fase de desenvolvimento. Esta funcionalidade faz uso de algumas propriedades dos mapas, tais como “TestMap Input Instance” e “TestMap Output Instance”. Portanto, antes de depurar o mapa, será necessário configurar as suas propriedades dos mapas, com especial foco nas duas anteriores.
Sandro Pereira DevScope | MVP & MCTS BizTalk Server 2010 http://sandroaspbiztalkblog.wordpress.com/ | @sandro_asp
Sandro Pereira edited Revision 5. Comment: Adicionado link para o código fonte
Sandro Pereira edited Revision 4. Comment: Novas imagens
Fernando Lugão Veltem edited Revision 3. Comment: removido espaços e correção nas cores da fonte
Fernando Lugão Veltem edited Revision 2. Comment: adicionado toc
Sandro Pereira edited Revision 1. Comment: Adicionar coneúdos