Monday, December 20, 2010

Dynamic SMTP Send Port - Unknown Error Description

The other day I was using the Dynamic SMTP port to send an email message after a technical error had occurred in BizTalk.

I used a BRE Policy to configure the Email settings and had set the SMTP.EmailBodyText property.

Although there are a lot of things that can go wrong I was convinced it was rooted in my BRE call and result.

It took me several dreadful minutes before i stumbled on a post of a fellow BizTalk developer who had faced the same issue.

It turns out that when you use the BodyText you MUST set the charset:

EmailMessage(SMTP.EmailBodyTextCharset) = "UTF-8";



Sunday, December 19, 2010

BizTalk 2010 exam review

Hi there, I just finished providing some feedback for the upcoming BizTalk 2010 exam and I hope the input was valuable.

As I am preparing for the SQL Server 70-342 I hope the exam will be finalized early next year so that I can it to my list of exams to take.


Saturday, December 18, 2010

File Adapter quirks

Since I try to have posts for all the adapters I have encountered it can be that this is a post that it not new for all the people already working with BizTalk for a long time. It just wanted to have it on my blog for the sake of completeness;

The FILE adapters requires that the Host Instance account user has FULL Control on the folder it tries to read from.

I was giving a course on security in BizTalk and explained the security modal of BizTalk (like BizTalk operator / BizTalk administrator) and the ability to run Host instances under minimal privileges accounts (BizTalk Application Users member) and had a hard time to explain why the file was not picked up when Read only rights were assigned.

This answer is: because I said so Winking smile



Scheduled Task Adapter

After considering the options for a project where interfacing in a scheduled manner was required i came across the Scheduled task adapter. This thing is so easy to use, I must speak about it!

The following section describes the steps required to implement the scheduled task adapter.

Register the components

