Building BizTalk Server 2009 Applications : What are BizTalk schemas?

<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Person>
<xs:complexType>
<xs:sequence>
<xs:element name="FirstName" type="xs:string"/>
<xs:element name="LastName" type="xs:string"/>
<xs:element name="Age" type="xs:int"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Having a strict contract can reduce flexibility but it greatly increases predictability as the message consumer can confidently build an application, which depends on the message being formatted a specific way.

Schema creation and characteristics

While producing completely valid XSD syntax, the BizTalk Schema Editor takes a higher-level approach to defining the schema itself. Specifically, instead of working purely with familiar XML concepts of elements and attributes, the BizTalk Schema Editor advances a simpler model based on records and fields, which is meant to better represent the hierarchical nature of a schema. Do not let this fact mislead you to believe that the BizTalk Schema Editor is just some elementary tool designed to accommodate the drooling masses. In fact, the Editor enables us to graphically construct relatively complex message shapes through a fairly robust set of visual properties and XSD annotations.

There are a multiple ways to create schemas in the BizTalk Schema Editor. These include:

• You can generate a schema from an existing XML file. The BizTalk Editor infers the node names and structure from the provided XML instance. In many integration projects, you start off knowing exactly what the transmission payload looks like. If you are fortunate enough to start your project with a sample XML file already in place, this schema generation mechanism is a big time-saver. However, there are caveats to this strategy. The BizTalk Editor can only build a schema structure based on the nodes that are present in the XML file. If optional nodes were omitted from the instance file, then they will be missing from the schema. Also, the schema will not mark "repeating" structures unless the XML file represents a particular node multiple times. Finally, the generated schema will not try to guess the data type of the node, and will default all nodes to a type of string. Despite these considerations, this method is a fantastic way to establish a head start on schema construction.

• XSD schemas may also be manufactured through the BizTalk adapters. For example, the BizTalk adapters for SQL Server and Oracle will generate XSD schemas based on the database table you are targeting. As we will see shortly, BizTalk Server also generates schemas for services that you wish to consume. Using adapters to harvest metadata and automatically generate schemas is a powerful way to make certain that your messages match the expected system format.

• New schemas can actually be created by importing and including previously created schemas. If XSD complex types are defined in a schema (for example, then new schemas can be built by mixing and matching existing types. Because these inherited types are merely referenced, not copied, changes to the original content types cascade down to the schemas that reuse them. If you are inclined to design a base set of standard types, then building schemas as compositions of existing types is a very useful way to go. Address)

• Finally, you have the option to roll up your sleeves, and build a new XSD schema from scratch. Now while you can switch to a text editor and literally type out a schema, the BizTalk Editor allows you to graphically build a schema tree from the beginning. Note that because of BizTalk Server's rigorous support for the XSD standard, you can even fashion your XML Schemas in alternate tools like Altova's XML Spy. We will handcraft many of our schemas in the BizTalk Editor for the schemas that we build together in this chapter and throughout the book.

If you're like me, you often sketch the schema layout first, and only later worry about concepts such as data types, repeating nodes, and entry restrictions. By default, each new node is assigned a string data type and is assumed to only exist once in a single XML document. Using the BizTalk Server Schema Editor, you can associate a given node with a wide variety of alternate data types such as dateTime, integer, and base64Binary. One thing to remember is that while you may use a more forgiving schema for inbound data, you should be strict in what you send out to other systems. We want to make sure to only produce messages that have clean data and stand little chance of being outright rejected by the target system.

Changing the number of times a particular node can appear in an XML document is as simple as highlighting the target node and setting the Max Occurs property. It's also fairly straightforward to set limits on the data allowed within certain nodes. What if we want a ZipCode field to only accept a maximum of 10 characters? Or what if the data stored in an AddressType node should be constrained to only 3 allowable choices? By default, these options are not visible for a given node. To change that, you can select a node and set the Derived By equal to Restriction. A flurry of new properties becomes available such as Maximum Length or Enumeration.

Property schemas

A critical BizTalk schema concept to examine is the property schema. Earlier in this chapter, I mentioned the notion of promoted properties which expose a message's data content to the BizTalk messaging layer. This in turn allows for a message to be routed to subscribers who are specifically interested in data condition (for example Order Number == 12345). Promoted properties are defined in a property schema, which is a special schema type within BizTalk Server. The property schema contains a flat list of elements (no records allowed) that represent the type of data we want the BizTalk messaging engine to know about. Once the property schema is created, we can associate specific fields in our message schema with the elements defined in the property schema. As we will see in practice later in this book, one key benefit of property schemas is that they can be used by more than one XSD schema. For instance, we could create a NewEmployee and ModifiedEmployee message that both map to a single EmployeeID property field. In this manner, we can associate messages of different types which have common data attributes.

The BizTalk Schema Editor is a robust tool for building industry-standard XSD schemas. In a service-oriented architecture, the data contract is key, and understanding how to construct an XSD contract within BizTalk Server is an important skill.