Category name:Orchestration

BizTalk WCF-WebHttp adapter does not detect 500 error

Update 2016-11-17: Microsoft has fixed the bug in CU5 for BizTalk 2013 R2:

Original post:

For a project at my current client, we use a REST-based API to retrieve some data using the BizTalk 2013R2 WCF-WebHttp adapter. We tried this in a message-only scenario, but soon noticed that errors did not give the desired result. It seems the port sending the response from the API back to the caller did not realize that an error had occurred. In other words: the WCF-WebHttp adapter does not detect all errors.

To further debug this behavior, we tried to call the same API using a simple orchestration. In this orchestration a request is received from a Filedrop location, mapped to the request for the API (to promote the required properties for parameter mapping in the port) and sent to the MessageBox using a two-way send port. Around the send and receive shape is a scope with an exception handler on System.Exception. The exception that occurs is then output via a System.Diagnostics.Trace() statement.

To further assess the behavior, the WCF.InboundHttpStatusCode context property of the API response message is also written to the trace.

Finally, the response of the API is sent to disk via a FILE send port.

The part of the orchestration that does the REST API call is depicted below:


If we test this solution with a happy flow message, all is well.

If we test this solution, with a call that gives a 400 error in the API, it also works: the exception handler kicks in and the error is written to a trace statement.

However, if we test this solution with a call that gives a 500 error in the API, the orchestration thinks that the call was successful and will not enter the exception handler. There is no data in the response message, only an error. In a regular orchestration, not a test like this one, we would now try to process the data received and fail. Also, in a message-only scenario this will cause unexpected behavior.

If we check the HTTP status code in the different scenario’s, we find the following:

In case of a HTTP 200 StatusCode, the ContextProperty value is “OK”.
In case of a HTTP 400 StatusCode, the ContextProperty is not available.
In case of a HTTP 500 StatusCode, the ContextProperty value is “InternalServerError”.

We would expect that the BizTalk engine would recognize a HTTP 500 error and act on it, but it does not. As a work around you could develop orchestrations to check for the WCF.InboundHttpStatusCode ContextProperty and its value.

Since I am unable to find anywhere that this is the expected behavior, I assume this is a bug in the WCF-WebHttp adapter. A bug report is on its way to Microsoft, so hopefully it will be fixed soon. Does anyone find the same behavior or is this the behavior that is expected?

Update 2016-07-12: Microsoft support has responded and the product team has verified the bug. However, since not a lot of users are affected and we have provided them with a workaround, they do not intend to fix it at the moment. If you have the same issue, please report it to Microsoft as well, so they are more motivated to fix it :). You may refer to our bug registration: (number removed, since it is fixed).

Error when publishing a message from a convoy in BizTalk Server 2013

Today I was migrating another interface from BizTalk Server 2009 to BizTalk Server2013. This interface included a sequential convoy with a filter on the activating receive shape. Multiple MessageTypes can be processed and all shapes and ports use the XmlDocument type to communicate with the MessageBox. When publishing a output message from within the loop, the message has the same context property with the same value as the filter in the activating receive shape of the orchestration. Because the activating receive shape starts a correlation, the subscription also includes a few “exists” checks, beside the mentioned filter. This is why the outgoing message is not picked up by the same orchestration again – the published message does not have the other context properties in the subscription of the activating receive shape.

All this works as expected in BizTalk Server 2009, but in BizTalk Server 2013 an error occurs when publishing the message to the MessageBox. The orchestration is suspended with the following error message (no routing failure occurs):

Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘ConvoyPublishingErrorTest.ConvoyOrch(70c08f5c-8d53-9a89-87f3-5dd970d8daba)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 26d22144-3130-4a5e-8da8-76356c646326
Shape name: Send_OutgoingConvoy
ShapeId: 2c8a68fb-8bcc-4551-b87b-836e8151fbf7
Exception thrown from: segment 2, progress 4
Inner exception: Exception occurred when persisting state to the database.

Exception type: PersistenceException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void Commit()
The following is a stack trace that identifies the location where the exception occurred…..

In the Eventviewer, the following error by the source ‘BizTalk Server’ is shown:

The following stored procedure call failed: ” { call [dbo].[bts_AddConvoySetInstance]( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}”. SQL Server returned error string: “The statement has been terminated.;Cannot insert the value NULL into column ‘vtProp1’, table ‘BizTalkMsgBoxDb.dbo.ConvoySetInstances’; column does not allow nulls. INSERT fails.”.

Apparently something is changed in the handling of convoys, causing our solution to fail. To demonstrate this behavior I have created a little demo solution you can download below. Deploy this solution on your BizTalk Server 2013 environment, import the bindings, create the filedrops, start the application and use the provided Input.xml message to see what goes wrong (copy/paste the input message, since the receive location monitors “* – Copy.xml”). All the expression shapes in the orchestration are trace outputs, so you can use DebugView to monitor the orchestation.

We will open another call with Microsoft for this problem. As soon as we hear something, I will update this blogpost.

Download demo solution.

Update 21-01-2014: After some research by Microsoft, a workaround is found for this issue. This workaround includes setting an extra != filter on the activating receive shape.

To fix the issue in the demo solution, I have added a third ContextProperty to the PropertySchema. I promoted a random field from the InputSchema into this property and set the filter on the activating receive shape to <newContextProperty> != “ValueItWillNeverHave”. As long as the incoming message does not have “ValueItWillNeverHave” as a value for the promoted field, the orchestration will pick up the received message. On the message that will be sent out, I add the ContextProperty in the MessageAssignment with the value “ValueItWillNeverHave”. With this explicit filter (as apposed to the implicted filter we had before), the exception no longer appears and the convoy keeps running as expected.

However, we feel this is basic BizTalk Server functionality that should work as it did in previous versions of BizTalk Server. Therefore we have asked Microsoft to further investigate this issue and solve it at the core. This has to be done by the Product Team and might take several months before we hear more about this. I will update this post if we receive more information. We have also asked Microsoft to add this issue to the known issue list of BizTalk Server 2013, so it is documented for other users.