How catch http 400 Status from Rest Service in BizTalk Orchestration

Question

On BizTalk 2013/R2 (CU6), I have seen another app/orchestration in my current client that seems to be doing this, but my app/orchestration is not.

I cloned their send port by doing export, editing, and then importing, changing only name, and operation/method binding. It has the "enable routing for failed messages checked".

Looks like I am catching it in the orchestration with a System.Exception, but I still see the SendPort suspended (resumable), and a routing error (nonresumeable).

Sample error that I'm catching (I'm forcing the error on purpose to test the error handling).

System.Net.WebException: The remote server returned an unexpected response: (400) Bad Request. {"httpStatusCode":400,"httpMessage":"Bad Request","errorMessage":"Unable to handle shipment request","errors":[{"severity":"ERROR","message":"No credentials were found for this vendor. Did you add them to ABC dashboard?","source":"SYSTEM"}],"supportReferenceId":"31eee61a-8770-4524-bada-2d906a53ab48"}

I've seen some other blogs and questions indicate that 500 errors are not returned, and that the http status is not set. But I haven't seen anything about the Suspended SendPorts. Also seems like earlier today, my System.Exception was not catching it, but I cannot go back in time to be sure.

I have retry count on the SendPort to 0.

Also, what actually determines which http statuses can get back to the orchestration? My colleague's code checked for 400, 401, and 403 as well.

Related question: BizTalk Catch Http Response Code

Update: My colleague is on another team, but I heard back from her. She had another orchestration that just "eats" the error message to avoid errors.

Answer 1

There shouldn't be anything special about Http errors vs any other hard fault. They're raised back to the Orchestration just the same.

Here's an article on handling errors in Orchestrations with some useful techniques.

BizTalk Server: Suspend and Resume an Orchestration on Two Way Port Error

Answer 2

Yes, even when you catch it in the Orchestration as a System.Exception the message will still suspend in the send port. You can fix this by doing the following.

1. Switching on Routing for Failed messages on the Send Port
2. Have another send port with a custom NULL adapter or, as per your note and the blog linked to by Johns, an Orchestration that subscribes to all error messages from the send port eg ErrorReport.SendPortName == SendPortName .
3. If you have another send port like the ESB ALL.Exception port subscribing to failures, then you need to update the rule to exclude that port ErrorReport.SendPortName != SendPortName

The Null Adapter does what the name implies, it just throws the message away. You can find a NULL Adapter on GitHub. If you can't install that, just write it to a FILE location and have a cleanup job delete them.