Paolo Salvatori's Blog

Adventures in the magic world of Windows Azure

How to integrate BizTalk Server 2013 with Windows Azure Service Bus

How to integrate BizTalk Server 2013 with Windows Azure Service Bus

Rate This
  • Comments 14

How to integrate a BizTalk Server 2013 application with Window Azure Service Bus Brokered and Relayed Messaging

Introduction

Microsoft BizTalk Server enables organizations to connect and extend heterogeneous systems across the enterprise and with trading partners. The Service Bus is part of Windows Azure and is designed to provide connectivity, queuing, and routing capabilities not only for the cloud applications but also for on-premises applications. Using both together enables a significant number of scenarios in which you can build secure, reliable and scalable hybrid
solutions that span the cloud and on premises environments:

  • Exchange electronic documents with trading partners.
  • Expose services running on-premises behind firewalls to third parties.
  • Enable communication between spoke branches and a hub back office system.


This sample is the evolution of my previous article How to integrate a BizTalk Server 2010 application with Service
Bus Queues and Topics
. This solution shows how to integrate a BizTalk Server 2013 application with the Windows Azure Service Bus to exchange messages with external systems in a reliable, flexible, and scalable manner. In particular, this solution demonstrates how to use the new SB-Messaging adapter to integrate a BizTalk application with Windows Azure Service Bus Queues, Topics and Subscriptions, and how to use the WCF-NetTcpRelay and WCF-BasicHttpRelay adapters to let a BizTalk Server 2013 application expose a receive location in the cloud as a Service Bus Relay Service.

In this demo you will learn how to use the classes in the Service Bus .NET API contained in the Microsoft.ServiceBus library and the new Service Bus adapters provided by BizTalk Server 2013 to perform the following operations:

  • Send messages to a BizTalk Server 2013 application via a Service Bus queue.
  • Send messages to a BizTalk Server 2013 application via a Service Bus topic.
  • Receive messages from a BizTalk Server 2013 application via a Service Bus queue.
  • Receive messages from a BizTalk Server 2013 application via a Service Bus subscription.
  • Invoke a WCF-NetTcpRelay receive location exposed by a BizTalk Server 2013 application.

In order to send messages to the BizTalk application, you can use the Service Bus Explorer tool or you can leverage the client application included in the solution. This client application makes use of the Microsoft.ServiceBus.dll to exchange messages with the BizTalk application via the Service Bus Brokered and Relayed Messaging. In particular, the client application allows to choose between 5 different synchronous and asynchronous ways to send messages to a queue or a topic.

In this demo you will also learn how to translate the explicit and user-defined properties of a BrokeredMessage object into the context properties of a BizTalk message and viceversa using the functionality supplied by the SB-Messaging adapter.

The following picture shows the first of the three scenarios implemented by the sample. In this context, the Windows Forms client application simulates a line-of-business system running on-premises or in the cloud that exchanges messages with a BizTalk Server application by using queues, topics and subscriptions provided by the Service Bus messaging infrastructure. In this sample, the BizTalk Server 2013 application uses always the same queue or topic to send the response back to the caller.

 

Message Flow:

  1. A Windows Forms application uses a MessageSender object to send a request message to a BizTalk Server 2013 application running on-premises or in the cloud via a Service Bus queue or topic.
  2. The BizTalk Server 2013 application uses a SB-Messaging Receive Location to receive the request message from the request queue or subscription. The SB-Messaging Adapter promotes the standard and      custom properties of the BrokeredMessage  into message context properties of the BizTalk message.
  3. The request message is published to the MessageBox.
  4. The request message triggers an instance of the StaticSendPortOrchestration. The orchestration processes the incoming request and generates a response message. If the string contained in the ReplyTo context property contains the word queue, the response message is sent back to response queue via the corresponding SB-Messaging One-Way Static Send Port, otherwise is sent to the response topic via another send port. The orchestration copies the context properties from the request to response message.
  5. The response message is published to the MessageBox.
  6. The response message is consumed by a SB-Messaging One-Way Static Send Port. The SB-Messaging      Adapter transforms the context properties of the response message into standard and custom properties of the outgoing BrokeredMessage object.
  7. The SB-Messaging One-Way Static Send Port sends the reply message to the response queue or topic as specified by the caller in the ReplyTo context property of the request message.
  8. The client application uses a MessageReceiver object to retrieve the reply message from the response queue/subscription.

The following picture shows the second of the three scenarios implemented by the sample. The Windows Forms client application still simulates a line-of-business system running on-premises or in the cloud that exchanges messages with a BizTalk Server application by using queues, topics and subscriptions provided by the Service Bus messaging infrastructure. However, in this case the client application specifies the URL of the response queue or topic in the ReplyTo property.

 

