BizTalk Server – HL7 Error: Failure executing BTAHL72XSendPipeline “Body schema is missing”

Recently I had a requirement to generate an HL7 ORM to send to Oracle.
To fulfill the requirements, an HL7 message must be generated inline inside an orchestration.
The ExecuteReceivePipeline method must be used in orchestration, to execute the BTAHL72XSendPipeline pipeline with the HL7 multipart message to finally generate the message in HL7 format.

All HL7 must be multipart messages consisting of three segments:

  • Body segment – The HL7 message (marked as message body part)
  • MSH segment – The HL7 header
  • Z Segment – HL7 custom segment

To generate the ORM HL7 message, the BTAHL72XSendPipeline requires that the “message type” property be promoted, otherwise the error “Body schema is missing” will be thrown.
This property cannot be directly set, because is a reserved property used by BizTalk, the only way is to copy from other message.
If your orchestration receives the same HL7 message type, it’s easy to fix this issue, just set the multipart properties from the inbound message using the “(*)” syntax. In this way, the “message type” property will be copied.

There are several posts with this fix like and

If you do not have an incoming  HL7  message, the solution is a little bit tricky.

  1. Create an BizTalk ORM message (you can use other HL7 message type or versions depending of the business requirements);
  2. Force the “message type” promotion executing the XmlReceive pipeline (inline in orchestration);
  3. Set the message created in1) to the multipart BodySegments segment;
  4. Copy the ORM properties to the multipart message ( HL7MultipartMessage(*)=ORMMessage(*) )

Hope this helps!




BizTalk Server HL7 – Strange break lines in MSH segment

If you create an HL7 MSH segment with XmlDocument, you can get a strange break line in all empty values, like in the following image.

The HL7 message will also be created with the same break line, generating an invalid HL7 message.

It’s easy to deal with it, just set PreserveWhitespace property in XmlDocument with “true”, before assigning it to the HL7 MSHSegment.

xmlDocument.PreserveWhitespace = true;

hl7msg.MSHSegment = xmlDocument;

You can get more info in

VSTS – How to link a GIT commit with backlog task or bug

It’s very easy and recommended to link all GIT commits with VSTS scrum backlog tasks or bugs.
Just put the task or bug “id” in the commit description with the #[id] format.

For example, if you want to link a specific commit to the task “28”, put “#28” in the commit description like “Bla bla #28“.

All commits will be linked with the task or bug and shown in the development area.

BTDF – How to config BRE policies or vocabularies

Greetings to all BizTalk programmers 🙂

There’s not much information how to properly add a BRE rule in a BTDF deployment script.
It’s very easy to put it to work, but not so easy to get it there.