To install the Scheduled task adapter download the adapter from ‘Codeplex’ ( Run the setup and follow the steps during the setup.

Note: In the current version the setup does not register the necessary dll’s in the Global Assembly Cache. These steps have to be performed manually.

- Start the Visual Studio command prompt

- Navigate to ‘C:\Program Files\Biztalk ScheduledTask Adapter’

- Run ‘GACUTIL –i Biztalk.Adapter.ScheduledTaskProperties.dll’

- Run ‘GACUTIL –i Calendar.Schedules.dll’

- Run ‘GACUTIL –i ScheduledTaskAdapter.Admin.dll’

- Run ‘GACUTIL –i ScheduledTaskAdapter.dll’

- Run ‘GACUTIL –i ScheduledTaskAdapter.TaskComponents.dll’

Add the adapter

Start the administration console and create a new adapter under ‘Platform settings’.


Select the Schedule adapter and name it as desired, for example ScheduledTaskAdapter


Restart the host instance



The Scheduled task adapter has the ability to fire a trigger based on a regular interval. This trigger can be defined as desired, the most common usage is to use a String trigger which will submit a predefined String (e.g. an Xml message) to the messagebox so that it can be picked up by an Orchestration.

The first step is to create a new Receive port that will contain a receive location using the ScheduledTaskAdapter.

Create a new One-Way receive port


Create a new Receive location and select the ScheduledTaskAdapter, ensure that you choose XMLReceive as the receive pipeline.


Click on Configure and define a name for the schedule


Define a schedule which executes the tasks periodically


Select a task component


This tab allows the usage of implemented Task items. These are the actions performed, you can implement any task as long as it conforms to the API of the ScheduledTaskAdapter. In this case we will use a task type that is included with the Adapter.

Click on ‘FindTask’, this will show the assembly browser


Click on ‘Browse’ and select the assembly ‘ScheduledTaskAdapter.TaskComponents.dll’ (located in the Program Files\Biztalk ScheduledTask Adapter directory).


Double click the XMLStringStreamProvider and click ok


Under taskproperties, configure the XmlString that will be published on the messagebox at the moment the task is executed


Note: this is a xml instance that you can used as the first receive shape in the orchestration that should be started.


Have fun with it!

Thursday, December 02, 2010

BizTalk 2010 Mapper Pros/Cons

I am now using the BizTalk mapper 2010 frequently, I faced 2 changes I don’t appreciate:


- Search elements

When you type in a fieldname, it is highlighted! You can even toggle buttons so that only the highlighted elements are shown. Cool

- Copy Paste

Copy/paste works like a charm, elements can be selected easily and it now works as it should have been a long time…intuitive.


- Replace functoid does not work anymore

It used to be, that when you drag a functoid and drop it over a functoid already on the mapping grid that it would replace the existing functoid. Well, it’s noted, not really what I wanted.

- Create a message from scratch

When I make a new message and I don’t have input for it a Assign a new message using a Message variable of type XmlDoc. Assign it a value with the first element of the schema (e.g. <Error />) and then use the mapper to set all the different elements in the message (using a string concatenate with an empty value).


I am not 100% finished with analyzing this, but it looks like this does not work anymore. The mapper does not overwrite the elements and the original input is passed ==> <Error />

This means that you would have to provide all the elements that you want to use, this the added value of using the XmlDoc approach for creating a message is than quite low.

I will post an update if I have found some more detailed info and will try to make an example solution.


Wednesday, August 18, 2010

ESB Toolkit not showing itinerary designer

I recently used a virtual machine that included the BizTalk ESB Toolkit. When i tried to start the machine everything worked fine, so i decided to startup some projects.

At the part where i wanted to design an ESB Itinerary i faced the issue that the designer was not showing. At first i suspected that a corrupted registry entry was the cause and was preparing myself for a fresh install untill i noticed something.


The visual studio version link that i used was different than another link i had on the system;’

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" /rootSuffix Exp /RANU

As Aaron Marten points out this is related to the new security layer where it should not be required for a visual studio developer to have full access to the machine. In my case this postfix was added due to a earlier installation of the VS.Net CTP or some other not released version. Later on the newer version was installed but the link had remained in the system.

It seems that the itinerary designer requires some additional rights due to access in the filesystem, registry or whatever. In my case i only had to use another link to get the desired itinerary designer….



Wednesday, August 04, 2010

Migrating BizTalk 2006R2 to BizTalk 2010

My colleague Rene Brauwers (Wren’s world) faced some issues when converting BizTalk projects created in 2006 R2 to the new BizTalk 2010 version. Please read his post i you are facing this problem as well: Migrating Biztalk 2006r2 solutions to Biztalk 2010

Tuesday, August 03, 2010

BizTalk Scale-Out Interactive poster

Besides the already well known BizTalk scale out poster and the MSDN documentation regarding scaling out the BizTalk Server Tier i found the interactive version that i can higly recommend!

This version provides the user with spoken comments, a transcript and the ability to click on the scale-out scenario of interest providing you with info in a sort of mini-presentation. Going through the entire presentation will take about 10-15 minutes.

See: BizTalk interactive scale out-poster





Monday, August 02, 2010

BizTalk workflow vs NinTex workflow tool

A customer recently asked about the interoperability of the Workflow modelling tool NinTex (on top of sharepoint) with other systems like BizTalk. Since i was not familiar with NinTex i downloaded the SDK, some product sheets and the help to find out about the capabilities to interop with other systems.

Since workfows can be developed quite easily with NinTex the first customer question was;

‘How can the flows from NinTex be used in developing BizTalk’.

NinTex has the ability to export the developed workflow to (unfortenately) an propietary format only. This means that it it not possible to re-use even parts of this workflow in for example visio.

" A workflow can be exported and saved in the file format ".nwf" in order to be used in another location. "

The second question was related to integrating with NinTex;

‘How can BizTalk provide integration in such a way that the back-end is controlled by BizTalk and the front-end is controlled by NinTex’

NinTex is a fairly extensive tool and has integration capabilities. The following means make integration possible;

- Use the schemas defined in the tool and export these as schemas

- Leverage the integration capabilities of Webservice

- Use the BizTalk shape inside NinTex to communicate directly with BizTalk

Note: Communicate directly means that the correlation/schema features are used, on the BizTalk side it means that the orchestration must be published as a webservice.


BizTalk is good in integrating with back-end systems by the provided Adapters, NinTex is a tool that can be used to develop workflows in a easy to use interface. Integration capabilities with BizTalk are available and making the combination of NinTex as a Fron-End mediator and BizTalk as a Back-End mediator with systems as SAP / HR Soft and others an obvious choice when NinTex is already the standard within the organisation.

Monday, July 19, 2010

BizTalk 2010 ESB Toolkit interactive poster

The BizTalk developer center and contain lots of usefull information and documentation for every BizTalk developer. Today i noticed the BizTalk 2010 ESB Toolkit Interactive poster and its quite cool!


Wednesday, June 30, 2010

BizTalk 2009 migration to 64-bit and the MQSC Adapter

The migration from BizTalk 2006 R2 to BizTalk 2009 was a fairly smooth one, untill we faced an issue that the MQSC Adapter was not working on the 64bit environment.

We tried to define a 64-bit host and run the adapter inside this host, this however did not proved to be the solution;


After browsing through the MSDN pages we found that it just wasn’t going to be a 9till5 workday;

“Only x86 (32-bit) Windows operating systems that are supported by BizTalk Server 2006 are supported by the MQSC Adapter. WebSphere MQ on Windows is not supported on 64-bit Windows operating systems. This means that the MQSC Adapter is not supported on either X64 (64-bit) Windows or a 32-bit BizTalk Host Instance on x64.” (

The setup we had previously used was;

- BizTalk 2006 R2 32-bit / MQ Client 6.2.5 + SSL / MQSC Adapter

“IBM WebSphere MQ Client 5.3 with CSD10, or IBM Websphere MQ Client 6.0 with Fix Pack” (

The new setup was;

- BizTalk 2009 64-bit / MQ Client 6.2.5 + SSL / MQSC Adapter

We looked for information on a bunch of pages likes forums/MSDN/technet/articles and came to the following conclusion;

BizTalk 2006 MQSC adapter does not support 64-bit and can only be used in conjunction with the MQ Client version

BizTalk 2009 MQSC Adapter has the same limitation when used with version but does support the new version of the MQ Client (7.x).

We installed the latest version and ran into another problem; error code AMQ9716. This was related to the usage of SSL and the new feature: certificate validation (OCSP Authentication) that was already in place in earlier versions, but was only actively refusing certificates in V7 of the MQ Client (

A collegae of mine noticed the sentence “This was ignored before V7.0.1.0” which led hem to believe that a V7 release existed without this validation. He searched and managed to get version…

I am glad to report that this is a winning team when you want to use 64-bit in BizTalk 2009;

BizTalk 2009 64-bit / MQ Client + SSL / MQSC Adapter

Solution: install the MQ Client version

Monday, May 31, 2010

SQL Server – Searching through an XML Field

In our project we are doing some additional logging like message payload, customer ids etc. The other day i want to provide the request/response times based on the starting point of the business transaction and information in an XML column that was filled when the message was sent. On a lot of websites i could find some examples but they all involved using namespaces etc. I thought i could do that with the lazy-goggles on and hereby the starting point of what is now a monster query ;)

SELECT as MessageID,
i.createdon MessageReceived,
CAST(m.messagesent.query('//*[local-name() = ''Timestamp'']/text()') as varchar) MessageSent
FROM instance i, message m
m.parentid = and i.customerref = 'CUSTID_00014041'
and CAST
(m.messagesent.query('//*[local-name() = ''Action'']/text()') as varchar) = 'SendResponse'

Note: the is required for the <xmlcolumn>. The query returns a Xml datatype, if you do not perform a cast you will receive an error.

Thursday, April 08, 2010

Back to the future - Microsoft.XLANGs.Core.TimeoutException

I recently faced this not so welcome friend of mine. This was the case on mine development environment consisting of:

- separate BizTalk machine + separate SQL Server

I could track down the source of this message being an atomic scope with a timeout of 60 seconds (receive shape waiting for a web service response). Since the error was pretty clear i finally found the cause….please take note of this for future generations ;)

The SQL Server machine clock was advanced 2 minutes compared to the BizTalk server running the orchestrations

Therefore the orchestration was ‘running in the past’ forcing a time-out in the atomic scope shape.

Somehow the time synchronisation service was not doing it’s job. I fixed the issue by using the ‘w32tm’ command line tool.

“w32tm /resync” (force the machine to resync the windows time using the PDC time)

Note: to view the difference between the current machine and the PDC you can you the monitor parameter;

“w32tm /monitor”

Monday, January 25, 2010

MQSC Adapter…BizTalk against IBM MQ + SSL

This article will go into detail about one of the possible approaches to connect from BizTalk to IBM MQ.

  • Note: This is not the only or best approach and this article serves as an example for the few out there facing the problem in setting up MQSC Adapter for IBM MQ + Certificates.

For starters i would like to quote a fellow BizTalker that spoke at the BTUG last week and said that in order to do SAP with BizTalk you would have to fulfill requirement #1: ‘Search for a SAP buddy’.

Well although i think this will apply to other adapters as well (e.g. Dynamics AX 2009!) it is a good general rule to have someone at the other side for support. It can get tough!


When communicating with IBM MQ there are a number of scenarios, although i might forget some, i believe the following are possible:

1) MQ Server hosted within your BizTalk environment

This would require the use of the MQSeries Adapter.

2) MQ Server hosted outside your BizTalk environment

