IBM Websphere MQ basics 6: process define process define

concept

      A process definition contains information about the application that starts in response to a trigger event on a queue manager. When you enable triggering on a queue, you can create a process definition and associate it with the queue. Each queue can specify a different process definition, or several queues can share the same process definition. If you create a process definition, the queue manager extracts the information from the process definition and places it in the trigger message for the trigger monitor to use.

      The process definition in IBM MQ contains the necessary information of the application to respond to trigger events on QM. When the trigger is enabled on the queue, a process definition can be created to associate the trigger event. Each queue can specify a different process definition, and several different queues can also share related processes. After creating the process definition, QM extracts information from the process definition and places it in the trigger message for use by the trigger monitor.

If you want to trigger the start of a channel, instead of an application, you do not need to create a process definition because the transmission queue definition is used instead.

         If the requirement is to trigger the start of the channel, there is no need to create a process definition.

Define a process trigger

  • Create the QmgrName to start the entry queue manager
crtmqm QmgrName 
strmqm QmgrName 
runmqsc QmgrName 
  • Create a local queue and start trigger monitoring
DEFINE QLOCAL('TRIGGER.QUEUE') REPLACE DESCR('Application queue to test triggering') SHARE TRIGGER TRIGTYPE (EVERY) INITQ('TEST.INIT.QUEUE') PROCESS('IBMMQ.PROCESS') 

The initiation queue for this trigger monitoring is: TEST.INIT.QUEUE;

process define 为:IBMMQ.PROCESS;

The trigger type is: every, every time

  • Define a process
DEFINE PROCESS('IBMMQ.PROCESS') REPLACE DESCR('Process to test triggering') APPLICID('/var/mqm/test_process.sh')

The application is a script, and the script is used to return the current script name $0 :

[mqm@t24app1sg ~]<20190602 11:14:20>$ cat test_process.sh

#!/bin/bash
echo "This is process:" $0
  • Define the initiation queue
DEFINE QLOCAL('TEST.INIT.QUEUE') REPLACE DESCR('Initiation queue to test triggering') 
  • Start trigger monitoring (linux view, not runmqsc view)
runmqtrm -m QmgrName -q TEST.INIT.QUEUE

       After startup, trigger the monitoring process to monitor the initiation queue cyclically.

  • Put a message in TRIGGER.QUEUE ( open another window and send the message )
amqsput TRIGGER.QUEUE QmgrName

Test effect:                     

So, the result shows: the test is correct.

    Practical applications can do a lot of articles on tigger type and process according to the application scenario . For example, based on the in-depth trigger, when the depth of the queue reaches the threshold, the startup process notifies the message producer to suspend message sending.

Guess you like

Origin blog.csdn.net/zhaogang1993/article/details/90740160