A business object contains the data that an application-specific component moves into or out of a particular application. Therefore, each business object definition reflects the application's data model and the application-specific component's access method.
Even when two application-specific business objects refer to similar application entities, differences appear in the way that attributes are organized and in the application-specific information for them.
Applications often organize the same information in different ways. For example, Application A stores a telephone number and fax number for a contact in four fields, but Application B stores the same numbers in two fields.
Figure 13. Telephone data in two applications.
The business object definitions for the Application A business object and the Application B business object have different attributes to reflect this difference.
Business objects also differ because each can optionally contain built-in processing instructions for its application-specific component. Referred to as application-specific information (or meta-data), it can consist of any information that the application-specific component needs to process the business object.
A business object definition can have application-specific information that applies to the entire business object, to each attribute, and to each verb. At each place where application-specific information appears in a business object definition, it provides information that the connector uses in its interactions with the application.
Application-specific information for the business object provides information that the application-specific component uses when processing the business object as a whole.
Often, application-specific information that applies to an attribute identifies the attribute value's location in the application. The application-specific component uses this identifier when building API calls to the application to retrieve or enter the attribute value.
Application-specific information takes different forms for different applications. Sometimes the application-specific component can reference the attribute location by means of the application's form and field names; other times the reference is more complex.
Table 2 provides examples of parameters that might be included in an
attribute's application-specific information. These parameters
would be relevant only to a business object that represents data in a database
table.
Table 2. Example name-value parameters for attribute application-specific information
A single attribute's application-specific information might combine several of the example parameters listed above. This example uses semicolon (;) delimiters to separate the parameters:
TN=LineItems;CN=POid;FK=..PO_ID
The application-specific information in this example specifies the name of the table, the name of the column, and that the current attribute is a foreign key that links the child business object to its parent
In exceptional cases, application-specific information for attributes is
unnecessary. For example, some applications provide very direct and
easy to use designations for units of data. Imagine that an application
identifies sample fields as Table 3 illustrates.
Table 3. Sample application identifiers
Attribute | Application's identifier for the field containing the value |
---|---|
Customer ID | XCustomerID |
Customer name | XCustomerName |
Status | XStatus |
Industry | XIndustry |
In the example that Table 3 illustrates, it is easy for the application-specific component to associate an attribute with its identifier in the application because the rules for conversion are so regular: add the X or subtract the X. Therefore, the attributes in business objects for this application may not need application-specific information.
A business object definition can include application-specific information for each verb that it supports. The application-specific information tells the application-specific component how to process the business object when that verb is active.