BizTalk Server: Reducing and Consolidating WCF Serialization Schema Types

Article
1/17/2024

Reducing and Consolidating WCF Serialization Schema Types

Eventually, it seems every customer asks why there are so many duplicates in the Schemas list. What they always seem to be referring to is the types defined in xxxSerialization.xsd generated by various WCF metadata Wizards.

Download the Code Gallery Sample here: BizTalk: SQL Patterns for Polling and Batch Retrieve

The (Not Really Big) Problem

We can see the effect when viewing the deployed schemas for my last article BizTalk: SQL Patterns for Polling and Batch Retrieve which involved the generation of 3 SQL operations.

Each generated SQL operation brought its own serialization schema so we see three instances of each type it defines. While this does not create any problems at runtime, it does make the list a little harder to work with when managing or checking on Schemas, for tracking and such.

Solutions

Here, I’m presenting 3 simple techniques to clean up the schemas list

Remove the Reference
Reference an Existing Schema
Set Root Reference

Removing the Reference

Sometimes the inclusion of the types in Serializaion.xsd does not provide a substantial benefit, particularly if the field is Adapter generated only, as is the case in a polling scenario.

Examining the output schema for the Polling a Database We Own example, we see that the only serialization type used, ‘guid’, is for the two uniqueidentifier fields, rowguid and PollingID.

In the serialization schema, ‘guid’ is defined as a restriction of xs:string with at RegEx pattern.

In this situation, we can be very confident that the SQL Adapter will always emit a valid GUID format so having the custom type for validation doesn’t provide any significant extra value.

We can remove the XSD Import on the serialization schema after setting the Data Type for the guid fields to xs:string, their current base type.

Once we remove the XSD Include from the Imports collection property of the <Schema> node, we can remove the serialization schema from the project and Deploy.

Now, when we look at the Schemas list, we see only two duplicates.

Referencing an Existing Schema

Here, it’s important to point out that the serialization schema is common across implementations. Because of this, if the situation warrants keeping the types in the serialization schema, we can have all our operation schemas can reference a single serialization schema.

For this example, I’m going to add a Project reference to the RetrieveAsABatch Project which contains another copy of the serialization schema.

Next, change the XSD Import reference from the local schema to the schema in the RetrieveAsABatch Project.

Note, changing the import location via the GUI can be challenging because the schema designer enforces any references. I made the change to the schemaLocation attribute manually.

<xs:import schemaLocation="RetrievingABatch.getSalesOrdersByIDs_Serialization" namespace="http://schemas.microsoft.com/2003/10/Serialization/" />

When this is done, we can remove the local serialization schema from the project and Redeploy.

Now, when we look at the Schemas list, we see only one instance of each serialization type.

Note, if referencing a single serialization schema from multiple operations, it is a better practice to give the serialization schema a generic, solution scoped name, SQLPatterns_Serialization.xsd for example.

Set the Root Reference

Up to here, we’ve managed to remove the duplicate entries from the Schemas list, but we can still take this one step further.

The definitions in the serialization Schema appear on the list because they are root level elements in the Schema itself. However, they will never be used as actual root elements.

Fortunately, BizTalk has a way to help with this as well by using the Root Reference Property of the <Schema> node.

Since we can only set Record elements as the Root Reference, the anyType element is our only choice.

Now after Redeploying the Solution, we see just the one anyType entry for the serialization schema shared by the two individual operations.

Share via