Calling Restful Services using Itinerary in BizTalk 2013
In the previous post, I showed how to call Restful services using dynamic send ports.
In this post, I am going to leverage that concept to make a Rest Service call using Itinerary.
1. In order to call a restful service using dynamic send port, three main context values should be available in the message. These are
2. These values can’t be promoted using any out of box components in Itinerary. Hence I created a custom pipeline component, that promotes these three values to context. I am using this custom component on my Receive Side -> Decode Stage.
3. I created a Receive pipeline with my custom pipeline component (to promote the 3 main values) + ESB Components to select the itinerary & dispatcher.
When I applied this pipeline, my required fields for Restful call & ESB itinerary will be available in the context of the message before it is published to the message box.
4. I started working on creating an itinerary. But Itinerary routing resolver doesn’t provide WebHttp Transport Name.
Hence I started creating a Custom Adapter Provider extending from “WCFBaseAdapterProvider”. Below are the contents of the class.
I then Gac’ed the assembly and added the details of this transport name in esb.config file. (It will be C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.2\esb.config)
5. After the above changes to esb.config file, I am able to see WebHttp Transport type.
6. I created a simple Itinerary like below.
For the static Resolver, below is how I set the Url & Transport type.
7. Quick Summary:
• I used a custom pipeline component to promote my required operation & variable mapping on the Receive Pipeline.
• Since, I don’t see WebHttp transport name, I created a custom adapter type & updated esb.config file.
• I used a static Resolver & Provided Transport Location & Transport Name.
8. That’s it. I am done. Once a message is received, my custom pipeline component will write the operation & variable mapping to context. ESB itinerary will be loaded. Itinerary will set the Transport Type as WCF-WebHttp & Transport url to the configured value. This message is then submitted to a Dynamic Send Port. Response from dynamic Send Port is routed back to the Request Response Receive port.
I am not sure if this is a perfect way of doing. But it solved my problem.