Esta página foi útil?
Seus comentários sobre este conteúdo são importantes. Queremos saber sua opinião.
Comentários adicionais?
1500 caracteres restantes
Exportar (0) Imprimir
Expandir Tudo

Usos e Estágios das Pontes

Atualizado: maio de 2015

A Serviços BizTalk fornece dois tipos de pontes – Ponte de passagem e Ponte XML. Ponte XMLs, por sua vez, incluem a Ponte unidirecional XML e a Ponte de solicitação-resposta XML. Esta seção fornece informações sobre os usos e estágios destas pontes.

É possível usar a Ponte XML para mediar e compartilhar incompatibilidades entre dois ou mais sistemas discrepantes que se comunicam por intercâmbio de mensagens XML. As Ponte XMLs, possivelmente em conjunção com outras entidades do Barramento do Serviço num fluxo de mensagens, fornecem uma variedade de paradigmas e cenários de mediação, tais como os seguintes:

  • Validação de mensagens: a Ponte XML suporta a validação de mensagens XML de entrada em relação a um esquema XSD. As mensagens com falha na validação são rejeitadas.

  • Enriquecimento e extração de mensagens: a Ponte XML suporta o enriquecimento de mensagens através de procura de dados de outras fontes de dados. Isto é normalmente útil em cenários onde as mensagens podem requerer dados contextuais presentes além de limitações de mensagens normalmente de um repositório de configuração, de um serviço externo ou semelhante.

    A Ponte XML também permite extrair propriedades de uma mensagem XML que pode ser usada para eventualmente rotear. Por exemplo, numa mensagem de ordem de compra, é possível marcar o elemento Quantidade. A mensagem pode, em seguida, ser roteada com base no valor da quantidade pedida.

  • Transformação de mensagens: a Ponte XML suporta as transformações do corpo da mensagem de uma estrutura XML para outra. Esse recurso de uma Ponte XML pode também ser usado para “normalizar” uma mensagem em cenários onde várias mensagens são mapeadas para uma mensagem única. Por exemplo, uma ponte pode necessitar aceitar ordens de compra em diferentes esquemas de diferentes clientes, mas elas são eventualmente transformadas em um esquema de ordem de compra único requerido pela organização.

  • Virtualização da localização: a Ponte XML fornece virtualização da localização primitiva de serviços back-end. Os clientes enviam mensagens para o ponto de extremidade da Ponte XML exposto na nuvem e não para o serviço real (que pode ser na nuvem ou no local). Em seguida, a ponte roteia as mensagens para o serviço back-end com base em regras de roteamento.

  • Processamento personalizado: as pontes fornecem as opções de incluir código personalizado para incorporar tarefas de processamento que não estão inclusas na configuração da ponte pronta para uso.

Esta seção fornece informações sobre os diferentes estágios de uma Ponte XML. Observe que cada estágio é opcional e pode ser ligado ou desligado.

O primeiro estágio na Ponte XML é o estágio Validar. Isso fornece a validação XSD de mensagens XML em relação a esquemas especificados. Os esquemas a usar para validação são especificados durante a configuração da ponte. Uma Ponte XML única pode receber e processar mensagens XML com esquemas diferentes. Durante o estágio de validação, dependendo da mensagem de entrada, o esquema correspondente é escolhido e usado para a validação. Uma vez a mensagem validada no esquema, o estágio Validar promove a propriedade X_PIPELINE_MESSAGETYPE na mensagem. O valor da propriedade é uma combinação do namespace de destino do esquema e o nome do nó raiz, por exemplo, http://IntegrationServices.Schema#RootNode. Se a mensagem de validação falhar, seja por não encontrar um esquema correspondente ou devido a uma correspondência ambígua (mais de um esquema coincidente), será gerada uma exceção.

Para obter instruções sobre como configurar o estágio de validação, consulte Criar uma ponte unidirecional XML ou Criar uma ponte de solicitação-resposta XML.

No estágio Enriquecer, é possível enriquecer uma mensagem criando propriedades, cujos valores podem derivar do cabeçalho de uma mensagem de entrada, a partir de uma propriedade promovida pelo sistema, a partir de um elemento ou atributo no corpo da mensagem de entrada ou através de uma fonte de dados externa tal como as tabelas do Banco de dados SQL do Microsoft Azure. Em seguida, é possível usar essas propriedades para rotear mensagens para pontos de extremidades de destino e pontes de protocolos.

 

