BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 1

Posted: November 26, 2015  |  Categories: BizTalk Uncategorized
Tags:

We have discovered that if a SOAP fault is sent to a pipeline using the JSON Encoder the following error occurs;

A response message sent to adapter “WCF-WebHttp” on receive port “OrderAPI” with URI “/order/v2/Service1.svc” is suspended.

Error details: There was a failure executing the response(send) pipeline: “Pipelines.CustomerDetails.Snd_JSON, Pipelines.CustomerDetails, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1bdcdd64c42ec63e” Source: “JSON encoder” Receive Port: “OrderAPI” URI: “/order/v2/Service1.svc” Reason: Object reference not set to an instance of an object. 

We can reproduce the same error if we submit the SOAP fault to any send port that uses the JSON Encoder. We believe that this is an inherent problem in the JSON encoder i.e. It cannot resolve a SOAP fault. This makes it very difficult to handle exceptions and return a message to clients that want to consume a REST/JSON service hosted in BizTalk Server. We had intended to “sanitize” all faults in a custom behaviour but this runs after the pipeline component is executed.

We added an orchestration between the receive and downstream endpoints. We also added exception handling in the orchestration to raise a fault message. This time the JSON encoder does process the fault message successfully.

Thus one workaround for this issue is to introduce an orchestration into the messaging only solution. Can anyone else think of a way that we can maintain a messaging only solution that uses BizTalk 2013 R2  JSON encoder by removing the SOAP fault envelope prior to the message going through the inbound pipeline?

  • Hi Mark, I wonder if it could just be a context property that the pipeline expects that’s not populated unless the message runs through an orchestration… If you could isolate which context property it is then you could set it manually using a pipeline component on the send port maybe?

    If you’re really unlucky then it’ll have something to do with the message part, or the the message part data…

    • mbrimble

      Hi Johann,
      thanks for the suggestion. Deepa has found a workaround using your BRE pipeline framework which I will blog about shortly (you’ve probably worked out what we did already).

      We have captured the fault XML from the orchestration and from the messaging only solution and then tested passing them through an independant one way send port with the json encoder in the send pipeline. Both the XML messages are valid XML.The fault XML from the orchestration processes without error but the SOAP envelope XML from the messaging only solution gives the same error – “Object reference not set to an instance of an object”. We have dissembled the JSON Encoder and it tries to find a matching XML schema to every message. I am thinking that this is failing with some schemas.

  • Rachid K.

    You can also add a custom component BEFORE the json encoder and process specifically this king of message , at least to provide mssing elements for the json

    • mbrimble

      Hi,
      see part 2 for an example of how to do this.

  • Pingback: BizTalk 2013 R2 known bugs, issues & quirks | BizTalk musings()

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

Back to Top