HowTo define a Custom Soap Header in BizTalk. Expose it, Consume it , even map them..

June 13, 2008 / Comments Off on HowTo define a Custom Soap Header in BizTalk. Expose it, Consume it , even map them..


1. Create the schema that defines your custom header. This schema should be a NORMAL schema. (Give it a decent rootnode name)

2. Create a PROPERTY schema with TargetNamespace :

3. Make sure you define a property in the PROPERTYSCHEMA with EXACTLY the same name as the ROOTNODE of the schema in step 1

4. Make sure you set the set the “Property schema base” to “MessageContextPropertyBase” !!!!!

5. Deploy.

That’s it…… I was really confused by other posts on the web that are just not clear enough… But the summary above is very short so I will explain a bit more.

First step.

Create a normal schema that represents your custom header. Below is a screenshot of my schema.

But I also wanted to send a custom header, so I had to create a second schema representing my outgoing envelope.


Second step.

Now I had to create a property schema. Taking care that my property names where EXACTLY the same as the Rootnodes in the schemas. I also had to set the namespace to the correct SOAPHeader namespace.

After setting  the “Property schema base” to “MessageContextPropertyBase” I deployed everything. And I was basically ready to go.

The orchestration

I created a very simple orchestration. It Receives a message, Maps it to the output and sends the output back. More on this orchestration later. I then generated a web service With the wizard that came with Biztalk. It is probably important to mention that when generating the service, I added extra SOAP headers. As the inbound header I specified the “inHeader” schema  and as the outbound header I specified the “outHeader” schema (So not the propertyschema). Then after some wizardry of the wizard, I fired up my trusted WebService Studio tool” and hit the GET button. I was presented with the following picture..

Everything I was expecting, was there. So it was very easy to send and receive headers.


After receiving the message, the Adapter (it also works with PASSTHROUGH) will strip off the header and put it into the context property. Below is a screenshot of the received message. As you can see there is no messagetype set so it was received via a passthrough pipeline.

But how nice … the context property “inHeader” contains an XML document with the content of the SOAP header.

So if you want to get to a Specific SOAP Header in an Orchestration. The following code should do the trick.



For Sending messages with the header it works the other way around. Just make sure you have set the content of the outbound header context property to an XML document representing a valid header. I created mine with the mapper.

Then I threw in a shape where I put the contructed document into the context property…

And Presto….





New Style SSO Available on Codeplex

June 2, 2008 / Comments Off on New Style SSO Available on Codeplex

If you are working with BizTalk you know the dilemma, where do I store my configuration data. Could be on several locations. Have a read of this article to have some in-dept information.

I created a base class SSOBaseFunctionality thad deals with storing and loading configuratioin data to and from SSO. So if you want to store a specific class in SSO just make sure it inherits from SSOBaseFunctionality and you are ready to go.

The project is on Codeplex.

Your class could simply look like this.

    public class SampleConnectionData:SSOConfigItem
        public SampleConnectionData(string ApplicationName)
            base.SSO_ApplicationSettingName = ApplicationName;

        public SampleConnectionData()

        private string dataSource = string.Empty;
        private string database = string.Empty;
        private string applicationName = string.Empty;
        private string userName = string.Empty;
        private string password = string.Empty;
        private bool trustedConnection = false ;

        public bool TrustedConnection
            get { return trustedConnection; }
            set { trustedConnection = value; }
        public string Password
            get { return password; }
            set { password = value; }

        public string UserName
            get { return userName; }
            set { userName = value; }

        public string ApplicationName
            get { return applicationName; }
            set { applicationName = value; }
        public string DataSource
            get { return dataSource; }
            set { dataSource = value; }

        public string Database
            get { return database; }
            set { database = value; }

And then you will have functionality like this :

// Create a SSO connection class.
SampleConnectionData objConnection = new SampleConnectionData(“SomeApplicationName”);

// Set properties
objConnection.TrustedConnection = true;
objConnection.DataSource = “(Local)”;
objConnection.Database = “Master”;
objConnection.ApplicationName = “DemonstrateUsage”;

// Create the applications

// Save the application

// Get a new Object
SampleConnectionData OtherConnection = new SampleConnectionData(“SomeApplicationName”);
// Load properties from SSO Configuration Store


  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta