JSON Encoder hangs forever

Posted: April 11, 2017  |  Categories: BizTalk Uncategorized

Does a JSON Encoder custom pipeline ever run forever for you? This article explains why this is happening. Furthermore I show  how implementing best practice development can avoid this problem.

Setting up JSON Encoder that hangs forever

Microsoft introduced  the JSON Encoder pipeline component In BizTalk 2013 R2 and published this tutorial. Firstly, let’s start with the custom send pipeline component configured as shown below.

Secondly, deploy this to BizTalk Server and wire this up as a pipeline on a send port. Thirdly, bind the send port to a file receive port.

Fourthly find a deployed XML schema that references a complex type or another schema and find an XML file that matches. I choose to use an orders XML  file that I had lying around where an order type was referenced. This is shown below.

Finally, drop the XML file into the pick up folder. Subsequently the receive port picks the file up but the send port with the JSON encoder pipeline  continues to process it for ever. In the end all you can do is terminate the running instance.

Yet removing the XML namespace creates a file that processes in seconds, generating the desired JSON file.

Investigation

I found a clue to this puzzling behaviour in one of my previous posts. In summary that post showed that if you have a schema deployed that matches the XML going into JSON encoder pipeline component, then it creates an JSON array even if the XML contains only one repeating XML fragment. What I did not state is that if you don’t use typed XML, for example by removing the namespace,  then the JSON array does not get created.

This leads me to think that the JSON encoder tries to find a deployed schema that matches the XML before transforming it to JSON. I think this is how it knows whether to add an array for repeating node even if the XML only contains one XML record.

I think the JSON encoder hangs forever if the schema it matches is too complex. In this case it does not return any error. Examples of schemas that exhibit this behaviour are those using referenced typed schemas like our example or that reference other schemas. Furthermore I think this is a defect because at the very least this should return a error.

Proof and Solution

Following the theory above I created another schema, shown below, with a different namespace and without the same complex types to represent our XML file. The next step was to deploy this schema to the runtime and add the new namespace to the XML file. Gratifyingly the XML file now processed through the JSON encoder in record time and gave the desired JSON.

Conclusion

Always deploy a simple schema to the BizTalk runtime if it represents XML that is going to processed by the JSON encoder. The schema should not contain references to other schemas or complex types or else it might hang forever .

turbo360

Back to Top