WebSphere MQ provides a facility, called triggering, that enables an application to be started automatically when there are messages available to retrieve. The WebSphere InterChange Server product uses an MQ-triggered Object Activation Daemon (OAD) to handle the following tasks:
This MQ-triggered OAD uses the triggering feature of WebSphere MQ to restart a connector agent.
To set up this OAD requires the following steps:
Use of the MQ-triggered OAD requires installation of the MQ Trigger Monitor. This monitor is installed as part of the WebSphere MQ software, described in Installing IBM WebSphere MQ. This software must exist on the machine on which the connector agent resides.
In Figure 20, each connector agent is participating in either remote starts or automatic restarts, or both. On each machine on which a participating connector agent resides, the WebSphere MQ software must exist. Note that only one MQ Trigger Monitor is required on a machine, regardless of how many connector agents are on that machine. If the local machine has WebSphere MQ Server installed, the runmqtrm command invokes the MQ Trigger Monitor daemon. If the local machine has WebSphere MQ client installed, the runmqtmc command invokes the MQ Trigger Monitor daemon.
Figure 20. Example OAD configuration
The configuration in Figure 20 would require that the following software be installed:
There is an issue when using the runmqtrm to invoke the MQ Trigger Monitor daemon on UNIX. The mqm user is the owner of the Trigger Monitor, but may not have the correct paths and permissions to execute commands initiated by the cwadmin user, for instance. To circumvent this issue, make a copy of the runmqtrm command which is then dissociated from the mqm user and group, and used solely for the initiation of the MQ Trigger Monitor daemon. The necessary commands are:
cp /opt/mqm/bin/runmqtrm /opt/mqm/bin/runmqtrm2
to copy the runmqtrm to runmqtrm2, and
chmod ug-s /opt/mqm/bin/runmqtrm2
removing the user and group settings from the runmqtrm2 command.
The runmqtrm2 command is then used to invoke the MQ Trigger Monitor daemon, which will be owned by the user issuing the runmqtrm2 command. This creates a secondary problem, because the issuing user may not have all the permissions required to access the queue manager, the initiation queue (where trigger messages are placed) and the dead letter queue. Use the "setmqaut" program to give chosen groups the authority to access MQ objects, but note that you cannot give authority to individual users.
For example, a user who is a member of the "appdev" group needs to run runmqtrm2. The queue manager name is "CALVIN", the initiation queue is called "CALVIN.INITQ" and the dead letter queue is "SYSTEM.DEAD.LETTER.QUEUE". Run the following commands to give the "appdev" group authority to run the Trigger Monitor:
setmqaut -m CALVIN -t qmgr -g appdev +connect +inq
setmqaut -m CALVIN -t queue -n CALVIN.INITQ -g appdev +get
setmqaut -m CALVIN -t queue -n SYSTEM.DEAD.LETTER.QUEUE -g appdev +put +inq +passall
Note that every member of that group has permission to access the queue manager.
For more information about how to install WebSphere MQ, see Installing IBM WebSphere MQ.
To support MQ-triggered OAD, the WebSphere MQ queue manager must be
configured to handle triggers. This support requires that the WebSphere
MQ-related objects in Table 30 be created on the same machine that contains InterChange
Server and the WebSphere MQ queue manager.
Table 30. WebSphere MQ-related objects for WebSphere MQ-triggered OAD
Service | Purpose of database access |
---|---|
Initiation queue | Receives trigger messages for the MQ Trigger Monitor from the MQ queue manager. |
Process definition | Describes the process that MQ Trigger Monitor invokes when it retrieves a trigger message from the initiation queue. |
Adapter-activation queue | Receives triggering events for an adapter from InterChange Server. These messages are picked up by the connector framework of the connector associated with the queue. |
To create these MQ-related objects, run the mqtriggersetup script, which resides in the ProductDir/bin subdirectory. Run this script on the machine that contains the connector for which you want to enable the automatic-and-remote-restart feature.
mqtriggersetup WICS_queueManagerName connName connStartupScript
where:
For example, to set up automatic and remote restart for a connector called MyConn, you can use the following call to mqtriggersetup:
mqtriggersetup InterChangeServer.queue.manager MyConn /IBM/WebSphereBI/connectors/MyConn/connector_manager_MyConn.sh
You must run the mqtriggersetup script on the machine that contains the MQ queue manager. Run the mqtriggersetup script for each connector that resides on the same machine. In addition, you must run this script for each connector that resides on a remote machine.
To start the MQ-triggered OAD, you must explicitly start MQ Trigger Monitor with the appropriate startup script. You must start an MQ Trigger Monitor on each machine on which connectors reside.
When you install WebSphere MQ, the installation program installs the runmqtrm or runmqtmc files. These scripts start the MQ Trigger Monitor as part of an MQ Server or MQ Client release, respectively. For example, the following command starts MQ Trigger Monitor (in an MQ Server release):
runmqtrm -m WICS_queueManager -q INITIATION.QUEUE
where WICS_queueManager is the name of the MQ queue manager for your InterChange Server.
To configure an individual connector so that it uses automatic and remote restart, you must take the following steps:
For information on how to set these properties, see the System Administration Guide.