BizTalk team did a good job hiding the .NET guts from developers. Developers are working with editors and hardly with .NET code. The Orchestration editor, the Mapper, the Schema editor, the Pipeline editor, all these editors hide what is going on with artifacts created and deployed.

Working with the BizTalk artifacts year after year brings us some knowledge which could help to understand more about the .NET guts.

I would like to highlight the .NET namespaces. What they are, how they influence our everyday tasks in the BizTalk application development.

What is it?

Most of the BizTalk artifacts are compiled into the NET classes. Not all of them… but I will show you later. Classes are placed inside the namespaces. I will not describe here why we need namespaces and what is it. I assume you all know about it more then me.

Here I would like to emphasize that almost each BizTalk artifact is implemented as a .NET class within a .NET namespace.

Where to see the namespaces in development?

The namespaces are inconsistently spread across the artifact parameters.

Let’s start with namespace placement in development. Then we go with namespaces in deployment and operations.

I am using pictures from the BizTalk Server 2013 Beta and the Visual Studio 2012 but there was no changes regarding the namespaces starting from the BizTalk 2006.

Default namespace

When a new BizTalk project is created, the default namespace is set up the same as a name of a project. This namespace would be used for all new BizTalk artifacts added to this project.

Orchestrations

When we select a green or a red markers (the Begin and End orchestration shapes) we will see the orchestration Properties window. We also can click anywhere on the space between Port Surfaces to see this window.

Schemas

The only way to see the NET namespace for map is selecting the schema file name into the Solution Explorer.

Notes:

• We can also see the Type Name parameter. It is a name of the correspondent .NET class.
• We can also see the Fully Qualified Name parameter.
• We cannot see the schema namespace when selecting any node on the schema editor surface. Only selecting a schema file name gives us a namespace parameter.
• If we select a <Schema> node we can get the Target Namespace parameter of the schema.
  
  
  
  This is NOT the .NET namespace! It is an XML namespace. See this XML namespace inside the XML schema, it is shown as a special targetNamespace attribute
  
  Here this XML namespace appears inside the XML document itself. It is shown as a special xmlns attribute.
  
   

Maps

It is similar to the schemas. The only way to see the NET namespace for map is selecting a map file name into the Solution Explorer.

Pipelines

It is similar to the schemas. The only way to see the NET namespace for pipeline is selecting a pipeline file name into the Solution Explorer.
z

Ports, Policies and Tracking Profiles

The Send and Receive Ports, the Policies and the BAM Tracking Profiles do not create the .NET classes and they do not have the associated .NET namespaces.

How to copy artifacts?

Since the new versions of the BizTalk Server are going to production I am spending more and more time redesigning and refactoring the BizTalk applications. It is good to know how the refactoring process copes with the .NET namespaces. Let see what is going on with the namespaces when we copy the artifacts from one project to another.

Here is an example: I am going to group the artifacts under the project folders. So, I have created a Group folder, have run the Add / Existing Item.. command and have chosen all artifacts in the project root. The artifact copies were created in the Group folder:

What was happened with the namespaces of the artifacts?

As you can see, the folder name, the “Group”, was added to the namespace. It is great! When I added a folder, I have added one more level in the name hierarchy and the namespace change just reflexes this hierarchy change.  The same namespace adjustment happens when we copy the BizTalk artifacts between the projects.

But there is an issue with the namespace of an orchestration. It was not changed. The namespaces of the schemas, maps, pipelines are changed but not the orchestration namespace. I have to change the orchestration namespace manually.

Now another example: I am creating a new Project folder and moving the artifacts there from the project root by drag and drop. We will mention the artifact namespaces are not changed.

Another example: I am copying the artifacts from the project root by (drag and drop) + Ctrl. We will mention the artifact namespaces are changed. It works exactly as it was with the Add / Existing Item.. command.

Conclusion:

• The namespace parameter is put inconsistently in different places for different artifacts
• Moving artifacts changes the namespaces of the schemas, maps, pipelines but not the orchestrations.