To ensure that business object definitions conform to the requirements of the XML data handler, use the guidelines in this section, which involve:
A properly-constructed business object definition ensures that the data handler can correctly convert a business object to an XML document and an XML document to a business object. For information on how to create business objects for the XML data handler, see Creating business object definitions from DTDs.
To represent a DTD or schema document requires at least two business object definitions:
This attribute must has the type=pi tag in its application-specific information.
This attribute must have as its type a single-cardinality business object, whose type is the business object definition for the root element of the DTD or schema document. The XML ODA obtains the name of this root element from the Root ODA configuration property. The application-specific information must list the name of this element with the elem_name tag.
A business object that is processed by the XML data handler using business object definitions from DTDs or schema documents must follow these additional rules:
This document provides the following information about the structure of business object definitions for DTDs and schema documents:
Data model | For more information |
---|---|
Document type definition (DTD) | Business object structure for DTDs |
Schema document | Business object structure for schema documents |
Business object definitions define attributes. Each attribute has various properties that provide information about the attribute. This section describes how the XML data handler interprets several of these properties and describes how to set them when modifying a business object definition.
Each business object attribute must have a unique name. The attribute name must exactly match the name of an XML element or attribute, unless the XML element or attribute contains special characters (such as periods or hyphens). In this case, the name of the XML element (or attribute) specified in the elem_name (or attr_name) tag of the attribute application-specific informatin contains the special characters. However, the name of the business object attribute (which does not allow these special characters) omits them.
Each business object attribute must have a type, such as Integer, String, or the type of a contained child business object, as follows:
Each business object must have at least one primary key attribute, which is specified by setting the Key property to true for an attribute. The setting of the Foreign Key property is optional and depends on the structure of the XML document. This section provides the following information about the Key and Foreign Key attribute properties:
In earlier versions of XML-business-object-definition-generation tools (such as XMLBorgen, Edifecs SpecBuilder, and the XML ODA), the generation tool designated the ObjectEventId attribute as the key of a parent XML business object. However, as of this release, Business Object Designer Express no longer allows you to save a business object definition that has the ObjectEventId attribute specified as a key.
Because of this restriction, the current version of XML ODA now takes the following actions:
To provide a key to a parent business object definition that the XML ODA generates, you must bring up the business object definition in Business Object Designer Express and analyze your business object definition to determine the appropriate attribute to designate as the key. You must change the business object definition's key attribute before you can save the business object definition in Business Object Designer Express.
This document provides the following information about the relationship between keys and "required-ness":
Data model | For more information |
---|---|
Document type definition (DTD) | Business object attribute properties for DTDs |
Schema document | Business object attribute properties for schema documents |
If this property is specified for an attribute that contains a single-cardinality child business object, the XML data handler requires that the parent business object contain a child business object for this attribute. The settings of the Cardinality, Key, and Foreign Key attribute properties can affect the setting an attribute's Required property.
This document provides the following information about "required-ness":
Data model | For more information |
---|---|
Document type definition (DTD) | Business object attribute properties for DTDs |
Schema document | Business object attribute properties for schema documents |
The Cardinality property indicates the number of child business objects allowed in an attribute that has a business object definition as its type. The setting of this property depends on the structure of the XML document and its elements. Its setting also affects whether the attribute must be required (its Required property set to true).
This document provides the following information about the relationship between cardinality and "required-ness":
Data model | For more information |
---|---|
Document type definition (DTD) | Business object attribute properties for DTDs |
Schema document |
A business object attribute has a value whose type matches the attribute's Type property. In addition, an attribute can have either of two special values:
When the XML data handler receives a business object from an integration broker, it ignores all attributes with a value of CxIgnore. It is as if those attributes are invisible to the data handler. Therefore, the data handler does not generate a corresponding XML element; that is, it does not create an XML tag for this attribute (not even an empty tag).
The XML data handler processes the CxBlank attribute value based on the attribute's Type property:
Application-specific information in business object definitions provides the data handler with instructions on how to convert business objects to XML documents. The application-specific information enables the data handler to process the business object correctly. Therefore, if you create new business objects or modify existing business objects for the XML data handler, make sure that the application-specific information in the business object definition matches the syntax that the data handler expects. The XML data handler can use the following kinds of application-specific information:
This document provides the following information about application-specific information:
Data model | For more information |
---|---|
Document type definition (DTD) | Application-specific information for XML components in DTDs |
Schema document | Application-specific information for XML compnents in schema documents |
When converting business objects to XML documents, the XML data handler does not generate XML for the verb, nor does it set a verb when converting an XML document to a business object. However, verb information can be preserved in one of these ways: