How the InterChange Server system uses mapping

Mapping make it possible for collaborations to take the data from a business object of one application and transform it to generate a business object for a disparate application. In the mapping process, collaborations interact with connectors, with the Access Interface, or with both.

The IBM WebSphere InterChange Server system provides comprehensive support for data mapping between business objects, including the following capabilities:

In an IBM WebSphere InterChange Server environment, mapping typically takes place between application-specific business objects and generic business objects. The IBM WebSphere InterChange Server system does not map application-specific business objects directly to other application-specific business objects. Instead, the generic object acts as an intermediary between two application data models, carrying the mapped information from one data model to the collaboration (either through a connector or through the Server Access Interface), then carrying mapped information from the collaboration to a connector for another data model.

Figure 5-1 illustrates the way that data mapping occurs at runtime, using a fictionalized Employee Management collaboration as an example: The Employee Management collaboration receives an employee business object from the source connector, then sends an employee business object to the destination connector. (In this example, a collaboration receives a business object from a connector; a similar mapping process takes place when a collaboration receives a business object from the Access Interface.)

Figure 36. Data mapping at runtime


Figure 5-1 illustrates the following sequence:

  1. The App A connector agent produces an App A Employee business object and sends it to the connector controller.
  2. The connector controller passes the App A Employee business object to the InterChange Server for mapping. The request includes the name of the data map that the Server must use, based on the map name specified in the connector configuration.
  3. The map returns the generic Employee business object to the connector controller.
  4. The connector controller checks the collaborations that have subscriptions to the generic Employee business object. In this case, Collaboration1 has a subscription, so the connector controller hands the business object to Collaboration1.
  5. The collaboration performs some processing and then produces another generic Employee business object as output, which it sends to the connector controller.
  6. The connector controller passes the generic business object to the InterChange Server, requesting mapping to the App B Employee business object.
  7. The map returns the application-specific business object to the connector controller.
  8. The connector controller passes the App B business object to the App B connector agent, which can then pass the data in the business object into Application B.

The example above used two maps--one from the App A Employee business object to the generic Employee business object used by the collaboration, and one from the generic Employee business object to the App B Employee business object. The Employee data moved in only one direction--from App A toward App B.

If you wanted to exchange the Employee data in both directions between the two different applications, four maps would be required:

Copyright IBM Corp. 1997, 2004