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.
Figure 14. Design focus: identify applications with which to integrate
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:
Table 13. Business Object Verb-Scoping Summary
Business object name | Required request Verbs (request processing) | Required delivery verbs (application event notification) |
---|---|---|
Object 1 | &box. Create &box. Update &box. Delete | &box. Create &box. Update &box. Delete |
Object 2 | &box. Create &box. Update &box. Delete | &box. Create &box. Update &box. Delete |
Object n | &box. Create &box. Update &box. Delete | &box. Create &box. Update &box. 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 meta-data.
Meta-data 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 meta-data 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 meta-data 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 meta-data, as Table 14 shows.
Table 14. Connector support for meta-data
Connector's use of meta-data | Business object handlers required | For more information |
---|---|---|
Entirely driven by the processing instructions in the meta-data of its business object definitions | One generic meta-data-drive business object handler | "Meta-data-driven connectors" |
Partially driven by the meta-data in its business object definitions | One partially meta-data-driven business object handler | "Partially meta-data-driven connectors" |
Cannot use meta-data | Separate business object handler for each business object that does not use meta-data | "Connectors that do not use meta-data" |
While some application interfaces have constraints that restrict the use of meta-data in connector and business object design, a worthwhile goal for connector development is to make the connector as meta-data driven as possible. Advantages and disadvantages of the approaches in Table 14 are discussed below.
To be able to support meta-data-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 meta-data to provide information about the application entity to be acted upon and the attribute data as the values for that object. A meta-data-driven connector can then use the business object values and the meta-data (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 meta-data-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 meta-data-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 meta-data-driven business object handler, which does not contain hard-coded logic for processing specific business objects.
WebSphere InterChange Server |
---|
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. |
Figure 16. Using meta-data in the business object for processing instructions
Because a meta-data-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 meta-data, the business object itself can be changed without requiring corresponding changes in the connector.
For more information on designing a meta-data-driven business object handler, see "Implementing meta-data-driven business object handlers".
IBM encourages the meta-data 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 meta-data-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 meta-data, though this meta-data does not contain the actual processing instructions. This partially meta-data-driven connector can use the meta-data 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 meta-data for the connector. This meta-data 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 meta-data-driven business object handler because this meta-data 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.
Figure 17. Application-specific processing in the application
The benefit to the partially meta-data-driven connector is that it still uses just one business object handler. However, unlike with a meta-data-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 meta-data 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.
Figure 18. Application-specific processing in the connector
The drawback of this non-meta-data 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.