Tuesday, October 22, 2013

BizTalk 2010 invoking PeopleSoft Web Service throws System.ServiceModel.CommunicationException

As I've mentioned before, I try and leverage content based routing whenever possible in BizTalk.  There are a number of reasons for doing this, the main one being to not overcomplicate your messaging scenarios when you don't need to.  As I try and practice what I preach, content based routing is widely used within the current environment I support.

Our main Enterprise Resource Planning (ERP) system, PeopleSoft, has many messaging scenarios set up with content based routing.  When originally setting up messaging for PeopleSoft subscriptions using the WCF Custom Transport Type, I kept on running into an error when sending the message.  The message looked like the below:

I immediately googled this problem and found the following Microsoft Question/Answer.  Basically it explains that BizTalk is expecting a NON NULL response from the PeopleSoft Service.   When inspecting the message through Fiddler,sure enough, this was the issue:

So the solution from the link above was to just have PeopleSoft include a non NULL response, but what if that isn't possible?  There is a way for BizTalk to handle a NULL response.  By using the WCF Custom Transport Type with a CustomBinding binding type, I can include a Binding Element Extension.  Within the WCF-Custom Transport Properties, select the "Binding" tab:

Right click the root "CustomBindingElement" in the left hand pane.  It will give you the option to "Add Extension".  In the Select Binding Element Extension, there should be an extension for "oneWay":

 Select the "oneWay" extension and click "OK".  This will take you back to the Binding tab where the new extension will now be visible in the left pane labeled "Binding".  The last piece of the puzzle is to move this extension up by right clicking the "oneWay" extension and selecting the "Move Extension Up" option.  This extension must be the first one:

After setting up the binding and re-testing the send port, the error no longer appears.  By setting the "oneWay" extension on the binding, BizTalk is no longer expecting the NON NULL response.  

No comments: