Wow, in my attempt to build my gateway using BizTalk 2013 I feel like being run over by a truck each step I make.
I realize this is quite a bold statement to start my article. In this article I’ll take you through the process I’ve been going through.
* Hang on, it will be quite a ride! *
In my previous article, I left off at the point on which I configured a REST end point in BizTalk. I figured out how I could receive the REST POST message using a WCF Web HTTP adapter on the receive location receive port I defined. Sorting out the details costed me a couple of hours, as the information is scattered all around the internet.
This morning I tried to test if the receive port was able to pick up messages I threw at it. My first attempt was using Internet Explorer to send a message to the Receive Port. In the URL bar I entered the following URL:
Sending this message resulted immediately in an error. The error indicated that the user account I was using didn’t have permission to access the BizTalk databases. I turned out that the account on the receive location should be a member of the BizTalk Isolated Users group. I entered the correct user, give the user access to the databases in SQL Server and gave it another attempt.
Second error popping up indicating that my user did not have permissions to access the BizTalk databases. Stupid me… I forgot to change the credentials for the Application Pool user in Internet Information Server.
Once fixed, I thought I was good to go… * Wrong! Another truck running over me *.
When sending a REST Url in the address bar of the browser, you are making a GET call instead of a POST call. Fortunatelly there is a nify tool out there called PostMan. PostMan is an application (that runs in Chrome) that will enable you to make all kinds of REST calls from your browser to your REST endpoint (GET, POST, PUT and so on).
I entered the URL in PostMan, and sent a POST request. Another vague error. Studying the windows Event Log resulted in a hint. I had to modify the web.config on Internet Information Server. Once I set the serviceDebug attribute includeExceptionDetailInFaults to “true“, firing the call in PostMan learned me that I need to configure a send port. Which is logical… What is the use of a receive location and receive port if you can’t drop the messages somewhere.
Time for some more configuration
I had to define a Send Port. Adding a Send Port to BizTalk is a simple task that can be performed in the BizTalk Administration Console.
In the Send Port you have to specify the type. As I wanted to write the incoming messages to the file system, the type I chose was “FILE”. Then I pressed Configure, and I was able to specify the location to which the messages were going to be saved.
The one million dollar question…
The next hurdle that I needed to overcome was how to connect the Receive Port to the Send Port. My intuition told me, go to the pipeline section and add a pipeline. Unfortunatelly BizTalk is not that friendly. It turns out that you can achieve the binding of the Receive Port and the Send Port, by using the Filters on the Send Port. I didn’t give the Receive Port a decent name, so I changed it to IoT2CRM.ReceivePort
Then I opened up the Send Port again, went to the filters section and added the following filter: BTS.ReceivePortName == IoT2CRM.ReceivePort
I enabled the send port, fired another POST call to BizTalk… and… a message appeared in the folder.
When you think you’ve solved the puzzle…
What the ****, the message is empty! What happened?
It turns out that BizTalk 2013 is not capable of handling JSON messages out of the box. You have to write a custom component for it. On the BizTalk360 Blog there is a great article about writing a Json adapter for BizTalk. The latest version of BizTalk, BizTalk 2013 R2 offers support out of the box for JSON… Can you believe that??
My intention was to use a no coding solution as an alternative for the custom solution I implemented in a few hours time. This BizTalk fight costed me over a day in working hours and I still don’t have a working result.
What I will do is the following… I’ll upgrade to BizTalk 2013 R2, and give this scenario another chance.