This topic applies only to the IBM Business Automation Workflow Advanced configuration.

Business object characteristics

Edit online
Draft comment:
This topic only applies to BAW, and is located in the BAW repository. Last updated on 2025-03-13 12:15
Business objects have inherent characteristics that enhance their use within the business object framework.

Cardinality

The cardinality of properties is defined by standard XML schema minOccurs and maxOccurs facets for simple and complex types and the use attribute for attributes.

Default property values

The capability to provide default values in XML schema for attributes and simple types in a business object is supported by the business object framework. This support is visible at creation time when the simple property types of a business object reflect their default values.

Nillable

An element can be defined in XML schema to be nillable. The business object framework enables properties that are nillable to have their value set to Null at run time.

Key definition

Business object key information can be used by multiple subsystems, such as relationship, sequencing, and isolation. However, each of these subsystems can define their own key mechanism independent of the business object's key definition. Since the underlying model language leveraged by business objects is XML schema, first class support for key definitions exists within the modeling language. However, this support within the modeling language is not fully supported in the SDO run time.

xs:ID, xs:IDREF, and xs:IDREFS
These types were added to XML schema primarily to provide an upgrade path for DTDs. Each complex type can have 0 or 1 elements/attributes typed as an xs:ID. IDs must be unique to an entire document, as opposed to a primary key in a database, for example, that must be unique with respect to the scope of the table. As an example, a conformant document cannot use the same ID value to identify both a Product and a ProductCategory. Often elements get around this restriction by prepending the complex type name to the key value. An attribute typed IDREF must contain a value that matches one of the ID values in the current document. In addition, XML schema provides for a construct which is an element that can be typed to contain a list of ID references, xs:IDREFs.
xs:unique, xs:key, xs:keyref
XML schema introduced a new style enabling key definitions and key references. The xs:unique construct enables a user to define that 1 or more fields in an element that must be unique within a particular scope of the element (which represent the entire document). The xs:key construct is a variant of xs:unique with the additional constraint that the elements referenced are required. The xs:keyref construct is used to identify that the value of an element must be named key or unique construct.
The unique, key, and keyref constructs have several advantages over the ID, IDREF, and IDREFS set, including:
  • They can define compound keys.
  • They can define unique constraints that are relative to a portion of the document.

Although a business object is not required to have a defined key, it is highly recommended. Business objects that do not define a key can be used by applications. This scenario is a common use model in many Java™ EE centric applications use models, where JavaBeans are passed back and forth between the servlet and EJB containers without the specification of a key. However, those business objects that do not define a key are unable to interact with the subsystems that require a key. This situation limits their ability to take advantage of IBM® Business Automation Workflow qualities of service.