Operação Descrição

Cabeçalho para atribuição de propriedades

Nesta operação, é possível usar um valor do cabeçalho da mensagem e atribuí-lo a uma propriedade. Por exemplo, pode extrair a ação do cabeçalho SOAP, atribuí-la a uma propriedade e, em seguida, usar essa propriedade para processamento e/ou roteamento adicional. Pode usar as propriedades baseadas no protocolo de mensagens que é usado para enviar a mensagem à ponte. Os protocolos suportados são HTTP, SOAP, FTP e SFTP. As seguintes propriedades estão disponíveis para esses protocolos.

  • SOAP

    • Ação

    • MessageId

    • ReplyTo

    • Para

    • Cabeçalhos SOAP personalizados

  • HTTP – Cabeçalhos HTTP padrão

  • FTP/SFTP

    • FileName

    • ServerAddress

    • Pasta

Para obter instruções sobre como configurar o cabeçalho para a atribuição de propriedades, consulte Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Usando propriedades promovidas do sistema

Por padrão, os Serviços BizTalk promovem algumas propriedades nas mensagens que são processadas pela ponte. Essas propriedades também são chamadas de propriedades promovidas pelo sistema. Os valores dessas propriedades podem também ser usados para várias tarefas de processamento, tais como decidir o destino do roteamento etc. As propriedades promovidas pelo sistema disponíveis são:

  • RequestId – Um ID de solicitação exclusivo atribuído à mensagem.

  • MessageReceivedTime – O carimbo de data/hora denotando a que horas a mensagem foi recebida no pondo de extremidade da ponte.

  • SourceName – O nome da origem, como definido na superfície de configuração da ponte, da qual a ponte recebe mensagens.

  • SourceType – O tipo de origem, como usado na superfície de configuração da ponte, da qual a ponte recebe mensagens.

Para obter instruções sobre como usar as propriedades promovidas pelo sistema, consulte Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Extrair

A operação Extrair do estágio Enriquecer é usada para extrair os valores de elementos ou atributos específicos do corpo da mensagem para usar durante o roteamento da mensagem ou processamento adicional.

Para obter instruções sobre como configurar a operação de extração, consulte Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Pesquisa

A operação Procurar do estágio Enriquecer é usada para enriquecer a mensagem procurando e incluindo dados de origens fora do limite de uma mensagem. Por exemplo, poderá existir uma loja de varejo online que permite que seus usuários efetuem pedidos usando moeda local, enquanto o serviço back-end para o processamento de pedidos usa uma moeda única, digamos dólares, para qualquer processamento de pedidos. Nesse caso, antes do envio da mensagem ao serviço back-end, o valor da ordem tem que ser convertido da moeda local para dólares. Isto pode ser feito procurando um outro serviço que forneça as últimas taxas de câmbio.

Para esta versão, o estágio de enriquecimento suporta somente a procura de dados a partir do Banco de dados SQL do Microsoft Azure. Em outras palavras, o Banco de dados SQL do Microsoft Azure é o único “fornecedor” de procura suportado para a versão atual. As informações sobre o fornecedor de procura são armazenadas num LookupProviderConfigurations.xml, que é adicionado ao Projeto do Serviço BizTalk. É possível ter vários provedores definidos como um único arquivo .xml, correspondendo ao fato que você pode procurar mais de uma fonte de dados do Banco de dados SQL do Microsoft Azure como parte do estágio de enriquecimento único. Uma definição típica do fornecedor num arquivo LookupProviderConfigurations.xml será semelhante ao seguinte:

<ArrayOfLookupProviderConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/WindowsAzureServiceBus/Bridge">
  <LookupProviderConfiguration i:type="SqlTableLookupProviderConfiguration">
    <ProviderName>...</ProviderName>
    <ConnectionString>...</ConnectionString>
    <QueryInColumnName>...</QueryInColumnName>
    <QueryOutColumnName>...</QueryOutColumnName>
    <TableName>...</TableName>
  </LookupProviderConfiguration>
</ArrayOfLookupProviderConfiguration>

