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:
The following two considerations illustrate the complexity of business logic analysis:
Sometimes the application that triggers the collaboration object does not provide all the data required to process the triggering business object. The additional data may reside in other applications, including the destination application.
For example, a Sales Force Automation (SFA) application (such as Siebel) may generate a quote that needs to be logged as an Order in an order management system (such as SAP). However, before the Quote can become an Order, it may require additional information not available in the SFA application. For example, an Order may require such additional data as customer credit status (from a financial system), contact information (from a customer support system), or Availability To Promise information (from a warehousing system).
When you design the generic Order business object, you may have to include attributes and design a structure that supports data which is not present in the source application necessarily, but may be present in other applications involved in the interface.
Determine how and whether individual application entities correspond to each other or are cross-referenced to each other generically in the business process.
For example, a customer in Oracle is represented as a Customer whose address is represented as an Address. A customer in SAP is represented as a "SoldTo" entity whose address is represented as a "ship-to" entity. A customer in Clarify is represented as a "Business Organization" whose address is represented as a "Site".
Study the functionality and relationships between an application's entities to determine the business objects and processes involved in integrating data between applications.
Consider the following integration possibilities:
To be consistent with IBM-delivered generic business objects, use the following standards when designing a generic business object:
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.
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.
You might 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 when you conduct the 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 object can greatly facilitate 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 a single 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. For more information, see Naming IBM WebSphere InterChange Server Components.