Exportar (0) Imprimir
Expandir todo

How to integrate BizTalk Server 2010 / 2013 with Service Bus for Windows Server

Actualizado: marzo de 2014

Autor: Paolo Salvatori

Revisores: Mandi Ohlinger

(Descargar ejemplo: Cómo integrar BizTalk Server 2010/2013 con Service Bus para Windows Server

Microsoft BizTalk Server permite a las organizaciones conectar y ampliar sistemas heterogéneos en la empresa y con asociados comerciales. Service Bus proporciona capacidades de conectividad, puesta en cola y enrutamiento para las aplicaciones locales y en la nube. En la nube, Service Bus está disponible en la plataforma . En local, Service Bus para Windows Server está disponible como un conjunto de componentes y servicios instalables.

Este tema incluye un ejemplo que evolucionó de Cómo integrar una aplicación de BizTalk Server 2010 con las colas y los temas de Service Bus. Este ejemplo muestra cómo usar WCF con NetMessagingBinding para integrar una aplicación de BizTalk Server 2010/2013 con Service Bus para Windows Server.

La solución utiliza los siguientes componentes para integrar BizTalk Server y Service Bus para Windows Server:

En este artículo se muestra cómo usar estos componentes en una aplicación de BizTalk y cómo configurar una aplicación cliente de WCF para implementar lo siguiente:

  • Enviar mensajes a una aplicación de BizTalk Server 2010/2013 con una cola Service Bus.

  • Enviar mensajes a una aplicación de BizTalk Server 2010/2013 con un tema Service Bus.

  • Recibir mensajes de una aplicación de BizTalk Server 2010/2013 con una cola Service Bus.

  • Recibir mensajes de una aplicación de BizTalk Server 2010/2013 con una suscripción Service Bus.

Para enviar mensajes a la aplicación de BizTalk, puede usar la herramienta Explorador de Service Bus o usar la aplicación cliente incluida en este ejemplo. Esta aplicación cliente usa Microsoft.ServiceBus.dll para intercambiar mensajes con la aplicación de BizTalk con WCF.

Hay dos escenarios:

Escenario 1: la aplicación usa puertos de envío estáticos.

Escenario 2: la aplicación cliente especifica la URL de la cola o el tema de respuesta.

La aplicación cliente de Windows Forms simula un sistema de línea de negocio (LOB) local. El sistema de LOB intercambia mensajes con una aplicación de BizTalk Server que usa colas, temas y suscripciones que proporciona Service Bus para Windows Server. En este escenario, la aplicación de BizTalk Server 2010/2013 usa puertos de envío estáticos y la misma cola o tema para devolver la respuesta al llamador.

  1. La aplicación cliente de Windows Forms usa un proxy WCD para enviar un mensaje de solicitud a requestqueue o a requesttopic.

  2. La aplicación de BizTalk Server usa un puerto de recepción unidireccional para recibir mensajes de solicitud de Service Bus. Concretamente, una ubicación de recepción personalizada de WCF (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Queue.ReceiveLocation) lee mensajes de solicitud de requestqueue. Una segunda ubicación de recepción personalizada de WCF (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Subscription.ReceiveLocation) recibe mensajes de solicitud de la suscripción italyMilan de requesttopic. Ambas ubicaciones de recepción reciben los siguientes componentes:

    • NetMessagingBinding recibe mensajes de una cola o suscripción.

    • En tiempo de ejecución, un inspector de mensajes de WCF personalizado (ServiceBusMessageInspector) lee BrokeredMessageProperty de la colección Propiedades del Mensaje de WCF de entrada. El inspector de mensajes de WCF (ServiceBusMessageInspector) transforma sus propiedades estándar (como MessageId y ReplyTo) y las propiedades específicas de la aplicación (los pares de clave-valor en la colección Propiedades de BrokeredMessageProperty) en las propiedades de contexto del mensaje de BizTalk.

    • La ubicación de recepción personalizada de WCF usa ListenUriEndpointBehavior que recupera mensajes de la suscripción ItalyMilan definida en requesttopic. Este componente personalizado establece el valor de la propiedad ListenUri del extremo del servicio. ListenUriEndpointBehavior se describe más adelante en este artículo.

    • Si una aplicación recupera mensajes de una cola o suscripción con sesión, SessionChannelEndpointBehavior se debe agregar a la configuración de la ubicación de recepción personalizada de WCF. Este componente personalizado confirma que en tiempo de ejecución el adaptador personalizado de WCF crea IInputSessionChannel en lugar de IInputChannel. Como requisito obligatorio debe agregar SessionChannelEndpointBehavior para recibir mensajes de una entidad de mensajería con sesión.

    • TokenProviderEndpointBehavior permite a la ubicación de recepción autenticarse en el STS local que utiliza el espacio de nombres Service Bus con WindowsTokenProvider o OAuthTokenProvider. Al usar WindowsTokenProvider, puede usar la cuenta de servicio de instancia de host que ejecuta la ubicación de recepción para autenticarse en el STS local, o bien, puede especificar credenciales alternativas. Al usar OAuthTokenProvider, especifique siempre credenciales con el formato de nombre de usuario, contraseña o dominio. LocalMachine\LocalUser o Domain\DomainUser se utiliza para acceder al espacio de nombres Service Bus. La cuenta de usuario que utiliza la ubicación de recepción debe estar autorizada para acceder al espacio de nombres Service Bus que hospeda la cola o la suscripción. Para autorizar a la cuenta de usuario a acceder al espacio de nombres, puede usar el cmdlet de Windows PowerShell New-SBNamespace cuando crea el espacio de nombres, o el cmdlet Set-SBNamespace para agregar la cuenta de usuario al grupo de administradores de espacio de nombres.

  3. El Agente de mensaje envía el mensaje de solicitud al Cuadro de mensajes (BizTalkMsgBoxDb).

  4. La solicitud de entrada inicia una nueva instancia de StaticSendPortOrchestrationStaticSendPortOrchestration usa un puerto directo para recibir mensajes de solicitud que cumplen la siguiente expresión de filtro:

    Microsoft.WindowsAzure.CAT.Samples.ServiceBusForWindowsServer.Schemas.Method == Static

    La orquestación invoca un método que expone el componente auxiliar RequestManager para calcular el mensaje de respuesta. Copia las propiedades de contexto del mensaje de solicitud al mensaje de respuesta y asigna el valor de propiedad de contexto MessageId del mensaje de solicitud a la propiedad CorrelationId del mensaje de respuesta. Por último, comprueba el valor de cadena contenido en la propiedad del contexto ReplyTo. Si el valor de cadena contiene la palabra "cola", la orquestación devuelve el mensaje de respuesta a través de un puerto lógico enlazado a un puerto de envío personalizado de WCF configurado para enviar mensajes a responsequeue. De lo contrario, publica la respuesta al Cuadro de mensajes con un puerto de envío lógico enlazado a un puerto de envío personalizado de WCF configurado para enviar mensajes a responsetopic.

  5. El Agente de mensaje envía el mensaje de solicitud al Cuadro de mensajes (BizTalkMsgBoxDb).

  6. Uno de los siguientes puertos de envío personalizados de WCF utiliza el mensaje de respuesta:

    • ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Queue.SendPort: escribe el mensaje de respuesta a responsequeue.

    • ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Topic.SendPort: escribe el mensaje de respuesta a responsetopic.

  7. El puerto de envío seleccionado escribe el mensaje de respuesta a responsequeue o a responsetopic. Ambos puertos de envío están configurados para usar los siguientes componentes:

    • NetMessagingBinding envía mensajes a Service Bus.

    • ServiceBusMessageInspector transforma las propiedades de contexto del mensaje en propiedades BrokeredMessage.

    • TokenProviderEndpointBehavior permite al puerto de envío autenticarse en el STS local que utiliza el espacio de nombres Service Bus con WindowsTokenProvider o OAuthTokenProvider. También se aplican las mismas consideraciones para enviar puertos cuando se usa este componente en una ubicación de recepción.

  8. La aplicación cliente utiliza un servicio WCF con dos extremos para recuperar el mensaje de respuesta de responsequeue o responsetopic. En un entorno con varias aplicaciones cliente, cada extremo debe utilizar una cola o una suscripción independiente para recibir los mensajes de respuesta de BizTalk Server.

La aplicación cliente de Windows Forms también simula un sistema de línea de negocio (LOB). El sistema de LOB intercambia mensajes con una aplicación de BizTalk Server que usa colas, temas y suscripciones que proporciona Service Bus para Windows Server. En este escenario, la aplicación cliente especifica la URL de la cola o tema de respuesta en la propiedad ReplyTo. La especificación de la URL permite que diferentes aplicaciones cliente envíen solicitudes a través de la misma cola o tema; sin embargo, esta usa diferentes colas y temas para recibir respuestas. Esta arquitectura permite a la aplicación de BizTalk usar un único puerto de envío dinámico para transmitir respuestas a aplicaciones cliente.

  1. La aplicación cliente de Windows Forms usa un proxy WCD para enviar un mensaje de solicitud a requestqueue o a requesttopic.

  2. La aplicación de BizTalk Server usa un puerto de recepción unidireccional para recibir mensajes de solicitud de Service Bus. Concretamente, una ubicación de recepción personalizada de WCF (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Queue.ReceiveLocation) lee mensajes de solicitud de requestqueue. Una segunda ubicación de recepción personalizada de WCF (ServiceBusForWindowsServer.WCF-Custom.NetMessagingBinding.Subscription.ReceiveLocation) recibe mensajes de solicitud de la suscripción italyMilan de requesttopic. Ambas ubicaciones de recepción están configuradas para usar los siguientes componentes:

    • NetMessagingBinding recibe mensajes de una cola o suscripción.

    • En tiempo de ejecución, un inspector de mensajes de WCF personalizado (ServiceBusMessageInspector) lee BrokeredMessageProperty de la colección Propiedades del Mensaje de WCF de entrada. El inspector de mensajes de WCF (ServiceBusMessageInspector) transforma sus propiedades estándar (como MessageId y ReplyTo) y las propiedades específicas de la aplicación (los pares de clave-valor contenidos en la colección Propiedades de BrokeredMessageProperty) en las propiedades de contexto del mensaje de BizTalk.

    • La ubicación de recepción personalizada de WCF usa ListenUriEndpointBehavior que recupera mensajes de la suscripción ItalyMilan definida en requesttopic. Este componente personalizado establece el valor de la propiedad ListenUri del extremo del servicio. ListenUriEndpointBehavior se describe más adelante en esta nota del producto en ListenUriEndpointBehavior.

    • Si una aplicación recupera mensajes de una cola o suscripción con sesión, SessionChannelEndpointBehavior se debe agregar a la configuración de la ubicación de recepción personalizada de WCF. SessionChannelEndpointBehavior confirma que en tiempo de ejecución el adaptador personalizado de WCF crea IInputSessionChannel en lugar de IInputChannel. Como requisito obligatorio debe agregar SessionChannelEndpointBehavior para recibir mensajes de una entidad de mensajería con sesión.

    • TokenProviderEndpointBehavior permite a la ubicación de recepción autenticarse en el STS local que utiliza el espacio de nombres Service Bus con WindowsTokenProvider o OAuthTokenProvider. Al usar WindowsTokenProvider, puede usar la cuenta de servicio de host que ejecuta la ubicación de recepción para autenticarse en el STS local, o bien, puede especificar credenciales alternativas. Al usar OAuthTokenProvider, especifique siempre credenciales con el formato de nombre de usuario, contraseña o dominio. LocalMachine\LocalUser o Domain\DomainUser se utiliza para acceder al espacio de nombres Service Bus. La cuenta de usuario que utiliza la ubicación de recepción debe estar autorizada para acceder al espacio de nombres Service Bus que hospeda la cola o la suscripción. Para autorizar a la cuenta de usuario a acceder al espacio de nombres, puede usar el cmdlet de Windows PowerShell New-SBNamespace cuando crea el espacio de nombres, o el cmdlet Set-SBNamespace para agregar la cuenta de usuario al grupo de administradores de espacio de nombres.

  3. El Agente de mensaje envía el mensaje de solicitud al Cuadro de mensajes (BizTalkMsgBoxDb).

  4. La solicitud de entrada inicia una nueva instancia de DynamicSendPortOrchestrationDynamicSendPortOrchestration usa un puerto directo para recibir mensajes de solicitud que cumplen la siguiente expresión de filtro:

    Microsoft.WindowsAzure.CAT.Samples.ServiceBusForWindowsServer.Schemas.Method == Dynamic

    La orquestación invoca un método que expone el componente auxiliar RequestManager para calcular el mensaje de respuesta. Copia las propiedades de contexto del mensaje de solicitud al mensaje de respuesta y asigna el valor de propiedad de contexto MessageId del mensaje de solicitud a la propiedad CorrelationId del mensaje de respuesta. A continuación, lee la dirección de la entidad de mensajería (cola o tema) a la que se va a enviar la respuesta de la propiedad de contexto ReplyTo. Finalmente, la orquestación configura las propiedades de contexto del mensaje de respuesta y las propiedades del puerto de envío dinámico para usar los siguientes componentes:

    • NetMessagingBinding envía mensajes a Service Bus.

    • ServiceBusMessageInspector transforma las propiedades de contexto del mensaje en propiedades BrokeredMessage.

    • TokenProviderEndpointBehavior permite a la ubicación de recepción autenticarse en el STS local que utiliza el espacio de nombres Service Bus con WindowsTokenProvider o OAuthTokenProvider.

  5. El Agente de mensaje envía el mensaje de solicitud al Cuadro de mensajes (BizTalkMsgBoxDb).

  6. El puerto de envío unidireccional dinámico ServiceBusForWindowsServer.Dynamic.SendPort utiliza el mensaje de respuesta.

  7. El puerto de envío dinámico utiliza el adaptador personalizado de WCF y NetMessagingBinding según especifica la orquestación para devolver la respuesta a la entidad de mensajería (en este ejemplo, responsequeue o responsetopic) cuya dirección está especificada en la aplicación cliente en la propiedad ReplyTo de BrokeredMessageProperty.

  8. La aplicación cliente utiliza un servicio WCF con dos extremos para recuperar el mensaje de respuesta de responsequeue o responsetopic. En un entorno con varias aplicaciones cliente, cada extremo debe utilizar una cola o una suscripción independiente para recibir los mensajes de respuesta de BizTalk Server.

Vea también

Mostrar:
© 2014 Microsoft