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:
- 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.
- 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.
- 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. |
- 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:
- Event notification--the connector sends an event (in the form of a
business object) to the integration broker to notify it of some operation that
has occurred in the application.
- Request processing--the connector receives a request business object from
an integration broker.
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:
- An integration broker subscribes to a business object that
represents an event in an application.
WebSphere InterChange Server |
---|
If your business integration system uses InterChange Server, a
collaboration subscribes to a business object that represents an
event in an application, and then the collaboration waits. |
- A connector uses an event-notification mechanism to monitor when
application events occur. When an application event does occur, the
connector publishes a notification of the event in the form of a
business object and a verb. When the integration broker receives an
event in the form of the business object that it has subscribed to, it can
begin the associated business logic on this data.
WebSphere InterChange Server |
---|
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.
- 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:
- 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.
- 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.
- 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. |
- 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

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:
- 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".
- 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".
- 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.
- 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".
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.
- 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:
- 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.
- The connector controller forwards the service call request to the
connector framework. The connector controller sends the request
business object as a C++ object.
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.
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:
- When the connector starts up, the connector framework receives from the
connector controller the list of
business objects that the connector supports.
- The
connector framework calls the
getBOHandlerforBO() method (defined in the connector base class) to
instantiate one or more
business object handlers.
- For each supported business object, the getBOHandlerforBO()
method returns a reference to a business object handler, and this reference is
stored in the business object definition in the memory of the connector
process.
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".
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.
|
