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.