Application-specific business objects are the units of work that are triggered within the application, created and processed by the connector, and sent to the integration broker. A connector uses these business objects to export data from its application to other applications and to import data from other applications.
The connector exposes all the information about an application entity that is necessary to allow other applications to share the data. Once the connector makes the entity available to other applications, the integration broker can route the data to any number of other applications through their connectors.
Designing the relationship between the connector and its supported application-specific business objects is one of the tasks in connector development. Application-specific business object design can generate requirements for connector programming logic that must be integrated into the connector development process. Therefore, business object and connector developers must work together to develop specifications for the connector and its business objects.
Consider the following design guidelines when you design your application-specific business objects:
The complexity of business objects can have a significant impact on the amount of work that is necessary to build a connector. A first step in identifying application-specific business objects is to determine what application entities the connector will work with.
You can identify application entities that the connector will work with in two ways:
If you are using InterChange Server as your integration broker, one way to begin identifying application-specific business objects is to list the InterChange Server collaborations that you want the application to work with. Consider the features of each collaboration, and note which generic business objects each collaboration references. Using this list, you can decide what kinds of business objects allow your application to work with the collaboration.
For example, you may decide that you want to use your application with the Customer Manager collaboration. In this case, the connector must handle customer entities. The connector might extract customer data from the application to forward to the collaboration or receive customer data from the collaboration to pass back to the application.
Alternatively, you might start the connector development task by looking at other applications with which you want to integrate. As you examine your application and other applications, you can determine what business processes you want to share across applications and identify what data you want to exchange. The goal is to determine what entities in your application make sense to implement as business objects to enable integration with other applications.
For example, if your application stores customer data, you may want to keep the customer database consistent with the customer database in another application. To synchronize customer data, you need to know about the customer entity that each application publishes. Figure 14 illustrates a design approach that focuses on integrating with other applications.
Use the following topics and questions to gather more information about application entities and business objects:
For example, in many applications a contract entity has one to many line items. The IBM WebSphere Business Integration Contract business object contains child line items as business objects. Determine whether the entities your connector will work with have related entities that will be defined as child business objects.
For example, an application may have two types of contracts: hardware contracts and software contracts. Both are of type Contract, but they are stored in different tables in the application database. In addition, the attributes for each Contract type differ.
Because a single set of maps can convert between only one generic business object and one application-specific business object, developers for this application must design business objects to account for the different entities in the application. For example, they may need to redesign the IBM WebSphere Business Integration generic business object, create new generic child business objects, and create new maps.
Figure 15 shows the business objects that may result from multiple application entities of the same type. It illustrates the creation of two generic child business objects, one that contains data specific to hardware contracts and one that contains data specific to software contracts.
Are there application entities that reside in more than one location in the database but that correspond to the same logical entity?
For example, Contract, Customer, and Contact entities might each have Customer address fields as part of the physical table definition for each entity. If the Customer address field changes in one entity, it must be updated in all entities.
However, the address fields might be consolidated into an Address business object that needs to be updated for the Contact, Customer, and Contract business objects if the address changes for any of the entities. In this case, the Address business object would be referenced rather than contained by the top-level business objects that use the data.
Are there batch processes associated with the creation of application entities?
In some applications, batch processing may add data to entities. As an example, a data entry operator may enter a new customer into the application database at 11:00 AM, but the customer record will not be complete until a 7:00 PM batch job runs to fill in some remaining values.
If a batch process is associated with application entities and the process adds important or required data, you need to determine when the business object is generated. For example:
If there is a need for real-time data synchronization, but there are batch processes running in the background, your connector development plans must account for this.
When you have determined at a high level what business objects you need to define, you then need to determine the verb support for the business object development, as follows:
Business object name | Required request Verbs (request processing) | Required delivery verbs (application event notification) |
---|---|---|
Object 1 | O Create O Update O Delete | O Create O Update O Delete |
Object 2 | O Create O Update O Delete | O Create O Update O Delete |
Object n | O Create O Update O Delete | O Create O Update O Delete |
In addition to its structure and attributes, a business object definition can contain application-specific information, which can provide processing instructions or information on how the business object is represented in the application. Such information is called metadata.
Metadata can include any information that the connector needs in its interactions with the application. For example, if a business object definition for a table-based application includes metadata that provides the application table and column names, the connector can locate requested data using this information, and the application column names do not need to be encoded in the connector. Because the connector has access to its supported business object definitions at runtime, it can use the metadata in the business object definition to dynamically determine how to process a particular business object.
Depending on the application and its programming interface (API), a connector and its business objects might be designed based on the ability to support the use of metadata, as Table 14 shows.
Connector's use of metadata | Business object handlers required | For more information |
---|---|---|
Entirely driven by the processing instructions in the metadata of its business object definitions | One generic metadata-drive business object handler | Metadata-driven connectors |
Partially driven by the metadata in its business object definitions | One partially metadata-driven business object handler | Partially metadata-driven connectors |
Cannot use metadata | Separate business object handler for each business object that does not use metadata | Connectors that do not use metadata |
While some application interfaces have constraints that restrict the use of metadata in connector and business object design, a worthwhile goal for connector development is to make the connector as metadata driven as possible. Advantages and disadvantages of the approaches in Table 14 are discussed below.
To be able to support metadata-driven design, the application API must be able to specify what objects in the application are to be acted upon. In general, this means that you can use the business object metadata to provide information about the application entity to be acted upon and the attribute data as the values for that object. A metadata-driven connector can then use the business object values and the metadata (the application-specific information that the business object definition contains) to build the appropriate application function calls or SQL statements to access the entity. The function calls perform the required changes in the application for the business object and verb the connector is processing.
Applications based on forms, tables, or objects are well suited for metadata-driven connectors. For example, applications that are forms-based consist of named forms. Programmatic interaction with a forms-based application consists of opening a form, reading or writing fields on the form, and then saving or dismissing the form. The connector for such an application can be driven directly by the business object definitions that the connector supports.
The main benefit to a metadata-driven connector is that the connector can use one generic business object handler for all business objects. In this approach, the business object definition contains all the information that the connector needs to process the business object. Because the business object itself contains the application-specific information, the connector can handle new or modified business objects without requiring modifications to the connector source code. The connector can be written in a generic manner, with a single metadata-driven business object handler, which does not contain hard-coded logic for processing specific business objects.
Figure 16 shows an application-specific business object and a connector with a meta-data-driven business object handler. The processing instructions in the application-specific information of the App_Order business object tell the connector how to process the business object.
Because a metadata-driven connector derives its processing instructions from its application-specific business objects, the business objects must be designed with this type of processing in mind. This approach to connector and business object design provides flexibility and easy extensibility, but it requires more planning in the design phase. When connectors are designed to work with business object metadata, the business object itself can be changed without requiring corresponding changes in the connector.
For more information on designing a metadata-driven business object handler, see Implementing metadata-driven business object handlers.
IBM encourages the metadata approach for designing connectors and application-specific business object definitions. However, some applications might not be suited for this approach. Application APIs that are specific for each entity in an application make it more difficult to write a metadata-driven connector. Often the issue is that the call itself differs between objects in some structural way, rather than just in the name of the method or the data that is passed.
Sometimes you can still drive a connector with metadata, though this metadata does not contain the actual processing instructions. This partially metadata-driven connector can use the metadata in the business object definition or attributes to help determine what processing to perform. For example, an application that has a large amount of business logic embedded in its user interface might have restrictions on how an external program, such as a connector, can get information into and out of its database. In some cases, it may be necessary to provide an extension to the application using the application environment and application programming interface. You may need to add object-specific modules to the application to handle the processing for each business object. The application may require the use of its application environment and interface to ensure that application business logic is enforced and not bypassed.
In this case, the business object and attribute application-specific information can still contain metadata for the connector. This metadata specifies the name of the module or API call needed to perform operations for the business object in the application. The connector can still be implemented with a single business object handler, but it is a partially metadata-driven business object handler because this metadata does not contain the processing instructions.
Figure 17 illustrates an application extension that is responsible for handling requests from the connector. The extension contains separate modules for each business object supported by the connector.
The benefit to the partially metadata-driven connector is that it still uses just one business object handler. However, unlike with a metadata-driven connector, there is coding to do when new business objects are created for the connector. In this case, new object functions must be written and added to the application, but the connector does not need to be recoded or recompiled.
If the application API does not provide the ability to specify what entities in the application are to be acted upon, the connector cannot use metadata to support a single business object handler. Instead, it must provide multiple business object handlers, one for each business object the connector supports. In this approach, each business object handler contains specific logic and code to process a particular business object.
In Figure 18,, the connector has multiple, object-specific business object handlers. When the connector receives a business object, it calls the appropriate business object handler for that business object.
The drawback of this non-metadata approach is that when a business object is changed or a new business object is added, this type of connector must be recoded to handle the new or changed business object.