Message Flow:

 

  1. A Windows Forms application uses a MessageSender object to send a request message to a BizTalk Server 2013 application running on-premises or in the cloud via a Service Bus queue or topic.
  2. The BizTalk Server 2013 application uses a SB-Messaging Receive Location to receive the request message from the request queue or subscription. The SB-Messaging Adapter promotes the standard and      custom properties of the BrokeredMessage  into message context properties of the BizTalk message.
  3. The request message is published to the MessageBox.
  4. The request message triggers an instance of the DynamicSendPortOrchestration. The orchestration processes the incoming request and generates a response message. The orchestration reads the address of the response queue or topic from the ReplyTo context property of the incoming message and properly sets the context properties of the outgoing response message and the properties of the Dynamic Send Port used to send the response to the caller. The orchestration copies the context properties from the request to response message.
  5. The response message is published to the MessageBox.
  6. The response message is consumed by a Dynamic Send Port. The SB-Messaging Adapter transforms      the context properties of the response message into standard and custom properties of the outgoing BrokeredMessage object.
  7. The Dynamic Send Port sends the reply message to the response queue or topic whose URL was specified  by the caller in the ReplyTo context property of the request message.
  8. The client application uses a MessageReceiver object to retrieve the reply message from the response queue/subscription

The following picture show the third scenario implemented by this sample. In this case, the Windows Forms client application uses a WCF proxy with the NetTcpRelayBinding client endpoint to invoke a WCF-NetTcpRelay
Two-Way Request-Response Receive Location
exposed by the BizTalk Server 2013 application.

 

Message Flow:

 

  1. A Windows Forms application uses a WCF proxyto send a request message to a BizTalk Server 2013 application via a Service Bus Relay Service.
  2. The BizTalk Server 2013 application uses a WCF-NetTcpRelay Receive Location to receive the request message from the Service Bus Relay Service.
  3. The request message is  published to the MessageBox.
  4. The request message triggers an instance of the RelayServiceOrchestration. The orchestration processes the incoming request and generates a response message.
  5. The response message is published to the MessageBox.
  6. The response message is returned to the WCF-NetTcpRelay Receive Location that received the initial call.
  7. The WCF-NetTcpRelay Receive Location returns the response message to the Service Bus Relay Service.
  8. The Service Bus Relay Service returns the response message to the client application.

 

Requirements

The following list contains the software required for building and running the sample:

  • Windows Server 2008 R2 SP1, Windows Server 2012, Windows 7 SP1, Windows 8 or higher.
  • Windows Azure Service Bus 1.8 or higher.
  • BizTalk Server 2013
  • SQL Server 2012 or SQL Server 2008 R2 SP1
  • NET Framework 4.5
  • Visual Studio 2012
  • Any Microsoft SDK which provides a gacutil version for .NET 4.0/4.5.

Building the Sample

Inside the zip file you can find a Readme file with the instructions on how to install the demo. In particular, the Setup folder contains the binding file to create the receive locations and send ports required by the solution.  

Note 1: to create the Service Bus queues, topics and subscriptions required by the sample you can use the Provisioning console application contained in the solution.

Note 2: before importing the binding file in your BizTalk Server 2013 application, make sure to perform the following
operations:

 

  • Open the binding file and replace the [SERVICE_BUS_NAMESPACE] placeholder with the name of your Windows Azure Service Bus namespace.
  • Create the following 2 in-process hosts and specify the same service account of the BizTalkServerApplication
    host.
    • BizTalkServerReceiveHost64
    • BizTalkServerSendHost64
  • Create a new Send Handler for the SB-Messaging adapter and specify BizTalkServerSendHost64 as the host.
  • Create a new Receive Handler for the SB-Messaging adapter and specify BizTalkServerReceiveHost64 as the host.
  • Create a new Receive Handler for the WCF-NetTcpRelay and WCF-BasicHttpRelay adapter and specify
    BizTalkServerReceiveHost64 as the host.

Note 3: make sure to replace the [ISSUER_SECRET] and [SERVICE_BUS_NAMESPACE] placeholders in the following solution files:

  • BusinessLogic\ResponseManager.cs
  • Client\App.config.

Nota 4: if you use session-aware request queue and subscription you need to specify this explicitly in both SB-Messaging receive Locations configuration as shown in the picture below:

 


Running the Sample

Assuming that you have already deployed and properly configured the solution, you can proceed as follows to test it.

  • To send a request message to the StaticSendPortOrchestration, set the value of the Method property to Static2013.
  • To send a request message to the DynamicSendPortOrchestration, set the value of the Method property to Dynamic2013.
  • To send a request message to the BizTalk Server 2013 application via the requestqueue, select the Queue radio button in the Request Methods group.
  • To send a request message to the BizTalk Server 2013 application via the requesttopic, select the Topic radio button in the Request Methods group.
  • To ask the BizTalk Server 2013 application to send the response message via the responsequeue, select the Queue radio button in the Response Methods group.
  • To ask the BizTalk Server 2013 application to send the response message via the responsetopic, select the Topic radio button in the Response Methods group.

The figure below shows the how to use the client application to invoke the most interesting combination:

  • The client sends the request message to the requesttopic.
  • The BizTalk Server 2013 application reads the request from the ItalyMilan subscription of the requesttopic using a SB-Messaging Receive Location.
  • The adapter turns the standard and custom properties (e.g. Country, City, etc.) of the incoming BrokeredMessage into context properties of the corresponding BizTalk message.
  • The DynamicSendPortOrchestration processes the incoming request, creates a response, copies context properties from the request to the response and sends the response message to the responsetopic using the dynamic send port.
  • The client application receives the response message via the ItalyMilan subscription defined on the responsetopic.

