connecting biztalk to a wcf service containing a fault contact
I’ve created a wcf web service which accepts a string as a request and gives an appropriate response if the request meets certain criteria, otherwise it throws a faultexception .
The wsdl for this web service displays 3 data contacts, one for request, one for response and one for fault.
Ive used the consume wcf service wizard to consume this web service.
When I use a port to connect to this web service in a biztalk r2 orchestration the port appears with 3 message endpoints displayed:
One for request, one for the response and one for a fault.
I am unable to connect the fault end point to a receive shape the way I can connect the response end point.
When a fault message (do to a fault exception) is sent from the wcf web service , a soap exception is thrown which can be caught, but along with that a separate fault message is also transmitted, resulting in an error which is seen in the event viewer.
I basically would like to know if this fault end point can be made useful, by connecting it to any shape in the orchestration? And also i would like to know how to suppress this error in the event viewer if it is possible.
Any help or suggestions would be appreciated. :-)
Yes, that fault operation is indeed useful, and it is used to handle the typed faults coming from the remote WCF service. You don't need to connect it to anything in your orchestration.
Let’s assume that remote service returns a fault of type MyException, and we want to catch the exceptions of that type inside our orchestration.
Here is the solution:
1- Run the consuming wizard to generate the solicit-response send port types, and also the message types including request, response and MyException
2- Cover the send and receive operations with a scope to be able to add an exception handler
4- Add an exception handler to the scope, and set its type to the type of the Fault operation.
5- Import the generated binding file to create the send port, and bind the send port to the orchestration
6- Set “Propagate Fault Message” property to true
7- Choose the xPath option for inbound message body processing, and set the xpath expression to /*[local-name()='Fault']/*[local-name()='detail']/*[local-name()='MyException']
Please note that you need to have at least R2 RC build to be able to execute multiple xPath statements in step 7. We're planning to ship an SDK sample for this scenario. Help me out here, you say:
7- Choose the xPath option for inbound message body processing, and set the xpath expression to /*[local-name()='Fault']/*[local-name()='detail']/*[local-name()='MyException']
Please note that you need to have at least R2 RC build to be able to execute multiple xPath statements in step 7. We're planning to ship an SDK sample for this scenario.
Is the RC Build available yet on the Connect site? Is this the 4/13/2007 download date version you are referring to?
Because there are no options to set multiple XPath statements here, unless there's an undocumented Delimiter you add to the XPath statement...
I can easily get one fault contract working, but what about 2 or more that a service would yield?
The one in the connect site is R2 Beta2, and it looks like R2 RC build will not be available to public. You need to wait for the RTM build to be able to use the multiple xpath execution feature.
For the time being, you can use a custom receive pipeline component in the send port, and extract the fault exception from the soap envelope yourself as a workaround.
Regarding the multiple fault contracts, the orchestration port type generated by WCF consuming wizard should contain all the fault operation types your remote service provides, and you can all handle them the same way by adding an exception handler for each one.
Hi, I am using the WCF service in same way as described in earlier replies. I did following steps:-
My WCF Web service returns Exception of type : FaultException<DefaultFaultContract>, which here I think has been named as DefaultFaultContractFault, i.e. adding Fault at the end, while generating the schemas and binding info information.
Let’s assume that remote service returns a fault of type DefaultFaultContractFault, and we want to catch the exceptions of that type inside our orchestration.
1- Run the consuming wizard to generate the solicit-response send port types, and also the message types including request, response and DefaultFaultContractFault
2- Cover the send and receive operations with a scope to be able to add an exception handler
4- Add an exception handler to the scope, and set its type to the type of the Fault operation.
5- Import the generated binding file to create the send port, and bind the send port to the orchestration
6- Set “Propagate Fault Message” property to true
Now in the last step,
7- Choose the xPath option for inbound message body processing, and set the xpath expression to /*[local-name()='Fault']/*[local-name()='detail']/*[local-name()='DefaultFaultContractFault']
It gives me error for invalid xpath. Let me know the valid XPath, if not this.
/*[local-name()='Fault']/*[local-name()='detail']/*[local-name()='DefaultFaultContractFault']
So right now I have connected to second option - Body - contents of <soap:Body> element. Then the WCF service works but, I am not able catch Faults if they are occured at service end. I guess probably correcting this error of XPath should work for me.
Further more I want to ask why it appears in the Port that this can be connected to some recieve message, though you say we need not to connect it to anything. I guess there should be some reason for that.
If anyone know, please let me know.
Hi,
try 'DefaultFaultContract' instead of 'DefaultFaultContractFault'. It worked for me.
However I realized, now although I'm able to catch the specific faults, I'm not getting positive response back from the port as it is searching for the Fault tag in that case also.
Pls help!!!
Somehow, the last part of the xPath statement was stripped off in my original post. There should actually be a "|" statement
Correction:
Step 7:
/*[local-name()='Fault']/*[local-name()='detail']/*[local-name()='MyException'] | /*[local-name()='DivideResponse']
DivideResponse is for handling the positive responses (assuming that your remote WCF service method's name is Divide) not available in RC build, and you need to wait for RTM since RC build is not public.
