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 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:
You can derive one generic business-object-handler class to implement a metadata-driven business object handler, which handles processing of all business objects. For more information, see Implementing metadata-driven business object handlers.
You can:
For more information, see Implementing multiple 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.
This section provides the following information about metadata-driven design for a business object handler:
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 22 shows some typical schemes for encoding application-specific information in business objects.
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.
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 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.
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 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.