Arguably, the building block of any BizTalk Server solution (and general SOA solution) is the data contract, which describes the type of messages that flow through BizTalk Server. A contract for a message in BizTalk Server is represented using an industry standard XML Schema Definition (XSD). For a given contract, the XSD spells out the elements, their organizational structure, and their data types. An XSD also defines the expected ordering of nodes, whether or not the node is required, and how many times the node can appear at the particular location in the node tree; it can even be used to enforce further constraints based on lengths or regular expressions to name a few. The following is an example XSD file:
<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>Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
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 in a specific way.
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 represent the hierarchical nature of a schema in a better way. 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 multiple ways to create schemas in the BizTalk Schema Editor, namely:
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 in 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 or stored procedure that 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,
Address), 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.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 with alternate tools such as 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 (unless you intend to validate inbound data before it is accepted), you should be strict in what you send out to other systems. We want to ensure 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? Alternately, what if the data stored in an AddressType node has to be constrained to only three 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 such as Maximum Length or Enumeration become available. This is illustrated as follows:
A critical BizTalk schema concept to examine is the property schema. These schemas are internal to BizTalk and do not represent any message which will be exchanged with an external system. 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 can create NewEmployee and ModifiedEmployee message, both containing an EmployeeID element that maps to a single EmployeeID property field. In this manner, we can associate messages of different types: that 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.