I'm trying to handle faults from an API in my orchestration.
I created a schema that looks like the xml-fault I get from the API, then I added a Fault Message to the operation for the port using that schema.
The idea is to have a send port subscribe to fultmessages and save them to a folder.
But when I try to compile my BizTalk orchestration I get an error: "error X2065: the 'response' messagetype must have a 'body' part distinct from any 'fault' messagetype 'body' part"
Googling this error I get nothing, so right now I'm stumped.
Response xml:
<response>
<result>
<case_number>case_number_0</case_number>
<table_sys_id>table_sys_id_0</table_sys_id>
<table_name>table_name_0</table_name>
<status>status_0</status>
</result>
</response>
Fault xml:
<response>
<error>
<detail>detail_0</detail>
<message>message_0</message>
</error>
<status>status_0</status>
</response>
Is it possible to solve this or should I make a schema that holds both structures and then pick it apart in the orchestration? I can not change the responses from the API, it is what it is.
It is basically telling you that your root element or namespace must be different on the error response.
Is the API you are calling actually sending back a non 200 series HTTP error? If not then it will simply come back on the response part of the logical port, and you just need a XPath expression to see if it is a error or a result, or have a map that creates a payload that adds counts of those nodes, and have a If shape based on that.
If the API is actually giving a 400 or 500 series error, it will throw it as a SOAP error, and that is the schema you need (which is available out of the box)
Note: There is a know bug with the WCF-WebHttp adapater (or at least on some version of BizTalk, I'm going to verify if this still exists in BizTalk 2020)
Details from my blog BizTalk 2013 R2 known bugs, issues & quirks
BUG: BIZTALK WCF-WEBHTTP ADAPTER DOES NOT SET THE MESSAGE TYPE ON ERROR
Details: When you get a non 200 series http status code from a RESTful service using the WCF-WebHttp adapter, the SOAP fault message published to the message box does not have the context property MessageType. This means you cannot map it or catch it in a Fault on the Logical Port in the Orchestration
Work around: Catch it in a System.Exception block in the Orchestration, see (BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 1) or use BRE rules in a Pipeline to handle the SOAP Exception see BizTalk 2013 R2 JSON Encoder error – “Object reference not set to an instance of an object” – Part 2