A source code could be downloaded from here.
Sometimes in BizTalk the artifact visibility can be global. We place the artifacts in different assemblies and it doesn’t change visibility. We place the artifacts in different BizTalk applications and it doesn’t change visibility.
Let’s talk about the schemas. In my previous post BizTalk: Internals: namespaces I’ve shown that schemas have additional parameter, the Xml [target] namespace. Why it is so important?
The BizTalk receives messages on the Receive Locations. Theoretically messages are just the byte arrays. But the BizTalk frequently has to do additional tasks like changing the message format from the one system format to another. That means the message should be received in an known format. Without knowing the format the BizTalk cannot make a transformation. The BizTalk message internal format is an Xml or a byte array. Here I am talking about the messages in the Xml format.
So the Xml messages are received by the Receive port as the byte arrays and should be parsed into Xml format. The XmlReceive pipeline makes this transformation. The first thing the XmlReceive makes, it searches a Xml namespace and a root node. Those two parameters create a MessageType parameter with is promoted as a context parameter.
As you can see the BizTalk uses the MessageType to find out the schema for this message. This Xml schema is used to parse the whole message into Xml format.
So the first step is to find a Xml namespace and a root node inside the byte array regardless of anything else, the second step is to find out the Xml schema, then this schema is used to parse the whole message into Xml format.
Now we are discussing the second step, how the BizTalk is searching the right schema.
The BizTalk searches through the whole schema list regardless of the application boundaries. Each schema belongs to one of the BizTalk application, but BizTalk ignores this. The global schema list is stored inside the BizTalk management database. When we deploy a project with a schema, the schema is registered inside this database.
When an inbound message is received and processed by the XmlReceive pipeline, the BizTalk extracts a MessageType (a namespace + a root node), and searches for this MessageType in the management database. An error is raised if the MessageType is not found. The error is raised if more than one schemas with this MessageType is found.
An important note is the schema uniqueness rule is not verified at the deployment time.
I have created several samples to show how it works. These samples are barebone projects, focused on the “schema uniqueness” rule.
Identical schemas in the one BizTalk application
The application includes two projects. Each project is compounded from one schema.
Both schemas have the same structure and the same Xml namespaces.
The only difference is the .NET namespaces. Each schema is placed in different assembly.
I have created one receive port with one File receive location and XMLReceive pipeline. A send port works as a subscriber to this receive port.
Nothing else is in this application. Two identical schemas in different assemblies and receive and send ports.
I droped a test Xml file in the receive folder. What do you think is happened? You are right, I’ve got an error and two related events, 5753 and 5719.
It is a famous "Cannot locate document specification because multiple schemas matched the message type ###" error. :)
Conclusion: schemas of the receive messages should be unique across allne BizTalk application.
Identical schemas in the different BizTalk applications
Now two the same projects are in different BizTalk applications. (As you can see I have broken the naming convention, which forces to place the BizTalk applications in the different Visual Studio soulutions. In real life there would be two Visual Studio solutions. Sorry for that. )
The ports are the same as they are in the first sample.
When I droped a test file I have got the same error as in the first sample. So the schemas are now placed in different applications but it doesn’t change the schema visibility. The schema from one application is visible from another application.
Conclusion: schemas of the receive messages should be unique in different BizTalk applications. In other words they should be unique across the whole BizTalk Server Group.
Identical schemas imported by different schemas
Now let’s ask a question. Is the “schema uniqueness” rule relating to the imported schemas?
Here is a real-life example. We are consuming the WCF web-service metadata, and it creates the schema set where we can see the Microsoft Serialization schema. It is the same schema almost in each and every WCF service. Do we have to take care of this schema if we consume several WCF services? Do we have to “fight” this schema, extract it into Schared project, etc.?
This sample is the same as a previous sample with two additional schemas: Importing.xsd and Imported.xsd.
Both Importing schemas in two applications are different. They have different Xml namespaces.
But both Imorting schemas are identical.
The ports are the same as they were in the first sample.
When I droped a test file there was no error.
So the “root” schema namespaces, the namespaces which define the MessageType were different, but the namespaces of the imported schemas were the same and this the XMLReceive pipeline could successfully recognize the MessageType of the message.
Conclusion: the “schema uniqueness” rule works only for the schema which define a MessgeType of the received message and doesn’t work for the imported schemas.
- Two parameters of Imported schema are changed from default values. It forces to include the namespace prefixes of the Imported schema into the Xml documents. Those parameters are the AttributeFormDefault and ElementFormDefault.
A message with these parameter values equal “Qualified”:
A message with these parameter values equal “Default”:
- We could mention the “typeOnlySchema” Root Name for the Imported schema. Actually this schema doesn’t have any root, any elements, it includes only types.
“Schema Uniqueness” Rule
The schemas used for the MessageType should be unique within the BizTalk Service group if these schemas are used in the XMLReceive pipeline of the receive locations.
Is there a reason for the “Schema Uniqueness” rule?
Is there a good reason for this rule?
I would prefer if the schema visibility is limited inside the BizTalk application. It would extrimply simplify the schema and service versioning.
Let’s take an example when our partner added a new version of the service. The service schemas itself are different in both services (several nodes were removed, several nodes were added), but the schema namaspaces and roots are the same in both services. The new and old services work side-by-side and we have to consume both service versions. If we could limit the schema visibility inside the application boundaries, creating the BizTalk applicatons for consuming both service versions would be simple. Now it is cumpersome. I am sure, each experienced BizTalk deverloper can remember several real-life examples, when this “schema uniqueness” rule was a reason when several hours project was instead implemented in several days.
Looks like a reason for this “schema uniquness” rule is simple. The BizTalk application was introduced only in the BizTalk 2006. In this time Microsoft decided do not change the XMLReceive pipeline to embrace new application conception and since then this feature was not on the priority list in the BizTalk development.
| posted on Monday, December 24, 2012 1:00 PM