Today I’ve encountered an issue with remote BizTalk deployment.  Every night we run a TFS build and the result of that build is deployed to our BizTalk Test Server.  Because the build process runs on our TFS Build Server, we actually perform a remote deployment to the BizTalk Test Server.  Until last night, everything worked fine.

The error

This error occurred during the import of one of the binding files: Failed to create 'WCF-Custom' Transport Component.

The reason

It was the first time we tried to remotely import a BizTalk binding file that contained the WCF-Custom adapter.

The troubleshooting

I used the Microsoft.BizTalk.Deployment.DeployerComponent to import the bindings.  I created a workaround for the issue, by executing BTSTASK.exe remotely via PSEXEC.exe.  This worked fine, but then I’ve got the same error while starting receive locations and send ports, that were configured with the WCF-Custom adapter.  As I didn’t have a good command line alternative for this functionality, the workaround was useless.

Afterwards, I’ve tried to install some extra BizTalk software on the TFS Build Server. And yes, this was the way to go!

The solution

The Windows Communication Foundation Adapter runtime should also be installed on the local machine (in our case TFS Build Server).  This is not documented somewhere and it’s not the behavior you would expect.  The BizTalk deployment libraries work fine for remote deployment, until you use the WCF adapter…

This is an overview of the BizTalk software installed on our TFS Build Server:

- BizTalk Developer Tools and SDK  [needed to run Unit Tests]

- BizTalk Project Build Component  [needed to build BizTalk Projects]

- BizTalk 2010 Cumulative Update Pack 4.0 [contains this fix]

- Windows Communication Foundation Adapter [apparently needed to remotely import bindings containing WCF adapters]

You want to make a custom BizTalk pipeline component that handles content from an inbound XML-message, e.g. getting a value with XPath. Then you could use a MemoryStream or load the message in an XmlDocument. This is not the most performant way for doing this, though. Loading the message into memory with an XMLDocument, can take up to 10 times of the amount of space than the actual message size.

If you want to make a pipeline component that has a good performance, you might want to use an Xml(Text)Reader, a ReadOnlySeekableStreem or a VirtualStream. This doesn’t load the message entirely into memory.

In order to do this, you will need the assembly Microsoft.BizTalk.Streaming.dll.

You can find this assemby in the GAC and get it by executing this in cmd.exe:

cd C:\Windows\assembly\GAC_MSIL\Microsoft.BizTalk.Streaming\3.0.1.0__31bf3856ad364e35
xcopy Microsoft.BizTalk.Streaming.dll "C:\Program Files (x86)\Microsoft BizTalk Server 2010"

For an example you can check out this post:

http://blog.codit.eu/post/2011/10/15/XslTransform-pipeline-component.aspx

For more info about the VirtualStream and it’s advantages, you can take a look at this topic:

http://msdn.microsoft.com/en-us/library/ee377071(v=bts.10).aspx

It’s a good practice to have some XML validation in your BizTalk integration flows.  It prevents you of sending mal-formatted messages to back-end systems and it also gives you the opportunity to validate incoming messages.  In the BizTalk toolbox, you have two standard pipeline components that can perform this XML validation.  Let’s have a look...

XML Disassembler (or XML Assembler)

The default configuration of the XML Disassembler will not perform any kind of XML validation on the message

If you want to enable XML validation on the XML Disassembler you need to set Validate document structure to True and explicitly set the Document schema(s) that need to be validated. Compared to the specified Documents schema(s):
- If the processed message has the same TargetNamespace#RootNodeName combination, XML validation will be performed

- If the processed message has another TargetNamespace#RootNodeName combination, an exception will be thrown (can’t recognize the data)

XML Validator

The default configuration of the XML Validator will already perform XML validation. How? It retrieves the XML definition from the BizTalkMgmtDb, at run-time, using the TargetNamespace#RootNodeName combination.

-   If a matching schema is found, XML validation will be performed on the processed message

-   If no matching schema is found, the XML Validator will throw an exception (cannot retrieve document specification)

You can also explicitly specify at design-time the Document schema(s).  Compared to the specified Documents schema(s):

-   If the processed message has the same TargetNamespace#RootNodeName combination, XML validation will be performed

-   If the processed message has another TargetNamespace#RootNodeName combination, no XML validation will be performed

Conclusion

You see a different behavior when comparing the components, especially when specifying Document schema(s). Depending on your needs, you can choose the appropriate setup.  I mostly opt for the combination of the XML Disassembler and XML Validator, both with their default configuration.  It has the advantage that you don’t need to configure anything at design-time.  They work together in this way:

-   The XML Disassembler is responsible for retrieving the BTS.MessageType, promoting context properties and debatching

-   The XML Validator will validate all messages, deciding at run-time which schema to use

Microsoft has just released the beta release of BizTalk Server 2013.  The first good news is that the initial name (BizTalk 2010 R2) has changed to BizTalk 2013, indicating it will be a major release, providing longer support to our customers.  The Windows Azure image gallery will also be updated to include BizTalk 2013 beta.

Codit is part of two different TAP programs with the same product team: BizTalk 2013 and the Windows Azure BizTalk Services (earlier known as EAI & EDI services).  We have been testing our Integration Framework for BizTalk Server and our Integration Dashboard for BizTalk Server against this new release and we can say we are ready.

It’s great to see things are moving in the Microsoft integration space.

The beta can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=35553 and contains the following capabilities:

• Integration with Windows Azure Service Bus – these are mainly out-of-the-box adapters for Windows Azure Service Bus (both messaging & relay)
• Support for REST – seeing the web- & device-world move to a REST-oriented approach, it is a very good thing to see support for REST in BizTalk 2013.  And this is not only for consuming, but also for exposing RESTful services!
• SFTP adapter – this has been a request for years and it’s with great relief that a true SFTP adapter will be part of BizTalk 2013
• ESB Toolkit – The ESB toolkit has been one of the most unclear parts of BizTalk since its inception.  From guidance over toolkit and now ending up as part of the product.  The configuration experience is much better, which is already good.
• Dependency tracking – the administration console now shows the dependencies between artifacts
• Other changes – enhanced SharePoint adapter, improvements in send ports…
• Host Integration Server, that comes with your BizTalk license, also has some improvements in the following areas: DB2 integration, TI management, Support for MQ v7.5 & v7.1

Conclusion

What first looked like a pure platform update (aligning with SQL Server 2012, Windows Server 2012, .NET 4.5) now has changed to a big upgrade with a lot of enhancements to the product.  Having a full release is an important sign to the market, meaning support lifecycle for this product is significantly longer.