Many integration components in an interface depend upon and reference one another, so the tasks of developing each of the components are intertwined and iterative.
It is recommended that you develop your integration components in the following order:
Identify and install the connectors you will use. Connectors communicate directly with the applications or technologies being integrated, and must meet their requirements. In turn, other integration components, such as application-specific business objects, depend, on the design of the connector. This makes connectors the logical starting point for your design.
Connectors are installed to your system when you install adapters. A connector is part of the adapter. (Many adapters also include an Object Discovery Agent, which assists you in generating business objects that are specific to the application with which the connector interacts.)
Adapters designed for certain technologies are provided with your installation of WebSphere Business Integration Server Express and Express Plus. If you are using Express Plus, you may wish to consider obtaining additional, application-specific connectors that are included in an Adapter Capacity Pack. Capacity packs are separately available as optional additions to IBM WebSphere Business Integration Server Express Plus.
For more information about the connectors supplied with the product and the connectors contained in Adapter Capacity Packs, see the IBM WebSphere Business Integration Server Express installation guide for your platform.
You do not do any customization on connectors themselves, but you may need to make modifications to some of the integration components with which the connectors interact. And you will need to configure the connectors. These tasks are described in the topics that follow.
After you have selected and installed the files for your connector, you should develop the application-specific business objects for it. This topic provides a brief overview of that task. For details about working with application-specific business object definitions, see the WebSphere InterChange Server: Business Object Development Guide.
You should develop application-specific business objects after connectors, because you must understand the connector in order to develop business objects for it. You should develop application-specific business objects before you develop generic business objects, because generic business objects generally represent a superset of the application-specific business objects in an interface.
Many adapters include object discovery agents (ODAs) to assist you in generating application-specific business objects that work with the connector. Refer to the guide for the adapter to determine if the adapter features an Object Discovery Agent (ODA) that can be used to generate application-specific business objects. ODAs can greatly expedite this stage of development.
You may also need to design and create application-specific business objects individually. It is recommended that you create application-specific business objects in multiple iterations. Develop the application-specific business object at first as a relatively simple structure and then test it to make sure that the connector can use the business object structure to exchange data with the application successfully. Then add a layer of complexity and re-test the business object to make sure that the interface still works in spite of the modifications. Repeat this process until the application-specific business object is as large and complex as it has to be to satisfy the interface.
When you create the business object definition you should also create any source application triggers or other event detection mechanisms if necessary.
For details about designing and developing application-specific business object definitions, see the WebSphere InterChange Server: Business Object Development Guide.
When you configure a connector for the purpose of unit testing an application-specific business object you may not yet have developed all of the business object definitions and maps that the connector requires to perform its role in the implementation. You can, however, add support for the business object definition you need to test and be able to test it successfully without those other components. When you have finished developing the other components you must then re-configure the connector definition to add support for the business object definitions and associate the required maps.
See the guide for your adapter for information about its application-specific properties. See Configuring connectors for information about connector standard properties and information on how to use Connector Configurator Express.
Once you have developed the application-specific business object and added support for it to a connector definition you should unit-test the business object to make sure that the connector can use it to exchange data with the application successfully. You do not need the generic objects, maps, or collaboration template that the interface will eventually use to perform this test. Do the following to unit-test an application-specific business object:
For more information about creating collaboration templates, see the WebSphere InterChange Server: Collaboration Development Guide.
For more information about deploying components, see Exporting components to a package using System Manager.
For more information about starting a connector, see your adapter guide and the WebSphere InterChange Server: System Administration Guide.
For more information on Test Connector, see Using Test Connector.
For more information on creating collaboration objects, see Right-clicking to configure InterChange Server Express properties.
For more information about deploying components, see Exporting components to a package using System Manager.
For more information about starting a connector, see your adapter guide and the WebSphere InterChange Server: System Administration Guide.
For more information on Test Connector, see Using Test Connector.
You should develop or customize the generic business object after you have developed all of the application-specific business objects required for the interface.
Determine if there are existing generic business objects available to you that might be appropriate for the business process. If so, examine them and customize them as needed, to ensure that they satisfy the interface in its current design, as reflected in characteristics of the application-specific business objects. You may need to create new generic business objects.
If you have obtained and installed one or more collaborations from the Collaboration Capacity Pack, you already have some generic business objects available to you; most of the collaborations in the Collaboration Capacity Pack come with a default set of generic business objects. You may be able to use some of these without customization; others you may need to customize. (Note: The Collaboration Capacity Pack is separately available as an optional addition to IBM WebSphere Business Integration Server Express Plus.)
If no existing generic business object can be used, you will need to either extend an existing generic business object or create a new one. For information on creating new business objects or customizing existing ones, see the WebSphere InterChange Server: Business Object Development Guide.
This is an optional task. Configuring database connection pools beforehand allows you to code use of them into maps as you develop the maps. However, you may choose instead to begin the development of maps before configuring database connection pools.
To decide if and when you want to use database connection pools, see Configuring database connection pools.
After you have identified or developed the business objects for an interface, you can develop the maps and relationships used in transforming application-specific objects into generic objects, and generic objects into application-specific objects.
You use Map Designer Express to create a map, define the transformation rules, and unit test the map with a sample input generic or application-specific business object.
As you develop maps, you may need to create relationship definitions that the maps will use for performing complex transformations. You may also find it useful to create database connection pools.
As you develop the maps, you should unit-test them by using the debugging facilities of Map Designer Express. Unit-test your maps at the following points:
When you test a map that uses relationships, you must make sure that you test the maps in the order in which they would execute within the context of the interface. If you do not, then the cross-referencing logic will not execute properly.
For more information on developing maps and relationships, see the WebSphere InterChange Server: Map Development Guide.
The collaboration template defines the business logic of the interface. The simplest collaborations merely route business objects between connectors. Other collaborations might also have complex interactions involving delegation of processing to other collaboration objects. Regardless, collaborations are centered around the generic business object that represents a superset of the application-specific business objects in an interface.
If you are using Express Plus, you may wish to consider obtaining collaboration templates that are included in a Collaboration Capacity Pack. Capacity packs are separately available as optional additions to IBM WebSphere Business Integration Server Express Plus. Consult the documentation, available at the InfoCenter for WebSphere Business Integration Server Express, for each specific collaboration that you might consider using. Examine the characteristics of the collaboration templates to determine whether they meet your needs.
Your specific needs may require that you customize a pre-developed collaboration template, or create additional ones, using Process Designer Express. For information about customizing or creating collaboration templates, and about the structure of collaborations generally, see the WebSphere InterChange Server: Collaboration Development Guide.
After you complete the collaboration template and all of the components with which it interfaces, you should create a collaboration object based on the template.
You should unit test the collaboration object without the connector agents running by using Integrated Test Environment or Test Connector. This allows you to test the integrity of the interface without introducing connectivity issues and thereby rule out errors related to the map and collaboration logic. Then you should test the interface as a whole with the connector agents running.
You can unit-test the collaboration template without using the maps, application-specific business objects, or connectors that you are developing for the interface. Do the following to unit-test a collaboration template:
For more information on creating collaboration objects, see Right-clicking to configure InterChange Server Express properties.
For more information about deploying components, see Exporting components to a package using System Manager.
For more information on Test Connector, see Using Test Connector.
The collaboration receives and processes the event and each service call sends the generic business object to Test Connector, where you can edit it to examine the data for modification.
Before you can test all of the developed components together, you must reconfigure the connector definitions to add support for the application-specific and generic objects they require to participate in the interface. The system associates any maps that it can automatically, but in situations where there are multiple maps that could transform objects you must explicitly associate a map. For more information, see Configuring connectors.
Once you have added support for the required business object definitions to the connectors you can create a collaboration object based on the template and bind its ports to the proper components.
For more information on working with collaboration objects, see Right-clicking to configure InterChange Server Express properties.
After you have created all of the required components for the interface you must deploy it to your local InterChange Server Express instance to test the interface. For more information on deployment, see Exporting components to a package using System Manager.
After you have deployed the interface to your local InterChange Server Express instance you should test the interface as a whole to ensure that the components satisfy the business requirements when working together. Do the following to test the interface: