Designing business object handlers

The business object handler implements request processing for the connector. Therefore, the defining and coding of business object handlers is one of the primary tasks in connector development. A business object handler is an instance of a subclass of the BOHandlerCPP class. Each business object definition refers to a business object handler, which contains a set of methods to perform the tasks for the verbs that the business object definition supports. You need to code one or more business object handlers to process the business objects that the connector supports.

The way to implement a business object handler depends on the application programming interface (API) that you are using and how this interface exposes application entities. To determine how many business object handlers your connector requires, you need to take a look at the application that the connector will interact with:

Implementing metadata-driven business object handlers

If the application API is suitable for a metadata-driven connector, and if you design business object definitions to include metadata, you can implement a metadata-driven business object handler. This business object handler uses the metadata to process all requests. A business object handler can be completely metadata-driven if the application is consistent in its design, and the metadata follows a consistent syntax for each supported business object.

Note:
For an introduction to metadata and metadata-driven design, see "Assessing support for metadata-driven design"..

This section provides the following information about metadata-driven design for a business object handler:

Metadata in business objects

Business object definitions have specific locations for different types of application-specific data. For example, business object attributes have a set of properties, such as Key, Foreign Key, Required, Type, and so on, that provide the business object handler with information that it can use to drive business object processing. In addition, the AppSpecificInfo property can provide the business object handler with application-specific information, which can specify how to access data in the application and how to process application entities.

The AppSpecificInfo property is available for the business object definition, attributes, and verbs. Table 25 shows some typical schemes for encoding application-specific information in business objects.

Table 25. Example schemes for storage of application information in business objects

Scope of application-specific information Table-based application
Form-based application
The whole business object Table name Form name
An individual attribute Column name Field name
The business object verb SQL statement or other verb-processing instructions Action to be performed

Using application-specific information, a metadata-driven business object handler might simply:

If a business object definition contains the table name and column names, you do not have to explicitly code those names in the business object handler.

Benefits of metadata design

Encoding application information in a business object accomplishes two things:

If information about application entities is encoded consistently in the business object definition, all request business objects can be handled by a single business-object-handler class in the connector. Also, you need to implement only a single getBOHandlerforBO() method to return the single business object handler and a single doVerbFor() method to implement this business object handler. This approach is recommended for connector development because it provides flexibility and automatic support for new business object attributes.

Implementing multiple business object handlers

For each business object definition that does not encapsulate all the metadata and business logic for an application entity, you need a separate business-object-handler class. You can derive separate handler classes directly from the business-object-handler base class, or you can derive a single utility class and derive subclasses as needed. You must then implement the getBOHandlerforBO() method to return business object handler that corresponds to particular business object definitions.

Each business object handler must contain a doVerbFor() method. If you implement multiple business object handlers, you must implement a doVerbFor() method for each business-object-handler class. In each doVerbFor() method, include code to handle any parts of the application entity or operations on the application entity that the business object definition does not describe.

This approach results in higher maintenance requirements and longer development time than designing a single business object handler for a metadata-driven connector. For this reason, this approach should be avoided if possible. However, if the application has different access methods for different kinds of entities, coding multiple, entity-specific business object handlers might be unavoidable.

Copyright IBM Corp. 1997, 2003