MQSeries Integrator operates in a serverless environment. No central authority controls how the entire system works. Each application connecting to MQSeries Integrator contains information necessary to make that connection. Each computer connecting to an MQSeries Integrator network (or framework) has a Queue Manager (QM) that has some default queues, so you do not necessarily have to create any queues. The queues are defined for each QM if needed and a main attribute of a queue is its name. A Queue Manager can have multiple queues.
Below is a list of commands you can use to send and receive messages to and from the MQSeries Integrator product. For each command, you can request to receive a reply. Some of the commands below refer to a “unit of work”. A unit of work is a group of commands or instructions that must be executed together. If one or more commands fail, all of them fail. Messages that are received within a unit of work are committed or backed out together.
GetMessage – gets a copy of the first message in the Get Channel queue. It does not actually delete the message, as it did in version 2.8.3.
GetMessagePutReply – places a response to the message received from the queue.
PutMessage – places a message on a queue for an application to pick up. This command supports the integration of EC Gateway with other electronic commerce applications.
PutMessageGetReply – sends a message to a message queue and waits for a reply.
RemoveMessage – removes all messages received in this script from any queue since the first GetMessage command, or from the previous RemoveMessage or RestoreMessage commands.
RestoreMessage – restores all the messages received in this script from any queue since the first GetMessage command, or from the previous RemoveMessage or RestoreMessage commands such that subsequent GetMessage commands can reread the same messages.
These commands are described in more detail in Chapter 5, “Scheduling.”
The communications channel combines a queue manager and a queue into a single entity. This is because they are both required to send or receive a message.
If more than one queue manager is required in a particular environment, use the RemoveMessage or RestoreMessage command to properly terminate a unit of work. The reason for this caution is that a queue manager acts as a transaction resource manager and a unit of work is maintained within a connection to one queue manager. If you switch from one queue manager to another, you terminate the unit of work.
If the unit of work is not properly terminated with the RemoveMessage or RestoreMessage commands, the script interpreter uses fixed logic to resolve the situation and it backs out the last unit of work before disconnecting. After the unit of work is backed out, a warning message is written to the log. The same applies to the condition when the script ends without explicit termination of the unit of work.
When you write a script, commit the messages after they are (successfully) processed unless several messages constitute a single unit of work. Here is an example of a script committing two messages with one commit statement:
Get Message 1 <process message> If successful - Get Message 2 <process message> If successful, - commit – both messages are removed from the queue. Else, back out – both messages are restored on the queue even though the first one was successfully processed.
In this example, if processing of Message 2 fails, Message 1 is processed again the next time the script is run. Unless there is a valid reason why both messages have to be processed within a single unit of work, the script should commit Message 1, once it is successfully processed.
