The 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.
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.
If your business integration system uses a WebSphere message broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or WebSphere Business Integration Message 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 9).
Figure 9 shows event-triggering flow within the IBM WebSphere business integration system, which involves the following steps:
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.
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.
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 9 shows, a connector can participate in one of two roles:
Each of these connector roles is described in more detail in the following sections.
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:
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:
If your business integration system uses InterChange Server, the connector controller checks its own subscription list when it receives a business object from the connector framework to determine which any collaborations have subscribed to this type of business object. If so, it then forwards the business object to the subscribing collaboration. When a collaboration receives the subscribed event, it begins executing.
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.
The following steps outline the tasks of an event-notification mechanism:
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.
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.
If your business integration system uses a WebSphere message broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or WebSphere Business Integration Message Broker) or WebSphere Application Server, 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.
Figure 10 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.
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.
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.
Request processing involves the following steps:
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.
The way a request is initiated depends on the integration broker in your IBM WebSphere business integration system:
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.
One the service call request is initiated, the InterChange Server system takes the following steps:
If your business integration system uses a WebSphere message broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or WebSphere Business Integration Message Broker) or WebSphere Application Server, 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 your integration broker.
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 method, see Obtaining the business object handler."Obtaining the business object handler" on page 5.
Once a connector has processed this request and completed the interaction with the application, it can return a response to the integration broker.
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.
If your business integration system uses a WebSphere message broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or WebSphere Business Integration Message Broker) or WebSphere Application Server, the connector framework's response includes:
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 the integration broker on a synchronous request queue and expect its response from the broker on a synchronous response queue. A correlation ID on the response message identifies the message request to which it is responding.