Copyright © Cloud Software Group, Inc. All Rights Reserved
Copyright © Cloud Software Group, Inc. All Rights Reserved


Chapter 5 Administering iProcess Engine Server Processes : Server Processes

Server Processes
The following table shows the server processes that are initially set up when iProcess Engine is installed. The details of each process are stored in the process_config table. Note that:
Process Sentinels  are responsible for controlling all the TIBCO iProcess Engine processes. If a node cluster architecture is used, then Process Sentinels will exist on each server to manage the processes running on that server.
Foreground processes  are responsible for communicating with TIBCO iProcess Workspaces and for passing any TIBCO iProcess Workspace requests such as released work items to the background area for processing.
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.
Name Shown in Task Manager1
RPC_POOL2
DBQD3
IAPJMS4

1
The Windows Task Manager. Not applicable on UNIX.

2
This process does not get listed by swadm show_processes or swsvrmgr status -v.

3
Only present on the DB2 version of iProcess Engine.

4
This process is disabled unless you have chosen to enable it when installing iProcess Engine.

Sequence Number Caching
The iProcess Engine server processes use sequence numbers extensively in doing their work. A sequence number is simply a unique identifier for an object, such as a case number, wait ID or request ID.
Sequence numbers are generated on an “as required” basis by calling a stored database procedure that accesses the sequence table. (This table contains an identity column. The procedure inserts a row into the table, returns the value of the identity column, then deletes the row.)
However, getting sequence numbers directly from the database in this way can create a performance bottleneck, because while one process is requesting a number it must block any other process from attempting to do so.
To minimize the effect of this bottleneck, you can assign caches of sequence numbers to a process, using process attributes. The process will get a sequence number from its cache when it needs one, and will only need to access the database to refresh the cache when it has run out of numbers.
The following table shows:
The different sequence numbers that can be cached, and the process attributes that you need to set to cache them. (See Administering Process Attributes for more information about process attributes and how to set them.)
Sequence number (Process Attribute)
No, unless the system makes heavy use of sub-procedures.
Yes - used when starting new cases from TIBCO iProcess Workspace.
Yes - A REQ ID is needed for each work item that is sent out.
Yes - used when starting new cases from TIBCO iProcess Workspace.
Yes, if waits are used in procedures.
 
Note that if you use sequence number caching:
Gaps may appear in the value of the sequence numbers. For example, if the BG process caches 50 REQ IDs when it starts up, processes one NEWCASE instruction and then shuts down, the unused REQ IDs (2 to 50) will be lost.
It is possible for a lower case number to be started after a higher case number. For example, suppose that a WIS has 50 case numbers (1 to 50) cached, and a user uses SWUTIL CSTART, which are located in the SWDIR\bin directory to start a case. The case will have case number 51 - the next available number in the sequence. However, if a user then starts a case through the WIS, that case will have case number 1 - the next available number in the cached sequence. Thus, the start date/time for case number 1 will be later than the start date/time for case number 51.

Copyright © Cloud Software Group, Inc. All Rights Reserved
Copyright © Cloud Software Group, Inc. All Rights Reserved