The integration framework supports both synchronous and
asynchronous message processing in a highly available environment.
The Tivoli®'s process automation
engine integration
framework supports various message formats and protocols for exchanging
messages between the process automation engine and
external systems.
Depending on the integration framework capabilities that are used,
there are different ways to configure high availability.
When you use the integration framework in a high availability environment,
you must pay attention to the following areas:
- Integration framework error handling
- The mxe.int.globaldir property defines where
integration framework error logs, the schema, and Web Services Description
Language (WSDL) files are stored and read from. In a clustered environment,
the directory is on a shared disk and all application servers must
have access to that location.
- Synchronous integration
- Synchronous integration does not use JMS Queues. For example,
the synchronous message exchange can use HTTP, web services, and Enterprise
JavaBeans. The high availability characteristics of synchronous integration
are similar to the process automation engine user
interface client; the web browser. If an error occurs, the request
must be resubmitted to continue.
- Asynchronous integration
- Asynchronous integration uses JMS queues. For example, the asynchronous
message exchange can use HTTP, web services, Enterprise JavaBeans,
file loading, and interface tables. Queue failover must be considered: WebSphere® Application Server configures
queues for failover by default in a clustered environment.
As part of asynchronous integration, the consumer of the messages
and the producer of the messages must be considered:
- Consumer
- The process automation engine consumes
messages in the queue.
- Sequential queue: Guarantees the order of messages that are processed
is based on the order that the messages are received. Only one instance
of a cron task handles the consumption of messages from the queue.
If the server fails, the highly available environment starts another
instance of the cron task to handle the failed job on another server
or node.
- Continuous queue: Multiple instances or servers consume messages
from the queue in a multi-threaded mode and the processing order is
not guaranteed. If one server fails, a second server picks up the
message.
- Producer
- An external system puts the messages in the queue. If an error
occurs when the message is placed in the queue, the sender must handle
the error and resend the message.