Not Using "http://namespace#root" as BizTalk Message Type

This has come up twice for me in the past week: once while reading the tech review comments on my own book (due out in April), and again while I was tech reviewing another BizTalk book (due out in July).  That is, we presumptively say that the BizTalk “message type” always equals http://namespace#root when that’s not necessarily true.  Let’s look at two cases demonstrated here.

This first simple case looks at a situation where an XML schema actually has no namespace.  Consider this schema:

Perfectly fine schema, no target namespace.  I’ve gone ahead and created another schema (with namespace) and mapped the no-namespace schema to the namespace schema.  After I deploy this solution and create the necessary ports to both pick up and drop off the message, I can stop the send port and observe the context properties of the inbound message.

Notice that my message type is set to ReturnRequest which is the name of the root node of my schema.  Obviously, no namespace is required here.  If I throw my map on the send port, I can also see that the source schema is successfully found and used when mapping to my destination format.

So, for case #1, you can have schemas with no namespace, and the message type for that message traveling through BizTalk is in no worse shape.

For case #2, I wanted to try creating my own message type arbitrarily and keep it as something BizTalk doesn’t generate.  For instance, let’s say I receive binary files (e.g. PDFs) but want to add not only promoted fields about the PDF, but also type the message itself.  The PDF file has a specific name which reflects the type of data it contains (e.g. ProductRefund_982100.pdf and ProductReturn_20032.pdf).  The file location where these PDFs are dropped have names based on the country of origin, like so:

So I can set a “type” for the message based on the file name prefix, and I can set a promoted “country” value based on the location I picked it up from.  After adding a new property schema to my existing BizTalk solution, I next built a custom pipeline component which could work this magic for me.  The guts of the pipeline component, the Execute operation, is shown here:

public IBaseMessage Execute(
     IPipelineContext pContext, 
     IBaseMessage pInMsg)
 //get context pointer
 IBaseMessageContext context = pInMsg.Context;

 //read file name and path 
 string filePath = context.Read("ReceivedFileName", 
 //parse file name to determine message type
 string fileName = Path.GetFileNameWithoutExtension(filePath);
 string[] namePieces = fileName.Split('_');
 string messageType = namePieces[0];
 //get last folder which indicates country this pertains to
 string[] directories = filePath.Split(Path.DirectorySeparatorChar);
 string country = directories[directories.Length - 2];

 //set message type

 //set promoted data value

 return pInMsg;

After compiling this and adding to the “Pipeline Components” directory in the BizTalk install folder, I added a new receive pipeline to my existing BizTalk solution and added my BinaryPromoter component.

After deploying, I added a single receive port with two receive locations that each point to a different “country” pickup folder.  Each receive location uses my new custom receive pipeline.

I have two send ports, each subscribing to a different “message type” value.  My second send port, shown here, also subscribes on my custom “country” promoted value.

When I drop a PDF “product refund” file into the “USA” folder, I can observe that my message (of PDF type) has a message type and promoted data value.

Neat.  So while it’s important to have BizTalk-defined message types when doing many operations, be aware that you can (a) still have message types without namespaces, and (b) define completely custom message types for use in message routing.

Technorati Tags:

Author: Richard Seroter

Richard Seroter is Director of Developer Relations and Outbound Product Management at Google Cloud. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former editor plus former 12-time Microsoft MVP for cloud. As Director of Developer Relations and Outbound Product Management, Richard leads an organization of Google Cloud developer advocates, engineers, platform builders, and outbound product managers that help customers find success in their cloud journey. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

7 thoughts

  1. Richard,

    I faced the same on my latest project (good to know it’s not just me). It seems like there are a lot of companies that do not use namespaces on ther schemas.

  2. This is good stuff, now if I could just find a way to change the MessageType condition of my orchestrations. I want to have my pipeline component to figure out the schema of the message, so it can have a unique MessageType, but there doesn’t seem to be any way to override the MessageType condition that’s created in the subscription for an orchestraion. Any ideas?

    1. You could use an XmlDocument as the message type into an orchestration which means that ANY schema matches. Maybe you could route it to that orch based on something else then.

  3. Thanks…. Nice explanation. However it does not help me all-the-way.
    My namespace is:




    How to handle a schema like this ? I have anothe application with the same Navision XML-files for PurchaseOrders. These conflict..

    Thanks for any help at all 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.