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


Chapter 2 Introduction to the TIBCO iProcess Engine : TIBCO iProcess Engine Process Structure

TIBCO iProcess Engine Process Structure
In order to understand the flow of data through the TIBCO iProcess Engine and the relationship of TIBCO iProcess Engine processes, you can think of the TIBCO iProcess Engine as being split into the following four areas.

 

 
A TIBCO iProcess Engine process operates in either the foreground or background layer. The Mbox set provides the communication link between the foreground and background processes. This is the Messaging layer where instructions are sent from the foreground to the background and vice versa.
The foreground area deals with the user interaction, list of queues and their contents. The background processes perform the case processing.
The Process Sentinels keep control of all the processes to make sure they are always running.
Process Sentinels
The Process Sentinels (SWDIR\etc\procmgr) are responsible for controlling all the TIBCO iProcess Engine processes. If a node cluster architecture is used, then the Process Sentinels will exist on each server to manage the processes running on that server. This process operates in different ways depending on whether you are using a third party transaction processing monitor.
In a node cluster, the Process Sentinels have a master process on one of the servers, which manages and controls slave Process Sentinels on all the other servers in the node cluster.
The Process Sentinels control the safe start up and shut down of processes on one or multiple servers i.e. making sure processes are started in the correct sequence.
The Process Sentinels can also monitor processes to check that they are running and can automatically restart them if they fail. It can also detect if SWDIR\logs\sw_error and SWDIR\logs\sw_warn files have been created and sends a work item to the administrator to inform them that these files have been created.
Refer to Process Management for more information about the Process Sentinels.
Foreground Processes
These processes are responsible for communicating with the TIBCO iProcess Workspaces and for passing any TIBCO iProcess Workspace requests such as released work items to the background area for processing.
The following table shows the processes that operate in the foreground:
Refer to Foreground Processes for more information about what these processes do.
All of the foreground processes must operate on the master server. See Determining Where Processes Run for more information.
Mbox Sets
The Mbox Sets are responsible for communicating information between the foreground and background processes. It is essentially the messaging system that stores and processes messages from TIBCO iProcess Workspace or TIBCO iProcess Engine requests. Mbox sets comprise of one or more message queues.
The messaging system used is:
in the UNIX Oracle and Windows Oracle versions, Oracle AQ. This is a transactional messaging system provided by the Oracle database.
in the UNIX DB2 and Windows SQL Server versions, the iProcess Suite’s own transactional messaging system, which uses database tables provided by the DB2 or Microsoft® SQL Server database.
The messaging system provides the ability to store messages in tables. This means that message queues are highly scalable and have a guaranteed delivery mechanism.
See iProcess Mbox Sets on page 89 for more information about the Mbox sets.
Background Processes
The background processes are responsible for processing message instructions received from the clients such as releasing a step or forwarding a step. They also monitor and process any deadlines that have been set up in the procedure and manage case prediction.
The following processes operate in the background:
DBQD1

1
This process is only present on the DB2 version of the TIBCO iProcess Engine.

Refer to Background Processes for more information about what these processes do.
Event Handling
The TIBCO iProcess Engine uses a publish/subscribe event mechanism to handle the following inter-process tasks:
The event handling mechanism used depends on the TIBCO iProcess Engine variant used, as follows:
UNIX Oracle version. Events are handled using Oracle AQ’s publish/subscribe interface.
Windows Oracle and Windows SQL Server versions. Events are handled using the iProcess Events COM+ application, which is installed with the TIBCO iProcess Engine. All processes that want to subscribe to events register with the iProcess Events COM+ application.
If you are using a node cluster architecture, the iProcess Events COM+ application runs by default on the machine on which you installed the master server. If performance is or becomes an issue, TIBCO recommend that you dedicate a separate server, which is not running any TIBCO iProcess Engine processes, as the event server. This will reduce the load on the master server.
UNIX DB2 version. Events are handled using iProcess event/notification daemons.
The event daemon is a single thread created by the Process Sentinel watcher process. The event daemon:
A notification daemon is a thread created by any TIBCO iProcess Engine process that wishes to receive event notifications.

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