Note 1: you can select one of 5 different methods to send a BrokeredMessage to the BizTalk Server 2013 application.

 

Note 2: you can use DebugView to monitor the trace messages produced by the orchestrations.


 

Article

I’ll soon publish an article on MSDN to describe the solution in detail. So come back later for the link! The demo code can be found on MSDN Code Gallery.

  • Hi Paolo,

    Did you get time to publish the detailed description of the above solution.If so, please provide me with the link.

    Thanks

  • Hi Swaran

    Unfortunately this is one of the few, probably the one, solution for which I didn't provide a detailed description. Sorry about that. :(

    Ciao

    Paolo

  • Hi Paolo,

    Is it possible to expose orchestration as a web service and consume the same using Windows Azure BizTalk services.

    In our project we have a requirement to use orchestrations, so as orch is not supported in WABS. Is there any other ways we can achieve the same.

    Please help me in this regard.

    Thanks.

  • Absolutely, you can expose the orchestration using the Service Bus Relayed Messaging and call the endpoint from a bridge running In Windows Azure BizTalk Services. Just create a receive location based  on one of the following adapters:

    - WCF-NetTcpRelay

    - WCF-BasicHttpRelay

    - WCF-Custom + Service Bus binding (BasicHttpRelayBinding, NetTcpRelayBinding)

    See the bridge contained in my sample code.msdn.microsoft.com/.../How-to-integrate-Mobile-6718aaf2 to understand how to invoke the WCF receive location from a bridge.

    Ciao

    Paolo

  • Thanks alot Paolo...

    Will try to simulate the same and let you know for any issues... :)

    Thanking you again for the quick reply... :)

  • Hi Paolo,

    Could you please help me with a small demo on how to expose the orchestration using the Service Bus Relayed Messaging and calling the endpoint from a bridge running In Windows Azure BizTalk Services.

    Thanks

  • Hi mate

    I'm extremely busy in this period, I don't have time to build a demo, sorry about that. See how to expose a relay service using a WCF adapter in my sample code.msdn.microsoft.com/.../How-to-integrate-Mobiles-77b25d12.  I will have time just starting in mid-March, unless something new arrives on my plate before that date. :)

    Ciao

    Paolo

  • Not a prob..Will try to work it out.....Thanks alot for all your help.. :)

    Thanks

  • Hi Paolo,

    I have exposed the orchestration as a WCF service, but the service endpoints (.svc and .svc_mex) are not getting listed out under the service bus in WABS portal.

    What could be the reason for the same?

    Thanks

  • Hi Swaran

    please, contact me on the email. This blog is not meant to receive suggestions for a PoC. :) Said that, I don't understand where you are searching for the service relay endpoint  on the WABS portal. You should rather search for them in the Relays tab under the your Service Bus namespace on the WA management portal. Make sure to use the serviceRegistrySettings endpoint behavior to make your WCF receive location discoverable. :)

    Ciao

    Paolo

  • Sure will do that.And sorry for the same.Could you please provide me with your email ID.

  • Thanks Paolo,

    I'm really enjoying your insights -- and absolutely love the SB Explorer (nice work).

    In this entry though, I'm missing the value added by using SB Queues/Topics to transport the request/response through to the BizTalk Orchestration.  We could just as easily and more simply use an exposed WCF Service BizTalk endpoint.  Am I missing something?

    We're thinking of adding Windows Server SB to our integration platform but might limit it to pub/sub solutions at least until the relay service is available (wish, wish) -- does that sound typical?

    Thanks again for all you do

    JimF

  • Hi Jim

    thanks for the feedback! :) To answer your question, I would say, it depends on what binding you use on your WCF-Custom receive location:

    - Service Bus Topics and Queues provides a pub/sub, asynchronous, pull model while WCF typical bindings (e.g. NetTcpBinding or its Service Relay counterpart, NetTcpRelayBinding) provides a synchronous, push model.

    - When using Topics and Queues, sender and receiver don't necessarily need to be up at the same time, while this is strictly necessary when using WCF with any binding provising a synchronous message Exchange pattern

    - Service Bus Topics and Queues provide many functions out of the box: duplicate detection, scheduled messages, sessions, message time to live, etc.

    I can guarantee that there are a ton of customers using BizTalk along with Service Bus... I can't make names here, but also big companies. ;)

    Ciao

    Paolo

  • Thanks Paolo,

    That makes alot of sense.  And I totally appreciate your enthusiastic endorsement.  

    You've led me to recognize that I'm not placing a high enough value on the durable messaging feature of the Service Bus.  We tend to think in terms of the Request-Response  pattern even when it's not required or even appropriate.

    THanks for your help -- I feel a little more confident thinking through the addition of Service Bus features to the integration platform.

    Hope that all is going well.

    Jim

Page 1 of 1 (14 items)
Leave a Comment
  • Please add 8 and 8 and type the answer here:
  • Post
Search Blogs