Just follow the below instructions :

  1. Create the rule in Business Rule Composer.
  2. Use the Rules Engine Deployment Wizard to export the created policy or vocabulary xml.

  3. Put the exported policy or vocabulary xml in a VS project folder (I advise to put in Deployment/BRE/Policies folder).
  4. Edit btdfproj file (if you dont’t know how to set this file, check codeplex BTDF site
  5. Set “IncludeVocabAndRules” element with the value “true”.
  6. Add the following elements  (set the policy or vocabulary xml name and location).
  7. The BRE rules are always updated after MSI or VS deploy by executing the options “Deploy BizTalk solution” or “Deploy Rules or Vocabularies”.

This configuration also works with environment settings variables (${variablename}), allowing us for example to set different policy data in quality and production environments.

BTDF – Generate specific environment binding

BizTalk Deployment Framework (BTDF) is known as the best way to perform BizTalk artifacts installation.
It’s also the only way (I know) to create an automatic BizTalk deployment.

If you don’t know what is BTDF, go to

This Framework allow us to create an MSI deployment package directly  from Visual Studio or Command Line.
It also has a great feature that allow us to maintain only one binding file concerning all environments.
That binding template files are replaced for the correct environment data in the MSI generation.
The specific environment data is configured in a XML file that can be opened in Excel.

Sometimes there are releases that only have binding changes, and you want to use the best practice of always use BTDF generated data in your deployments.
So… how can you deal with this in BTDF.!! The VS menu does not have an option to generate environment bindings.

The BTDF installation give us a tool called xmlpreprocess, which is used in the MSI generation by the BTDF engine.
Xmlpreprocess tool allow us to merge a specific environment configuration with the binding template (normally named master binding), resulting in the transformed deployment binding.

It’s very easy to use.

  1. Open a Command Line Prompt
  2. Navigate to the  BTDF install folder “..\Framework\DeployTools” (normally  C:\Program Files (x86)\Deployment Framework for BizTalk 5.6\Framework\DeployTools)

For example

xmlpreprocess.exe /v /c /noDirectives /i:”C:\Projects\MyProject\Deployment\PortBindingsMaster.xml” /o:”C:\Projects\MyProject\GeneratedBindings\OutputBinding.xml” /d:CurDir=”C:\Projects\MyProject” /s:”C:\Projects\MyProject\Deployment\EnvironmentSettings\Exported_ProdSettings.xml”

The generated environment (Local, QA, PRD, …) is defined in xml file path after the “/s” parameter.

Hope this helps.


BizTalk Server Single Sign On – Save config data in SSO

This is my last post about using SSO on Biztalk Server. In this post I will show how to set and retrieve configuration data from SSO.

To configure and set configuration data, Microsoft has an MMC Snap-In called “SSO Configuration Application”, that allow us to create and manipulate applications and their properties (

From the community there are several tools to set SSO configuration. The most well know was created by Richard Seroter in 2007 that allow us to manipulate previously created properties in an easy way (  There are also some Richard Seroter tool improvements, like a version from Mark Burch in, that allow us to create new SSO properties.

BizTalk Deployment Framework also include an SSO module, that use a different approach of using the Excel to set SSO config data in each environment (

To get configuration from SSO by code, you can use “SSOConfigHelper.cs” included in Microsoft BizTalk Server 2006 SDK, but still working with the latest Biztalk server versions (
Just get the code and include “Microsoft.BizTalk.Interop.SSOClient.dll” in SSO install folder (for example C:\Program Files\Common Files\Enterprise Single Sign-On\Interop1.1\Microsoft.BizTalk.Interop.SSOClient.dll) and call the read method, setting the previous create application and property name.

Hope that 4 posts about SSO will help you to use SSO more frequently in BizTalk programming.

BizTalk Server Single Sign On – Using SSO with adapters

In BizTalk Server there are several adapters that automatically support SSO without any code.
Many BizTalk Adapters already support this feature, like SQL, most of WCF, Oracle, FTP, HTTP, etc.

The SSO configuration to support this feature is very easy.
First enter SSO Administration tool, and create a new affiliate application with the above settings (you can put any name in the application name):





In BizTalk Server Administration, when setting the receive location configuration, set the use SSO option, and use an isolated host with a running account that belongs to the SSO application administrators group (images above).



In the send port adapter configuration set the affiliate application created earlier.


To finalize the configuration, you must set SSO to allow ticket usage (by default is not allowed).
Execute the following instruction in the command prompt “ssomanage -tickets yes” (

The credential mapping is working without any “hand made” code creation.

BizTalk Server Single Sign On – Get mapped credential by code

This is my second post about using single sign on in Biztalk Server.
In this post i will show how to access mapped credentials by code.

First create a new affiliate application and a credential mapping as i show in the last post.

    1. Create a new class library project called “Test.SSO”
    2. Add a reference to the assembly “Microsoft.BizTalk.Interop.SSOClient.dll”, located in “C:\Program Files\Common Files\Enterprise Single Sign-On”
    3. Add the following code in a new class called SSOManager
      using System;
      using System.Collections;
      using System.Collections.Specialized;
      using Microsoft.BizTalk.SSOClient.Interop;
      namespace Test.SSO
           public static class SSOManager
                /// <summary>
                /// Get external application credentials.
                /// </summary>
                /// <param name="ticket">Credential ticket generated by biztalk receive port.</param>
                /// <param name="appName">Application name to get external credentials.</param>
                /// <param name="userAccount">User account to get external credentials.</param>
                /// <returns>ArrayList with mapped credentials.</returns>
                public static ArrayList GetExternalApplicationCredentials(string ticket, string appName, string userAccount)
                     ISSOTicket ssoTicket = new ISSOTicket();
                     string externalUsername;
                     string[] credentials = ssoTicket.RedeemTicket(appName, userAccount, ticket, SSOFlag.SSO_WINDOWS_TO_EXTERNAL, out externalUsername);
                     if (credentials == null || credentials.Length == 0 || String.IsNullOrWhiteSpace(externalUsername))
                          return null;
                     ArrayList credentialsList = new ArrayList();
                     return credentialsList;
    4. Create a new Orchestration called SSOOrch
    5. Include a reference to the previous created class library
    6. Publish a new wcf service  using “WCF Service Publishing Wizard” and publish it at basic auth (
    7. Set the Orchestration receive location to receive messages from the service created
    8. Configure the receive location security área like the following image, but checking “Use Single-On” option.
    9. Create na Orchestration variable called ssoMapping as ArrayList
    10. Add a new expression shape in the orchestration
    11. Add the following code in the previous expression Shape (TestApp is the name of the affiliate application previously created)
      ssoMapping = Test.SSO.SSOManager.GetExternalApplicationMapping(SSOOrch(BTS.SSOTicket), “TestApp”, SSOOrch(BTS.WindowsUser));
    12. Complete the orchestration by setting a send shape to file system.
    13. Deploy the orchestration and set the regular configurations, but very important – set an host instance with an account that belongs to a SSO application administration group
    14. Invoke the previously created wcf service with an account that you have set in the SSO mapping.
    15. If you debug the orchestration, you will get in the ssoMapping ArrayList 4 parameters with the data you have set in “User Id”, “MappedUser”, “”MappedPassword” and “MappedDomain” as you see in the next image.

Hope this example will help you to easily use SSO in BizTalk Server.
Happy coding.

BizTalk Server Single Sign On Configuration

This is my first post (in a total of four) about using SSO on BizTalk Server.
In this post i will show how to config an 1 on 1 credential mapping in SSO, in the next 3 posts i will show how to access mapped credentials by code, use SSO directly in BizTalk adapters, and the most commonly used to store key pair values.

It’s very easy to configure SSO to store credential mapping data.
First access mmc console and choose Enterprise Single-Sign-On application.


Then choose Affiliate Applications and select “Create Application”.


The application creation wizard starts. Choose “next”.


For 1 on 1 credential mapping, select “Individual” application Type. To read about all mapping types, check
Select the application name, description and leave the other options unchecked (if you are using dev or single server, check the option “Allow local accounts for access accounts”).


Set the Windows group that will manage this Affiliate Application in the “Application Administrators” picker.
Set the windows group for which mappings can be created in “Application Users” picker.
You can check more about this configurations in


In the Options menu check the following options:

    • Enabled.
    • Allow Windows initiated SSO.
    • Tickets Allowed (with all ticket options selected).
    • Application Users cannot create mappings (only a security measure).

A ticket is a kind of SSO encrypted context, that contains the request user domain and username and the ticket expiration time.
You can check more info about SSO tickets in


In the fields menu, you must choose the destiny application attributes to map in this SSO affiliate application.
I have created 3 attributes (Mapped User, Password and Domain).
The User ID mapping is created by default and is a mapped credential unique key.
The masked attribute is used for the password fields, and the synchronized attribute determines that the field is used for password synchronization.


The affiliate application is created successfully.


After creating the affiliate application it’s very easy to create a mapped credential.
Just go to the Affiliate Applications menu, select the previously created “TestApp” application and “New Mapping” option.


In the “Create New Mapping” menu select the windows account to map and the unique destiny account name to map.
Check the “Set credentails for this mapping” option.


In the Set Credentials menu, set the mapped data.
The user id can be used to store the mapped user data, but beware because user id must be unique. So I have created the MappedUser field, because I can have multiple source accounts to map to the same destiny account data.


The new mapped credential appears in the “TestApp” affiliate application mapped credentials.


In the next post I will show how to get the mapped credentials data by code, to use for example in a BizTalk Orchestration or Pipeline.

Biztalk xml header processing

When we use infopath or similar technologies with biztalk, the messages have always a xml processing header. Biztalk does not copy xml processing header to the output messages by default, so we have to set it manually.

There are several options in biztalk to manipulate xml header processing in output messages:

  • Set the header in orchestration using the message context properties

message(XMLNORM.ProcessingInstructionOption) = 0 (append) or 1 (create new);
message(XMLNORM.ProcessingInstruction) = “xml processing header to add or append”;

Important: For the demoting process to occur, you must use the Xml assembler component or xml transmit pipeline in the output send port.

  • Use xml transmit pipeline or a custom pipeline with the xml assembler component in the output send port

When you use the xml transmit pipeline, you must set the following properties:

ProcessingInstructionsOptions – 0 (append) or 1 (create new)
XmlAsmProcessingInstructions – “xml processing header to add or append”

  • Use a custom pipeline component

When  you use a custom pipeline with xml assembler component, set the following properties:

Add Processing Instructions – Append or Create new
Add processing instructions text – “xml processing header to add or append”

This option is the most difficult to implement, you have to create a custom assembler component, get and change the output message.

Do not forget to set the the biztalk maps property “copy processing instructions (pis)” to “yes” when you want to copy the processing instructions from the input to output messages.