This would be possible using 2 implementations:

- MQ Series Bridge as an MQ interface + Internal MSMQ (or another protocol)

- MQSC Adapter that directly communicates with the MQ Server & MQ Client in the BizTalk environment

  • Note: In this article i will discuss the latter, a Microsoft employee informed me later that the MQ Series Bridge is the most flexible and underpriced option when more interfaces are expected in the future.

MQSC Adapter

For my client we were obligated to use MQ, we received a license for the MQ Client (transactional) and received the configuration (tab) file to communicate with the MQ Server.

Although we could have implemented the API of the MQ Client, or extended the example .Net application we figured, why don’t use the free MQSC Adapter included in the ‘BizTalk Server Adapters for Host Systems’ (free in combination with a BizTalk license).

The Adapter assumes a Server on the outbound side that communicates with a MQ Client on the inbound side. The communication on MQ is performed on port 1414, the session is initialized by the client which requires an firewall configuration on port 1414 from inbound to outbound.

To enable communication with the B2B interface (BizTalk) with the MQ Client a dedicated MQ Client Adapter is required. The MQSC Adapter is a component of the ‘BizTalk 2006 - Adapters for Host Systems’ package. This adapter is known to only officially support MQ Client version


In this article the installation is explained, i will go into detail of the relevant steps;

