In a previous post, I started a series on explaining some of the new features of BizTalk 2013 in more detail. We started with a more detailed explanation on why BizTalk 2013 will be using the XslCompiledTransform API. You can find a list of the new features that BizTalk 2013 introduces on our earlier post.
In this next post in the serie, I would like to explain the announced ‘Improvements in dynamic send ports’… What has been changed in this new version of BizTalk?
BizTalk 2010 (& earlier)
Dynamic send ports where introduced already in an earlier version of BizTalk. However, unlike a static send port, you didn’t have the possibility to choose a BizTalk host that the ports send handler would run on. The dynamic send port will use the default send handler that is configured for the adapter that is being used. Meaning we are tied to using the same default Host for each dynamic port that uses the same adapter, which could cause separation of concern issues with bigger systems.
Or in other words… when you wish to run a dynamic send port using a different host, you are obliged to change the default send handler of the specific adapter. But keep in mind this will effect all dynamic send ports that are using this adapter as well.
BizTalk 2013 now has the ability to assign a host handler per adapter. This means you now have the possibility to configure a host to be used per adapter on a dynamic send port… providing more control on how your workload gets executed with dynamic send ports. This change will bring better scales and performance for dynamic send ports.
When adding a dynamic send port, you see there is a whole new Transport section in the General tab of the send port properties. By clicking on the Configure-button of the transport section, you’ll be able to choose which host must be configured as send handler for each available adapter.
Note however that the hosts that can be assigned to an adapter are the configured send handlers of the adapter. So you need to make sure that there is a send handler defined on the adapter configured to use your desired host. The chosen host no longer needs to be the default send handler defined for the adapter.
The Microsoft Team has just announced the release of the very first Cumulative Update For BizTalk 2013.
But an even more surprising news is that it is available using Microsoft Update!… This is the very first time a BizTalk Update can be obtained with Microsoft Update, as before it had to be done by downloading it manually through the hotfix download. An amazing improvement if you ask me, making it a whole lot easier for administrators.
The update will still be available through the hotfix download though.
The Content of the Cumulative Update
The very first CU for BizTalk 2013 brings 3 fixes:
- User cannot perform certain database-related operations in BizTalk Server 2013
- BAM tools cannot be configured in a multi-node BizTalk Server 2013 environment
- The vertical scroll bar on the target schema does not work correctly when you use Visual Studio to design a BizTalk Server 2013 map
How to install using Microsoft Update
The following steps are applicable if you have Microsoft Update enabled in the machine where BizTalk Server is installed.
- Log into a server where BizTalk Server is already installed, and Microsoft Update is enabled
- Check for windows update
- Notice available fixes for BizTalk Server under optional updates
- Select the update and install
(Perform the above operations in each of the BizTalk nodes)
The original announcement can be found here.
In a previous post we announced the release of the new BizTalk 2013, listing all of the new features it will bring. In the upcoming posts I would like to explain in more detail some of these features, and the consequences it will bring with it.
First of all, one of the changes introduced in BizTalk 2013 is the use of the enhanced XslCompiledTransform API, instead of using the XslTransform API that is used in older BizTalk versions. This change would provide significant improvements in mapping engine performance for complex maps. Sounds great, but what is the difference between both?
First of all, I would like to note that the XslTransform API has become obsolete and has been replaced by XslCompiledTransform.
The new XslCompiledTransform API will boost the performance for complex maps. Although I would like to make a side note about this one… Although the overall performance of the XslCompiledTransform class is better than the XslTransform class, the Load method of the XslCompiledTransform class might perform more slowly than the Load method of the XslTransform class the first time it is called on a transformation. This is because the XSLT file must be compiled before it is loaded. For more information, see the following blog post: XslCompiledTransform Slower than XslTransform?
Using the XslCompiledTransform will compile the XSLT style sheet down to a common intermediate format. And once the style sheet is compiled, it can be cached and reused. Making the XslCompiledTransform considered the best choice for the “one