Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 4 TIBCO iProcess Engine Processes : Mbox Sets and Message Queues

Mbox Sets and Message Queues
The foreground and background processes communicate with each other using messages. Messages contain information about the iProcess case and instructions about what to do with the case (such as release, keep or forward it.) A message is processed by the case instruction processors. Mbox set is the generic name used for a container in which these messages are stored. Processes can dequeue messages from a Mbox set as and when resources are available.
The messages are stored and managed in the following way:
in the UNIX Oracle and Windows Oracle versions, using Oracle AQ. Oracle AQ uses message queues, which are defined as Oracle AQ tables.
in the UNIX DB2 and Windows SQL Server version, using iProcess database tables that are managed by the database server.
The TIBCO iProcess Engine uses a logical and physical grouping for queues to help improve message throughput. The physical message queues are grouped together as logical Mbox sets.
An Mbox set can be used for different purposes, for example two Mbox sets can be created for the Backgrounds. The Deadline Manager (DLMGR) can write to one set while other processes could write to the second set. The relative priority of processing the work can be changed by assigning different numbers of background processes to dequeue the messages in the different Mbox sets.
Processes can be configured to enqueue or dequeue messages to/from a specific Mbox set rather than to/from a single Mbox queue. The sets can be changed as the performance demands change in your system environment. Multiple queues in an Mbox set enable processes to distribute messages in a round robin manner resulting in an even distribution of messages on the queues.
Refer to Chapter 6 on page 95 for more information about Mbox sets.
Transaction Control of Messages
The Mbox provides a message repository so that processes can post messages and continue with their own processing without having to wait for a reply. The messages are stored persistently and are processed only once. Messages have to be processed exactly once to preserve the data integrity of a transaction. For example, if a message instruction is to debit an amount from a bank account then this has to happen once only even if the systems fail. This is achieved using transaction control.
The messages in the database tables provides a reliable messaging system because the message queues are under transaction control. For example, if a message is delivered to the background case instruction processor but the server goes offline for a while, the message instruction is still persisted in the queue and is retried at a later time.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved