A connector agent accomplishes its event notification and request-handling tasks by constructing and deconstructing business objects:
A connector's transformation of an application event to a business object and from a business object to an application request is driven by data definitions ( metadata) that are defined when a business object is designed.
Connector agents and business object metadata are designed to work together. The design of a connector agent and its business objects is analogous to the design of a computer device in which certain functionality can be implemented by either the software or hardware. The developer considers performance, extensibility, and other issues to decide where to implement key features.
Similarly, the division of work between the connector agent and its business objects is a result of the connector developer's design decisions. IBM WebSphere InterChange Server design principles encourage using the business object metadata to drive connector logic, rather than hard-coding logic in connector agents.
In addition to properties that specify the types, sizes, and default values for attributes, business object definitions use application-specific fields to pass specific instructions to the connector agent on how to process the business object.
For example, recall that Business objects, presents some examples of application-specific information
for the attributes of a business object that represents a customer. Table 7 shows some of those examples.
Table 7. Sample application-specific information
Attribute | Application-specific information |
---|---|
Customer ID | CUST1:CID |
Customer name | CUST1:CNAM |
Status | CUST1:CSTAT |
When processing a business object, the connector agent reads the definition and uses the application-specific information to build an application request:
Because application-specific information and other metadata in the business object definition guides the actions of a connector agent, a connector agent's behavior can be described as metadata-driven.
A metadata-driven connector agent is flexible, because it does not have hard-coded instructions on how to handle each type of business object that it supports. Without recoding or recompiling, the connector agent automatically supports new business object definitions, as long as they match the connector's specifications.
A metadata-driven connector agent also supports new or changed attributes within a business object definition. The connector agent processes the attributes automatically as it loops through the attributes of the business object definition.
The following process describes how a connector agent creates a business object from its definition:
Figure 35 is an example of a connector agent that is building a business object from the definition. The connector agent has retrieved an application event involving an item whose key value, the item number, is 123. The connector agent must build an Item business object from the business object definition, which contains four attributes: Group, Description, Price, and ItemNum.
Figure 35. Building a business object in a connector
Using the item number, 123, to identify the item, the connector agent retrieves the values of the remaining attributes. Application-specific information provides the form and field identifier for the required data.
For example, FormXFieldB identifies Group data. The connector agent requests the value of Field B in Form X for item ID 123. The connector agent then uses the returned value, "hardware," to fill in the value of the business object's Group attribute.
The process of deconstruction works in the opposite way. The connector agent uses the business object definition to determine how to make an application request from the data contained in the business object that it received.