Progress
AppBuilder
Developer’s Guide


XML Schema and Mapping Files

Although two business partners might use an identical set of logical documents, their documents generally have different physical formats and map to databases that are organized differently. Rarely will two businesses use the identical format for their Purchase Orders, for example, or have identically-named tables and fields. This creates a problem for automatic handling. Although human beings are extremely good at recognizing when two different physical formats are logically equivalent, computers are not. For this reason, some way is needed to transform a logical document from the sender’s local format into the receiver’s local format. The most general solution to this problem is to create a shareable intermediate representation. XML, emerging as an international standard, is well-suited to that role.

XML schema are defined using a notation called “XML Data, subset reduced.” A number of organizations have arisen that act as repositories for shareable schema and there are already schema defined for many common documents. You can discover some of them through the WWW Consortium Web site and others by using a Web search engine.

An XML schema for some logical unit of communication (a purchase order, an invoice, a catalog, etc.) is defined in advance and shared with business partners who will receive that kind of document. XML schema serve the same purpose as database schema—they define how raw data should be interpreted. They deal with form rather than content.

After a schema for a document has been agreed upon, each business creates an additional XML file that describes how to map between that common, shared schema and their own local data format. Typically, different mapping files will be used for inbound and outbound documents, even within a single site.

Once those mapping files have been created and debugged, communication becomes a relatively straightforward operation.

CAUTION: At present, there is no automatic safeguard against schema version skew. It is possible for a particular schema to be changed without notice, with an updated map file being created only at one end of the communication channel. In that case, miscommunication will certainly occur, possibly in ways that are important but hard to detect. Although you cannot eliminate this problem, you can reduce it by maintaining and checking for version information in any schema you create.

Figure 6–2 illustrates how the schema, the map file, and the data interact in inter-business messaging.

Figure 6–2: Simple One-to-One XML Mapping in Data Communication

On the originating side (the left side in Figure 6–2), the value for the Surname (family name) field in the Empl table is “Smith”. The XML schema specifies a Surname field of type string. The map file relates the XML Surname node to the Empl.Surname field.

The SmartB2BObject would use that mapping to extract the value “Smith” from the data and insert it into the message. When the message is received (the right side in the figure), the SmartB2BObject there parses the message, encounters Surname, and checks its own map file, where it sees that Surname maps to the Client.FamName field. It then passes the value “Smith” to the SmartDataObject handling that table.

Note that neither the table nor the field need have the same name on both sides. That is the purpose of XML mapping: to make such differences irrelevant.

Figure 6–2 illustrated the simplest mapping: an XML field to a database field. Figure 6–3 illustrates a more complex possibility: deriving a value for the message by filtering local data.

Figure 6–3: Mapping an XML Node to a Function

In this example, the node definition in the XML schema is the same as in Figure 6–2: Surname, defined as type string. Here, though, there is no surname field in the Empl table. The whole name is stored as a single string. The mapping in this case is to a dedicated function FamilyName() that reads the Name field and returns the surname substring.

Where does that dedicated function come from? You create it.

You can create mappable procedures and functions within the SmartB2BObject itself, or in the SmartBusinessObject or SmartDataObject that cooperates with the SmartB2BObject. In general, good programming practice suggests that you put special procedures and functions inside the object to which they are most closely related. In the illustrated case (Figure 6–3), that would be the SmartDataObject, since a FamilyName() function would be the logical equivalent of a calculated field.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095