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.  

Friday, October 18, 2013

BizTalk 2010 Tools of the Trade

Having worked with BizTalk for several versions now, I've collected a number of "Tools of the Trade" that I thought I would share.  These tools cover a wide variety of aspects within BizTalk 2010 but have all contributed to increased productivity and stability in the environments I've worked in.


  • BizTalk360 - The most recently added tool to my repertoire, it must be said that this is much more than just a tool.  Saravana Kumar has developed a formidable application that covers a number of topics the most important being monitoring.  No more logging into production environments for discovering problems, the pro active monitoring that can be configured within BizTalk360 can notify interested parties of problems, and it's all configurable via a web interface.  There might be other monitoring solutions out there, but I think Saravana's team has one of the best solutions.
  • BizTalk Deployment Framework - I can't recollect how I deployed my BizTalk applications before this utility, but one thing I know is that before this tool, the process was time consuming and stressful.  Thomas F. Abraham and Scott Colestock have put together a tool that allows a developer or admin to build an .msi file which contains all artifacts associated with a BizTalk application.  Huge kudos to these guys for this tool is a huge time saver in many areas, the most important being deployment.


  • Pipeline Component Wizard - Need to create a custom pipeline component?  Trying to remember all the different methods required of a custom pipeline component class can be difficult.  Let this wizard do the heavy lifting.  Not the best documentation and a little buggy, but a big time saver in this area.


  • Pipeline Testing - Need to unit test that new pipeline component you just created with the Pipeline Component Wizard?  Tomas Restrpo has a testing library that can help.  Before I even think of leveraging a custom pipeline component, I'll test it with this library.  This library can save you an enormous amount of time when troubleshooting pipeline components.
  • WCF Storm - Working with Web Service or WCF Services?  This app can test your endpoints whether they are associated with BizTalk or not.  Since my current work environment uses the Pub/Sub Message pattern extensively, this tool has worked for unit testing our endpoints.


  • Fiddler - The go to standard for web debugging in general, I use Fiddler for all web service troubleshooting.  I love the tools ability to inspect the raw XML.  Especially useful when failures on BizTalk send ports.
This is just a start to the list, and I plan on including more tools as I discover them.  If you have any suggestions for tools in any area within BizTalk, please let me know.

Monday, October 14, 2013

WCF Send Port SOAP Action header property in Content-Based routing vs. Orchestration

In my current work environment, BizTalk is leveraged for a lot of content-based routing scenarios.  As a rule, I've tried to use WCF Custom receive and send ports wherever possible. Recently while working with the business, there was a need to change from pure content-based message routing to incorporating an orchestration.  This orchestration was set up to use the current send ports that had already been created with  content-based routing. When testing the orchestration, everything was working as expected, except when the message hit the send port.

 The Send Port was originally set up to use the WCF-Custom Adapter (the message is actually being sent to a web service). It was configured with the following SOAP Action:

When testing the message, the message would always suspend.  Here is the error:

So why is it suspending with an incorrect SOAP Action when the message is sent from an orchestration and not when it is sent via content-based routing?  I had to pull out Fiddler to find the answer (If you have never used Fiddler, get to know it, I use it for all my troubleshooting of Web Service issues).  

When inspecting the Raw Message in Fiddler, notice the SoapAction included the whole action mapping setting that was set up in the Action property of the SOAP Action header in the WCF-Custom Transport. After reading this from Microsoft, there are two solutions and both included updating the WCF-Custom Transport configuration SOAP Action header:

1.) Change the name of the Operation in the SOAP Action header bts action mapping to match what was used in the orchestration. See below screenshots:

2.) Instead of using the BtsActionMapping in the SOAP Action header, just use the name of the SoapAction that the receiving system is expecting.

This will surely come up again when the business requires more than just content-based routing out of BizTalk.  Hopefully this will help someone else who might have missed this small but important configuration change.