While in Europe last week presenting at the Integration Days event, I showed off some demonstration of cool new technologies working with existing integration tools. One of those demos combined SignalR and BizTalk Server in a novel way.

One of the use cases for an integration bus like BizTalk Server is to aggregate data from multiple back end systems and return a composite message (also known as a Scatter-Gather pattern). In some cases, it may make sense to do this as part of a synchronous endpoint where a web service caller makes a request, and BizTalk returns an aggregated response. However, we all know that BizTalk Server’s durable messaging architecture introduces latency into the communication flow, and trying to do this sort of operation may not scale well when the number of callers goes way up. So how can we deliver a high-performing, scalable solution that will accommodate today’s highly interactive web applications? In this solution that I build, I used ASP.NET and SignalR to send incremental messages from BizTalk back to the calling web application.

The end user wants to search for product inventory that may be recorded in multiple systems. We don’t want our web application to have to query these systems individually, and would rather put an aggregator in the middle. Instead of exposing the scatter-gather BizTalk orchestration in a request-response fashion, I’ve chosen to expose an asynchronous inbound channel, and will then send messages back to the ASP.NET web application as soon as each inventory system respond.

First off, I have a BizTalk orchestration. It takes in the inventory lookup request and makes a parallel query to three different inventory systems. In this demonstration, I don’t actually query back-end systems, but simulate the activity by introducing a delay into each parallel branch.

As each branch concludes, I send the response immediately to a one-way send port. This is in contrast to the “standard” scatter-gather pattern where we’d wait for all parallel branches to complete and then aggregate all the responses into a single message. This way, we are providing incremental feedback, a more responsive application, and protection against a poor-performing inventory system.

After building and deploying this solution, I walked through the WCF Service Publishing Wizard in order to create the web service on-ramp into the BizTalk orchestration.

I couldn’t yet create the BizTalk send port as I didn’t have an endpoint to send the inventory responses to. Next up, I built the ASP.NET web application that also had a WCF service for accepting the inventory messages. First, in a new ASP.NET project in Visual Studio, I added a service reference to my BizTalk-generated service. I then added the NuGet package for SignalR, and a new class to act as my SignalR “hub.” The Hub represents the code that the client browser will invoke on the server. In this case, the client code needs to invoke a “lookup inventory” action which will forwards a request to BizTalk Server. It’s important to notice that I’m acquiring and transmitting the unique connection ID associated with the particular browser client.

Next, I added a single Web Form to this ASP.NET project. There’s nothing in the code-behind file as we’re dealing entirely with jQuery and client-side fun. The HTML markup of the page is pretty simple and contains a single textbox that accepts a inventory part number, and a button that triggers a lookup. You’ll also notice a DIV with an ID of “responselist” which will hold all the responses sent back from BizTalk Server.

The real magic of the page (and SignalR) happens in the head of the HTML page. Here I referenced all the necessary JavaScript libraries for SignalR and jQuery. Then I established a reference to the server-side SignalR Hub. Then you’ll notice that I create a function that the *server* can call when it has data for me. So the *server* will call the “addLookupResponse” operation on my page. Awesome. Finally, I start up the connection and define the click function that the button on the page triggers.

Nearly done! All that’s left is to open up a channel for BizTalk to send messages to the target browser connection. I added a WCF service to this existing ASP.NET project. The WCF contract has a single operation for BizTalk to call.

Notice that BizTalk is sending back the client (connection) ID corresponding to whoever made this inventory request. SignalR makes it possible to send messages to ALL connected clients, a group of clients, or even individual clients. In this case, I only want to transmit a message to the browser client that made this specific request.

After adding the rest of the necessary WCF service details to the web.config file of the project, I added a new BizTalk send port targeting the service. Once the entire BizTalk project was started up (receive location for the on-ramp WCF service, orchestration that calls inventory systems, send port that sends responses to the web application), I browsed to my ASP.NET site.

For this demonstration, I opened a couple browser instances to prove that each one was getting unique results based on whatever inventory part was queried. Sure enough, a few seconds after entering in a random part identifier, data starting trickling back. On each browser client, results were returned in a staggered fashion as each back-end system returned data.

I’m biased of course, but I think that this is a pretty cool query pattern. You can have the best of BizTalk (e.g. visually modeled workflow for scatter-gather, broad application adapter choice) while not sacrificing interactivity and performance.

I have re-created all the artifacts as per the design and everything works perfectly fine except the send port not calling the web application’s WCF service. Can you please walk me through the process of calling the publishresponse Operation from BizTalk Send Port.

Thanks for the Quick Response, I have done this but the still the orchestration is in the Dehydrated status. To Debug i have provided the Backup Transport to FILE and the XML files are placed in the folder after 3 retries without any problem with actual data from Orchestration Transformed message. Any Idea why the orchestration is going to the Dehydrated status?

Man you are fast responding – This is what the event log states. is the OperationContract arguments have to match the Schema on the BizTalk Orchestration send?

The adapter failed to transmit message going to send port “SendInventoryResponse” with URL “http://localhost/IntegrationDays.SignalRDemo/InventoryResponseService.svc.”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.ServiceModel.FaultException: a:ActionNotSupportedThe message with Action ‘<BtsActionMapping xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<Operation Name=”PublishQuotes” Action=”http://tempuri.org/IInventoryResponseService/PublishResults” />
</BtsActionMapping>’ cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)”.

So one thing I didn’t point out in the blog post is that I actually created the SignalR piece FIRST, and then did an “add generated items” to BizTalk in order to get the right WCF schemas and binding file. Consider doing that to get past any mismatch problem. The SignalR piece can’t be done until BizTalk development is done because the ASP.NET app needs the BizTalk service endpoint, but I ended up building enough of each to connect them!

Richard, The “add generated items” tip worked great and i was doing one more mistake by not exactly specifying the Send Port Operation name from “Operation_1” to “PublishResults”. These changes made the solution work perfectly fine. Thanks for all your support, this SignalR is very revolutionary and have solved the long time Web application Problem.

Works like a charm. Thanks. In one of my previous contract we exposed BizTalk orchestrations as a WCF service and it was consumed by a front end java web app. The BizTalk orchestration calls a variety of back end services and we implemented a call back functionality to update the status to the web application in an asynchronous fashion. Had we known this 2 years before we coiuld have implemented this. How long SignalR has been in the technology space? any idea?

I try to run your demo solution, but I don’t understand this part “the WCF Service Publishing Wizard in order to create the web service on-ramp into the BizTalk orchestration.”. The input and output body message are defined “use=literal”.

Does it mean that we don’t use the predefined schema here?
And where can I define “use=literal” in the wizard? Because I need to select an input and an output schema.