6

I'm using BizTalk Server 2013 WCF-WebHttp adapter to call REST API SalesForce. When I receive HTTP Status code different from 200, my orchestration catch the SystemException, but I still have a send port instance suspended. Is there any "native" solution to avoid send port instance suspended ? I read this post : BizTalk Server: REST Services Error Handling

But for WCF-WebHttp adapter, the CustomBinding option is not available. I tried to add fault message, but I did't find appropriate type to catch this exception yet.

Do you have any idea ?

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
Larysa SUDAS
  • 61
  • 1
  • 3

1 Answers1

2

Unfortunately, no there isn't

There is an updated version of that article BizTalk Server 2013 R2: Handle exceptions from REST services in Orchestration

You have to set your send port to WCF-Custom and use the Custom binding and then re-create all the settings from WCF-WebHttp.

More details to follow.

Update:
Catching the exception in the Orchestration as a System Exception is good, you can then inspect the error to see if it is a business exception e.g. if you are doing a query to see if an object exists or not in a RESTful services before doing a create or an updated and getting a 404.

However you have to do a few more things to stop the Suspended messages on the port.

1) To stop the Suspended message on the port Enable Routing for Failed messages on the Send Port.

2) This however means it will then go to whatever framework you have for handling failed messages causing a lot of errors to be raised for business exceptions

To prevent this you either need to tweak the filter expression on your exception handler or have rules in your exception handling framework to ignore these messages.

For example we use the ESB Exception Handling Framework and we tweaked the rule to exclude that particular send port.

ESB All.Exceptions port ESB Exceptions Handling Framework All.Exceptions Port

3) However the you still need to have something else subscribe to the failed messages to make them disappear, we use a custom null-adapter for that with a filter to subscribe to the errors. This means the error only goes to the Orchestration.

NULL Adapter filter expression

NULL Adapter filter expression

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
  • Hi, Thank you for your answer. That's sad, I wanted to keep WCF-WebHttp adapter for it Variable Mapping option. I would like more details to follow. Best regards. – Larysa SUDAS May 04 '16 at 14:41
  • @LarysaSUDAS Yes, we are looking at exactly the same issue now. Looks like the 2013 R2 article I linked too does not use a custom binding, but that it tries to sanitize the fault in the pipeline. I suspect that you still end up with either a suspended message or a failure that is routed to whatever you have handling failed messages. – Dijkgraaf Jul 20 '16 at 00:31
  • I experimented with WCF-WebHttp adapter in BT 2013 and found that there's no "uncatchable" exception for HTTP status codes 200, 201, 202, 203, and also for 500 in case fault message returned together with status code 500 is added to the operation. There is no need for custom pipeline. Default XMLReceive pipeline works the same way. Also if fault message is added to the operation then catchable fault exception is thrown in case fault message is returned in the response body even for status codes 2xx. – oderibas Jul 25 '16 at 08:21
  • @OlegDeribas The issue is that we are talking to web services that are returning non-xml responses, e.g. JSON. In that case yes, you can catch the SOAP error in the Orchestration, but it also causes errors to be thrown from the port to the ESB Exception framework. 1) We don't want these exceptions going to the framework if it is a business exception e.g. a 404 in RESTful service. 2) We want the JSON payload to go through the JSON Decoder rather than getting a SOAP error back where the JSON response is embedded with other text in the error. – Dijkgraaf Jul 25 '16 at 20:12
  • @LarysaSUDAS I've posted a work around for the issue. – Dijkgraaf Jul 25 '16 at 21:00
  • @Dijkgraaf Yes, you described scenario I'm talking about. And there are no errors on the port for HTTP status codes I've listed in my previous comment. So if you control also that RESTful service you're calling, you can design it in a way that it is easier to consume it from BizTalk by using only these status codes I mentioned. – oderibas Jul 26 '16 at 07:27
  • @OlegDeribas Unfortunately it tends to be that we are consuming RESTful services that we don't control, so they throw a 400 for a validation error or a 404 for if a certain instance of an object does not exist. So we have to handle non 200 status codes. – Dijkgraaf Jul 26 '16 at 07:56
  • @Dijkgraaf, thank you for this update. I think it is the best way for the moment to handle REST errors with WCF-WebHttp adapter. – Larysa SUDAS Jul 27 '16 at 09:57