Designing generic business objects (InterChange Server only)

A generic business object reflects a superset of information that represents entities used by multiple diverse applications or programmatic entities. InterChange Server collaboration objects use generic business objects so they can provide information for a variety of diverse applications. Therefore, designing generic business objects is part of the task of collaboration object development. When designing a generic business object, take into account the following:

Generic business object design standards

To be consistent with IBM-delivered generic business objects, use the following standards when designing a generic business object:

Designing for event isolation

When designing a generic business object, it is recommended that you consider the needs of event isolation, as explained in the Collaboration Development Guide (in the section entitled "Designing for Parallel Execution").

To prevent more than one collaboration object from updating the same data at the same time, each business object should be modified by only one type of collaboration object. In other words, a Customer business object should be modified only by a CustomerSync collaboration object.

If a collaboration object modifies a business object that contains a child business object, and the child business object is also contained by a different top-level business object that has its own modifying collaboration object, design the top-level business objects to contain the child semantically rather than structurally. Develop a third collaboration object to modify the shared child. The collaboration objects that own the two top-level business objects should then delegate processing of the shared child to the third collaboration object.

For example, if both Customer and Contact business objects contain the same address data, design the Address business object as a top-level business object that is referenced by Customer and Contact, but not contained by them. Then develop a separate Address collaboration object to modify address data.

In another example, however, if the Order business object is the only business object that modifies OrderLineItem data, you can design Order to contain the OrderLineItem child business objects rather than merely reference them.

In other words, design the Customer and Contact business objects so that they contain a foreign-key attribute that references the Address business object, that is, that contains only the key value for Address. Do not design them to contain an attribute that represents a full-valued Address business object. But design the Order business object to contain an attribute that represents a full-valued OrderLineItem business object.

Note:
Designing shared business objects as referenced rather than contained can simplify business object distribution. If the same child business object is defined in multiple business object definitions, the repos_copy utility attempts to load the same business object twice during installation, causing rollback. For information on repos_copy flags that change this default behavior, see the System Administration Guide.

Attributes in a generic business object

When defining attributes for a generic business object, study the attributes of the application-specific business objects to which the generic business object will map. Consider these guidelines:

In general, a generic business object definition should include attributes that capture all the data elements that are to be transformed among all the application-specific business objects to which the generic business object will map.

Names of the attributes should be as intuitive as possible. For example, if several applications refer to an entity as a Customer and one application refers to the same entity as a Business Organization, use the more common terminology to name the generic attributes.

Note:
The name of an attribute can contain only alphanumeric characters and underscore (_).

Evaluating existing generic business objects

You may be able to facilitate development of a generic business object by copying and customizing an existing one.

To evaluate a generic business object, examine the data involved in the interface. A guideline is that if 80% or more of the data exists in a delivered generic business object, customize the existing object.

When performing this analysis, it is more important to look at the business object structure than the attributes. Attributes are relatively easy to add and remove, whereas structural or hierarchical changes can require much more effort.

If you decide to customize an existing generic business object, examine the business object definition to determine whether it is missing one or more desired attributes. Missing attributes become more apparent during mapping design. If the generic business object requires one or more additional attributes, create a child business object that contains the additional attributes. Isolating custom attributes in child business objects facilitates future upgrade of IBM-delivered business objects.

If you embed custom attributes in an IBM-delivered business object, upgrading to a new version of the business object requires re-embedding those attributes in the new business object. Isolating the custom attributes in their own business object allows you to add one attribute to the new IBM business object--the attribute that creates the relationship between the parent and the custom child business object. If you are customizing a hierarchical business object that requires additional attributes in both the parent and the child, create separate child business objects for each.

It is recommended that you name custom attributes and business objects in a way that readily identifies them. A simple convention is to add an _x suffix to each custom name. For example, if you create a custom child business object that adds attributes to the generic Order business object, name the child Order_x. Doing so allows alphabetic listing to keep related names together. If it is more important to identify custom business objects or attributes than to alphabetize the custom object with its generic object, add an x_ prefix to each custom name.

Copyright IBM Corp. 1997, 2004