Usos y fases de los puentes

Actualizado: julio de 2015

Servicios de BizTalk proporcionan dos tipos de puentes: el Puente paso a través el Puente XML. El Puente XML incluye a su vez el Puente unidireccional XML y el Puente de solicitud y respuesta XML. Esta sección ofrece información sobre los usos y las fases de dichos puentes.

El Puente XML puede usarse para mediar y eliminar la falta de correspondencia entre dos o más sistemas dispares que se comunican mediante mensajes XML. El Puente XML, posiblemente junto con otras entidades del CmdLets de un flujo de mensajes, proporciona una serie de paradigmas y escenarios de mediación, entre los que se incluyen los siguientes:

  • Validación de mensajes: el Puente XML admite la validación de los mensajes XML entrantes tomando un esquema XSD como referencia. Los mensajes que no pasan la validación son rechazados.

  • Enriquecimiento y extracción de mensajes: el Puente XML admite el enriquecimiento de mensajes mediante una búsqueda de datos en otros orígenes de datos. Esto normalmente es útil en escenarios en los que los mensajes pueden requerir la presencia de datos contextuales más allá de los límites que suelen tener los mensajes de un almacén de configuración, un servicio externo o similares.

    El Puente XML también permite extraer propiedades de un mensaje XML que pueden usarse en último término para realizar el enrutamiento. Por ejemplo, en un mensaje de pedido de compra, se puede marcar el elemento Cantidad. De ese modo se puede enrutar el mensaje en base al valor de la cantidad establecida en el pedido.

  • Transformación de mensajes: el Puente XML admite las transformaciones del cuerpo del mensaje de una a otra estructura XML. Dicha funcionalidad de un Puente XML puede usarse también para «normalizar» un mensaje en escenarios en los que se asignan varios mensajes a un solo mensaje. Por ejemplo, un puente puede tener que aceptar pedidos de compra de distintos esquemas provenientes de distintos clientes, pero en último término estos se transforman en un solo esquema de pedido de compra requerido por la organización.

  • Virtualización de la ubicación: el Puente XML proporciona la virtualización de ubicaciones primitivas de los servicios back-end. Los clientes envían mensajes al extremo del Puente XML expuesto en la nube, no en el servicio real (el cual puede ubicarse en la nube o en un entorno local. El puente enruta entonces los mensajes al servicio back-end basado en reglas de enrutamiento.

  • Procesamiento personalizado: los puentes ofrecen la opción de incluir código personalizado para incorporar tareas de procesamiento que no se incluyen en la configuración lista para usar del puente.

Esta sección proporciona información sobre las distintas fases de un Puente XML. Tenga en cuenta que cada fase es opcional y que puede ser activada o desactivada.

La primera fase del Puente XML es la fase de Validación. Dicha fase ofrece la posibilidad de realizar una validación XSD de los mensajes XML tomando como referencia esquemas específicos. Los esquemas que se van a usar en la validación se especifican en la configuración del puente. Un solo Puente XML puede recibir y procesar mensajes XML con distintos esquemas. Durante la fase de validación, dependiendo del mensaje entrante, se elige el esquema correspondiente para usarlo en la validación. Una vez que se valida el mensaje tomado el esquema como referencia, la fase de Validación promociona la propiedad X_PIPELINE_MESSAGETYPE en el mensaje. El valor de la propiedad es una combinación entre el espacio de nombres de destino del esquema y el nombre del nodo raíz, por ejemplo, http://IntegrationServices.Schema#RootNode. Si la validación del mensaje falla, ya sea por no haberse hallado un esquema coincidente o debido a una correspondencia ambigua (hay más de un esquema coincidente), se inicia una excepción.

Para ver instrucciones sobre cómo configurar la fase de validación, consulte Crear un puente unidireccional XML o Crear un puente de solicitud y respuesta XML.

En la fase de Enriquecimiento puede enriquecer un mensaje creando propiedades cuyos valores pueden derivarse del encabezado del mensaje entrante, de una propiedad promocionada por el sistema, de un elemento o atributo del cuerpo del mensaje entrante o mediante una búsqueda en un origen de datos externo, como pueden ser las tablas de la Base de datos SQL de Microsoft Azure. Dichas propiedades pueden usarse entonces para enrutar los mensajes a los extremos de destino y para crear puentes entre protocolos.

 

Operación Descripción

Asignación de encabezado a propiedad

Con esta operación puede usar el valor del encabezado del mensaje y asignarlo a una propiedad. Por ejemplo, puede extraer la acción del encabezado SOAP, asignarla a una propiedad y, después, usar dicha propiedad para más tareas de procesamiento y/o enrutamiento. Puede usar las propiedades basadas en el protocolo del mensaje que se usa para enviar el mensaje al puente. Los protocolos admitidos son HTTP, SOAP, FTP y SFTP. Las siguientes propiedades están disponibles para dichos protocolos.

  • SOAP

    • Action

    • MessageId

    • ReplyTo

    • Para

    • Encabezados SOAP personalizados

  • HTTP: encabezados HTTP estándar

  • FTP/SFTP

    • FileName

    • ServerAddress

    • Carpeta

Para ver instrucciones sobre cómo configurar la asignación de encabezado a propiedad, consulte Create an XML Bridge o XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Usar propiedades promocionadas por el sistema

De forma predeterminada, los Servicios de BizTalk promocionan algunas de las propiedades de los mensajes que son procesados por el puente. Dichas propiedades se denominan también «propiedades promocionadas por el sistema». Los valores de estas propiedades también pueden usarse para varias tareas de procesamiento, tales como decidir el destino del enrutamiento. Las propiedades promocionadas por el sistema disponibles son:

  • RequestId: un solo identificador de solicitud asignado al mensaje.

  • MessageReceivedTime: la marca de tiempo que determina la hora en que se recibió el mensaje en el extremo del puente.

  • SourceName: el nombre del origen, tal y como se define en la superficie de configuración del puente, desde el cual el puente recibe los mensajes.

  • SourceType: el tipo de origen, tal y como se usa en la superficie de configuración del puente, desde el cual el puente recibe los mensajes.

Para ver instrucciones de cómo usar las propiedades promocionadas por el sistema, consulte Create an XML Bridge o XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Extracción

La operación Extracción de la fase de Enriquecimiento se usa para extraer los valores de elementos o atributos específicos del cuerpo mismo del mensaje para su uso en el enrutamiento de mensajes o en las labores adicionales de procesamiento.

Para ver instrucciones sobre cómo configurar la operación de extracción, consulte Create an XML Bridge o XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Búsqueda

La operación Búsqueda de la fase de Enriquecimiento se usa para enriquecer los mensajes buscando e incluyendo datos desde orígenes externos a los límites de los mensajes. Por ejemplo, puede darse el caso de una tienda en línea que permita a los usuarios realizar sus pedidos con su divisa local a pesar de que el servicio back-end para el procesamiento de pedidos use una sola divisa, como por ejemplo el dólar, para procesar todos los pedidos. En tal caso, antes de que el mensaje sea enviado al servicio back-end, el importe del pedido ha de convertirse de la divisa local al dólar. Esto puede realizarse buscando otro servicio que ofrezca las tasas de cambio más recientes.

En la presente versión, la fase de enriquecimiento solo admite buscar datos en la Base de datos SQL de Microsoft Azure. En otras palabras, Base de datos SQL de Microsoft Azure es el único «proveedor» de búsquedas admitido por la versión actual. La información sobre el proveedor de búsquedas se almacena en el archivo LookupProviderConfigurations.xml, que se agrega a un Proyecto de servicio de BizTalk. Puede tener definidos varios proveedores en un solo archivo .xml, debido al hecho de que se puede buscar en más de un origen de la Base de datos SQL de Microsoft Azure como parte de una sola fase de enriquecimiento. Un definición de proveedor típica en el archivo LookupProviderConfigurations.xml tiene este aspecto:

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

En el extracto anterior, fíjese en que el atributo type del elemento LookupProviderConfiguration precede a SqlTableLookupProviderConfiguration. Ello se debe a que actualmente solo puede buscar en una tabla de la Base de datos SQL de Microsoft Azure.

Existen además algunas consideraciones que hay que tener en cuenta al buscar datos en una Base de datos SQL de Microsoft Azure.

  • Solo puede realizar búsquedas en una tabla de la Base de datos SQL de Microsoft Azure.

  • La búsqueda debe realizarse usando un par de clave-valor.

  • La búsqueda debe producir un solo valor, que es asignado a una propiedad del mensaje. Si la búsqueda produce más de un valor, se asigna el primero de ellos a la propiedad.

  • Puedes buscar un valor en varios orígenes de datos, lo que significa que se pueden realizar búsquedas en más de una tabla de la Base de datos SQL de Microsoft Azure o en más de una Base de datos SQL de Microsoft Azure.

Para ver instrucciones sobre cómo configurar la operación de búsqueda, consulte Create an XML Bridge o XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

La información sobre los proveedores se almacena en el archivo LookupProviderConfigurations.xml. Por su parte, la información sobre qué valores del encabezado se asignan a las propiedades del mensaje, qué valores se extraen y qué valores se buscan se almacena en un archivo de configuración del puente. Cuando genera un Proyecto de servicio de BizTalk, también el archivo LookupProviderConfigurations.xml se guarda en un archivo de configuración del puente. Cuando implementa el Proyecto de servicio de BizTalk, es el archivo de configuración del puente el que se implementa en el CmdLets.

En la fase de enriquecimiento, crea propiedades y asigna valores a las mismas. Pero la pregunta que viene a la mente es qué se puede hacer con dichas propiedades. ¿De qué manera hacen estas propiedades que mi tarea sea más fácil? Puede usar las propiedades de dos formas.

  • Puede usarlas para establecer condiciones de filtro para enrutar mensajes a distintos destinos. Para ver instrucciones sobre cómo se hace esto, consulte The Routing Condition.

  • Puede usar las propiedades para eliminar las discrepancias de protocolo entre el remitente del mensaje y el receptor del mismo. Por ejemplo, tiene un mensaje SOAP entrante con un valor de encabezamiento personalizado. Desea pasar dicho valor como encabezamiento personalizado de un mensaje HTTP porque el receptor del mensaje quiere un mensaje REST al no comprender el formato de mensajes SOAP. Puede usar las propiedades para hacerlo. Primero puede asignar el valor del encabezado del mensaje entrante a una propiedad (por ejemplo, P1) y, después, al enviar el mensaje al receptor, asignar el valor de la P1 al encabezado del mensaje saliente. Para obtener más información, vea Acciones de enrutamiento y respuesta: eliminación de discrepancias de protocolo.

En una Configuración del puente, las propiedades que define como parte de la fase de enriquecimiento están disponibles en todo el flujo del mensaje de cada fase de la Configuración del puente. En otras palabras, si ha definido una propiedad en la fase de enriquecimiento, puede usar dicha propiedad durante la fase de transformación así como para cualquier fase de asignación. Las propiedades definidas en la fase de enriquecimiento también pueden usarse fuera del límite de una Configuración del puente, teniendo en cuenta ciertas consideraciones. Antes de entrar en detalles, hay que entender que los valores de propiedad se almacenan como propiedades de la clase BrokeredMessage del CmdLets. Una vez que hemos comprendido este hecho, tratemos sobre la vigencia de las propiedades fuera de una Configuración del puente.

  • Dado que solo una cola o un tema del CmdLets puede consumir mensajes del tipo BrokeredMessage, las propiedades y sus valores (tales como un par clave-valor) pueden ser consumidos directamente por las colas y los temas. Tras ello, los temas, por ejemplo, pueden usar potencialmente las propiedades para más tareas de procesamiento y enrutamiento.

  • No puede pasar las propiedades y sus valores a otros componentes de la Configuración del puente, como por ejemplo, los extremos de retransmisión unidireccional/bidireccional o los extremos de servicio externo unidireccional/bidireccional. Si no desea pasar los valores de propiedad a estas entidades, debes asignar los valores de propiedad a los encabezados del mensaje saliente. Para obtener más información, vea Acciones de enrutamiento y respuesta: eliminación de discrepancias de protocolo.

  • En un escenario de «encadenamiento» en el que el mensaje de un puente se enruta a otro puente y, en última instancia, a una cola del CmdLets (por ejemplo), solo las propiedades del último puente de la cadena estarán disponibles para realizar más tareas de enrutamiento o procesamiento. Además, para pasar valores de propiedad a los siguientes puentes, se deben asignar los valores de propiedad a los encabezados del mensaje saliente. Dichas propiedades deben ser entonces extraídas al segundo puente.

La fase de Transformación, como su nombre sugiere, proporciona la funcionalidad de realizar transformaciones estructurales en los mensajes. Al igual que las otras fases de la canalización, la fase de Transformación puede funcionar con varios tipos de mensajes, de modo que se puede disponer de más de una transformación como parte de la fase de transformación. La transformación más adecuada para su realización se busca en el tiempo de ejecución según el tipo de mensaje entrante, siempre que las transformaciones correspondientes hayan sido configuradas y cargadas durante la configuración del puente. La resolución de transformaciones se produce según el tipo del mensaje entrante.

  • La fase de transformación coincide con el tipo de mensaje del esquema de origen de una asignación.

  • Si se desactiva la fase de validación, la fase de transformación hace coincidir el mensaje entrante con el esquema del mensaje de origen. Si se produce la resolución, esta promociona la propiedad MessageType del mensaje.

La presente versión solo admite transformaciones desde origen único a destino único. Para obtener más información, vea Aprender a crear mapas y transformaciones de mensajes. Para ver instrucciones sobre cómo configurar la fase de transformación, consulte Create an XML Bridge o XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

La fase de Enriquecimiento posterior a la transformación es similar a la fase de enriquecimiento anterior a la transformación. La única diferencia es que, en la fase de enriquecimiento posterior a la transformación, se puede enriquecer el mensaje transformado. El modo de configurar la fase de enriquecimiento sigue siendo el mismo que en la fase de enriquecimiento anterior a la transformación. Para ver instrucciones sobre cómo configurar la fase de enriquecimiento posterior a la transformación, consulte Create an XML Bridge o XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

noteNota
Todas las propiedades extraídas o buscadas antes de las fases de transformación se encuentran también disponibles en el mensaje que ha sido transformado. Una propiedad anteriormente extraída o enriquecida será sobrescrita si es modificada durante una fase de enriquecimiento posterior a la transformación.

En la sección anterior hemos visto que en la fase de Validación esta se realiza en relación con esquemas y que en la fase de Transformación se transforma el mensaje usando una transformación. Por tanto, los artefactos que están disponibles como parte de un Puente XML son:

  • Esquemas. Tienen la extensión .XSD

  • Transformaciones. Tienen la extensión .TRFM y pueden existir varias transformaciones en una fase de transformación.

  • Ensamblados. Incluyen la lógica de procesamiento personalizado que puede incorporarse en fases específicas del puente.

  • Certificados. Se usan para realizar la transferencia segura de mensajes.

noteNota
Un archivo de configuración del puente no es un artefacto porque no se puede compartir entre distintos puentes. Un archivo de configuración del puente es específico de un puente.

La aplicación del servicio de BizTalk puede tener varios puentes y cada uno de estos puentes puede utilizar varias transformaciones y esquemas. Por ello, una aplicación típica de Servicios de BizTalk tendría un número elevado de transformaciones y esquemas. Sin embargo, al mismo tiempo, todas las transformaciones y esquemas pueden no ser necesarios para cada Puente XML. Por tanto, debe haber una manera de asociar dichas transformaciones y esquemas a un puente. Esta asociación puede realizarse mientras se configura el puente.

Para asociar esquemas y transformaciones, consulte Crear un puente unidireccional XML o Crear un puente de solicitud y respuesta XML.

Un Puente paso a través se utiliza cuando se quiere que cualquier tipo de mensaje sea procesado por el puente. Como resultado, un Puente paso a través no incluye fases de validación ni de transformación porque estas dos fases están vinculadas a los tipos de mensajes. Un Puente paso a través solo incluye la fase de Enriquecimiento, la cual se utiliza con el mismo propósito que en un Puente XML. Para obtener más información sobre cómo configurar un Puente paso a través, consulte Crear un puente de paso a través.

Vea también

Mostrar: