Recently I faced the challenge of returning a delivery acknowledgement message to an WCF service when it shoots a new message in our BizTalk environment. All this needs to be done using “context based routing”, in other words, without the use of an orchestration. Main reason for this is the extra performance overhead you get using orchestrations.
To sum it all up, our goal for today is:
- DON’T USE ORCHESTRATIONS!
- Send a dummy message to the WCF service.
- Wait for the message to be placed into the BizTalk messagebox.
- Receive an acknowledgement that the message is indeed accepted by BizTalk.
After some “intelli searching” on the web I came across this article of Daniel Probert. In this article he shares his vision on the problem at hand. Being a total newby in BizTalk world his explanation was a bit mindboggling for me. After a couple of hours playing with the concept I manage to recreated his concept to the point I actually understood what was going on beneath the shiny surface.
It all has to do with a “magical” subscription that will be created on the fly by BizTalk when the receive-port receives a new message. But first things first!
To be able to send messages to BizTalk using a webservice we can use the “BizTalk WCF Service Publishing Wizard”. This Wizard will guide you thru the process of setting up your Webservice and “connecting” it to your BizTalk application, resulting in a newly created “receive port / location” in your BizTalk Application. This newly created port is by default a Two Way receive port, meaning it can talk both ways (Request/ Response). Exactly what I wished for… NOT!
The problem lies is the response handling, when BizTalk receives a new incoming message it will try to deliver it to its subscribers and.. that’s about it…. There’s no build-in response system! So what you will experience using the Web-service is a time-out (lack of response) on you WCF request.
Back to the “magical” subscription part… every time BizTalk accepts a message from a two way port it automatically creates a new subscription for its “response” port subscribing it to ALL messages containing the following promoted properties:
- EpmRRCorrelationToken == {*****}
- RouteDirectToTP == True
Sadly these properties can’t be promoted the usual way since they are some sort of special system properties. To accomplish the impossible we will have to create a custom pipeline that will do exactly that for us. And that’s exactly what I did, using a little code snippet from Daniel.
After using this custom pipeline as your “Receive Pipeline” BizTalk will send back a copy of the incoming message as an acknowledgement to the initial WCF request.
Yeah! No more timeout’s, problem solved!
Installer: Windows Installer File (MSI)
Sourcecode: CodePlex
Documentation: Word Document
5 comments:
Great post. What happens if you get a fault on the send port? I can you catch the fault and then send a response on?
Thank you, works great.
Hi I had some issues compiling the code snipper. There seemed to have been 2 declarations of the class PromotePropertiesCBR.
I tried to mitigate this by making both declarations partial.
This compiled, but the component itself does not work in Biztalk as it no longer has a parameterless constructor and throws and exception to this effect. Any advice?
This is very useful.
One risk to point out however ...
If the downstream components that are supposed to pick up this message are unenlisted or not deployed this message will appear to the consumer as being accepted. In Biztalk there will be no indication that this message was not processed as intended.
... to add to that that faults, etc like validation that occur in the receive will get send back to the client if details are set to be emitted (which is good).
Post a Comment