RESTfully GETting JSON Formatted Data with BizTalk 2013

With the new WCF-WebHttp Adapter that shipped in BizTalk Server 2013 we now have the ability to specify which HTTP verbs to use – this opens up the possibility of invoking RESTful style applications.

In this post, I’ll investigate how we can RESTfully invoke an endpoint that exposes data via JSON using the GET verb – we’ll be ‘RESTfully GETting JSON Formatted Data with BizTalk 2013’; I’ll be retrieving stock tickers from Yahoo! Finance in JSON format.

Send/Receive Adapter

The RESTful endpoint is invoked via a solicit/response Send Port configured to use the WCF-WebHttp Adapter, providing the Yahoo! Finance URL and a single HTTP method of ‘GET’:

WCF-WebHttp Adapter Configuration


JSON Decode Receive Pipeline Component

The JSON response is passed to a custom Receive Pipeline via the adapter which contains a newly developed ‘JsonDecode’ component. This component invokes the fantastic Json.Net package (see for more information) to do the required heavy lifting and convert the JSON into an Xml representation. The Execute() method of the Pipeline Component looks something like this:

JSON Decode Pipeline Component Source Code

Once we have an Xml representation of the JSON response, we add a Root Node (and associated namespace) so we can leverage our usual magic BizTalk sauce. The root node name and namespace are exposed as properties via the Pipeline Component (think WCF-SQL Adapter):

JSON Decode Pipeline Component Configuration

Simply create a schema that represents your new message and voilà, you’re receiving JSON data and processing it as an Xml message within BizTalk; you’ll also have access to all of the usual property promotion/routing capabilities etc.

JSON in, Xml Out

Now that we have configured our solution, what do the input and output messages look like?

Something like this for the JSON response to our GET request:

JSON Response Data

and our corresponding Xml representation:

JSON Data as Xml Message to be Consumed by BizTalk

Feel free to download a copy of the solution if you’re interested –> Please note that the sample code is for demonstration purpose, and it is NOT production quality code.

Stay tuned for Part 2, where I will look at POSTing JSON data from BizTalk.


Beware of windows.old when upgrading to Windows 8

I have just taken the plunge and upgraded from Windows 7 to Windows 8 (partly because of the £25 upgrade offer). After the upgrade I noticed a severe lack of space on my otherwise roomy C: drive.

A quick check in Windows Explorer reveals a windows.old directory which contains all of my old Windows 7 ‘Windows’ directory, Program Files, Users and PerfLogs directories – and its just short of 20Gb. I’ll be shifting it to an external backup drive shortly…


Further MS-DTC Issues – Check the Startup Order of Clustered Services

We’ve just encountered an obscure MSDTC/SQL Server issue that I thought would be beneficial to the wide-community.

Following a failover of our (Windows Server 2008) cluster, we started to encounter unexpected errors when BizTalk attempted to perform any tasks that required a distributed transaction, even though everything appeared to be running correctly: MS-DTC was running and we could DTCPing the BizTalk Server from the SQL Server (and vice-a-versa), so no issues with DTC; SQL Server was also running as we could connect to the instance via Management Studio and BizTalk could read the Management Database etc., yet DTC operations still failed with the following error:

Enlist operation failed: 0x8004d01c(XACT_E_CONNECTION_DOWN). SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.
A severe error occurred on the current command.  The results, if any, should be discarded. (Microsoft SQL Server, Error: 8510)

It turns out that when clustered services are brought online, they must be started in a specific order, with the DTC service being started before SQL Server. If they are not brought online in this order, SQL Server fails to register itself and DTC transactions cannot be initiated, even though both the DTC and SQL service’s are running and everything looks correct.

Thanks to this forum post for providing us with the much needed pointer:

SBUG Mini Meeting – Integration Testing with MockingBird – 29th July at 8pm

The SBUG guys are holding their second online mini-meeting on Wednesday 29th July 2009 at 8pm (BST). Santosh Benjamin will be demonstrating the excellent Mocking Bird web-service mocking tool – I’ve been using it for a couple of weeks and I’m a convert; no need to stub our web-methods, just add virtual endpoints to a config and you’re done!

This should only be a 30-45 min meeting and is open to all via Live Meeting. Hope you can join us and see this excellent tool in action.

Full details – including registration – are available on the SBUG Website:

Interesting Quirk when Formatting Guid’s as Strings….

Originally posted by Nick Heppleston at:

I noticed an interesting quirk last night while trying to format a Guid into a string representation – by default, Guid.ToString() does not return an accurate representation of a GUID with curly braces. Hmmmmmm…..

Consider the following simple test, here we are instantiating a new Guid and before outputting the value to the debugger, we capture its value – note the curly braces at the end of the Guid:


If we let the test run its course, we get the Guid formatted as a string (using the default formatter) written to the debugger, but there are no curly braces:


After much head scratching and Googling, I decided to look at the MSDN documentation for the Guid.ToString() method – low and behold there are several format specifiers that can be provided to the ToString() method which determine the formatting provided to the resultant string. Using the format specifiers:


we get the desired output:


If no format specifier is used (i.e. we just Guid.ToString()), the default format is ‘D’ – no braces.