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


Chapter 2 Introduction to the TIBCO iProcess Engine : How Do Work Items Appear in Work Queues?

How Do Work Items Appear in Work Queues?
For any work item to appear in a user’s work queue, a work item record has to exist on the server for the TIBCO iProcess Workspace to know about it. The record contains information about the work item such as its case number, where in the database the fields and values are stored, the addressee and procedure, etc.
The WIS process contains work item records that define what work items are in the queue. The WIS reads the staffo database table which contains all the work item records where one row in the table represents one work item record. Each work item entry in the table contains specific information about the work item such as its case number, unique identifier, case description, name and node of case starter, etc. The TIBCO iProcess Workspace also calls the RPC server which makes requests to the database tables to retrieve fields and their values and any memos and attachments.
Sending Instructions From the TIBCO iProcess Workspace to the TIBCO iProcess Engine
When a user processes a work item by either Keeping or Releasing it, the TIBCO iProcess Workspace creates a package of instructions that are sent to the TIBCO iProcess Engine. This package contains all the information about the work item, such as what fields and data are shown on the form, what fields may have changed, and the instruction to be performed.
The message is sent from the TIBCO iProcess Workspace to the TIBCO iProcess Engine in packets via RPC calls. The package is split up into its various components so that an instruction message is sent to the background and any case data updates are made by updating the database. The instruction message is enqueued to a Mbox message queue where it waits to be processed by one of the background processes.
The Background process reads the message queues for new messages so it dequeues the message from the queue and then processes the case instructions. The Background performs the necessary actions such as update the changed fields in the database and determine what the next step is and who to send it to.
Mbox Sets
The message system is able to distribute messages across physical Mbox queues, which means that high volumes of messages can be handled. The Mbox queues are grouped into logical sets (Mbox sets) with each set configured for a specific purpose. Different processes require access to different Mbox sets, for example the instruction processor requires write access to a background Mbox, and WIS Mbox.
Message Queues
All TIBCO iProcess messages are posted to a central queue repository (Mbox). This is hosted by:
in the UNIX Oracle or Windows Oracle versions, a set of tables using Oracle Advanced Queues (Oracle AQ).
in the UNIX DB2 or Windows SQL Server versions, a set of iProcess queue tables in the database.
The Mbox can be configured to be a number of queues in a number of database tables, and even split across physical disks. Therefore, even though the Mbox appears as a single queue, it could consist of multiple queues in multiple tables across multiple disks.
The messaging system provides an assured delivery mechanism for instruction and request messages between the foreground and background.
User Access to iProcess Engine Work Queues
The total number of work queues a single iProcess user can have access to is 32,767.
If the number of work queues a iProcess user has access to exceeds 32,767, the iProcess user is not able to login to the iProcess Engine and the following error message is displayed:

 
Sal Queues Interface 'sal_queues_count()' returned fatal error -n. Called by wqsess_lcreat_folder.
Abort WorkQs?

 
where n is the total number of work queues.
This only affects the single user who has access to too many work queues. All other iProcess users will be able to log in to the iProcess Engine without any problems.
An iProcess user can have access to the following work queues:
Their Personal Queue which only they can access.
Any Group Queues that they are a member of.
Any Test User Queues or Test Group Queues, if the user is allowed to define procedures.
An iProcess user can also be given access to work queues in the following ways:
For example, the following table illustrates the total number of work queues a user called swusr001 has access to:
From the example above, you can see that the number of work queues a user can have access to can quickly increase if that user is a member of several groups and is a supervisor or participant of several queues.
This means it is important to plan in advance the number of work queues you want to create and how many supervisors and participants you are going to need. For example, if you want to create 17,000 work queues on your TIBCO iProcess Engine, you could not make a single user both a supervisor and a participant of all 17,000 work queues. This is because that user would then have access to 34,000 work queues which would exceed the limit.
If you do want to create a large number of work queues and you want to have supervisors and participants for them, you would have to split them between more than one user. For example, if you had 17,000 work queues you could make:
swusr001 a participant of all 17,000 work queues
swusr002 a supervisor of all 17,000 work queues.

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