No extrato anterior, note que o atributo tipo do elemento LookupProviderConfiguration está fixado para SqlTableLookupProviderConfiguration. Isso ocorre porque atualmente é possível procurar somente uma tabela no Banco de dados SQL do Microsoft Azure.

Também há algumas considerações enquanto se procuram dados a partir de um Banco de dados SQL do Microsoft Azure.

  • Só é possível procurar uma tabela do Banco de dados SQL do Microsoft Azure.

  • A procura deverá ser feita usando um par de chave/valor.

  • A procura deve produzir somente um valor, que é atribuído a uma propriedade na mensagem. Se a procura produzir mais que um valor, o primeiro desses valores é atribuído à propriedade.

  • É possível procurar um valor de várias fontes de dados, o que significa que é possível procurar mais de uma tabela do Banco de dados SQL do Microsoft Azure ou mais de um Banco de dados SQL do Microsoft Azure.

Para obter instruções sobre como configurar a operação de pesquisa, consulte Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Embora a informação sobre os fornecedores seja armazenada no LookupProviderConfigurations.xml, a informação sobre que valores atribuir do cabeçalho às propriedades da mensagem, que valores extrair e que valores procurar é armazenada num arquivo de configuração da ponte. Quando cria um Projeto do Serviço BizTalk, o LookupProviderConfigurations.xml também será acumulado em um arquivo de configuração da ponte. Quando implanta o Projeto do Serviço BizTalk, é este arquivo de configuração da ponte que é instalado no Barramento do Serviço.

No estágio de enriquecimento, você deve criar propriedades e atribuir valores a essas propriedades. Mas a questão que surge é o que posso fazer com essas propriedades? Como é que essas propriedades tornam minha tarefa mais fácil? É possível usar as propriedades de duas maneiras:

  • É possível usar as propriedades para definir condições de filtro para rotear mensagens para diferentes destinos. Para obter instruções sobre como realizar isto, consulte The Routing Condition.

  • É possível usar as propriedades para conectar a incompatibilidade de protocolo entre o emissor da mensagem e o receptor da mensagem. Por exemplo, você tem uma mensagem SOAP de entrada que tem um valor de cabeçalho personalizado. Você deseja passar este valor como o cabeçalho personalizado de uma mensagem HTTP, porque o receptor da mensagem deseja uma mensagem REST e não entende o formato da mensagem SOAP. É possível usar as propriedades para fazer isso. Você pode primeiro atribuir o valor do cabeçalho da mensagem de entrada a uma propriedade (digamos P1) e, em seguida, enquanto envia a mensagem ao receptor, atribuir o valor de P1 a um cabeçalho da mensagem da mensagem de saída. Para obter mais informações, consulte Ações de roteamento e resposta: Conectando incompatibilidades de protocolo.

Em uma Configuração da ponte, as propriedades que você define como parte do estágio de enriquecimento estarão disponíveis por todo o fluxo da mensagem para cada estágio na Configuração da ponte. Em outras palavras, se você definiu uma propriedade no estágio de enriquecimento, será possível usá-la durante o estágio de transformação e para qualquer operação de mapeamento. As propriedades definidas no estágio de enriquecimento também podem ser usadas fora do limite de uma Configuração da ponte, com algumas considerações. Antes de entrarmos em mais detalhes sobre disso, devemos entender que os valores das propriedades são armazenados como propriedades da classe BrokeredMessage do Barramento do Serviço. Agora que estamos cientes desse fato, vamos conversar sobre o tempo de vida das propriedades fora de uma Configuração da ponte.

  • Porque somente uma Fila ou Tópico do Barramento do Serviço pode consumir mensagens do tipo BrokeredMessage, as propriedades e seus valores (como par de chave/valor) podem ser diretamente consumidos pelas Filas e pelos Tópicos. Depois disso, os Tópicos por exemplo, podem potencialmente usar as propriedades para processamento e roteamento adicional

  • Não é possível passar as propriedades e seus valores para outros componentes da Configuração da ponte como Pontos de extremidades de retransmissão unidirecional/bidirecional ou Pontos de extremidades de serviço externo unidirecional/bidirecional. Se desejar passar os valores das propriedades para essas entidades, você deve atribuir os valores das propriedades aos cabeçalhos da mensagem de saída. Para obter mais informações, consulte Ações de roteamento e resposta: Conectando incompatibilidades de protocolo.

  • No cenário de “encadeamento” onde a mensagem de uma ponte é roteada para outra ponte e, em seguida, para uma Fila do Barramento do Serviço (por exemplo), somente as propriedades da última ponte na cadeia estão disponíveis para roteamento ou processamento adicional. Também, para passar valores de propriedades às pontes subsequentes, os valores das propriedades devem ser atribuídos aos cabeçalhos da mensagem de saída. Essas propriedades devem, em seguida, ser extraídas na segunda ponte.

