Event-triggered flow

The C++ connector library contain an API that allows a user-defined application-specific component to communicate with an integration broker through business objects. Applications can exchange information with other applications that the integration broker handles.
WebSphere InterChange Server

If your business integration system uses InterChange Server, the connector can communicates with other applications through executing a collaboration. A collaboration represents a business process that can involve several applications. A connector transforms data and logic into a business object that carries information about an event in the connector's application. The business object triggers a collaboration business process and provides the collaboration with information that it needs for the business process.

Note:
An external process can also initiate execution of collaborations through a call-triggered flow. For more information, see the Access Development Guide in the IBM WebSphere InterChange Server documentation set.
WebSphere MQ Integrator Broker

If your business integration system uses WebSphere MQ Integrator Broker, the connector might request information from or send information to other applications through WebSphere MQ workflows. The MQ workflow routes the information as appropriate.

When an event occurs in the application, the connector's application-specific component creates a business object to represent this event and sends the event to the integration broker. An application event is any event that affects an entity associated with a business object definition. To send an event to an integration broker, the connector initiates an event delivery. This event contains a business object. Therefore, the flow trigger that a connector initiates is called an event-triggered flow (see Figure 10).

Figure 10. Event-triggered flow for WebSphere business integration system


Figure 10 shows event-triggering flow within the IBM WebSphere business integration system, which involves the following steps:

  1. The connector creates the triggering event, which it sends to the integration broker during event delivery.

    When an event that affects an application entity occurs (such as when a user of the application creates, updates, or deletes application data), a connector creates a business object, which contains data from the application entity and a verb that indicates the operation performed on this data.

  2. The application-specific component of the connector calls the gotApplEvent() method of the C++ connector library to send the triggering event to the connector framework. Through this method call, the connector performs an event delivery, which initiates the event-triggered flow.
  3. The connector framework performs any needed conversion of the triggering event to a business object, then sends this event to the integration broker.
    WebSphere InterChange Server

    If your business integration system uses InterChange Server, the connector controller receives the triggering event, performing any needed mapping of the application-specific business object data to the appropriate generic business object. The connector controller then sends the triggering event to the specified collaboration to trigger its execution. This collaboration is one that has subscribed to the business object that the event represents. The collaboration receives this business object in its incoming port.

  4. The integration broker uses whatever logic it provides to route the event to the appropriate application. If it is so programmed, it might perform a request, routing the event information to the connector of some destination application, which would receive the event containing its request business object. In addition, this destination connector might send a request response back to the integration broker.
    WebSphere InterChange Server

    If your business integration system uses InterChange Server, the collaboration might perform a service call request to send a business object to the connector controller of the destination connector, which is bound to its outgoing port. This connector controller performs any needed conversion from the resulting generic business object to the appropriate application-specific business object. It then performs a service call response to send the event response to the connector controller, which routes it back to the collaboration.

As Figure 10 shows, a connector can participate in one of two roles:

Each of these connector roles is described in more detail in the following sections.

Event notification

One role of a connector is to detect changes to application business entities. When an event that affects an application entity occurs, such as when a user of the application creates, updates, or deletes application data, a connector sends an event to the integration broker. This event contains a business object and a verb. This role is called event notification.

This section provides the following information about event notification:

Publish-and-subscribe model

A connector assumes that the business integration system uses a publish-and-subscribe model to move information from an application to an integration broker for processing:

Event-notification mechanism

An event-notification mechanism enables a connector to determine when an entity within an application changes. When an event occurs in an application, the connector application-specific component processes the event, retrieves related application data, and returns the data to the integration broker in an business object.

Note:
This section provides an introduction to event notification. For more information on how to implement an event-notification mechanism, see Event notification.

The following steps outline the tasks of an event-notification mechanism:

  1. An application performs an event and puts an event record into the event store.

    The event store is a persistent cache in the application where event records are saved until the connector can process them. The event record contains information about the change to an event store in the application. This information includes the data that has been created or changed, as well as the operation (such as create, delete, or update) that has been performed on the data.

  2. The connector's application-specific component monitors the event store, usually through a polling mechanism, to check for incoming events. When it finds an event, it retrieves its event record from the event store and converts it into an application-specific business object with a verb.
  3. Before sending the business object to the integration broker, the application-specific component can verify that the integration broker is interested in receiving the business object.
    WebSphere InterChange Server

    If your business integration system uses InterChange Server, the connector framework does not assume that the integration broker is always interested in every supported business objects. At initialization, the connector framework requests its subscription list from the connector controller. At runtime, the application-specific component can query the connector framework to verify that some collaboration subscribes to a particular business object. The application-specific connector component can send the event only if some collaboration is currently subscribed. The application-specific component sends the event, in the form of a business object and a verb, to the connector framework, which in turn sends it to the connector controller within ICS. For more information, see "Mapping services".

    WebSphere MQ Integrator Broker

    If your business integration system uses WebSphere MQ Integrator Broker, the connector framework assumes that the integration broker is interested in all the connector's supported business objects. If the application-specific connector component queries the connector framework to verify whether to send the business object, it will receive a confirmation for every business object that the connector supports.

  4. If the integration broker is interested in the business object, the connector application-specific component sends the event, in the form of a business object and a verb, to the connector framework, which in turn sends it to the integration broker.