Connection Name

Name of the MQSeries Server that contains the Queue Manager and Queues that the BizTalk Adapter receives messages from. For the TCP transport type, the format to specify is SERVERNAME(PORT). Port number is equivalent to the port number defined in the Listener associated with the Queue Manager.

Value: <ip>(port) e.g.

Channel Name

Name of the channel defined on the MQSeries Server computer that the client communicates with. This must be a ‘Server Connection’ Channel type (case sensitive property).


MQSeries queue from which the adapter will receive (MQGet) or send messages to (MQPUT).

Queue Manager

Name of MQSeries Queue Manager that contains the Queues from which the adapter will retrieve messages.


When using SSL in a scenario where the outbound is responsible for the Server this means that;

- Client certificates are provided by this party

- User for which the client certificates are requested MUST BE the same user under which BizTalk host the Adapter runs!*

- SSL Key repository is the most flexible and easy way to configure the certificates (no client installation required, only the path to the SSL Key repository has to be configured

The following additional adapter settting must be configured

- SSL Cipher specification

This is a fixed value, defining the algorithm e.g. : NULL_MD5

- SSL Key Repository location

This is the location where the repository is stored.

  • Note: do not provide the extension, only provide the path in the form of C:\SSL\qmkeys

- SSL Peer name

This is a fixed value, this should be provided to you by the party that provided the key repository.


Since the certificate is requested for a specific user, this user must also set up the connection, otherwise the certificate can not be found. Since we use MQ through the MQSC Adapter, the host under which this adapter runs must also run under this user.

Reference [Error codes]

Relevant facts

- Only version of the MQ Client is supported due to adapter limitations.

- The Certificates should be provided by the external party

- The required port for MQ Communication 1414 is configured in the firewall that communicates from inbound to outbound. Because the MQ Client initiates communication the firewall doesn’t have to be configured bi-directional (this might make some administrators less worried about security ;)

- The Certificates are requested for a specific user, this has the implication that all future MQ communication must be set up for this specific user!

- Due to the aforementioned restriction the MQSC Adapter should run under the user specified in the certificate.

  • After contact with Microsoft the suggested approach when multiple parties require MQ Communication, is to introduce a MQ Bridge.

This means that outside the BizTalk environment MQ is used between the Bridge and the customer and internally MSMQ is used to communicate between the BizTalk environment and the Bridge.

  • Additional advantages: MQBridge is included in the BizTalk license / Extended MQClient is costly.


Suggestions to setup the communication

- MQ Client incorporates some command line tools (PUTC / GETC) to test the channel.

- Telnet can indicate whether communication is possible

- When ‘standard’ BizTalk-IBM MQ communication has been achieved, it does not mean you are there, the extra effort for SSL might consume more time than initial communication!

- A trial MQ Server can be used to understand MQ Client / Server architecture

- When using SSL first determine under which account you want to run the Adapter (forever!) and communicate this with all client

- Keep in mind that when multiple MQ clients are expected in the future the MQ Bridge is the logical way to implement MQ Communication

- Find an IBM MQ Buddy :)


Have fun!