Request processing

Note:
In WebSphere Business Integration Adapters documentation, "request processing" refers to the handling of a business object request message sent from the integration broker to a connector. The Hub Request interaction pattern is request processing in which the connector is required to return a result to the integration broker. The Hub One Way interaction pattern is request processing in which the connector is not required to return a result to the integration broker.

When a process tells it to do so, the integration broker sends requests, in the form of WebSphere MQ messages, to a connector.

In a typical scenario, the integration broker first receives an event notification business object message from the connector for a source application, and as a result of processing that event, it then sends a request business object message to the connector for a destination application.

A request can be made to the destination application to do either of the following:

For example, the integration broker might send a connector a request message to delete a contract, update a part, or create a customer.

When the connector framework receives an integration broker's request, it converts the message into a suitable business object and forwards it to the application-specific component. For example, if the integration broker sends a request to delete a contract, the application-specific component receives the request in the form of a Customer.Delete business object. The application-specific component translates the business object into an application request--typically a set of calls to the API--and then returns the results, if needed.

Figure 16 illustrates a connector's interactions with respect to handling messages from the integration broker in a Hub Request interaction pattern.

Figure 16. Connector interactions for request handling.


When an application-specific component receives a request, it determines how to process the request based on three types of information:

These factors are described in the topics that follow.

Verb-based processing

A connector's application-specific component responds to the Create, Retrieve, Update, or Delete verb in a request according to the logic and API of its application. The application-specific components of different connectors might handle the same type of request differently, although the result is logically the same.

For some connectors, only one method is required for performing operations on a business object, regardless of what verb the request contains. But for many connectors, each verb requires a different method.

When an application-specific component receives a request, it invokes the method in the application that matches the business object's active verb. For example, when a application-specific component receives an AppAEmployee.Update business object, it invokes the Update method on the AppAEmployee object. The Update method interacts with the application in order to perform the update.

Figure 17 illustrates some verb handling methods.

Figure 17. The processing of requests.


When the connector in Figure 17 receives a Customer.Create, Item.Retrieve, or Contract.Delete request, it invokes its DoCreate(), DoRetrieve(), or DoDelete() method, respectively. Each method builds the appropriate commands for the application to perform the specified operation.

Business object construction and deconstruction

A connector's application-specific component accomplishes its event notification and request-handling tasks by constructing and deconstructing business objects:

Business object meta-data and connector actions

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 (meta-data) that are defined when a business object is designed.

Application-specific components and business object meta-data are designed to work together. The design of an application-specific component and its business objects is analogous to the design of a computer device in which certain functions can be implemented by either the software or hardware. The developer considers performance, extensibility, and other issues to decide where to implement key features.

Business object definitions include properties that specify the types, sizes, and default values for attributes. They also include application-specific properties that contain instructions to the application-specific component on how to process the business object.


Table 5. Example name-value parameters for application-specific information associated with attributes.

Parameter Description
TN=TableName
The name of the database table
CN=col_name
The name of the database column for this attribute.
FK=[..]fk_attributeName]
The value of the Foreign Key property defines a parent/child relationship.
UID=AUTO
This parameter notifies the connector to generate the unique ID for the business object and load the value in this attribute.
CA=set_attr_name
The Copy Attribute property instructs the connector to copy the value of one attribute into another. If set_attr_name is set to the name of another attribute within the current individual business object, the connector uses the value of the specified attribute to set the value of this attribute before it adds the business object to the database during a Create operation.

When processing a business object, the application-specific component reads the definition and uses the application-specific information to build an application request. For more information on business objects, see the Business Object Development Guide.

Because the application-specific component is meta-data-driven, its actions are controlled by application-specific information and other meta-data in the business object definition. It does not have hard-coded instructions for each type of supported business object. Being meta-data-driven gives the application-specific component the flexibility to automatically support any new or changed business object definition as long as the corresponding application data can be accurately described by the connector's meta-data syntax.

An example of business object construction

The following process describes how an application-specific component creates a business object from its definition:

  1. Obtains the business object definition from its local repository and uses it to create a business object instance.
  2. The application-specific component loops through the business object instance attribute by attribute, using application-specific information to prepare an API call or build a query to obtain the application entity.
  3. The application-specific component sends the request to the application and retrieves the results.
  4. The application-specific component loops through the results, using the value of AppSpecificInfo to determine which retrieved value represents each business object attribute.

Figure 18 is an example of an application-specific component that is building a business object from the definition. The application-specific component has retrieved an application event involving an item whose key value, the item number, is 123. The application-specific component must build an Item business object from the business object definition, which contains four attributes: Group, Description, Price, and ItemNum.

Figure 18. Building a business object in a connector.


Using the item number, 123, to identify the item, the application-specific component retrieves the values of the remaining attributes. Application-specific information identifies the form and field identifier for the required data.

For example, FormXFieldB identifies Group data. The application-specific component requests the value of Field B in Form X for item ID 123. The application-specific component 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 application-specific component uses the business object definition to determine how to make an application request from the data contained in the business object that it received.

Application-specific information for verbs

Each verb in the business object definition can have application-specific information associated with it. The content of the verb's application-specific information is unique to the particular connector. The application-specific information for the verb provides the connector's application-specific component with additional instructions for processing the business object.

For example, application-specific information for the Retrieve verb in a business object definition might supply special input arguments to the Retrieve method in that application-specific component.

As an example, suppose that the MyApp application has three forms in which information about InventoryItem appears:

When the application-specific component for MyApp performs an operation on an inventory item, it must reference the correct form for that operation. In the InventoryItem business object definition, the application-specific information for the verb can be used to store the form name.

The combination of verb-specific methods and application-specific input to those methods gives an application-specific component unique instructions for processing.

Copyright IBM Corp. 1997, 2003