Phidiax Tech Blog

I've been working recently on a project that received JSON messages from Salesforce. While looking through various Binding Elements, I accidentally added the webHttp behavior while searching for a behavior I wanted. I was submitting a message and got a suspended message. Upon inspection I realized that the JSON message was converted to XML before the JSON pipeline component. Mikael Håkansson has a great article about his custom code to do this here. I came to the realization that you could do 90% of the work without a JSON Pipeline component and receive and create JSON data with XML data on the inside of the system. Here is a lengthy article about ALL the features of the WebHTTP extension.

For my purposes, the only thing I'm interested in is the ability to convert the JSON to XML and back without any special coding on my side. To handle JSON Messages simply in BizTalk without a JSON Pipeline component.

First, create your JSON Receive Port:

1. Using the WCF-Custom Transport Type
2. Select a reasonable endpoint… remember, you need to add the endpoint to the URLACL list. This endpoint can be anything, anything at all.

    
   netsh http add urlacl url=http://+:80/JSONReceive/RESTFul.svc user="%computername%\BizTalk Application Users" 
   

    

   
3. In the binding tab, select security and elements as you wish, this is not relevant to the problem, you do need to harden your endpoint.
4. This is where the magic happens. You can select a number of service and endpoint behaviors, but the key one is the webHttp Endpoint Behavior.
5. Add the webHttp Endpoint Behavior extension from the .Net 4.0 ServiceModel  
6. Now this is the default behavior, interestingly enough, this will probably work.
7. I override the defaultOutgoingResponseFormat and helpEnabled. If the inbound message doesn't properly define the INBOUND format, the webHttp extension looks at the defaultOutgoingResponseFormat and guesses that the inbound message is that format. The helpEnabled actually enables the psuedo WSDL description of the service we will see later.
8. Here is the HELP that is generated when the helpEnabled property is set to true. I puzzled over this for a long time, and I don't know how to convince the BizTalkSubmit endpoint to work. But the TwoWayMethod works just fine.  
9. I refuse to install anything to do with Google, so needless to say that "PostMan" tool is not something I will use, but the Telerik Fiddler was able to submit the message. Here I put in the TwoWayMethod endpoint, and then submit a simple JSON request. They KEY here is to set the Content-Type to application/json or the webHTTP will decide that it is some binary type and wrap it as <Binary>Based64</Binary> requiring some coding to fix.

And, the output of this message is transformed with no code into XML.

{
	"glossary" : {
		"title" : "example glossary",
		"GlossDiv" : {
			"title" : "S",
			"GlossList" : {
				"GlossEntry" : {
					"ID" : "SGML",
					"SortAs" : "SGML",
					"GlossTerm" : "Standard Generalized Markup Language",
					"Acronym" : "SGML",
					"Abbrev" : "ISO 8879:1986",
					"GlossDef" : {
						"para" : "A meta-markup language, used to create markup languages such as DocBook.",
						"GlossSeeAlso" : ["GML",
							"XML"]
					},
					"GlossSee" : "markup"
				}
			}
		}
	}
}

<root type="object">
	<glossary type="object">
		<title type="string">example glossary</title>
		<GlossDiv type="object">
			<title type="string">S</title>
			<GlossList type="object">
				<GlossEntry type="object">
					<ID type="string">SGML</ID>
					<SortAs type="string">SGML</SortAs>
					<GlossTerm type="string">Standard Generalized Markup Language</GlossTerm>
					<Acronym type="string">SGML</Acronym>
					<Abbrev type="string">ISO 8879:1986</Abbrev>
					<GlossDef type="object">
						<para type="string">A meta-markup language, used to create markup languages such as DocBook.</para>
						<GlossSeeAlso type="array">
							<item type="string">GML</item>
							<item type="string">XML</item>
						</GlossSeeAlso>
					</GlossDef>
					<GlossSee type="string">markup</GlossSee>
				</GlossEntry> 
			</GlossList>
		</GlossDiv> 
	</glossary> 
</root>

Summary

What I love about this solution is the absolute simplicity it gives me, I can stand up an endpoint and have someone send me JSON and I can build Schemas to match. For our solution I used the ESB Namespace Adder component and gave it a good namespace. Remember, the key elements are that you use the webHttp EndPoint Behavior, that you tweak the setting to handle JSON and finally, the submitter should use Content-Type: application/json.

Issues

There is no namespace associated with this and BizTalk doesn't like the message much. Hence, ESB Namespace Adder to the rescue.