Figure 11 illustrates the components of the event-notification mechanism. In event notification, the flow of information is from the application to the connector and then to the integration broker.

Figure 11. Event detection and retrieval


Request processing

In addition to detecting application events, another role of a connector is to respond to requests from the integration broker. A connector receives a request business object from a integration broker when the broker requests a change to the connector's application or needs information from the connector's application. In general, connectors perform create, retrieve, and update operations on application data in response to requests from a collaboration. Depending on the application's policies, the connector might also support delete operations. This role is called request processing.
WebSphere InterChange Server

If your business integration system uses InterChange Server, request processing can sometimes be called "service call request processing". The connector receives a business object from its connector controller, which receives it from a service call of a collaboration.

Note:
This section provides an introduction to request processing. For more information on how to implement request processing in your connector, see Request processing.

Request processing involves the following steps:

  1. As Figure 10 shows, an integration broker initiates request processing by sending a request to the connector framework. This request is in the form of a business object, called the request business object, and a verb. For more information, see "Initiating a request".
  2. The connector framework has the task of determining which business object handler in the application-specific component should process the request business object. For more information, see "Choosing a business object handler".
  3. The connector framework passes the request business object to the business object handler defined for it in its business object definition.

    The connector framework does this by calling the doVerbFor() method defined in the business object class and passing in the request business object. The business object handler then processes the business object, converting it to one or more application requests.

  4. When the business object handler completes the interaction with the application, it returns a return-status descriptor and possibly a response business object to the connector framework. For more information, see "Handling a request response".

Initiating a request

The way a request is initiated depends on the integration broker in your IBM WebSphere business integration system:

Initiating a request with InterChange Server

If your business integration system uses InterChange Server, the collaboration initiates a service call request, sending the request over one of its collaboration ports. When you bind a port of a collaboration object, you associate the port with a connector (or another collaboration object). Collaboration ports enable communication between bound entities, so that the collaboration object can accept the business object that triggers its business processes, and then send and receive business objects as service call requests and responses.

Note:
For more information on how to define collaboration ports, see the Collaboration Development Guide. For information on how to bind ports of a collaboration object, see the Implementation Guide for WebSphere InterChange Server. Both these documents are in the IBM WebSphere InterChange Server documentation set.

One the service call request is initiated, the InterChange Server system takes the following steps:

  1. The connector controller for the connector bound to the collaboration port receives the service call request. If necessary, the connector controller maps the generic business object to an application-specific business object before sending the request to the connector framework.
  2. The connector controller forwards the service call request to the connector framework. The connector controller sends the request business object as a C++ object.

Initiating a request with WebSphere MQ Integrator Broker

If your business integration system uses WebSphere MQ Integrator Broker, the integration broker initiates a request by sending a message to the WebSphere MQ queue associated with the connector. One the request is initiated, the connector framework gets the WebSphere MQ message off using its transport layer and converts the message to the appropriate business object using a custom data handler.

For more information on the IBM WebSphere business integration system and request processing, see the Implementation Guide for WebSphere MQ Integrator Broker.

Choosing a business object handler

A business object handler is the Java class that is responsible for transforming the request business object into a request for the appropriate application operation. An application-specific component includes one or more business object handlers to perform tasks for the verbs in the connector's supported business objects. Depending on the active verb, a business object handler can insert the data associated with a business object into an application, update an object, retrieve the object, delete it, or perform another task.

Based on this response business object's business object definition, the connector framework obtains the correct business object handler for the associated business object:

All conversions between business objects and application operations take place within the business object handler (or handlers).

For more information about how to implement the getBOHandlerforBO() method, see "Obtaining the business object handler".

Handling a request response

Once a connector has processed this request and completed the interaction with the application, it can return a response to the integration broker.
WebSphere InterChange Server

If your business integration system uses InterChange Server, the connector framework returns a service call response to the collaboration. Using information in the return-status descriptor, the collaboration can determine the state of its service call request and take appropriate actions.

WebSphere MQ Integrator Broker

If your business integration system uses WebSphere MQ Integrator Broker, the connector framework's response includes:

  • A status indicator, which contains the information return-status descriptor
  • Any business object messages, which contain the optional response business objects

The connector framework puts this response information onto the connector's queue. However, for the message transport to be synchronous (that is, for some program to wait for a response), a program must post its request message to WebSphere MQ Integrator Broker on a synchronous request queue and expect its response from WebSphere MQ Integrator Broker on a synchronous response queue. A correlation ID on the response message identifies the message request to which it is responding.

Copyright IBM Corp. 1997, 2003