O estágio Transformação, como o nome o sugere, permite realizar transformações estruturais nas mensagens. Como os outros estágios no pipeline, o estágio Transformação pode funcionar com múltiplos tipos de mensagens, para que você possa ter mais de uma transformação disponível como parte do estágio de transformação. A transformação correta a ser realizada é automaticamente procurada no tempo de execução com base no tipo de mensagem de entrada, desde que as transformações correspondentes tenham sido configuradas e atualizadas durante a configuração da ponte. A resolução de transformação ocorre baseada no tipo da mensagem de entrada.

  • O estágio de transformação corresponde ao tipo da mensagem com o mesmo tipo de mensagem do esquema de origem num mapa.

  • Se o estágio de validação estiver desligado, o estágio de transformação corresponde à mensagem de entrada com o esquema de origem da mensagem. Se a resolução ocorrer, esta promoverá a propriedade MessageType na mensagem.

A versão atual somente suporta transformações de origem única para destino único. Para obter mais informações, consulte Aprender e criar mapas de mensagem e transformações. Para obter instruções sobre como configurar o estágio de transformação, consulte Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

O estágio Enriquecer, pós-transformação, é similar ao estágio de enriquecimento antes da transformação. A única diferença é que no estágio de enriquecimento pós-transformação, é possível enriquecer a mensagem transformada. A forma que você configura o estágio de enriquecimento permanece igual ao estágio de enriquecimento pré-transformação. Para obter instruções sobre como configurar o estágio de enriquecimento, pós-transformação, consulte Create an XML Bridge ou XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

noteObservação
Todas as propriedades extraídas ou procuradas antes dos estágios de transformação estão também disponíveis na mensagem transformada. Uma propriedade previamente extraída ou enriquecida será substituída se for modificada no estágio de enriquecimento pós-transformação.

Na seção anterior, vimos que no estágio Validar, a validação ocorre nos esquemas e no estágio Transformação, a mensagem é transformada usando uma transformação. Por isso, os artefatos que estão disponíveis como parte de uma Ponte XML são:

  • Esquemas. Estes têm extensão .XSD

  • Transformações. Estes têm a extensão .TRFM e podem ocorrer várias transformações no estágio de transformação.

  • Assemblies. Estes incluem a lógica de processamento personalizado que pode ser incorporada em estágios específicos na ponte.

  • Certificados. Estes são usados para a transferência segura de mensagens.

noteObservação
Um arquivo de configuração da ponte não é um artefato, porque não pode ser compartilhado entre diferentes pontes. Um arquivo de configuração da ponte é específico para uma ponte.

O aplicativo do Serviço BizTalk pode ter múltiplas pontes e cada ponte pode estar usando várias transformações e esquemas. Por isso, um aplicativo de Serviços BizTalk típico terá um grande número de transformações e esquemas. No entanto, ao mesmo tempo, cada transformação e esquema pode não ser requerido para cada Ponte XML. Portanto, deve haver uma maneira de associar as transformações e esquemas para uma ponte. É possível fazer estas associações enquanto configura a ponte.

Para associar esquemas e transformações, consulte Criar uma ponte unidirecional XML ou Criar uma ponte de solicitação-resposta XML.

Uma Ponte de passagem é usada quando deseja que qualquer tipo de mensagem seja processado pela ponte. Como resultado, uma Ponte de passagem não inclui estágios de validação ou transformação, porque ambos os estágios estão ligados a tipos de mensagem. Uma Ponte de passagem somente inclui o estágio Enriquecer, que é usado para os mesmos propósitos que numa Ponte XML Para obter informações sobre como configurar uma Ponte de passagem, consulte Criar uma ponte de passagem.

Consulte também

Conceitos

O que são Pontes?

Mostrar:
© 2015 Microsoft