IN a happy day scenario, when you consume a WCF service in BizTalk, you will get the corresponding message type. However consider there is an exception thrown within the WCF service. Its hard to believe that the WCF send port instead of retrying or suspending the message, will just get the message. I enabled tracking message bodies on the send port and saw that I had got a SOAP fault message. Inside the SOAP fault message, I had details about the exception, WIERD.
There were posts in the internet which pointed me to implement the solution.
1. I created a fault operation in the Request/Response logical port. I set the type for the operation as BTS.soap_envelope_1__1.Fault
2. Added a scope shape and dragged the send/receive shapes within the scope.
3. Added a exception handler of the type of the fault operation i.e. BTS.soap_envelope_1__1.Fault.
4. Create a message which is again of the same type as discussed before and assign the exception variable to the message that we have created.
5. In the send port configuration, go to the Messages tab. In the inbound biztalk message body section, choose Path instead of the default Body radio button.
In the Body Path expression, you will have to set the list of all possible responses you will get
i.e. You will get the successful response as well as the failure response. You get a failure message within a fault node, so you will have to specify a xpath expression to extract the content that lies within the fault node. So you will have to specify like this /*[local-name()=’Fault’].
However you dont get a failure message everytime, rather you get the success message most of the time and sometimes get a failure message(this is how you design and implement the solution, for me its always the other way round 🙂 )
So to cope with that, you need to give a union xpath expression so that the WCF send port applies a or condition and picks up the nodes. so you need to write something like this /*[local-name()=’Fault’] | /*[local-name()=’ProcessStudentApplicationResponse’]
See the pipe | symbol which seperates the fault xpath expression and the success xpath expression.
5. So, now when a fault message is received by the BizTalk send port, the orchestration will understand that and the code within the exception handler will execute.
6. As we have assigned the exception variable to the message, we can access the fault details and can take necessary action.
Possible actions that you can take
1. Build a loop shape around this scope and retry until the message is sent. You can set a configurable value for retrying.
2. Use ESB exception framework by construct
If you dont implement the fault handling stuff when you consume the WCF service, then you wont have control in orchestration to handle that.