views:

702

answers:

2

I have an orchestration that uses a request response port to call to a web service and wait for a response. This is working perfectly.

I am now doing tests to handle errors and I am calling a web service that throws a divide by zero exception. The orchestration doesn't catch the exception as an exception; it acts as if the SOAP fault I am getting back is a regular string.

However when I tested this behavior with only a request port, I ended up within the catch block of the orchestration with the divide by zero exception. I need to catch the web service exception also in the request response ports and not only on the one way port.

+1  A: 

Your have to play by the rules first!

In order to catch an exception within your scope block in Biztalk while using a request-response port, you might have to do the following...

  1. Set the retry-count to 0 on your physical request-response port which you use to bind.
  2. Enable the flag Delivery Notification to 'Transmitted' on your logical request-response port within the orchestration.
  3. Catch the "System.Web.Services.Protocols.SoapException" exception and handle it as your please.

Hope this helps.

References: Have a look at my article in code project Code Project

Naveen Karamchetti
Everything was done as you wrote except one issueI am using a dynamic port and there is not retry-count attribute on the port (or i didnt see it)
IB
+1  A: 

This type of error you are seeing is because there is a problem with the HTTP response coming from the web service. BizTalk tries to parse the received response and break it up into header and body and then parse the header. If the response is malformed HTTP, it causes this kind of error. It's using the SOAP librbary to interpret the response message and it blows up becuase the message is bad. The divide by zero may happen because it couldn't accurately get the response length form the header and then scrogged some math.

I would place a packet sniffer on the line (like NetMon) and see what is actually being sent to BizTalk. If it's not HTTP compliant (browse the spec or find a good HTTP for dummies), BizTalk can react un predictably.

Best of luck.

ChrisLoris