TIBCO iProcess Engine Administrators Guide

Software Release 11.1 September 2009

Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE. USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME. This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc. TIB, TIBCO, TIBCO Software, TIBCO Adapter, Predictive Business, Information Bus, The Power of Now, TIBCO iProcess are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries. EJB, Java EE, J2EE, JMS and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only. THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README.TXT FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM. THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME. THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES. Copyright 2001-2009 TIBCO Software Inc. ALL RIGHTS RESERVED. TIBCO Software Inc. Confidential Information

|i

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
How to Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Changes from the Previous Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Target Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Where You Can Find More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi How to Contact TIBCO Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1 Controlling the iProcess Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Starting the iProcess Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Stopping the iProcess Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Configuring the iProcess Engine Events Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Configuring the Time Zone for the iProcess Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2 Using the iProcess Engine Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

SWDIR\swdefs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 SWDIR\etc\language.lng\staffico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 SWDIR\etc\staffpms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 SWDIR\etc\language.lng\audit.mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 SWDIR\etc\language.lng\auditusr.mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 SWDIR\etc\language.lng\stafferr.mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 SWDIR\etc\language.lng\staffw.mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 SWDIR\etc\language.lng\staff.mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 SWDIR\etc\swerwarn.mes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 3 Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters . . . . . . . . . . . . 41

Editing the SWDIR\etc\staffcfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 WQS Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 FORM Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 STAFFPRO Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

TIBCO iProcess Engine Administrators Guide

Back to Library

ii

Contents

STAFF Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 DBSIZES Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 DBPOOL Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 CDQP Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Obsolete Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Chapter 4 Administering Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Show all Server Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Update Server Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Add a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Remove a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Find a Servers Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Find the Master Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Define a Server as the Master Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Move Processes From One Server to Another . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Chapter 5 Administering iProcess Engine Server Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Server Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Using SWDIR\util\swadm to Administer Server Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Using SWDIR\util\swsvrmgr to Administer Server Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Using the iProcess Server Manager to Administer Server Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Chapter 6 Administering Process Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Using SWDIR\util\swadm to Administer Process Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Alphabetical List of Process Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 General iProcess Engine Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Process Management Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 WIS and WQS Process Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Message and Mbox Processing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Sequence Numbering Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Transaction Control Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Activity Monitoring and Work Queue Delta Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 TIBCO Rendezvous Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Case Prediction Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 TIBCO iProcess Workspace (Windows) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

TIBCO iProcess Engine Administrators Guide

Back to Library

Contents iii

Procedure Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 iProcess Objects Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Chapter 7 Administering Message Queues and Mbox Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Using SWDIR\util\swadm to Administer Mbox Sets, Message Queues and Messages . . . . . . . . . . . . . . . . . . 279 Using the iProcess Server Manager to Administer Message Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Default Message Handling Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Chapter 8 Administering Procedure Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Show Procedures and Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Tidy Instances of Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Chapter 9 Administering Firewall Port Ranges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 ADD_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 DEL_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 MOD_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 SET_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 SHOW_PORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 SHOW_RANGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 ADD_AQ_PORT_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 MOD_AQ_PORT_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 DEL_AQ_PORT_RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Chapter 10 Administering Activity Monitoring and Work Queue Delta Publication . . . . . . . 329
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Enabling Activity Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Filtering Message Event Request (MER) Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Configuring the iProcess Activity Publication (IAP) Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Updating the IAP Security Principle and Credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Using SWDIR\util\swadm to Administer Work Queue Delta Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Chapter 11 Administering the Work Queue Server and Work Item Server Processes . . . . . 341
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 The WQS Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 The WIS Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
TIBCO iProcess Engine Administrators Guide

Back to Library

iv

Contents

Troubleshooting Work Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Chapter 12 Administering Case Data Normalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Enabling Case Data Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Chapter 13 Managing EAI Step Server Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Unregister (Remove) an EAI Plug-In. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Modify an Existing EAI Plug-In Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 List Existing EAI Plug-In Registry Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Reload an EAI Plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Get Release Version Stored in EAI Plug-In. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Possible Errors When Using sweaireg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Appendix A iProcess Engine Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Appendix B System Backup Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Backup and Recovery of iProcess Case Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Backup and Recovery of iProcess Engine Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Appendix C iProcess Engine Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Appendix D Understanding Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Appendix E iProcess Server Manager Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
getNodeDetails() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 getProcessDetails() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 getProcessSummary() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 getProcessStatus() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 doStartProcesses() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 doStartTemporaryProcess() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 doRestartProcess() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 doStopProcesses() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 getIsTypeDynamic() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 getLogFileLines() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 getAllQueues() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

TIBCO iProcess Engine Administrators Guide

Back to Library

Contents v

getMessageHeader() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 getMessageDetail() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 deleteMessage() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 restoreDeadMessage() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

TIBCO iProcess Engine Administrators Guide

Back to Library

vi

Contents

TIBCO iProcess Engine Administrators Guide

Back to Library

| vii

Preface

This guide describes how to administer the iProcess Engine. There are additional administration tasks that can be performed on the TIBCO iProcess Workspace (Windows) such as case monitoring, managing users and groups and case administration. These are all described in the TIBCO iProcess Workspace (Windows) Manager's Guide.

Topics
How to Use This Guide, page viii Changes from the Previous Issue, page ix Target Audience, page x Where You Can Find More Information, page xi Documentation Conventions, page xiii

TIBCO iProcess Engine Administrators Guide

Back to Library

viii

Preface

How to Use This Guide

You should read Chapter 1 first. This chapter describes how to start, stop and control the iProcess Engine. For more information about specific aspects of administering the server, you can then consult the following chapters as required: Chapter 2 describes the most important iProcess Engine configuration files. Chapter 3 provides detailed information about configuring the iProcess Engine using the SWDIR\etc\staffcfg parameters. Chapter 4 describes how to use the server configuration utility SWDIR\util\swadm to administer the server(s) hosting your iProcess Engine. Chapter 5 describes how to administer iProcess Engine server processes using the SWDIR\util\swadm and SWDIR\util\swsvrmgr utilities and the iProcess Server Manager. Chapter 6 describes how to use the server configuration utility SWDIR\util\swadm to administer server process attributes. Chapter 7 describes how to use the server configuration utility SWDIR\util\swadm to administer queues, Mbox sets and message instructions. Chapter 8 describes how to use the server configuration utility SWDIR\util\swadm to administer procedures and libraries. Chapter 9 describes how to use the server configuration utility SWDIR\util\swadm to set up and use port ranges for the iProcess Engine, for use with firewall filters. Chapter 10 describes how to administer activity monitoring on the iProcess Engine. Chapter 11 describes how to administer the work queue server (WQS) and work items server (WIS). Chapter 12 describes how to administer case data normalization. Chapter 13 explains how to use the SWDIR\util\sweaireg command line utility to manage the Enterprise Application Integration Step (EAI) plug-in libraries.

Appendixes describe log files, system backup and recovery guidelines, the iProcess Engine directory structure, the audit trail messages and the process sentinel interfaces for TIBCO Hawk integration.

TIBCO iProcess Engine Administrators Guide

Back to Library

Changes from the Previous Issue ix

Changes from the Previous Issue

Major technical changes from the information presented in the previous (11.0) issue of this guide are: A new entry has been added in the $SWDIR\etc\staffpms file. See Configure Signals That Threads are Blocked From Receiving on page 31. A new parameter has been added to the STAFF section of the SWDIR\etc\staffcfg file to define how the predicted step duration is to be calculated. See DYNDEADPRED on page 74. A new parameter has been added to the STAFF section of the SWDIR\etc\staffcfg file to define the format of IAPJMS messages. See IAPSCHEMA on page 75 and Enabling Activity Monitoring on page 331 for details. The IS_ACTIVEDIRECTORY parameter in the STAFFPRO section of the SWDIR\etc\staffcfg file is now obsolete as a result of changes to the LDAPCONF utility. See Obsolete Parameters on page 86. A new process attribute has been added that allows configuration of uncommitted reads during an XPC SELECT. See XPC_READ_UNCOMMITTED on page 163. A new process attribute has been added that allows the batching of RPC calls to reduce the overhead of processing RPC calls individually. See RPC_SVR_CONTROL on page 184. A new process attribute has been added that defines the number of new item requests to be batched together so more can be processed in a single write lock. See WIS_NEW_ITEM_BATCH_SIZE on page 198. A new process attribute has been added that allows the use of priority escalation in the WIS process to be disabled. See WIS_USE_PRIORITY_ESCALATION on page 205. A new process attribute has been added that allows the gathering of RPC call stats within the WQS process to be configurable. See WQS_GATHER_RPC_STATS on page 206. New swadm commands have been added to add, modify or delete port ranges in the aq_port_range_conf table. See ADD_AQ_PORT_RANGE on page 326, MOD_AQ_PORT_RANGE on page 327 and DEL_AQ_PORT_RANGE on page 328.

TIBCO iProcess Engine Administrators Guide

Back to Library

Preface

Target Audience
This guide is aimed at administrators who need to perform iProcess administrative operations on the iProcess Engine. It assumes that: you have prior knowledge of iProcess concepts. You should be familiar with the concepts described in the TIBCO iProcess Engine: Architecture Guide. you have a detailed understanding of the operating system.

TIBCO iProcess Engine Administrators Guide

Back to Library

Where You Can Find More Information xi

Where You Can Find More Information

You can find more information about the TIBCO iProcess Engine from the following sources: TIBCO iProcess Engine Installation Guide Read this guide for instructions on site preparation and installation. This document is available in the \docs directory on the iProcess Engine distribution set. TIBCO iProcess Engine Release Notes Read the release notes for a list of new and changed features. This document also contains lists of known issues and closed issues for this release. This document is available in the \docs directory on the iProcess Engine distribution set.

TIBCO iProcess Engine: Architecture Guide Read this guide for detailed information about the structure, processes and data flow on the iProcess Engine. Read the following guide (depending on your database) for more information about iProcess Engine database tables: TIBCO iProcess Engine (SQL): Administrator's Guide TIBCO iProcess Engine (Oracle): Administrator's Guide TIBCO iProcess Engine (DB2): Administrator's Guide

TIBCO iProcess Engine Administrators Guide

Back to Library

TIBCO iProcess Suite Documentation Library This library contains all the guides for the iProcess Engine and other TIBCO products in the TIBCO iProcess Suite. The following guides are particularly relevant for iProcess Engine administrators:

xii

Preface

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, please contact TIBCO Support as follows. For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this site: http://www.tibco.com/services/support If you already have a valid maintenance or support contract, visit this site: https://support.tibco.com Entry to this site requires a user name and password. If you do not have a user name, you can request one.

TIBCO iProcess Engine Administrators Guide

Back to Library

Documentation Conventions xiii

Documentation Conventions
Because this guide covers Windows, UNIX and Linux versions of the iProcess Engine, this guide uses the Windows convention of a backslash (\). The equivalent pathname on a UNIX or Linux system is the same, but using the forward slash (/) as a separator character. UNIX or Linux pathnames are occasionally shown explicitly, using forward slashes as separators, where a UNIX/Linux-specific example or syntax is required. Any references to UNIX in this guide also apply to Linux unless explicitly stated otherwise. The following conventions are used throughout this guide. Convention SWDIR Description Indicates the iProcess system directory where the iProcess Engine is installed. For example, if SWDIR is set to \swserver\staffw_nod1 then the full path to the swutil command would be: on Windows: swserver\staffw_nod1\bin\swutil, or SWDIR\bin\swutil on UNIX: /swserver/staffw_nod1/bin/swutil, or $SWDIR/bin/swutil Note: On a UNIX system, the environment variable $SWDIR should be set up to point to the iProcess system directory for the root, IPEADMIN and IPEBACKGROUND users. IPEADMIN IPESERVICE IPEBACKGROUND Indicates the operating system account that is used to administer the iProcess Engine. Indicates the Windows account that is used to run the iProcess Engine. (Not used on UNIX.) Indicates the UNIX user account that owns most iProcess Engine files and is used to run the iProcess Engine background processes. (Not used on Windows.)

TIBCO iProcess Engine Administrators Guide

Back to Library

xiv

Preface

Convention italics
monospace text

Description Indicates emphasis, variables and manual titles. Indicates code samples, commands and their options, directories and filenames. Any text that you must enter from the keyboard is displayed as monospace text. Indicates variables in commands. Indicates a set of choices in a syntax line. The braces should not be entered. Indicates optional items in a syntax line. The brackets should not be entered. For example: SHOW_ALL_ATTRIBUTES [attribute]

monospace italic text

{ } [ ]

Indicates mutually exclusive choices in a syntax line i.e. you enter only one of the given choices. You should not enter the symbol itself.

TIBCO iProcess Engine Administrators Guide

Back to Library

|1
Chapter 1

Controlling the iProcess Engine

This chapter describes basic operations for controlling the iProcess Engine. You can also control, start and stop the iProcess Engine Process Sentinels and server processes using the SWDIR\util\swadm and SWDIR\util\swsvrmgr utilities. See Administering iProcess Engine Server Processes on page 99 for more information.

Topics
Starting the iProcess Engine, page 2 Stopping the iProcess Engine, page 6 Configuring the iProcess Engine Events Server, page 13 Configuring the Time Zone for the iProcess Engine, page 14 Error Handling, page 16

TIBCO iProcess Engine Administrators Guide

Back to Library

| Chapter 1

Controlling the iProcess Engine

Starting the iProcess Engine

The iProcess Engine server processes are controlled by the Process Sentinels. The Process Sentinels must be started first; they then control the start-up of the server processes. If you are using more than one server to host the iProcess Engine (a node cluster), the Process Sentinels must be started on each server. Before you can start the iProcess Engine, you must make sure that: 1. The iProcess database instance is running. 2. All required message queues are running. 3. The event manager is running. (This means that the event queues and agents are running.) The following sections explain how to start the Windows (see page 2) and UNIX versions (see page 4) of the iProcess Engine.

Windows Version
In the Windows version, the iProcess Engine functions are provided by the iProcess nodename Process Sentinels service (where nodename is the name of your iProcess Engine installation). By default, once the Process Sentinels have started they will automatically start the iProcess Engine server processes. This behavior is controlled by the PM_AUTO_BOOT process attribute; only processes that have a PM_AUTO_BOOT value of 1 will be started automatically. See Administering Process Attributes on page 133 for more information. You can start the Process Sentinels service in three different ways (unless you have installed the iProcess Engine to a Windows cluster): at system startup - see page 3. manually, from the Windows Control Panel - see page 4. using the SWDIR\bin\swstart.bat script - see page 4.

To be able to start the iProcess Engine, you must be logged in as either the IPEADMIN user, or as a user who is a member of both: the iProcess Administrators local group (which gives you permissions on files and directories in SWDIR.

TIBCO iProcess Engine Administrators Guide

Back to Library

Starting the iProcess Engine 3

an operating system group that gives you permissions to start a service, normally the Administrators group.

If you have installed the iProcess Engine to a Windows cluster, use the Bring online service in the Microsoft Cluster Administrator to start the iProcess Engine. Do not attempt to start the iProcess Engine on a Windows cluster using Control Panel > Services or the SWDIR\bin\swstart command. Configuring System Startup Behavior When you install the iProcess Engine, you choose whether or not the Process Sentinels service:

needs to be started manually. is disabled (cannot be started).

If you subsequently want to change this setting, do the following: 1. From the Start menu, click Settings > Control Panel. 2. Double-click Administration Tools. 3. Double-click Services.The Services dialog is displayed. 4. Select the iProcess nodename Process Sentinels service (where nodename is the name of your iProcess Engine installation) and click Startup. The Service dialog is displayed. 5. Set the Startup Type to: Automatic, if you want the Process Sentinels service to start automatically on system startup. Manual, if you want to manually start the Process Sentinels service (see below). Disabled, if you want to disable the Process Sentinels service. Do not change any other options in the Service dialog. Doing so may cause the iProcess Engine to fail.

TIBCO iProcess Engine Administrators Guide

Back to Library

starts automatically on system startup (the default option).

| Chapter 1

Controlling the iProcess Engine

Manually Starting the Process Sentinels Service To manually start the Process Sentinels service: 1. From the Start menu, click Settings > Control Panel. 2. Double-click Administration Tools. 3. Double-click Services.The Services dialog is displayed. 4. Select the iProcess nodename Process Sentinels service (where nodename is the name of your iProcess Engine installation). 5. Click Start. This will start the Process Sentinels service and the iProcess Engine server processes. You can use the Processes tab of the Windows Task Manager to view the processes as they start up. See Server Processes on page 101 for a list of processes that are started. Using the swstart.bat Script To start the Process Sentinels service using the SWDIR\bin\swstart.bat script: 1. Start the Process Sentinels using the command:
SWDIR\bin\swstart -p

2. Start the iProcess Engine server processes using the command:

SWDIR\bin\swstart

UNIX Version
In the UNIX version, the iProcess Engine functions are provided by the "worker" and "watcher" Process Sentinel processes. By default, once the Process Sentinels have started they will automatically start the iProcess Engine server processes. This behavior is controlled by the PM_AUTO_BOOT process attribute; only processes that have a PM_AUTO_BOOT value of 1 will be started automatically. See Administering Process Attributes on page 133 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

Starting the iProcess Engine 5

Starting the Process Sentinels You need to start the Process Sentinels on each server in your iProcess Engine. To start the Process Sentinels on a server: 1. Log in as the IPEBACKGROUND user. 2. Enter the command:
$SWDIR/bin/swstart -p

If you add this command to your UNIX start-up routine script the Process Sentinels will always be running on startup. Starting the Server Processes Use the $SWDIR/bin/swstart script to start all the required server processes. If you are using a node cluster, you can run this script from any server that is part of the node cluster and it will start all the processes on all of the servers in the iProcess Engine. To start the iProcess Engine server processes: 1. Log in as the IPEBACKGROUND user. 2. Enter the command:
$SWDIR/bin/swstart

As each server process is started, a start-up message is displayed.

TIBCO iProcess Engine Administrators Guide

Back to Library

| Chapter 1

Controlling the iProcess Engine

Stopping the iProcess Engine

The following sections explain how to stop the Windows (see below) and UNIX versions (see page 7) of the iProcess Engine.

Windows Version
The iProcess Engine functions are provided by the iProcess nodename Process Sentinels service (where nodename is the name of your iProcess Engine installation). You can stop the Process Sentinels service either:

using the SWDIR\bin\swstop.bat script - see page 7.

If you have installed the iProcess Engine to a Windows cluster, use the Take offline service in the Microsoft Cluster Administrator to stop the Process Sentinels service. Do not attempt to stop the Process Sentinels service on a Windows cluster using Control Panel > Services or the SWDIR\bin\swstop script. Manually Stopping the iProcess Engine To stop the iProcess Engine: 1. Make sure that all iProcess Workspace users are logged out from the iProcess Engine. 2. From the Start menu, click Settings > Control Panel. 3. Double-click Administration Tools. 4. Double-click Services.The Services dialog is displayed. 5. Select the iProcess nodename Process Sentinels service (where nodename is the name of your iProcess Engine installation). 6. Click Stop. This will stop the Process Sentinels service and the iProcess Engine server processes.

TIBCO iProcess Engine Administrators Guide

Back to Library

manually, from the Services dialog - see below.

Stopping the iProcess Engine 7

Using the swstop.bat Script To stop the iProcess Engine using the SWDIR\bin\swstop.bat script: 1. Make sure that all iProcess Workspace users are logged out from the iProcess Engine. If you cannot or do not want to do this for any reason, you can force the iProcess Engine to shut down even if users are still logged in. See Forcing the iProcess Engine to Shutdown on page 9 for more information. 2. Stop the iProcess Engine server processes using the command:
SWDIR\bin\swstop

3. Stop the Process Sentinels using the command:

SWDIR\bin\swstop -p

UNIX Version
To stop the iProcess Engine you must: 1. stop the server processes. 2. stop the Process Sentinels. Stopping the Server Processes Use the $SWDIR/bin/swstop script to stop all the required server processes. If you are using a node cluster, you can run this script from any server that is part of the node cluster and it will stop all the processes on all of the servers in the iProcess Engine. To stop the iProcess Engine server processes: 1. Log in as the IPEBACKGROUND user. 2. Make sure that all TIBCO iProcess Workspace users are logged out from the iProcess Engine. If you cannot or do not want to do this for any reason, you can force the iProcess Engine to shut down even if users are still logged in. See Forcing the iProcess Engine to Shutdown on page 9 for more information. 3. Enter the following command:
$SWDIR/bin/swstop

TIBCO iProcess Engine Administrators Guide

Back to Library

| Chapter 1

Controlling the iProcess Engine

A summary of the shutdown process is displayed as the processes are stopped an example is shown below.
Attempting to stop 17 processes Machine ID Proc Name 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 BG BG BG BG BGPREDICT DIRECTOR DLMGR IAPJMS RPCBG RPC_TCP_LI RPC_UDP_LI SPO WIS WIS WISMBD WISMBD WQS Proc Inst 1 2 3 4 1 1 1 1 1 1 1 1 1 2 1 2 1 Status SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN SHUTTING DOWN Comment Normal Shutdown Normal Shutdown Normal Shutdown Normal Shutdown Normal Shutdown Normal Shutdown main calling shutdown IAPJMS Process Shutdown Normal Shutdown RPC server shutdown RPC server shutdown Normal Shutdown Normal Shutdown Normal Shutdown WISMBD normal shutdown WISMBD normal shutdown WQS Normal shutdown

Current System Status : 'STOPPED'

Stopping the Process Sentinels You can also use the $SWDIR/bin/swstop script to stop the Process Sentinels. If you are using a node cluster, you can run this script from any server that is part of the node cluster and it will stop the Process Sentinels on all of the servers in the iProcess Engine. To stop the Process Sentinels: 1. Log in as the IPEBACKGROUND user. 2. Make sure that all TIBCO iProcess Workspace users are logged out from the iProcess Engine. If you cannot or do not want to do this for any reason, you can force the iProcess Engine to shut down even if users are still logged in. See Forcing the iProcess Engine to Shutdown on page 9 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

Stopping the iProcess Engine 9

3. Enter the following command:

$SWDIR/bin/swstop -p

which displays the following message:

Please wait, stopping process sentinels.

Forcing the iProcess Engine to Shutdown

Normally, when you want to shut down the iProcess Engine, you must first get all users to log out of the iProcess Suite.

Using the swstop command from a command prompt. See below. Using the swstop command from the Services dialog. See Enable Forced Shutdown from the Services dialog on page 10.

Using the swstop Command You can use the following command to force the iProcess Engine to shut down:
SWDIR\bin\swstop [-f [timeout]]

where: -f issues a forced shutdown event to shutdown the iProcess Engine processes, whether or not there are users logged in. timeout is the period, in seconds, to wait before shutting down the iProcess Engine. If timeout is omitted, a default timeout value of 300 (5 minutes) is used. If a subsequent swstop -f timeout command is issued before the first timeout value has expired, the timeout will be reset to the new value if the new timeout value is smaller. You cannot increase the timeout period - a larger timeout value will be ignored.

Note that: On a UNIX system, you must be logged in as the IPEBACKGROUND user to use this command. When the forced shutdown command is issued, a message is sent to all users informing them that the system will be stopped in timeout seconds. Make sure you save any changes to procedure definitions before enabling the forced shutdown otherwise any such changes will be lost.
TIBCO iProcess Engine Administrators Guide

Back to Library

However, you can force the iProcess Engine to shut down, even if there are users logged in. There are two ways you can do this:

10

| Chapter 1

Controlling the iProcess Engine

If any released work items have not been processed by the time the background processes shut down, these changes are queued and processed when the iProcess Engine restarts.

For example: The following command causes the iProcess Engine to shut down after the default delay of 300 seconds.
swstop -f

The following command causes the iProcess Engine to shut down after a delay of 3 minutes.
swstop -f 180

If this command is issued 1 minute after the previous example, the delay before shutdown will be reset to 30 seconds.
swstop -f 30

Enable Forced Shutdown from the Services dialog To force the iProcess Engine to shut down from the Services dialog, you must: Create a new string value called SERVICE_STOP_PARAMS in the Windows Registry and enter the swstop command as the string value data. See Creating the SERVICE_STOP_PARAMS String Value on page 11. Once you have created the SERVICE_STOP_PARAMS string value, when you stop the Process Sentinels from the Services dialog, the Process Sentinels are shut down using the swstop command with the parameters you specified. See Manually Stopping the iProcess Engine on page 6 for more information. To disable the forced shutdown from the Services dialog, either: delete the SERVICE_STOP_PARAMS string value from the Windows Registry, or delete the value data from the SERVICE_STOP_PARAMS string value in the Windows Registry.

TIBCO iProcess Engine Administrators Guide

Back to Library

Stopping the iProcess Engine 11

Creating the SERVICE_STOP_PARAMS String Value To create the SERVICE_STOP_PARAMS string value: 1. From the Start menu, click Run. The Run dialog is displayed. 2. In the Open: field, type regedit and click OK. The Registry Editor window is displayed. 3. Navigate to the registry list where the SERVICE_STOP_PARAMS string value is to be located, at: RegistryLocation\Staffware plc\Staffware Server\Nodes\nodename where: RegistryLocation is either \HKEY_LOCAL_MACHINE\SOFTWARE, if you are running the iProcess Engine on a 32-bit machine, or \HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node, if you are using a 64-bit machine. nodename is the name of the iProcess Engine installation. 4. From the Edit menu, click New > String Value. A new value called New Value #1 is created. 5. Right-click on New Value #1 and click Rename. Rename New Value #1 to SERVICE_STOP_PARAMS. 6. Right-click on SERVICE_STOP_PARAMS and click Modify. The Edit String dialog is displayed. 7. Enter the following value in the Value Data: box: swstop [-f [timeout]] [-n retries] where: -f issues a forced shutdown event to shutdown the iProcess Engine processes, whether or not there are users logged in. timeout (optional) is the period, in seconds, to wait before shutting down the iProcess Engine. If timeout is omitted, a default timeout value of 300 seconds (5 minutes) is used. The timeout value can be a numeric value between 0 - 7200. If a value less than 0 is entered, the default value of 300 seconds (5 minutes) is used. If a value greater than 7200 is entered, the value of 7200 seconds is used. -n retries (optional) is the maximum number of times the forced shutdown command will be retried, if required. The retries value can be a numeric value of 0 or greater. The re-issue of the forced shutdown command occurs if any of the processes have not shutdown. This overcomes the problem of

TIBCO iProcess Engine Administrators Guide

Back to Library

12

| Chapter 1

Controlling the iProcess Engine

an event being lost in the event system and the process not receiving the shutdown message. If all the processes have still not completely shutdown after the number of retries then a final forced shutdown is issued. If retries is omitted, (or if a value of less than 0 is entered), a default value of 0 is used. This means that a forced shutdown is issued after the timeout period and is not re-tried. Any processes that have not shutdown are forced to shutdown. If all the processes have still not completely shutdown after the final forced shutdown is issued because, for example, a process has hung, then these processes will have to be shutdown manually through the Task Manager or by restarting the machine that is hosting the iProcess Engine.

When the forced shutdown command is issued, a message is sent to all users informing them that the system will be stopped in timeout seconds. After 2 minutes, Microsoft Windows issues the following message: Could not stop the iProcess nodename Process Sentinels service on Local Computer. Error 1053: The service did not respond to the start or control request in a timely fashion where nodename is the name of your iProcess Engine installation. This is a warning only. Click OK, the Process Sentinels continue to shutdown.

Make sure you save any changes to procedure definitions before enabling the forced shutdown otherwise any such changes will be lost. If any released work items have not been processed by the time the background processes shut down, these changes are queued and processed when the iProcess Engine restarts.

TIBCO iProcess Engine Administrators Guide

Back to Library

Note that:

Configuring the iProcess Engine Events Server 13

Configuring the iProcess Engine Events Server

This section is only relevant if you are running the iProcess Engine on a Windows platform. The iProcess Engine uses a publish/subscribe event mechanism to handle the following inter-process tasks: notifying processes to update caches. synchronization of process startup and shutdown.

Events are handled by the Staffware Events COM+ application. All processes that want to subscribe to events register with the COM+ application.

RegistryLocation\Staffware plc\Staffware Server\Nodes\nodename\ IEL_EVENT_SERVER where: RegistryLocation is either \HKEY_LOCAL_MACHINE\SOFTWARE, if you are running the iProcess Engine on a 32-bit machine, or \HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node, if you are using a 64-bit machine. nodename is the name of the iProcess Engine installation.

If performance is or becomes an issue, TIBCO recommend that you dedicate one machine in the cluster, which is not running any iProcess Engine processes, to host the iProcess events. This reduces the load on the machine. To do this, you will need to edit the registry entry and change the nodename to the name of the new iProcess events server. You will need to restart the machine after doing this. Incorrectly editing the registry can severely damage your system. Make sure that you edit ONLY the indicated registry entry. Make sure that the Staffware Events application will start successfully on the new iProcess events server before starting the iProcess Engine, otherwise the system will not function correctly. On Windows Server 2003, the Staffware Events application does not run all the time. It shuts down automatically when it is idle, and restarts automatically when an event occurs.
TIBCO iProcess Engine Administrators Guide

Back to Library

The Staffware Events COM+ application is installed on the same machine as the iProcess Engine. If you are using a node cluster architecture, the event server is set to be the machine on which you installed the master server. The event server name is stored in the following registry key:

14

| Chapter 1

Controlling the iProcess Engine

Configuring the Time Zone for the iProcess Engine

An iProcess Engine that is installed on a server operating in one time zone may be accessed by TIBCO iProcess Workspace users who are operating in different time zones. For example, a companys office in California (Pacific Standard Time, GMT-08:00) may want to run cases of procedures that are hosted on a server running in the companys administrative centre in Washington D.C. (Eastern Standard Time, GMT-05:00). This will lead to a disparity between time stamps created by the server (which will use its local time) and their subsequent interpretation by the computers hosting the TIBCO iProcess Workspaces. This disparity will affect: work item time stamps audit trail time stamps deadline time stamps and processing priority escalation of work items date/time settings for participation and redirection.

To avoid this disparity, you can configure the iProcess Engine processes to operate in the same time zone as the clients. Note that: The time zone is set for ALL processes generated by the iProcess Engine. Different processes on the same iProcess Engine cannot use different time zones, even if they are running on different servers. To continue the example above, if the iProcess Engine is configured to run in Pacific Standard Time it can only administer sites in that time zone without discrepancy. If multiple iProcess Engines are running on the same physical hardware (which can be either a single node or a node cluster), each iProcess Engine can operate in its own designated time zone.

Setting the Time Zone

The time zone used by the iProcess Engine is stored using the TIMEZONE process attribute. Its value must be a valid time zone recognized by the operating system. See TIMEZONE on page 157. By default, the TIMEZONE attribute is not set, and the iProcess Engine uses the host servers local time.

TIBCO iProcess Engine Administrators Guide

Back to Library

Configuring the Time Zone for the iProcess Engine 15

You can set the value of TIMEZONE using the SWDIR\util\swadm utility. If you want to: see what time zone the iProcess Engine is currently operating in, use the SHOW_ALL_ATTRIBUTES command. See Display All Process Attributes on page 135. configure the iProcess Engine to operate in a different time zone, use the SET_ATTRIBUTE command. See Set a Process Attribute on page 136. reset the iProcess Engine to use the host servers local time, use the DELETE_ATTRIBUTE command. See Delete a Process Attribute on page 137.

Using swadm to change the time zone triggers an event informing the server processes that the time zone has changed; the iProcess Engine does not need to be restarted for the change to take effect.

TIBCO iProcess Engine Administrators Guide

Back to Library

16

| Chapter 1

Controlling the iProcess Engine

Error Handling
Most errors encountered by TIBCO iProcess Engine are reported directly to the user when they occur. Where this is not possible: a suitable error message is written to the SWDIR\logs\sw_warn or SWDIR\logs\sw_error file. a System Information message is sent to the IPEADMIN user, informing them that the file has been created.

See the TIBCO iProcess Engine System Messages guide for detailed information about the system error and warning messages that can be returned by the iProcess Engine in the SWDIR\logs\sw_warn and sw_error files. Each computer in a node cluster creates its own error files so you have to make sure to check each server for sw_error and sw_warn files. In all cases where a resolution cannot be achieved on site, contact TIBCO Support for further assistance.

TIBCO iProcess Engine Administrators Guide

Back to Library

| 17
Chapter 2

Using the iProcess Engine Configuration Files

This chapter describes various TIBCO iProcess Engine configuration files. Refer to Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters on page 41 for information about using the SWDIR\etc\staffcfg file to configure your iProcess Engine.

Topics
SWDIR\swdefs, page 18 SWDIR\etc\language.lng\staffico, page 19 SWDIR\etc\staffpms, page 22 SWDIR\etc\language.lng\audit.mes, page 32 SWDIR\etc\language.lng\auditusr.mes, page 33 SWDIR\etc\language.lng\stafferr.mes, page 34 SWDIR\etc\language.lng\staffw.mes, page 35 SWDIR\etc\language.lng\staff.mes, page 38 SWDIR\etc\swerwarn.mes, page 39

TIBCO iProcess Engine Administrators Guide

Back to Library

18

| Chapter 2

Using the iProcess Engine Configuration Files

SWDIR\swdefs
The SWDIR\swdefs file is the main system configuration file. The contents of this file are determined at installation time, and in general should not be changed. The following table describes the contents of the SWDIR\swdefs file. Line 1 2 3 4 Example i11.0-x(0.0) pro swadmin D:\swbkp (Windows) or \usr\swbkp (UNIX) 5 6 NULL swattach Description TIBCO iProcess Engine version Background (IPEBACKGROUND) user System administrator (IPEADMIN user) Path to backup directory. Note: This is not used by the TIBCO iProcess Engine. Not used Users' attachments subdirectory. Note: This is not used by the TIBCO iProcess Engine. 7 8 9 10 NULL staffw_nod1 English 391870 Reserved. Do not change this entry Nodename of this TIBCO iProcess Engine System default language Server\Server RPC service number Note: This is not used by the TIBCO iProcess Engine. 11 12 391875 3.0 Client\Server RPC service number Server\Server RPC version

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\language.lng\staffico 19

SWDIR\etc\language.lng\staffico
The SWDIR\etc\language.lng\staffico file specifies which tools are available to an iProcess user, depending on the value of their MENUNAME attribute. Tools are displayed in the Work Queue Manager, as items on the Tools menu and as toolbar buttons. If you want to modify the SWDIR\etc\language.lng\staffico file: 1. Log in as a user who (on Windows) is a member of the iProcess Administrators group or, (on UNIX) as user root. 2. Edit the file as required.

File Format
The file contains one section per defined MENUNAME attribute. Each section contains one entry per tool available for that MENUNAME. Lines that begin with a ; (semi-colon) character are treated as comments. Blank lines are ignored.
Section heading Tools entry The help and wqupdate entries are ignored in Work Queue Manager.

[admin] casestart=1,1,&Case Start audittrail=2,1,Case &Administration help=3,1,iProcess Help wqupdate=3,2,Update Queues procdefn=1,2,Process &Definer EXE,mainmenu.exe,NORM=2,2,Process Ad&ministrator

Tools are displayed in Work Queue Manager in the order that they are listed in the section.

TIBCO iProcess Engine Administrators Guide

Back to Library

The changes take effect when a user next logs in. (Users who are already logged in will need to log out and log back in again.)

20

| Chapter 2

Using the iProcess Engine Configuration Files

Tools Entry Format

Each tools entry has the following format: Tool_Definition=xpos,ypos,description where: Tool_Definition is one of the following: Tool Description Displays the Case Start dialog so that the user can start a case. Displays the Case Administration dialog, so that the user can perform administration tasks such as closing or purging cases and viewing audit trails of cases. Starts the TIBCO iProcess Modeler. Starts an executable program.exe. Note: By default, an EXE entry is provided to start the TIBCO iProcess Administrator (mainmenu.exe). Runs a caseless form for procedure procname and step stepname. Runs an EIS report for procedure procname and report EISobject. If the procname and EISobject parameters are omitted the Run EIS Report dialog is displayed, from which the user can choose an EIS report to run. SWIP Starts TIBCO iProcess Monitoring.

Tool_Definition CaseStart AuditTrail

ProcDefn EXE,program, NORM

RS,procname, stepname SWEIS[,procname, EISobject]

The Help and WQUpdate entries are no longer used.

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\language.lng\staffico 21

xpos, ypos defines the horizontal (column) and vertical (line) position of the icon in the Tools window. (1,1 is the top, left hand side of the window.) Co-ordinates outside the range 1-10 are ignored. The xpos and ypos parameters are ignored because the Tools window is no longer supported. Tools are listed in the Tools menu and button bar in the order that they are listed in the section.

description is the text that appears in the Tools menu and as button help in Work Queue Manager. description can be up to 40 characters long. Any text beyond this is truncated. The ampersand character (&) can be used to define a shortcut key for the tool. The character that follows the ampersand will appear underlined in the Tools menu. If you want to insert an actual ampersand character in the description, you must precede it with another ampersand character (&&).

TIBCO iProcess Engine Administrators Guide

Back to Library

22

| Chapter 2

Using the iProcess Engine Configuration Files

SWDIR\etc\staffpms
The SWDIR\etc\staffpms file specifies a number of different configuration options. The contents of this file are determined at installation time, and should NOT be changed other than as described in this section. To modify the SWDIR\etc\staffpms file: 1. Log in as a user who (on Windows) is a member of the iProcess Administrators group or, (on UNIX) as user root. 2. Edit the file as required. 3. Ask all users to log out of the iProcess Suite, then stop and restart the iProcess Engine.

Specifying if Client Passwords are Required on Login

Character 4 of line 4 specifies whether or not iProcess users need to give their password to log into this TIBCO iProcess Engine.
Y0NN5YNY??0A

If this character is: Y, iProcess users must supply their password when they log in to this TIBCO iProcess Engine. N, passwords are not required on login.

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\staffpms 23

Enabling Multiple Logins

Character 13 of line 4 specifies whether or not multiple logins to this TIBCO iProcess Engine are enabled.
Y0NN5YNY??0AYN

This character must be set to Y. Multiple logins must be enabled for the iProcess Engine to operate.

Specifying the Working Week

By default, all date calculations in iProcess use a 5-day working week of Monday to Friday. However, if a procedure has the Use working days flag un-set, a 7-day working week is used instead for cases of that procedure. The Use working days flag is set in the Procedure Manager, on the Status tab of the Properties dialog. For more information see Use Working Days Flag in the TIBCO iProcess Modeler - Procedure Management Guide. Line 5 ends with a 7-character string that defines the working week. There is one character for each day of the week, running from Sunday (on the left) to Saturday (on the right). Y indicates that the day is a working day, N indicates that it is a non-working day. The default entry specifies a working week of Monday to Friday, as shown below.
%2d\%2d\%4d\/\%s%s %s, %s\dmy\wdmy\%2d:%2d\:\ AM\ PM\Week\NYYYYYN

You can edit this string to change the specification of the working week that iProcess uses when calculating dates (for procedures which have the Use working days flag set). For example, to specify a 5 day working week of Sunday to Thursday, with Friday and Saturday being non-working days, change line 5 to:
%2d\%2d\%4d\/\%s%s %s, %s\dmy\wdmy\%2d:%2d\:\ AM\ PM\Week\YYYYYNN

To specify a six day working week of Monday to Saturday, with Sunday being a non-working day, change line 5 to read:
%2d\%2d\%4d\/\%s%s %s, %s\dmy\wdmy\%2d:%2d\:\ AM\ PM\Week\NYYYYYY

TIBCO iProcess Engine Administrators Guide

Back to Library

24

| Chapter 2

Using the iProcess Engine Configuration Files

Changing the Date Format Using the staffpms File

Line 5 of the SWDIR\etc\staffpms file determines how the date is displayed in the iProcess Engine. (The following example is for a iProcess Engine for Windows).
%2d/%2d/%4d\/\%s%s %s, %s\dmy\wdmy\%2d:%2d\:\ AM\ PM\Week\NYYYYYN

Individual entries are separated by a backslash character (\). The following table describes the meaning of each entry. Position 1 Example %2d/%2d/%4d Description The number of characters used to specify each component of the date. For example, 2 characters for day, 2 for month and 4 for year. The date delimiter. Not used. The order of the date format. Not used. The time format. The default is 24 hour format, for example 15:12. The time delimiter. Not used. Not used. Not used. The definition of the working week, running Sunday to Saturday. Y indicates a working day, N a non-working day. For example, Monday to Friday. See Specifying the Working Week on page 23.

2 3 4 5 6 7 8 9 10 11

/ %s%s %s, %s dmy wdmy %2d:%2d : AM PM Week NYYYYYN

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\staffpms 25

Changing the Order of the Date Format To change the format, for example, to yyyy/mm/dd: 1. Amend the date order entry (position 4) to be ymd. 2. Amend the number of characters entry (position 1) to be %4d/%2d/%2d.
%4d/%2d/%2d\/\%s%s %s, %s\ymd\wdmy\%2d:%2d\:\ AM\ PM\Week\NYYYYYN

Changing the Date Delimiter To change the date delimiter, for example to a hyphen character, amend the number of characters (position 1) and date delimiter (position 2) entries as shown.
%2d-%2d-%4d\-\%s%s %s, %s\dmy\wdmy\%2d:%2d\:\ AM\ PM\Week\NYYYYYN

Setting Database Connection Options

Line 9 contains the settings that the iProcess Engine uses to connect to the database. (The following example is for a TIBCO iProcess Engine for Windows).
3\swpro\swuser\swpro\\sw-servers\0

Individual entries are separated by a backslash character (\). The following table describes the meaning of each entry. Position 1 2 Example 3 swpro Description iProcess Engine type iProcess Engine database background user Notes This field must always be 3 for a database version. The name of the database login (for SQL Server or Oracle) or UNIX account (for DB2) that the iProcess Engine uses for background access to the iProcess Engine database schema. Note: This login/account must be the same login/account as the iProcess Engine database schema owner (specified in position 4).

TIBCO iProcess Engine Administrators Guide

Back to Library

26

| Chapter 2
Position 3

Using the iProcess Engine Configuration Files

Example swuser

Description iProcess Engine database user

Notes The name of the database login (for SQL Server or Oracle) or UNIX account (for DB2) that the iProcess Engine uses for other access to the iProcess Engine database schema. The name of the database login (for SQL Server or Oracle) or UNIX account (for DB2) that owns the iProcess Engine database schema. The Oracle TNS identifier that the iProcess Engine uses to connect to the Oracle instance holding the iProcess Engine database tables. This is the appropriate SERVICE_NAME entry in the ORACLE_HOME\network\admin\tnsnames.ora file). If a TNS identifier is not defined, the iProcess Engine will attempt to connect to the local Oracle instance, and Oracle Transparent Application Failover (TAF) will not be supported. Note: This entry is only used if the iProcess Engine uses an Oracle database.

swpro

iProcess Engine database schema owner Oracle database TNS identifier

null

sw-servers

ODBC Data Source (SQL) or Database Alias (DB2)

The name of the ODBC data source (for SQL Server) or Database Alias (for DB2) that the iProcess Engine uses to connect to the database. Note: This entry is not used if the iProcess Engine uses an Oracle database. This field is reserved for future use by the iProcess Engine.

Reserved

For more information about connecting to databases, refer to the appropriate iProcess Engine installation guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\staffpms 27

Changing Database Connection Passwords If you need to change the passwords that the iProcess Engine database schema owner or iProcess Engine database user use to connect to the database, follow this procedure: 1. Login as the IPEADMIN user. 2. Stop the iProcess Engine. 3. Enter the following command:
SWDIR\util\swconfig -u

The following prompt is displayed:

============================================================ TIBCO(R) iProcess Suite - Configuration Utility Copyright (c) 2001-2007, TIBCO Software Inc. ============================================================ Please enter a new Background User Password, ('Q' to quit) :

4. Enter the new password for the iProcess Engine database schema owner (the login/account defined in position 4 of line 9 of the SWDIR\etc\staffpms file). The following prompt is displayed.

Please enter a new Foreground User Password, ('Q' to quit) :

5. Enter the new password for the iProcess Engine database user (the login/account defined in position 3 of line 9 of the SWDIR\etc\staffpms file). The swconfig utility terminates and displays the following message.

Now log onto the Database and change the passwords

6. Change the corresponding passwords for these users in the database (for Oracle or SQL Server) or UNIX (for DB2). See your database/UNIX documentation for more information about how to do this. 7. Restart the iProcess Engine.

TIBCO iProcess Engine Administrators Guide

Back to Library

28

| Chapter 2

Using the iProcess Engine Configuration Files

Controlling Access to the iProcess Engine (for UNIX)

This section only applies to the UNIX version of the iProcess Engine. It is not relevant to the Windows version. Line 12 contains three settings (at the end of the line) that control access to the iProcess Engine.
1\GROUPNAME\0\666\swuser\staffwar\7

Individual entries are separated by a backslash character (\). The following table describes the meaning of each entry. Position 1 2 3 4 5 6 7 Example 1 GROUPNAME 1 666 swuser staffwar 7 Description Reserved for internal use - do not change. Reserved for internal use - do not change. Reserved for internal use - do not change. Reserved for internal use - do not change. The iProcess RPC Server account name. The default value is swuser. The iProcess group name. The default value is staffwar. The iProcess security umask value, which controls world access to iProcess files in and under $SWDIR. World permissions on each file installed by or created by the iProcess Suite are set to the iProcess group name permissions for the file, modified by this umask value. For example, if this value is: 7 for high security. World has no access to iProcess files in and under $SWDIR. This is the default. 0 for low security. World has the same access to each file in and under $SWDIR as the staffwar group.

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\staffpms 29

To change the iProcess RPC Server account name, iProcess group name, or iProcess security umask value at any time after installation, do the following: 1. Log in as the IPEBACKGROUND user. 2. Stop the iProcess Engine (if it is running). 3. Change the appropriate value on line 12 of the $SWDIR/etc/staffpms file. 4. Run $SWDIR/bin/fixperms to reset the ownership and permissions information on all files in and under $SWDIR. 5. Restart the iProcess Engine. The implications of these security values in $SWDIR/etc/staffpms are: You must be logged in as the IPEBACKGROUND user to start or stop the iProcess Engine. See Starting the iProcess Engine on page 2. All iProcess processes run with the UID of the IPEBACKGROUND user, even if the process is started by root. The only exceptions are the $SWDIR/util/runcmd utility and the RPC_UDP_LI process, which run as root. All iProcess files and directories (that is, all files in and under $SWDIR) are owned by either root or the IPEBACKGROUND user. Their group ID is set to the iProcess group (staffwar). World access to iProcess files and directories is restricted. On a new installation, world has no access (security umask is set to 7). All iProcess users who need access to iProcess files and directories must be members of the iProcess group (staffwar). For example, users who need to run $SWDIR/bin/swutil, or to use SERVERRUN commands that access files under $SWDIR.

Specifying How iProcess Validates Users

Lines 15 and 16 of the SWDIR\etc\staffpms file define whether and how iProcess uses the integral User Validation API provided with the LDAPCONF utility. Specifying an External User Validation Package Line 15 defines whether the iProcess Suite validates users against O/S user accounts (the default), or against an external validation package developed using the TIBCO iProcess User Validation API. This line is optional. If you are using the default method of validating users against O/S accounts, line 15 should be blank.

TIBCO iProcess Engine Administrators Guide

Back to Library

30

| Chapter 2

Using the iProcess Engine Configuration Files

If you want to validate users against an external validation package, line 15 must contain the full pathname of the user validation package (a DLL file on Windows, a shared library on UNIX). Note that: The pathname must contain a leading drive letter and UNIX style separators (/). Variables such as $SWDIR are not supported in this parameter.

The following example (for a iProcess Engine for Windows) specifies that user validation will be performed against the swuvamod.dll file in the d:/iProcess/staff200/lib directory.
d:/iProcess/staff200/lib/swuvamod.dll

C:/Tibco/iprocess_nod1/util/UVAPI.dll\N\swadmin\\\

For more information about how to: develop an external validation package, refer to the TIBCO iProcess User Validation API: User's Guide. install an external validation package, refer to the installation guide for the TIBCO iProcess User Validation API. use the integral user validation API provided with LDAPCONF, see the LDAPCONF Utility Users Guide.

Specifying a Proxy User Line 16 defines which proxy operating system user ID is used by the LDAP integral user validation API. This line applies only to UNIX and Linux systems.

This line is optional. If you are not using the LDAP integral user validation API, line 16 should be blank.

TIBCO iProcess Engine Administrators Guide

Back to Library

The following example specifies that user validation will be performed against the UVAPI.dll file in the C:/Tibco/iprocess_nod1/util directory; and that the proxy users are supplied by swadmin.

SWDIR\etc\staffpms 31

Configure Signals That Threads are Blocked From Receiving

Line 17 allows you to specify threads to be blocked from receiving signals. For example, to add blocking for the SIGALRM (14) signal the last few lines of the file will look like this:
QPARAM1\QPARAM2\QPARAM3\QPARAM4\CP_V... <blank line - unless UVAPI is configured> <blank line> 14

If you wish to add more signals to the list they will need to be separated by the '\' character:
QPARAM1\QPARAM2\QPARAM3\QPARAM4\CP_V... <blank line - unless UVAPI is configured>

14\13\12\\

If the line is blank or there are no signal IDs set then the default behaviour is not to block the threads from receiving signals.

TIBCO iProcess Engine Administrators Guide

Back to Library

<blank line>

32

| Chapter 2

Using the iProcess Engine Configuration Files

SWDIR\etc\language.lng\audit.mes
This file contains the system-defined audit trail messages. These are added to the audit trail by the system each time an action of some sort is performed on the step in the case. These messages are pre-defined in SWDIR\etc\language.lng\audit.mes. Each message has a three-digit number that is the message ID of the audit trail message. The system reserves Message IDs 000-255 for system use. Refer to Understanding Audit Trails on page 389 for an explanation of the system-defined messages and what they mean.

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\language.lng\auditusr.mes 33

SWDIR\etc\language.lng\auditusr.mes
This file contains the user-defined audit trail messages. You must predefine these messages in SWDIR\etc\language.lng\auditusr.mes. Once, you have predefined the audit trail messages, they can be added to the audit trail of a live case. You can use the SWDIR\bin\swutil AUDIT command to add a message to an audit trail of a live case. For information about adding user-defined audit entries, see Audit Trails in the TIBCO iProcess swutil and swbatch: Reference Guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

34

| Chapter 2

Using the iProcess Engine Configuration Files

SWDIR\etc\language.lng\stafferr.mes
This file contains the messages used by the $SYSTEM procedure. The $SYSTEM procedure sends a work item to the IPEADMIN users work queue when SWDIR\logs\sw_warn or sw_error files have been generated, warning the system administrator that an error has occurred.

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\etc\language.lng\staffw.mes 35

SWDIR\etc\language.lng\staffw.mes
This file contains some configurable messages that affect how the long date is displayed in the TIBCO iProcess Workspace.

Changing the Long Date Format

For information on using the long date and time format in an iProcess step definition, see Using Embedded and Ampersanded Fields in the TIBCO iProcess Modeler - Basic Design Guide. The SWDIR\etc\language.lng\staffw.mes file determines how the long date is displayed by the iProcess Workspace. The long date information is returned from the SWDIR\etc\language.lng\staffw.mes file instead of the SWDIR\etc\staffpms file because it enables different users on the same system to have different long date displays depending on their LANGUAGE attribute. Refer to Setting Pre-defined Attributes in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information about how to set a users LANGUAGE attribute. To ensure the date is displayed consistently in both the TIBCO iProcess Workspace and the iProcess Engine, the information in the SWDIR\etc\language.lng\staffw.mes and SWDIR\etc\language.lng\staff.mes file must be the same. This means that any changes must be made in both files. The following example is an extract from the SWDIR\etc\language.lng\staffw.mes file:
0004:W:\\%s %s, %s\\dmy\\\ AM\ PM\Week 0013:W:Sunday\Monday\Tuesday\Wednesday\Thursday\Friday\Saturday$ 0014:W:January\February\March\April\May\June\July\August\September \October\November\December

The file is divided into one message per line. The messages that determine how the long date is displayed are: 0004 specifies each component of the long date. 0013 specifies the days of the week. 0014 specifies the months of the year.

TIBCO iProcess Engine Administrators Guide

Back to Library

36

| Chapter 2

Using the iProcess Engine Configuration Files

Each message is in the format: number:type:data where: number is the identifier for this message. For example, 0004. type is either W, indicating that the message is used by the TIBCO iProcess Workspace, or blank, indicating that the message is used by the iProcess Engine. data is one or more data entries associated with this message. If there are multiple data entries, each entry is separated by a backslash (\) character.

For example, the following table describes the data entries for message 0004.

1 2 3 %s %s, %s

Not used. Not used. The number of components used to specify each part of the long date format. Each component represents the date, month and year. For example, 10 March, 2004. Not used. dmy The order of the date format. Not used. Not used. AM PM Week Used for 12 hr time format. For example, 09:10 AM. Used for 12 hr time format. For example, 03:12 PM. Not used.

4 5 6 7 8 9 10

To change the long date format, for example, to Wednesday 12 Dec, 2012:

TIBCO iProcess Engine Administrators Guide

Back to Library

Position

Data

Description

SWDIR\etc\language.lng\staffw.mes 37

1. Edit message 0004 of the SWDIR\etc\language.lng\staff.mes file as follows: a. Add %s to position 3 to represent the day of the week, as shown below. b. Add w to position 5 to represent the day of the week, as shown below. c. Edit message 0014 to use short month names rather than long ones. For example, Dec instead of December.
0004:W:\\%s %s %s, %s\\wdmy\\\ AM\ PM\Week 0013:W:Sunday\Monday\Tuesday\Wednesday\Thursday\Friday\Saturday$ 0014:W:Jan\Feb\Mar\Apr\May\Jun\Jul\Aug\Sept\Oct\Nov\Dec

TIBCO iProcess Engine Administrators Guide

Back to Library

2. Replicate the changes made in the SWDIR\etc\language.lng\staffw.mes file in the SWDIR\etc\language.lng\staff.mes file.

38

| Chapter 2

Using the iProcess Engine Configuration Files

SWDIR\etc\language.lng\staff.mes
This file contains some configurable messages and options that are used by some of the iProcess Engine programs, for example, the iProcess Background.

Changing the Long Date Format

To ensure the date is displayed consistently in both the TIBCO iProcess Workspace and the iProcess Engine, the information in the SWDIR\etc\language.lng\staffw.mes and SWDIR\etc\language.lng\staff.mes file must be the same. This means that any changes must be made in both files.

To see how to amend the format of the long date in the SWDIR\etc\language.lng\staff.mes, see SWDIR\etc\language.lng\staffw.mes on page 35.

TIBCO iProcess Engine Administrators Guide

Back to Library

The format of the SWDIR\etc\language.lng\staff.mes file is divided into messages in the same way as the SWDIR\etc\language.lng\staffw.mes file.

SWDIR\etc\swerwarn.mes 39

SWDIR\etc\swerwarn.mes
This file contains the templates for the messages that are written to the SWDIR\logs\sw_warn and SWDIR\logs\sw_error files.

TIBCO iProcess Engine Administrators Guide

Back to Library

40

| Chapter 2

Using the iProcess Engine Configuration Files

TIBCO iProcess Engine Administrators Guide

Back to Library

| 41
Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

This chapter describes all of the parameters that you can use in the iProcess Engine SWDIR\etc\staffcfg configuration file to optimize iProcesss performance for your particular requirements. The parameters all relate to memory and process configuration information.

Topics
Editing the SWDIR\etc\staffcfg File, page 42 WQS Section, page 44 FORM Section, page 52 STAFFPRO Section, page 55 STAFF Section, page 63 DBSIZES Section, page 76 DBPOOL Section, page 78 CDQP Section, page 83 Obsolete Parameters, page 86

TIBCO iProcess Engine Administrators Guide

Back to Library

42

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

Editing the SWDIR\etc\staffcfg File

The default file contains a number of parameters most of which define the limits within which the iProcess Suite is initially setup to work. There are also a number of other parameters which, when tuned, can give significant improvements in both performance and response. You should be extremely careful when editing the SWDIR\etc\staffcfg file. Careless changes can have a serious impact on system operation or performance. If you are in any doubt about whether or not to edit a specific parameter, please contact TIBCO Support for assistance. If you want to add, remove or update parameters in the SWDIR\etc\staffcfg file:

2. Edit the file as required. 3. If necessary, ask all users to log out of the iProcess Suite, then stop and restart the server.

SWDIR\etc\staffcfg File Format

The SWDIR\etc\staffcfg file is an ASCII file containing a number of lines, divided into functional sections: Each section is headed by the section name at the start of a line, followed by a number of configuration lines. Each configuration line starts with a TAB character followed by the configuration name (e.g. MAXCASES), followed by a comma (,) followed by the configuration value. Anything from a semicolon (;) to the end of the line is treated as a comment and ignored.

Using Multiple Copies of SWDIR\etc\staffcfg

You can use different copies of the SWDIR\etc\staffcfg file to optimize performance. For example, you can create one version which is optimized for batch processing, to be used at night, and another version which is optimized for user interaction, to be used during the day. You can then change the iProcess Suites configuration by using batch files to:

TIBCO iProcess Engine Administrators Guide

Back to Library

1. Log in as a user who (on Windows) is a member of the iProcess Administrators group or, (on UNIX) as user root.

Editing the SWDIR\etc\staffcfg File 43

1. Stop the server using the SWDIR\bin\swstop command - see Stopping the iProcess Engine on page 6. You do not need to shut down the Process Sentinels.

2. Copy the appropriate version of the staffcfg file to the SWDIR\etc directory. 3. Re-start the server - see Starting the iProcess Engine on page 2.

SWDIR\etc\staffcfg Parameters Back to Library

The remaining sections in this chapter describe all of the SWDIR\etc\staffcfg parameters. Each section of the staffcfg has a corresponding section in this chapter, as follows: WQS Section FORM Section STAFFPRO Section STAFF Section DBSIZES Section DBPOOL Section CDQP Section

TIBCO iProcess Engine Administrators Guide

44

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

WQS Section
This section is used to configure the behavior of the work queue services. The following parameters are available: WQS_DEFAULTPRIORITY WQS_URGENTPRIORITY WQS_ROUND_ROBIN WIS_MAXFILEDESC WQS_QUEUE_WEIGHTING WQS_SHARED_MEMORY_QUEUES WIS_AGE_USE_WORKING_DAYS

TIBCO iProcess Engine Administrators Guide

Back to Library

WQS_DEFAULTPRIORITY 45

WQS_DEFAULTPRIORITY
Section Initial Value Units Range Description

WQS 50 N/A 0 to 32767 Sets the default priority level for a new work item, if not already set. For more information about this parameter, refer to Using Work Item Priorities and Escalation in the TIBCO iProcess Modeler - Advanced Design Guide. Work items can have priorities so that they can be sorted/filtered, etc. by priority level. You need to decide how your system will use priority levels and then decide upon a sensible default. None.

Tuning

Related Parameters

TIBCO iProcess Engine Administrators Guide

Back to Library

46

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

WQS_URGENTPRIORITY
Section Initial Value Units Range Description

WQS 10 N/A 0 to 32767 Sets the default Urgent Priority level for a new work item, if not already set. For more information about this parameter, refer to Using Work Item Priorities and Escalation in the TIBCO iProcess Modeler - Advanced Design Guide. N/A.

Tuning

TIBCO iProcess Engine Administrators Guide

Back to Library

WQS_ROUND_ROBIN 47

WQS_ROUND_ROBIN
Section Default Value Units Range Description

WQS 0 N/A 0 (use on-demand) or 1 (use round-robin) The Work Queue Server is responsible for the assignment of work queues to WIS processes. There are 2 methods it can use, either round-robin or on-demand.

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

This parameter configures which of the methods is used for the queue allocation. See Configuring the Assignment of Queues to WIS Processes on page 345 for more information about the use of each method.

48

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

WIS_MAXFILEDESC
Section Initial Value Units Range Description

WQS 0 N/A >0 The work item server process uses the select system call when waiting for client requests. It passes this the NOFILE/MAXFILES kernel parameter to receive as many clients as possible. This can cause a problem if this number is greater than FD_SETSIZE. If this happens, WIS_MAXFILEDESC can be set to a number greater than 0 but less than FD_SETSIZE.

TIBCO iProcess Engine Administrators Guide

Back to Library

WQS_QUEUE_WEIGHTING 49

WQS_QUEUE_WEIGHTING
Section Initial Value Units Range Description

WQS 5 N/A >0 When using the on-demand queue allocation method, queues are allocated to Work Item Server (WIS) processes based on the cost of the work queue. The WQS_QUEUE_WEIGHTING parameter determines the cost of the work queues. See Configuring the Assignment of Queues to WIS Processes on page 345 for more information about the on-demand queue allocation method. This setting enables you to have some control about how work queues are allocated to WIS processes. For example, the larger the value, the more that the number of work queues rather than the number of work items in the work queues determines whether a work queue is allocated to a WIS process. Therefore, if you have lots of work queues with an even amount of work items in each, you may want to increase the value of the WQS_QUEUE_WEIGHTING parameter. If you only have a few work queues that contain large amounts of work items, you may want to lower the value.

Tuning

TIBCO iProcess Engine Administrators Guide

Back to Library

50

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

WQS_SHARED_MEMORY_QUEUES
Section Initial Value Units Range Description

WQS 1000 N/A >0 Specifies the minimum amount of shared memory to be allocated when the WQS process starts up.

the WQS_SHARED_MEMORY_QUEUES value. the number of user and group queues defined on the system.

You must ensure that your system has enough shared memory configured for the WQS process to allocate. If it does not, the WQS process will be unable to start. Depending on the number of queues you have defined, this value will therefore be at least: (WQS_SHARED_MEMORY_QUEUES * 2 )* 1.2K For example, if WQS_SHARED_MEMORY_QUEUES is 1000, and the number of queues defined on the system is 1250, then the WQS process will allocate 3000K of shared memory (1250*2*1.2). Your system must have at least 3000K of shared memory available for the WQS process. Please refer to your operating system documentation for information about how to configure shared memory on your system.

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

Because shared memory cannot be resized, the WQS process must allocate a fixed amount of shared memory when it starts up; it allocates shared memory equal to twice whichever of the following values is greater:

WIS_AGE_USE_WORKING_DAYS 51

WIS_AGE_USE_WORKING_DAYS
Section Initial Value Units Range Description

WQS 0 N/A 0 or 1 Defines whether or not iProcess will escalate a work items priority when its increment period expires. If the value is:

1, a work items priority will only escalate if the current date/time is defined as a working day (in the SWDIR\etc\staffpms file). Note that this value only affects procedures that have the Use Working Days flag set in the TIBCO iProcess Modeler.

For example, suppose that: on a Friday morning, a work item has a priority value of 10. its increment period is 1 day, and this period expires at 5pm each day. the working week is defined in the SWDIR\etc\staffpms file as Monday to Friday.

On the following Monday morning, the work items priority value will therefore be: 9, if WIS_AGE_USE_WORKING_DAYS is set to 1 and the procedures Use Working Days flag is set. (The priority value is incremented when the increment period expires on Friday, but is not incremented when it expires on Saturday and Sunday.) 7, for any other combination of these settings. (The priority value is incremented when the increment period expires on Friday, Saturday and Sunday.)

TIBCO iProcess Engine Administrators Guide

Back to Library

0, a work items priority will always escalate when its increment period expires, whether the current date/time is a working day or a non-working day (as defined in the SWDIR\etc\staffpms file - see page 22).

52

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

FORM Section
This section enables you to configure TIBCO iProcess Engine form parameters. Changes made to this section take effect after you log out of iProcess and then back in again. The following parameters are available: MAX_SCRIPT_CALL_DEPTH

MAXVLD

TIBCO iProcess Engine Administrators Guide

Back to Library

MAX_SCRIPT_CALL_DEPTH 53

MAX_SCRIPT_CALL_DEPTH
Section Initial Value Units Range Description

FORM 10 N/A >0 Defines the maximum recursive depth for calling scripts from scripts. The default is 10 which means that you can call out recursively up to 10 scripts. Therefore, if you have 10 scripts (script1, script2 etc) you can use the CALL expression in script1 to call script2 and script2 can call script3 and so on up to script10. Refer to Creating Scripts in the TIBCO iProcess Modeler - Advanced Design Guide for more information about using scripts.

Tuning

N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

54

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

MAXVLD
Section Initial Value Units Range Description

FORM 50 N/A >0 The maximum number of validations that are added to a validations list with the VLDFILE or VLDQUERY functions.

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

N/A.

STAFFPRO Section 55

STAFFPRO Section
This section enables you to configure TIBCO iProcess Engine server processes and performance parameters. You need to stop and restart the server before any changes are applied. The following parameters are available: LDAP_DIT LDAP_POOL_SIZE MODTIME_PERM PROCDEF_CACHESIZE

LAST_MODIFIED_TIME

TIBCO iProcess Engine Administrators Guide

Back to Library

RESEND_ORIGINAL_TIMESTAMP

56

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

LDAP_DIT
In previous iProcess Engine versions this parameter was called X500_DIT. If you upgrade from a pre-Version 10.2.0 iProcess Engine, the X500_DIT parameter is left in the staffcfg file, and can be manually deleted if required.
Section Initial Value Units Range Description

STAFFPRO 0 N/A 0 or 1 Defines whether or not to obtain iProcess user data from an LDAP Directory information Tree (DIT): 0 - iProcess user data is held internally. 1 - obtain iProcess user data from an LDAP DIT.

TIBCO iProcess Engine Administrators Guide

Back to Library

LDAP_POOL_SIZE 57

LDAP_POOL_SIZE
Section Initial Value Units Range Description

STAFFPRO 10 Connections >0 This parameter specifies the LDAP connection pool size. It only applies if LDAP_DIT is set to 1.

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

N/A.

58

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

MODTIME_PERM
Section Initial Value Units Range Description

STAFFPRO 0 N/A 0 or 1 When you use LDAPCONF with Active Directory, the modified timestamp is returned with either a Z or 0Z at the end of the string depending on the version of Active Directory. A value of:

1 means use a '.0Z' terminator for search.

TIBCO iProcess Engine Administrators Guide

Back to Library

0 means use a 'Z' terminator for search.

PROCDEF_CACHESIZE 59

PROCDEF_CACHESIZE
Section Initial Value Units Range Description Tuning

STAFFPRO 5 NA 2-1000 The number of procedure definitions to cache on the server computer. This value does not need to be larger than the number of procedures on your system.

TIBCO iProcess Engine Administrators Guide

Back to Library

60

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

LID_CLIENT_TIMEOUT
Section Initial Value Units Range Description

STAFFPRO 60 Seconds >0 The time that the iProcess Workspace is not allowed to update the sww.uid file before being assumed to have logged out. This is to allow users to log back in from iProcess Workspaces after an abnormal iProcess Workspace shutdown. N/A. UIDCRPERIOD.

Tuning Related Parameters

TIBCO iProcess Engine Administrators Guide

Back to Library

RESEND_ORIGINAL_TIMESTAMP 61

RESEND_ORIGINAL_TIMESTAMP
Section Initial Value Units Range Description

STAFFPRO 0 N/A 0 or 1 Sets the timestamp to be used for the Arrival Time of a work item when a resend is performed on a client queue: 0 means that the current timestamp (of the RESEND) is used. 1 means that the original timestamp (when the item was added to the queue) is used.

If this parameter is not present, the system defaults to the current timestamp (0).

Tuning

N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

62

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

LAST_MODIFIED_TIME
Section Initial Value Units Range Description

STAFFPRO 0 N/A 0 or 1 By default, when LDAPCONF performs a partial synchronization, it checks the LDAP ModifyTimeStamp attribute to determine whether an entry has been modified since the last update (and so needs to be downloaded to iProcess). However, some LDAP Admin applications modify this attribute when handling user logons and authentication, which means that LDAPCONF cannot use it in this way. You can therefore use the LDAP lastModifiedTime attribute instead, with LDAP servers that require it. The LAST_MODIFIED_TIME parameter defines which LDAP attribute LDAPCONF should check when performing a partial synchronization: 0 means that LDAPCONF checks the LDAP ModifyTimeStamp attribute to determine whether an entry has been modified since the last update. 1 means that LDAPCONF checks the LDAP lastModifiedTime attribute to determine whether an entry has been modified since the last update.

This parameter is not present by default. You must add it if required. If this parameter is not present, the system defaults to using the LDAP ModifyTimeStamp attribute (0).
Tuning

N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

STAFF Section 63

STAFF Section
This section enables you to configure the behavior of TIBCO iProcess Workspace. You have to stop and restart the server before any changes will take effect. The following parameters are available: UIDCRPERIOD RPCSVR_TIMEOUT PWD_PERIOD START_TX_RX RPCXFRSIZE MAX_USERS_PER_PROCESS PRE_LOAD_POOL_SERVERS USER_LOAD_ALLOCATION WQ_SORT_ITEM DYNDEADPRED IAPSCHEMA

TIBCO iProcess Engine Administrators Guide

Back to Library

64

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

UIDCRPERIOD
Section Initial Value Units Range Description Related Parameters

STAFF 30 Seconds >0 Defines the amount of time between a windows foreground login refresh. LID_CLIENT_TIMEOUT.

TIBCO iProcess Engine Administrators Guide

Back to Library

RPCSVR_TIMEOUT 65

RPCSVR_TIMEOUT
Section Initial Value Units Range Description

STAFF 600 Seconds >0 This parameter defines the period of time an RPC server connection exists without being used.

Tuning

There is generally no need to change this parameter as there should not be any need for it to come into effect. The downside of having it set to a long period (such as an hour) is that if a single machine is switched off with iProcess running, then the RPC server will not shutdown until after that period.

TIBCO iProcess Engine Administrators Guide

Back to Library

TIBCO iProcess Workspace will poll the RPC server (swrpcsvr) on a regular basis to keep it's connection alive. If the connection is lost for any reason, such as abnormal termination of the client, then the RPC server will wait for RPCSVR_TIMEOUT seconds without receiving a request before shutting down.

66

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

PWD_PERIOD
Section Initial Value Units Range Description Tuning

STAFF 15 Minutes >0 Defines the time interval between passwords being cached on clients. Reducing this value means that iProcess can detect changes in users passwords made outside of iProcess more quickly. However, it can mean that iProcess checks for user password changes more frequently causing a degradation in performance.

TIBCO iProcess Engine Administrators Guide

Back to Library

START_TX_RX 67

START_TX_RX
Section Initial Value Units Range Description Tuning

STAFF 0 N/A 1 or 0 Defines whether or not to start (1) server-to-server processes. None.

TIBCO iProcess Engine Administrators Guide

Back to Library

68

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

RPCXFRSIZE
Section Initial Value Units Range Description

STAFF 4096 Bytes 512, 1024, 2048, 4096 This setting determines the maximum buffer size used for client/server communication of stream data. This setting is primarily used when reading text files, forms or memos from the server or for copying files down to the client.

Adjusting this value enables you to tune the size and number of packets sent over the network.
Tuning

When considering network performance, particularly over a WAN, it is important to consider the number and size of requests being made over the network. Any tuning of this parameter needs to take into account the characteristics of the network, in general increasing the size of this parameter to 4096 will reduce the number of network requests and therefore reduce the latency inherent in waiting for a request to be responded to. There may be circumstances on a busy WAN where sending large packets is blocking other requests and therefore causing poor response for other users. In most cases, network performance problems in iProcess are not caused by the amount of data being transferred but the number of packets being sent. Therefore by increasing the value of RPCXFRSIZE many RPC calls can pass more data than before and therefore less calls are made. Even on a LAN a single RPC round trip can take 25ms irrespective of the size of the packet, i.e. 20 bytes or 4K, therefore 200 RPC calls are likely to take 5 seconds. If by increasing the packet size only 50 RPC calls are made then the total time come down to 1.25 secs. Example A procedure does a FileCopy from server to client of a 2Mb file. Results With RPCXFRSIZE=1024 time to copy 2Mb to Client = 15 Sec

TIBCO iProcess Engine Administrators Guide

Back to Library

As a significant amount of data needs to be read at login time increasing the size of this parameter can have benefits to login time on large systems, particularly over WANs.

RPCXFRSIZE 69

with RPCXFRSIZE=4095 time to copy 2Mb to Client = 8.5 Sec

While this is a large file and not necessarily a typical operation, you can see there are some benefits.

TIBCO iProcess Engine Administrators Guide

Back to Library

70

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

MAX_USERS_PER_PROCESS
Section Initial Value Units Range Description

STAFF 20 Users >1 Defines the number of users allocated to each RPC pool server. The iProcess Suite allocates users to the RPC pool servers, which have been started (or pre-loaded if you use PRE_LOAD_POOL_SERVERS), on a round robin basis by default. A new RPC server is started when there are no more allocated slots in the RPC servers currently running. For example, where there are 8 RPC pool servers pre-loaded and 8 users logged on, you could have each person connected to a different RPC pool server.

Tuning

N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

PRE_LOAD_POOL_SERVERS 71

PRE_LOAD_POOL_SERVERS
Section Initial Value Units Range Description

STAFF 0 RPC pool servers -1, 0 or any positive integer Defines the number of RPC pool servers that you want to pre-load during the iProcess startup process.

If you set the value to -1, the RPC server calculates the number of RPC pool servers to start up. The RPC server calculates this number using the MAX_USERS_PER_PROCESS value and the number of users held in the iProcess Engine. For example, if there are 800 users and MAX_USERS_PER_PROCESS is set to 40, then 20 RPC pool servers will be started. If the value is set to 0, pool servers are started up on demand as users log in. This can slow the login process because users have to wait for the processes to be started. Each client login will be assigned to one of the RPC pool servers.
Related Parameters

MAX_USERS_PER_PROCESS.

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

Setting this to a positive value results in that number of pool servers being started.

72

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

USER_LOAD_ALLOCATION
Section Initial Value Units Range Description Tuning

STAFF 0 N/A 0 or 1 Defines the process by which client connections are allocated to RPC pool servers. When set to the default value of 0, client login requests are allocated using a round robin method where each client login is allocated to the next RPC pool server. When set to 1, client requests are allocated to RPC pool servers by finding the pool server that has the least number of client connections. If all pool servers are full, a new process is created for the client request.

TIBCO iProcess Engine Administrators Guide

Back to Library

WQ_SORT_ITEM 73

WQ_SORT_ITEM
Section Initial Value Units Range Description

STAFF 0 N/A 0 or 1 Defines whether the folders in the work queues list of the Work Queue Manager are sorted by Queue Name or Queue Description.

When set to 1, the list of work queues is sorted by Queue Description. Note that upper-case letters appear first after sorting, so the following descriptions: Manager1 allenb Administrator richardH paulap would appear sorted as follows: Administrator Manager1 allenb paulap richardH

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

When set to the default value of 0, or when not present in the staffcfg file, the list of work queues are sorted by Queue Name.

74

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

DYNDEADPRED
Section Initial Value Units Range Description Tuning

STAFF 1 N/A 0 or 1 Defines how the predicted step duration is to be calculated. If the value is 1, then if the 'Use Deadline for Step Duration' flag is set then use the deadline as the predicted duration, otherwise, use either the configured duration or the deadline depending on which would elapse first. For example, if the deadline was set to expire in one hour and the duration was set to three hours then the deadline would be used for the predicted duration. Conversely if the deadline was set to expire in three hours and the duration was set to one hour then the duration would be used for the predicted duration. If the value is 0, then if the 'Use Deadline for Step Duration' flag is set then use the deadline as the predicted duration, otherwise use the configured duration for the predicted duration.

TIBCO iProcess Engine Administrators Guide

Back to Library

IAPSCHEMA 75

IAPSCHEMA
Section Initial Value Units Range Description

STAFF 0 N/A 0 or 1 This parameter controls whether messages generated by the IAPJMS process should be produced in the basic format or in the extended format that includes information on the audit user and addressee of the step, and the main procedure of a sub-case: 0 means that messages should be in basic format 1 means that messages should be in extended format

See Activity Monitoring and Work Queue Delta Configuration on page 236 and "Monitoring Activities" in the TIBCO iProcess Engine Architecture Guide for more information about IAPJMS.
Tuning

N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

76

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

DBSIZES Section
This section enables you to specify the size of certain items in the database. Changes are applied only after stopping and restarting the server. The following parameter is the only one available: MEMOATTMAX

TIBCO iProcess Engine Administrators Guide

Back to Library

MEMOATTMAX 77

MEMOATTMAX
Section Initial Value Units Range Description Tuning

DBSIZES 64000 Bytes NA Maximum size of Memos and Attachments. N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

78

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

DBPOOL Section
This section enables you to configure database connection pool parameters. You have to stop and restart an iProcess process before any changes take effect in that process. The following parameters are available: POOLSIZE POOLGROWSIZE MAXPOOLSIZE POOLCONNTIMEOUT

TIBCO iProcess Engine Administrators Guide

Back to Library

POOLSIZE 79

POOLSIZE
Section Initial Value Units Range Description Tuning

DBPOOL 1 Database connections >0 Defines the initial size of the database connection pool. N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

80

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

POOLGROWSIZE
Section Initial Value Units Range Description Tuning

DBPOOL 2 Database connections >0 The size by which to grow the database connection pool. N/A.

TIBCO iProcess Engine Administrators Guide

Back to Library

MAXPOOLSIZE 81

MAXPOOLSIZE
Section Initial Value Units Range Description

DBPOOL 10 Database connections >0 ; > POOLSIZE Defines the maximum size of the database connection pool. This value is used to calculate the maximum concurrent user connections needed on the database server by any iProcess process. N/A.

Tuning

TIBCO iProcess Engine Administrators Guide

Back to Library

82

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

POOLCONNTIMEOUT
Section Initial Value Units Range Description

DBPOOL 600 Seconds >0 Defines the timeout value for database connections. This value is checked whenever a new database connection is requested, and any existing connections that have been inactive for longer than this value are terminated. This ensures that the database connection pool is not increased unless all existing connections are actually in use. N/A.

Tuning

TIBCO iProcess Engine Administrators Guide

Back to Library

CDQP Section 83

CDQP Section
This section allows you to configure the use of Case Data Queue Parameters (CDQPs) on the server. Changes to parameters in this section take effect when CDQP configuration is next imported, using swutil QINFO. For more information about CDQPs see Case Data Queue Parameters in the TIBCO iProcess swutil and swbatch: Reference Guide. The following parameters are available: CDQPMAXGLOBAL

TIBCO iProcess Engine Administrators Guide

Back to Library

CDQPMAXQUEUE

84

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

CDQPMAXGLOBAL
Section Initial Value Units Range Description

CDQP 60 NA 0 - 32767 Defines the maximum number of CDQPs that can be defined on this server. To disable the use of CDQP parameters, either set this parameter to 0, or delete it.

Related Parameters

CDQPMAXQUEUE

TIBCO iProcess Engine Administrators Guide

Back to Library

Tuning

N/A.

CDQPMAXQUEUE 85

CDQPMAXQUEUE
Section Initial Value Units Range Description

CDQP 40 NA 0 - 32767 Define the maximum number of CDQPs that can be mapped to a particular queue (including the default user and default group queues). If this value is higher than the CDQPMAXGLOBAL value, the CDQPMAXGLOBAL value will be used instead. To disable the use of CDQP parameters, either set this parameter to 0, or delete it.

Tuning Related Parameters

N/A. CDQPMAXGLOBAL

TIBCO iProcess Engine Administrators Guide

Back to Library

86

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

Obsolete Parameters
The following SWDIR\etc\staffcfg parameters are not used in this version of the iProcess Engine. When you upgrade, some of these parameters may be removed from the SWDIR\etc\staffcfg file; others may remain. Those that do remain are, however, ignored by the iProcess Engine.

Parameter FGLITO

Section STAFF

Notes No longer needed because the login daemon process that uses it no longer exists. These parameters are no longer needed because port range configuration is now stored in the database, and can be configured by using the SWDIR\util\swadm utility. See Administering Firewall Port Ranges on page 313 for more information.

RNGMODE RNGBLOCKED RNGTHRESHOLD PORTSTART RPCSTART ALLOCRPCTIMEOUT IS_ACTIVEDIRECTORY

STAFF STAFF STAFF STAFF STAFF STAFF STAFFPRO

Obsolete because the LDAPCONF setup process now prompts for this data.

QUEUEPROCTIME RUNPROCTIME SYSPROCS URDSLEEP USERPROCS CMSDELAY CREATIME

STAFFPRO STAFFPRO STAFFPRO STAFFPRO STAFFPRO STAFFCMS STAFFCMS

TIBCO iProcess Engine Administrators Guide

Back to Library

Obsolete Parameters 87

Parameter CRXSIZE RPCTIME RXSLEEP TXSLEEP WIS_NEW_QUEUE_POLL_PERIOD WIS_CLIENT_IDLE_PERIOD WIS_MBOX_WORK_LIMIT WIS_RPC_SERVICE_PERIOD WIS_TOUT_GRANULARITY WQS_UPDATE_PERIOD WIS_WRITELOCKS

Section STAFFCMS STAFFCMS STAFFCMS STAFFCMS WQS WQS WQS WQS WQS WQS WQS

Notes

TIBCO iProcess Engine Administrators Guide

Back to Library

These parameters are no longer needed because the WIS process is now multi-threaded, and so can concurrently perform updates on queues and process RPC requests. See page 342 for more information.

88

| Chapter 3

Tuning the iProcess Engine Using SWDIR\etc\staffcfg Parameters

TIBCO iProcess Engine Administrators Guide

Back to Library

| 89
Chapter 4

Administering Servers

This chapter explains how to use the server configuration utility SWDIR\util\swadm to administer the server(s) hosting your iProcess Engine. To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user. If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance). These commands read and update data in the node_cluster database table.

Topics
Show all Server Details, page 90 Update Server Details, page 91 Add a Server, page 92 Remove a Server, page 93 Find a Servers Details, page 94 Find the Master Server, page 95 Define a Server as the Master Server, page 96 Move Processes From One Server to Another, page 97

TIBCO iProcess Engine Administrators Guide

Back to Library

90

| Chapter 4

Administering Servers

Show all Server Details

To display a list of the servers in your iProcess Engine, enter the following command:
swadm show_servers

Examples
1. This example shows the output from this command for an iProcess Engine that is installed as a single node, on server despina.
# swadm show_servers Machine ID 1 Machine Name DESPINA Master Y Check Error Files Y Machine Comment despina

2. This example shows the output from this command for an iProcess Engine that is installed as a node cluster, on servers despina and hades. The master Process Sentinels are running on despina and both servers are set to check for iProcess error files.
# swadm show_servers Machine ID 1 2 Machine Name DESPINA HADES Master Y N Check Error Files Y Y Machine Comment despina hades (slave)

TIBCO iProcess Engine Administrators Guide

Back to Library

Update Server Details 91

Update Server Details

To update the settings of a server in your iProcess Engine, such as the description of the server and whether it will check for SWDIR\logs\sw_error or SWDIR\logs\sw_warn files, you can use the following command:
swadm update_server

machine_id | machine_name check_error_files

machine_comment

where: machine_id is the server identifier (such as 1, 2 or 3). machine_name is the physical name of the server (such as pluto or hercules).

Y - Process Sentinels check for error files. N - no error checking is performed. machine_comment is used to provide any notes for the server. This can be used to describe the function of the server such as background_1 if it runs the background processes.

Example

If you want server hades in your iProcess Engine to start checking for error log files and have the description of BG_processor_2, you can change the setting of the server using the following command.
# swadm update_server hades Y BG_processor_2

TIBCO iProcess Engine Administrators Guide

Back to Library

check_error_files is used to define if the server checks for iProcess error files (SWDIR\logs\sw_error and SWDIR\logs\sw_warn). Replace check_error_files with one of the following values:

92

| Chapter 4

Administering Servers

Add a Server
You can add servers to your iProcess Engine at any time. For example, you can increase the amount of case processing by adding a server and starting more background processes. To add a server to your iProcess Engine, use the following command:
swadm add_server

machine_name master check_error_files machine_comment

where: machine_name is the physical name of the server you want to add. master is the parameter that specifies if you want the server to host the master Process Sentinels. Replace master with either: Y - master server N - slave server. Refer to Process Management in the TIBCO iProcess Engine: Architecture Guide for more information about the Process Sentinels architecture. check_error_files specifies whether the Process Sentinels on this server check for the creation of SWDIR\etc\sw_error and SWDIR\etc\sw_warn files. Y - Process Sentinels check for errors. N - no checking is performed.
Example

machine_comment is the text description added to identify the server.

The following example adds server pluto to the iProcess Engine. It: specifies that pluto will run as a slave server and will check for iProcess error files. sets its comment as BG_processor_3, indicating that it is the third server (in a node cluster) that runs background processes.

# swadm add_server pluto N Y BG_processor_3

TIBCO iProcess Engine Administrators Guide

Back to Library

Remove a Server 93

Remove a Server
If you need to remove a server from your iProcess Engine, for example, to take a server offline and upgrade it, you can use the following command:
swadm delete_server

machine_id | machine_name

where:
Example

machine_id is the server identifier (such as 1, 2 or 3) for the server you want to remove from the iProcess Engine. machine_name is the physical name of the server (such as pluto).

# swadm delete_server pluto

Alternatively, before removing the server from the cluster you can move the processes that currently run on the server to another server in the cluster using the move_server command on page 97. You can only move background processes individually. If you remove a server that is running only background processes, users may notice a reduction in the performance of case processing. However, if you remove a server that is running foreground processes such as a WIS, all of the clients need to log out and then log back in.

TIBCO iProcess Engine Administrators Guide

Back to Library

If you have four servers in your iProcess Engine (in a node cluster), and you need to take the server called pluto offline to perform some kernel changes and upgrades, you can remove the server from the node cluster using the following command:

94

| Chapter 4

Administering Servers

Find a Servers Details

To find out the configuration of a specific server in your iProcess Engine, use the following command:
swadm find_server

machine_id | machine_name

where:
Example

machine_id is the server identifier (such as 1, 2 or 3) for the server you want to see the properties of. machine_name is the physical name of the server.

# swadm find_server Machine ID 1 Machine Name DESPINA Master Y Check Error Files Y Machine Comment despina

TIBCO iProcess Engine Administrators Guide

Back to Library

The following example displays the configuration details for a server despina. The master Process Sentinels are running on despina and the server is set to check for iProcess error files.

Find the Master Server 95

Find the Master Server

To find out which server is currently hosting the master Process Sentinels, enter the following command:
swadm find_master

Example

The following example shows that the server called despina is currently configured to run the master Process Sentinels.

# swadm find_master Machine ID 1 Machine Name DESPINA Master Y Check Error Files Y Machine Comment despina

TIBCO iProcess Engine Administrators Guide

Back to Library

96

| Chapter 4

Administering Servers

Define a Server as the Master Server

Process Sentinels operate on each server involved in hosting your iProcess Engine, but one server has to be configured to host the master Process Sentinels. Refer to Process Management in the TIBCO iProcess Engine: Architecture Guide for more information about the Process Sentinels. If the master process fails or needs to be shutdown, such as when upgrading the server, you can assign a new server to host the master Process Sentinels using the following command:
swadm set_master

machine_id | machine_name

where:

machine_name is the physical name of the server on which you want the master Process Sentinels to run.

Example

To set the master Process Sentinels to run on the server called hades, you would enter the following command.
# swadm set_master hades The master machine has been set to machine hades.

TIBCO iProcess Engine Administrators Guide

Back to Library

machine_id is the server identifier (such as 1, 2 or 3) on which you want the master Process Sentinels to run.

Move Processes From One Server to Another 97

Move Processes From One Server to Another

You can move all processes assigned to operate on one server to another server. You might want to do this if one server has failed or you need to take it offline to upgrade it. Processes need to be stopped before you can move them. Refer to Issue a Shutdown Event on page 117 for more information. Use the following command to move processes to another server:
swadm move_server

machine_id machine_name

where:

Example

machine_name is the physical name of the destination server (such as pluto).

If you have two servers in your iProcess Engine (despina that has a unique ID of 1, and hades), you can move all the iProcess Engine server processes running on despina to hades using the following command.
# swadm move_server 1 hades

TIBCO iProcess Engine Administrators Guide

Back to Library

machine_id is the server identifier (such as 1, 2 or 3) of the source server.

98

| Chapter 4

Administering Servers

TIBCO iProcess Engine Administrators Guide

Back to Library

| 99
Chapter 5

Administering iProcess Engine Server Processes

This chapter explains how to use the server configuration utility SWDIR\util\swadm to administer iProcess Engine server processes.

Introduction, page 100 Server Processes, page 101 Using SWDIR\util\swadm to Administer Server Processes, page 104 Using SWDIR\util\swsvrmgr to Administer Server Processes, page 111 Using the iProcess Server Manager to Administer Server Processes, page 122

TIBCO iProcess Engine Administrators Guide

Back to Library

Topics

100

| Chapter 5

Administering iProcess Engine Server Processes

Introduction
There are three utilities that you can use to administer iProcess Engine server processes: the SWDIR\util\swadm utility, which you can use to directly administer server processes. See Using SWDIR\util\swadm to Administer Server Processes on page 104 for more information. the SWDIR\util\swsvrmgr utility, which you can use to administer server processes using the Process Sentinels. See Using SWDIR\util\swsvrmgr to Administer Server Processes on page 111 for more information.

the iProcess Server Manager, which provides a graphical view of server processes. You can use it to administer single processes, processes on individual machines, or processes in a node cluster. See Using the iProcess Server Manager to Administer Server Processes on page 122 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

The SWDIR\util\swadm utility directly updates the process_config database table, so any changes you make will still apply if the iProcess Engine is restarted. By contrast, any changes you make using the SWDIR\util\swsvrmgr utility will be lost if the Process Sentinels fail or are restarted.

Server Processes 101

Server Processes
The following table shows the server processes that are initially set up when the 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 the Process Sentinels will exist on each server to manage the processes running on that server. Foreground 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. All foreground processes must run on the master server.

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. Number of Processes Name Shown in Task Manager1

Process Name Process Sentinels PROCMGR PROCMGR

Process Description

Process Sentinel (worker) Process Sentinel (watcher)

1 1

procmgr.exe procmgr.exe

Foreground Processes RPC_POOL2 RPC_TCP_LI RPC_UDP_LI WIS WISMBD WQS RPC pool server RPC TCP listener RPC UDP listener Work Item Server Work Item Server Mbox daemon Work Queue Server 1-n 1 1 2 2 1 SWRPCSVR.EXE SWRPCSVR.EXE swrpcudp.exe WISRPC.EXE wismbd.exe WQSRPC.EXE

TIBCO iProcess Engine Administrators Guide

Back to Library

102

| Chapter 5
Process Name

Administering iProcess Engine Server Processes

Process Description

Number of Processes

Name Shown in Task Manager1

Background Processes BG BGPREDICT3 DBQD3 DIRECTOR3 DLMGR IAPJMS4 RPCBG SPO

1. 2. 3. 4.

Background Mbox daemon and Case Instruction processor Background case prediction server Database Queue Daemon TIBCO iProcess Objects Director Deadline Manager IAPJMS process RPC Background process TIBCO iProcess Objects Server

4 1 1 1 1 1 1 1

swbgmd.exe swbgmd.exe n/a SPODirector.exe

iapjms.exe staffrpcbg.exe SWEntObjSv.exe

The Windows Task Manager. Not applicable on UNIX. This process does not get listed by swadm show_processes or swsvrmgr status -v. Only present on the DB2 version of the iProcess Engine. This process is disabled unless you have chosen to enable it when installing the 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.

TIBCO iProcess Engine Administrators Guide

Back to Library

dlmgr.exe

Server Processes 103

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 on page 133 for more information about process attributes and how to set them.) the different processes that use each sequence number. Process Name BG No, unless the system makes heavy use of sub-procedures. Yes - A REQ ID is needed for each work item that is sent out. Yes, if waits are used in procedures. RPC_POOL Yes SWBATCH Yes WIS Yes - used when starting new cases from the TIBCO iProcess Workspace. Yes - used when starting new cases from the TIBCO iProcess Workspace. No

Sequence number (Process Attribute)

Case number (CNUM_SEQ_CACHE)

REQ ID (REQID_SEQ_CACHE)

Yes

Yes

Wait ID (WIS_INDEX_REFRESH)

No

No

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 SWDIR\bin\SWUTIL CSTART 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.

TIBCO iProcess Engine Administrators Guide

Back to Library

104

| Chapter 5

Administering iProcess Engine Server Processes

Using SWDIR\util\swadm to Administer Server Processes

You can use the SWDIR\util\swadm utility to view, run, delete and disable server processes. Note that: To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user. If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance).

The following table summarizes the commands you can use to administer process attributes.

Command swadm show_processes swadm add_process swadm disable_process swadm enable_process swadm delete_process

Task Show Server Processes Run a New Process Disable a Process Enable a Process Delete a Process

These commands read and update the process_config database table.

TIBCO iProcess Engine Administrators Guide

Back to Library

The following table summarizes the SWDIR\util\swadm commands you can use to administer server processes.

Show Server Processes 105

Show Server Processes

To display a list of the iProcess Engine server processes currently defined on your iProcess Engine, use the following command:
swadm show_processes -mmachine_id [-pprocess_name [-iprocess_instance]]

where: machine_id is the unique identifier for the server, assigned when the server is added to the iProcess Engine. You can find a servers identifier using the swadm show_servers command. process_name is the process name of the server process. process_instance is the specific instance of the process.

The command lists the following information for each process: Machine ID is the unique identifier for the server, assigned when the server is added to the iProcess Engine. Process Name is the process name of the server process. Process Inst is the specific instance of the process. Enabled is Y if the process is currently enabled, N if it is not. Persistent is Y if the process will be automatically restarted if the iProcess Engine restarts, and N if it will not. Whether or not a process restarts automatically is defined by the PM_AUTO_BOOT process attribute. Last Status is the last known status of the process - either starting, running, paused, shutting down or stopped. Status Comment is a descriptive comment associated with the Last Status.

TIBCO iProcess Engine Administrators Guide

Back to Library

106

| Chapter 5

Administering iProcess Engine Server Processes

Example

The following command shows the processes currently defined on a server.

# swadm show_processes -m1 Machine ID 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Process Name BG BG BG BG BGPREDICT DIRECTOR DLMGR IAPJMS RPCBG RPC_TCP_LI RPC_UDP_LI SPO WIS WIS WIS WIS WISMBD WISMBD WQS Process Inst 1 2 3 4 1 1 1 1 1 1 1 1 1 2 3 4 1 2 1 Enabled Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Persistent Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Last Status Running Running Running Running Running Running Running Running Running Running Running Running Running Running Running Running Running Running Running Status Comment BG process started BG process started BG process started BG process started BG process started DIRECTOR process started

IAPJMS process started RPCBG process started RPC listener process started RPC listener process started SPO Server process started WIS process started WIS process started WIS process started WIS process started WISMBD process started WISMB process started WQS process started

TIBCO iProcess Engine Administrators Guide

Back to Library

DLMGR process started

Run a New Process 107

Run a New Process

To start a new process running on a server, use the following command:
swadm add_process

machine_id | machine_name process_name enabled

where: machine_id is the unique identifier for the server. machine_name is the descriptive name of the server. process_name is the process name of the server process you want to run. If process_name is BG, BGPREDICT, DBQD, DLMGR, SPO or DIRECTOR, the process starts as soon as the Process Sentinels re-cache the changes to the process_config table. If process_name is any other process (i.e. a foreground process), the process does not start until the iProcess Engine is restarted. enabled is used to specify if you want the process to run immediately (Y) or whether it will be added to the process_config table but will be currently disabled (N).

Notes Example

All foreground processes (see page 101) must run on the master server. To start a new instance of the Background Mbox Daemon process on server2 so that it runs immediately, enter the following command:
# swadm add_process server2 bg Y

TIBCO iProcess Engine Administrators Guide

Back to Library

108

| Chapter 5

Administering iProcess Engine Server Processes

Disable a Process
You can temporarily disable a server process so that the Process Sentinels will not start it. To prevent the process running without removing the entry and configuration settings for it from the database tables, use the following command:
swadm disable_process

machine_id process_name process_instance

where: machine_id is the unique identifier for the server on which the process is configured to run. process_name is the process name of the server process you want to disable.

Example

To disable the second instance of the WIS process on the server with an ID of 3, you would enter the following command:
# swadm disable_process 3 WIS 2

TIBCO iProcess Engine Administrators Guide

Back to Library

process_instance is the number of the process instance which you want to disable.

Enable a Process 109

Enable a Process
You can re-enable a process so that the Process Sentinels can start it again using the following command.
swadm enable_process

machine_id process_name process_instance

where: machine_id is the unique identifier for the server on which you want to enable the process. process_name is the process name of the server process you want to enable. process_instance is the number of the process instance which you want to enable.

You need to use the SWDIR\util\swsvrmgr utility to start the process. Refer to Using SWDIR\util\swsvrmgr to Administer Server Processes on page 111.
Notes Example

All foreground processes (see page 101) must run on the master server. To enable the second instance of the Background Mbox Daemon process on the server with an ID of 3, you would enter the following command:
# swadm enable_process 3 WISMBD 2

TIBCO iProcess Engine Administrators Guide

Back to Library

110

| Chapter 5

Administering iProcess Engine Server Processes

Delete a Process
To remove a process from a server, use the following command:
swadm delete_process

machine_id process_name process_instance

where: machine_id is the unique identifier for the server that you want to remove the process from. process_name is the process name of the server process you want to delete. If process_name is BG, BGPREDICT, DBQD, DLMGR, IAPJMS, SPO or DIRECTOR, the process is removed as soon as the Process Sentinels re-cache the changes to the process_config table. If process_name is any other process (i.e. a foreground process), the process is not removed until the iProcess Engine is restarted. process_instance is the number of the process instance which you want to delete.

Example

If you want to remove an instance of a Background Mbox Daemon process so that instead of having four running instances of the process, you will only have three, enter the following command:
# swadm delete_process 2 bg 4

This command specifies that on the server with an ID of 2, the fourth instance of the Background Mbox Daemon (BG) process will be removed.

TIBCO iProcess Engine Administrators Guide

Back to Library

Using SWDIR\util\swsvrmgr to Administer Server Processes 111

Using SWDIR\util\swsvrmgr to Administer Server Processes

The SWDIR\util\swsvrmgr utility is used to administer server processes using the Process Sentinels. The Process Sentinels operate by subscribing to published internal events such as START a process or PAUSE a process. You can use SWDIR\util\swsvrmgr to trigger the event types that you want the Process Sentinels to subscribe to and then implement. Refer to Process Management in the TIBCO iProcess Engine: Architecture Guide for more information about the concepts of how the Process Sentinels work. To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user.

Command swsvrmgr STATUS swsvrmgr START swsvrmgr START_NEW swsvrmgr RESTART swsvrmgr SHUTDOWN swsvrmgr PAUSE|UNPAUSE swsvrmgr DUMPLOG swsvrmgr RESYNCTIME

Task View Process Status Issue a Start-up Event Issue a Start New Event Issue a Restart Event Issue a Shutdown Event Issue a Pause or Unpause Event Write a Shared Memory Debug Log File to Disk Resynchronize Timestamps with Windows Time

TIBCO iProcess Engine Administrators Guide

Back to Library

The following table summarizes the SWDIR\util\swsvrmgr commands you can use to administer server processes.

112

| Chapter 5

Administering iProcess Engine Server Processes

View Process Status

To view the current state of the system and, optionally, all processes on the system, you can issue a STATUS event to list a status report on the screen using the following command line:
swsvrmgr STATUS [-v] [-T

timeout]

where: -v displays the status of all processes on the system timeout is the optional timeout period that can be used to specify the time after which the command will terminate. If this is not specified, the default is 60 seconds.

Machine ID is the unique identifier for the server, assigned when the server is added to the iProcess Engine. Proc Name is the process name of the server process. Proc Inst is the specific instance of the process. Status is the current status of the process - either starting, running, paused, shutting down or stopped. Comment is a descriptive comment associated with the Status.

TIBCO iProcess Engine Administrators Guide

Back to Library

The command lists the following information for each process:

View Process Status 113

Example

The example on the following page displays the system status and the status of all processes.

swsvrmgr STATUS -v Machine ID 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Proc Name BG BG BG BG BGPREDICT DIRECTOR DLMGR IAPJMS RPCBG RPC_TCP_LI RPC_UDP_LI SPO WIS WIS WISMBD WISMBD WQS Proc Inst 1 2 3 4 1 1 1 1 1 1 1 1 1 2 1 2 1 Status RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING Comment BG process started BG process started BG process started BG process started BG process started DIRECTOR process started DLMGR process started IAPJMS process started RPCBG process started RPC listener process started RPC listener process started SPO Server process started WIS process started WIS process started WISMBD process started WISMBD process started WQS process started

Current System Status : 'RUNNING'

TIBCO iProcess Engine Administrators Guide

Back to Library

114

| Chapter 5

Administering iProcess Engine Server Processes

Issue a Start-up Event

To start the entire iProcess Engine or start individual processes, you can issue a START event so that the Process Sentinels subscribe to the published event and start the required processes. To issue a START event, use the following command:
swsvrmgr START [machine_name|machine_id [process_name [process_instance]]] [-T

timeout]

where: machine_name is the name of the server.

process_name is the process name of the server process you want to start, and must be one of: BG, BGPREDICT, DBQD, DLMGR, IAPJMS, SPO or DIRECTOR. If any other process name is specified, the command fails and an error message is displayed. process_instance is the instance of the process to start. timeout is the optional timeout period that can be used to specify the time after which the command will terminate. If this is not specified, the default is 60 seconds.

Notes Example

All foreground processes (see page 101) must run on the master server. To start the third instance of the background process (BG) that is operating on the computer called hercules using the default timeout, you would issue the following command:
swsvrmgr START hercules bg 3 BG 3 STARTED Process(es) successfully started

TIBCO iProcess Engine Administrators Guide

Back to Library

machine_id is the unique identifier of the server. You can find a servers identifier using the swsvrmgr status command.

Issue a Start New Event 115

Issue a Start New Event

You can issue a START_NEW event to start a number of temporary instances of a process. These instances will not be restarted if the iProcess Engine is restarted. For example, you may want to start a new background process to cope with a short peak in demand. To issue a START_NEW event, use the following command:
swsvrmgr START_NEW [machine_name|machine_id [process_name [instances]]] [-T

timeout]

where: machine_name is the name of the server.

process_name is the process name of the server process you want to start, and must be one of: BG, BGPREDICT, DBQD, DLMGR, IAPJMS, SPO or DIRECTOR. If any other process name is specified, the command fails and an error message is displayed. instances is the number of instances of the process to start. timeout is the optional timeout period that can be used to specify the time after which the command will terminate. If this is not specified, the default is 60 seconds.

Notes Example

All foreground processes (see page 101) must run on the master server. To start an additional instance of the background process (BG) that is operating on the computer called hercules using the default timeout, you would issue the following command:
swsvrmgr START_NEW hercules bg 1 BG 5 STARTED Process(es) successfully started

TIBCO iProcess Engine Administrators Guide

Back to Library

machine_id is the unique identifier of the server. You can find a servers identifier using the swsvrmgr status command.

116

| Chapter 5

Administering iProcess Engine Server Processes

Issue a Restart Event

You can issue a RESTART event to manually restart a suspended process (one that has stopped and not been automatically restarted). To issue a RESTART event, use the following command:
swsvrmgr RESTART [machine_name|machine_id [process_name [instance]]] [-T

timeout]

where: machine_name is the name of the server. machine_id is the unique identifier of the server. You can find a servers identifier using the swsvrmgr status command. process_name is the process name of the server process. instance is the instance of the process to restart. timeout is the optional timeout period that can be used to specify the time after which the command will terminate. If this is not specified, the default is 60 seconds.

Example

To restart the third instance of the background process (BG) that is operating on the computer called hercules using the default timeout, you would issue the following command:
swsvrmgr RESTART hercules bg 3 BG 3 STARTED Process(es) successfully started

TIBCO iProcess Engine Administrators Guide

Back to Library

Issue a Shutdown Event 117

Issue a Shutdown Event

You can issue a SHUTDOWN event to shut down: the complete system i.e. all processes are stopped. a particular server (in a node cluster). specific types of processes. individual instances of processes.

To issue a SHUTDOWN event, use the following command:

swsvrmgr SHUTDOWN [machine_name | [-T

machine_id [process_name [instance]]]

timeout]

machine_name is the name of the server. machine_id is the unique identifier of the server. You can find a servers identifier using the swsvrmgr status command. process_name is the process name of the server process you want to stop, and must be one of: BG, BGPREDICT, DBQD, DLMGR, IAPJMS, SPO or DIRECTOR. If any other process name is specified, the command fails and an error message is displayed. instance is the instance of the process to stop. timeout is the optional timeout period that can be used to specify the time after which the command will terminate. If this is not specified, the default is 60 seconds.

The result of the attempt to shutdown each process is displayed on the screen and a final status is displayed at the end.
Example

The following command shuts down the third instance of a background process on the server with Machine ID 1.

swsvrmgr shutdown 1 BG 3 Attempting to stop 1 processes

Machine ID 1

Proc Name BG

Proc Inst 3

Status SHUTTING DOWN

Comment Normal Shutdown

TIBCO iProcess Engine Administrators Guide

Back to Library

where:

118

| Chapter 5

Administering iProcess Engine Server Processes

Issue a Pause or Unpause Event

You can issue a PAUSE event to pause: the complete iProcess system. a server and all the processes running on it. process types. individual instances of processes.

The following server processes can be paused: WIS Mbox Daemon (WISMBD) Work Item Server (WIS) Background (BG) Case Prediction Server (BGPREDICT) Deadline Manager (DLMGR) Database Queue Daemon (DBQD)

Similarly, you can issue an UNPAUSE event to restart any previously PAUSED process. To issue a PAUSE or UNPAUSE event, use the following command:
swsvrmgr PAUSE | UNPAUSE [machine_name | [instance]]] [-T

machine_id [process_name

timeout]

where: machine_name is the name of the server. machine_id is the unique identifier of the server. You can find a servers identifier using the swsvrmgr status command. process_name is the process name of the server process you want to stop. instance is the instance of the process to stop. timeout is the optional timeout period that can be used to specify the time after which the command will terminate. If this is not specified, the default is 60 seconds.

TIBCO iProcess Engine Administrators Guide

Back to Library

Issue a Pause or Unpause Event 119

Example

The following command pauses the third instance of the background process on server hercules.
swsvrmgr PAUSE hercules BG 3 BG 3 PAUSED Process(es) successfully paused

The following command restarts the same background process.

swsvrmgr UNPAUSE hercules BG 3

TIBCO iProcess Engine Administrators Guide

Back to Library

120

| Chapter 5

Administering iProcess Engine Server Processes

Write a Shared Memory Debug Log File to Disk

You should only use this command when explicitly requested to do so by TIBCO Support. To write a shared memory debug log file for a process, use the following command:
swsvrmgr DUMPLOG [machine_name |

machine_id [process_name [instance]]]

where: machine_name is the name of the server. machine_id is the unique identifier of the server. You can find a servers identifier using the swsvrmgr status command. process_name is the process name of the server process you want to create a debug log file for. instance is the instance of the process you want to create a debug log file for.

When this command is issued, all debug in the process debug shared memory segment is written to the file:
SWDIR\logs\ProcessName_TimeStamp_ProcessID.dmp

TIBCO iProcess Engine Administrators Guide

Back to Library

Resynchronize Timestamps with Windows Time 121

Resynchronize Timestamps with Windows Time

This command is only relevant if you are running the iProcess Engine on a Windows system. To manually force the iProcess Engine to resynchronize its timestamps with Windows system time, use the following command:
swsvrmgr RESYNCTIME [machine_id]

where machine_id is the unique identifier of the server that you want to resynchronize. If you omit this parameter, time will be resynchronized on all servers in the iProcess Engine node.

TIBCO iProcess Engine Administrators Guide

Back to Library

For more information about keeping iProcess Engine timestamps and Windows time synchronized, see the description of the WINTIME_RESYNC_PERIOD process attribute on page 160.

122

| Chapter 5

Administering iProcess Engine Server Processes

Using the iProcess Server Manager to Administer Server Processes

The iProcess Server Manager is a JSP web client application that utilizes TIBCO Hawk to provide a graphical view of the server processes on a machine or a node cluster. You can do the following from the iProcess Server Manager: Start and stop processes (specifically BG, BGPREDICT, DLMGR, IAPJMS, SPO and DIRECTOR) Restart suspended processes Start and stop all processes on a selected node or node cluster.

Hawk Requirements
If you are planning to use the iProcess Server Manager, you must have TIBCO Hawk installed on: the machine hosting the iProcess Engine. (TIBCO Hawk is distributed with this version of the iProcess Engine, and can be installed when you install the iProcess Engine. See the TIBCO iProcess Engine Installation guide for more information.) the machines on which you want to use the iProcess Server Manager to administer iProcess Engine processes. For more information about how to install TIBCO Hawk, see the TIBCO Hawk Installation and Configuration Guide.

For information on the correct version of TIBCO Hawk to be used, please see the TIBCO iProcess Engine Installation guide.

Enabling the iProcess Server Manager

Windows On Windows, the iProcess Engine uses the iProcess nodename Web Server service (where nodename is the node name of the iProcess Engine) to communicate with TIBCO Hawk. This service runs a Tomcat JSP web server that is installed as part of the iProcess Engine (in SWDIR\tomcat.)

TIBCO iProcess Engine Administrators Guide

Back to Library

You can also use the iProcess Server Manager to administer message queues. See Using the iProcess Server Manager to Administer Message Queues on page 300.

Using the iProcess Server Manager to Administer Server Processes 123

You can install the iProcess nodename Web Server service when you install the iProcess Engine. See the TIBCO iProcess Engine Installation guide for more information. Alternatively, you can use the following command to install, remove, start or stop the service:
SWDIR\bin\smserv.bat action TIBCO_ROOT

where: action is either: install, uninstall, start or stop. TIBCO_ROOT is the base directory for TIBCO software installations on this computer (by default c:\tibco).

smserv.bat install C:\tibco smserv.bat start C:\tibco

UNIX On UNIX, the iProcess Engine communicates with TIBCO Hawk using the Tomcat JSP web server that is installed in $SWDIR/tomcat.) You must start the Tomcat JSP web server by running the following script:
SWDIR/bin/smstart

If you have installed the TIBCO Hawk software in a location other than the default (/opt/tibco), you must edit the SWDIR/bin/smstart file to modify the paths specified for HAWK_ROOT and RV_ROOT to reflect this. Similarly, to stop the Tomcat JSP web server, run the following script: SWDIR/bin/smstop

Configuring TIBCO Hawk Security for iProcess Server Manager

The TIBCO Hawk Installation and Configuration Guide describes how TIBCO Hawk implements its security policy. TIBCO iProcess Server Manager can be configured to use this TIBCO Hawk policy as follows: TIBCO Hawk Agents can be configured to use a specific Java class to implement secure access for console applications such as iProcess Server Manager. Once a Hawk Agent has been configured with a string specifying
TIBCO iProcess Engine Administrators Guide

Back to Library

For example, to install and start the iProcess nodename Web Server service, use the following commands:

124

| Chapter 5

Administering iProcess Engine Server Processes

that security class, this same string must be specified by all console applications that want to connect to this Agent and its microagents. Therefore, the iProcess Server Manager provides a file, iprocesshawk.properties, that contains an example of the security string HawkSecurityString. If you edit this string to the value required by the security model of the appropriate Hawk Agent, the Hawk Agent will read the correct value from this file and allow access. For example, if your Hawk Agent uses a security class name MySecurity.class, edit the file to read: HawkSecurityString=MySecurity.class The file can be found at:

With Trusted or TrustedWithDomain (see the TIBCO Hawk Installation and Configuration Guide for details), you can use the two Hawk default security models: the Hawk bin directory (for example, c:\tibco\hawk\bin) needs to be added to your system path. This is because the Java files use Java Native Interface (JNI) to call a Windows DLL (HawkTrustedUserID.dll). If this directory is not on the path, the iProcess Server Manager web application will not work with either of these two security models. You must also add the appropriate account to the appropriate access control file used by the TIBCO Hawk Agents security policy, on all machines that will run the iProcess Server Manager. On Windows, this account is the SYSTEM account. On other platforms, this account is the account that is used to run the SM Start shell script.

Starting the iProcess Server Manager

To start the iProcess Server Manager: 1. If you are running the iProcess Engine on: Windows: Make sure the iProcess nodename Web Server and TIBCO Hawk Agent services have been started (see page 122). UNIX/Linux: Make sure you have run the SWDIR/bin/smstart script (see page 123). 2. Enter a URL that has the following format:
http://machine:port/

TIBCO iProcess Engine Administrators Guide

Back to Library

SWDIR\tomcat\webapps\ipsvrmgr\WEB-INF\classes \iprocesshawk.properties

Using the iProcess Server Manager to Administer Server Processes 125

where machine is the machine where the iProcess Server Manager is installed. port is the port number of the machine where your iProcess Server Manager is listening to requests. The default is 8080. For example:
http://titan:8080/

When you first start the iProcess Server Manager, it opens with the Configuration pane displayed:

Configuring the iProcess Server Manager

When you first start the iProcess Server Manager, it displays the Configuration pane. Configure the iProcess Server Manager for use in your environment as follows: 1. Enter the name of your Hawk Domain. By default the Hawk Domain is blank, but if you configured a different domain name, enter it here. The name specified for Hawk Domain on the master machine must also be specified on all machines in a clustered environment. 2. If when you installed TIBCO Hawk, you used the defaults for the following TIBCO Rendezvous configuration parameters, continue with the next step: TIBCO Rendezvous Configuration Parameter Daemon Default Value 7474

TIBCO iProcess Engine Administrators Guide

Back to Library

126

| Chapter 5

Administering iProcess Engine Server Processes

TIBCO Rendezvous Configuration Parameter Network Service

Default Value ; 7474

However, if when you installed TIBCO Hawk, you changed TIBCO Rendezvous configuration parameters Daemon, Network or Service from the defaults, you must change the following process attributes in the iProcess Engine to reflect this. RV_DAEMON RV_NETWORK

3. In the Search for nodes field, enter the name of the iProcess Engine node that you want to administer and click Search. 4. When the iProcess Server Manager locates the node, it displays information about it as follows:

5. To find TIBCO Hawk Agents associated with the selected node, click Browse for Agents. If you have already browsed for agents, you can click Load Known Agents, which is faster than browsing. Also, if the Tomcat software times out, you need to click Load Known Agents. Browsing for TIBCO Hawk Agents can take several minutes.

6. The iProcess Server Manager displays the Process Control pane. Continue with the following section to learn more about controlling processes.

Controlling Processes
To view the Process Control pane, expand iProcess Management > Control.

TIBCO iProcess Engine Administrators Guide

Back to Library

RV_SERVICE

Using the iProcess Server Manager to Administer Server Processes 127

The iProcess Management page shows information for the server you have selected. The view is hierarchical, so expand a server or a node in a cluster to show individual processes running on each. For example:

Using the buttons at the bottom of the page, you can do the following: Button Start Description Starts the selected instance, all instances of a process, all processes on the selected server, or all processes in the node cluster. Starts the specified number of temporary instances of the selected process. Specify the number of instances in the text box to the left of the Start Temp button. These instances will not be restarted if the iProcess Engine is restarted. For example, you may want to start a new background process to cope with a short peak in demand.

Start Temp

TIBCO iProcess Engine Administrators Guide

Back to Library

Expanding a process shows the instances of that process:

128

| Chapter 5

Administering iProcess Engine Server Processes

Button Stop

Description Stops the selected instance, all instances of a process, all processes on the selected server, or all processes in the node cluster. You can also force stop processes by selecting the Force stop check box and specifying the number of seconds after which the Process Sentinels will stop waiting for processes to shut down cleanly and perform a forced stop (the default is 300 seconds). Restarts a process that is in a SUSPENDED state (one that has stopped and not been automatically restarted).

Restart

Example To stop all processes on node staffw_103a6, highlight the node and click Stop. The message "Requesting Process(es) stop" appears at the bottom of the window and a red square next to each instance indicates that the instance is shutting down or has shut down:

TIBCO iProcess Engine Administrators Guide

Back to Library

Using the iProcess Server Manager to Administer Server Processes 129

Viewing Process Statuses

To view the status of all processes, click iProcess Management - View. The Process View pane lists the currently configured processes, their status, number of instances and so on. For example:

Note that the IAPJMS process is disabled, and therefore appears "greyed out." The display is refreshed every 5 seconds. You can configure the refresh interval as described in Customizing the iProcess Server Manager on page 131.

View the Process Summary

To view summary information about processes, click iProcess Management Summary. The Process Summary pane lists the process name, number of processes, and the parent/child relationships. For example:

TIBCO iProcess Engine Administrators Guide

Back to Library

130

| Chapter 5

Administering iProcess Engine Server Processes

Viewing the iProcess Engine Log Files

To view log files related to the iProcess Engine, click Log Viewer. The Log Viewer pane is displayed:

To view a log file, do the following: 1. From the Server list, select the server that contains the log files you want to view. 2. Use a wildcard, if desired in the Log file filter field. 3. Click Get Logs. 4. From the Log Files list, select the log file you want to view (for example, sw_error). The list contains all the log files found in SWDIR\logs that matched the criteria you entered in the Log file filter field. 5. Enter the number of lines of the log file that you want to display and click either From Top of Log or From End of Log, depending on which part of the log file you want to view. You can also wrap lines by selecting the Wrap Lines check box. 6. The requested portion of the log file is displayed. For example:

You can use the following buttons for navigation: Next - displays the next portion of the log file. Previous - displays the previous portion of the log file.

TIBCO iProcess Engine Administrators Guide

Back to Library

Using the iProcess Server Manager to Administer Server Processes 131

Customizing the iProcess Server Manager

There are several configuration options that you can change by editing the SWDIR\tomcat\webapps\ipsvrmgr\configuration.xml file. For example, to change the default refresh period (5 seconds), edit the following entry:
<!-- page refresh interval in seconds --> <refresh>5</refresh>

Connecting to a Different Server

By default, the iProcess Server Manager displays the node cluster you are part of or the individual server that you are using (if you are not part of a node cluster). You can connect to other servers as follows:

2. Enter the node name of the server you are looking for in the Search for nodes field and click Search. After a short delay, the details of the requested node should be displayed in the Configuration pane.

TIBCO iProcess Engine Administrators Guide

Back to Library

1. Click Configuration.

132

| Chapter 5

Administering iProcess Engine Server Processes

TIBCO iProcess Engine Administrators Guide

Back to Library

| 133
Chapter 6

Administering Process Attributes

This chapter describes how to use the server configuration utility SWDIR\util\swadm to administer iProcess Engine process attributes. Each iProcess Engine server process can have associated attributes to specify how the process operates. Process attributes and their values are stored in the process_attributes database table.

Topics
Using SWDIR\util\swadm to Administer Process Attributes, page 134 Alphabetical List of Process Attributes, page 138 General iProcess Engine Configuration, page 147 Process Management Configuration, page 164 WIS and WQS Process Configuration, page 178 Message and Mbox Processing Configuration, page 212 Sequence Numbering Configuration, page 228 Transaction Control Configuration, page 232 Activity Monitoring and Work Queue Delta Configuration, page 236 TIBCO Rendezvous Configuration, page 251 Case Prediction Configuration, page 255 TIBCO iProcess Workspace (Windows) Configuration, page 258 Procedure Configuration, page 265 iProcess Objects Director, page 275

TIBCO iProcess Engine Administrators Guide

Back to Library

134

| Chapter 6

Administering Process Attributes

Using SWDIR\util\swadm to Administer Process Attributes

You can use the SWDIR\util\swadm utility to view, set and delete process attributes. Note that: To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user. If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance).

The following table summarizes the commands you can use to administer process attributes. Command swadm show_all_attributes swadm set_attribute swadm delete_attribute Task Display All Process Attributes Set a Process Attribute Delete a Process Attribute

TIBCO iProcess Engine Administrators Guide

Back to Library

Display All Process Attributes 135

Display All Process Attributes

You can display a list of all process attributes and their values that are currently defined on the iProcess Engine. The following command enables you to set a filter for attribute names so that you can either display all attributes on all servers or display all attributes of a certain name on all servers:
swadm SHOW_ALL_ATTRIBUTES [attribute_name]

where attribute_name is the (optional) name of the process attribute that you want to restrict the search by. For a list of valid process attribute names see Alphabetical List of Process Attributes on page 138.

TIBCO iProcess Engine Administrators Guide

Back to Library

136

| Chapter 6

Administering Process Attributes

Set a Process Attribute

You can set up a new attribute for a specific server process or update an existing entry using the following command:
swadm SET_ATTRIBUTE

machine_id process_name process_instance attribute_name

attribute_value

where:
Example

machine_id is the unique identifier for the server. If you specify a value of 0, the command will apply to all servers in the iProcess Engine. process_name is the name of the iProcess Engine process. If you specify a value of ALL, the command will apply to all process types.

attribute_name is the name of the attribute to be set. attribute_value is the value for the specified process attribute.

A companys office in California (Pacific Standard Time, GMT-08:00) wants to run cases of procedures that are hosted on a node running on a machine in the companys administrative centre in Washington D.C. (Eastern Standard Time, GMT-05:00). To configure the iProcess Engine to use Pacific Standard Time, use the following command.
swadm set_attribute 0 ALL 0 TIMEZONE "PST8"

TIBCO iProcess Engine Administrators Guide

Back to Library

process_instance is the instance number of the process. If you specify a value of 0, the command will apply to all instances of the process.

Delete a Process Attribute 137

Delete a Process Attribute

You can remove a process attribute from a server process so that the attribute no longer effects the process and is removed from the process_attributes table. Use the following command:
swadm DELETE_ATTRIBUTE

machine_id process_name process_instance

attribute_name

where:
Example

machine_id is the unique identifier for the server. If you specify a value of 0, the command will apply to all servers in the iProcess Engine. process_name is the name of the iProcess Engine process. If you specify a value of ALL, the command will apply to all process types. process_instance is the instance number of the process. If you specify a value of 0, the command will apply to all instances of the process. attribute_name is the name of the attribute to be deleted.

If the third instance of the BG process keeps failing but it has been set up to automatically restart, you can stop it restarting while you investigate the reason why it keeps failing. Enter the following command.
swadm delete_attribute 1 bg 3 process_auto_restarts

TIBCO iProcess Engine Administrators Guide

Back to Library

138

| Chapter 6

Administering Process Attributes

Alphabetical List of Process Attributes

The following table describes the available process attributes. Process attributes that are used by the DIRECTOR process are not listed in this table. See the TIBCO iProcess Objects Director Administrators Guide for more information about attributes that are used by the DIRECTOR process.

Attribute AUDIT_OPENKEEP BG_MAX_ACTIONS_PER_TRANS CCOUNT_CACHE_REFRESH CHECK_EAIWITHDRAW_ONPURGE

Description Controls whether the Open Work Item and Keep Work Item audit trail entries are enabled. Defines the limit of actions per workflow transaction. Enables you to define the refresh period for updating the cached list of cases currently on the system. Defines whether or not iProcess checks if any outstanding delayed release EAI steps have been successfully withdrawn before committing the purge transaction. Defines the number of loops to process before the background process checks for SWDIR\logs\sw_error files and available disk space. Defines the number of case numbers to be cached. Defines whether or not the list of available procedures in the TIBCO iProcess Workspaces Case Start dialog is automatically refreshed. Defines the size of shared memory segment (in Kb) that should be allocated for shared memory debug logs. Defines the number of messages that are cached by the DBQD process when it requests a block of messages from a database message queue.

CHECKFREQ

CNUM_SEQ_CACHE CSTART_AUTO_REFRESH

DBGMEMSIZE_KB

DBQD_MAX_CACHED_MESSAGES

TIBCO iProcess Engine Administrators Guide

Back to Library

Alphabetical List of Process Attributes 139

Attribute DBQD_MAX_FIL_SESSIONS

Description Defines the number of concurrent threads that the DBQD process uses to process RPC requests for messages from its cache from BG or WISMBD processes. Defines the default major version number that the TIBCO iProcess Modeler will use when a new procedure is saved. Defines the default minor version number that the TIBCO iProcess Modeler will use when a new procedure is saved.

DEF_MAJOR_VERS

DEF_MINOR_VERS

DISABLE_CASE_COUNTING

Defines whether case counts are displayed for procedures in the Live (Dead) Cases column of the Case Administrator dialog, when a user starts the iProcess Administrator from the iProcess Workspace (Windows) Defines whether or not a new user name is validated as an O/S user account when you add an iProcess user from the User Manager tool of the TIBCO iProcess Administrator. Defines whether or not the Possible iProcess User List button is displayed in the User Manager tool of the TIBCO iProcess Administrator. Defines the times during the day when the Deadline Manager checks the iProcess database for expired deadlines. Defines the EAI server plug-ins that need to use the Microsoft Distributed Transaction Coordinator (MSDTC). Defines how long the Mbox Daemons will sleep when all Mbox queues in the Mbox set are empty.

DISABLE_USER_CHECK

DISABLE_USER_LIST

DMD_PROCESS_INTERVAL

EAI_NEEDS_MSDTC

EMPTYMBOXSLEEP

TIBCO iProcess Engine Administrators Guide

Back to Library

DEPLOY_XSL_OUT_ENCODING

Defines the character set to be used for output encoding.

140

| Chapter 6
Attribute

Administering Process Attributes

Description Defines the number of seconds to increment the EMPTYMBOXSLEEP value by when a BG or WISMBD process requests a message from an empty Mbox. Defines the maximum value (in seconds) that EMPTYMBOXSLEEP can be set to. Defines whether or not background case prediction is enabled on the node. Note: This attribute has no effect on live case prediction or case simulation.

EMPTYMBOXSLEEP_INC

EMPTYMBOXSLEEP_MAX ENABLE_CASE_PREDICTION

FIL_PROCDEF_CACHE_SIZE

Defines the maximum number of procedure definitions that can be cached in memory by the BG, WIS and SPO processes. Defines the port number that is used for message communications between the BG process and the IAPJMS library. Defines whether or not the BG process is enabled to publish audit activities to the IAPJMS process. Defines whether or not failed message transactions should be rolled back. Defines whether or not the JMS topic name is static or dynamically configured at run-time. Defines whether message delivery is synchronous or asynchronous. Defines how long the IAPJMS process should wait before it times out if there is a network error. Defines the topic name for the JMS destination if activity monitoring is enabled. Defines whether users may keep or release work items even if pack data has changed.

IAPJMS_PORTNO

IAPJMS_PUBLISH IAPJMS_ROLLBACK IAPJMS_SIMPLETOPIC IAPJMS_SYNCHRONOUS IAPJMS_TIMEOUT IAPJMS_TOPICNAME IGNORE_PACK_CHANGED

TIBCO iProcess Engine Administrators Guide

Back to Library

Alphabetical List of Process Attributes 141

Attribute IQL_RETRY_COUNT

Description Defines how many times a failed message in a message queue is retried before being moved to the exception queue Defines the delay (in seconds) between each retry attempt for a failed message in a message queue, before the message is moved to the exception queue. Defines the JVM attributes that should be specified for the Java Virtual Machine when it is started. Defines the default location where passwords should be validated when a user attempts to logon to this iProcess Engine. Defines the time limit in seconds before the Deadline Manager will re-post unprocessed deadline messages. Defines the maximum number of times to loop during the prediction process. Determines the maximum number of nested sub-procedures supported by the server. Defines the unique identifier of the Mbox set to be used by a BG process when dequeuing messages received from a WISMBD process. Defines the unique identifier of the Mbox set to be used by a BGPREDICT process when posting case changes messages to a BG process. Defines the unique identifier of the Mbox set to be used by a WISMBD process when dequeuing messages received from a BG process. Defines the unique identifier of the Mbox set to be used by a process when writing to a BG process. Defines the unique identifier of the Mbox set to be used by a BGPREDICT process when posting case changes messages to a BG process.

IQL_RETRY_DELAY

JVMPROPS LOGON_OS_LOCATION

MAX_AGE_BEFORE_RESETPOST MAX_PREDICTION_LOOPS MAX_SUB_PROCEDURE_DEPTH MBSET_READ_BG

MBSET_READ_PREDICT

MBSET_READ_WIS

MBSET_WRITE_BG MBSET_WRITE_PREDICT

TIBCO iProcess Engine Administrators Guide

Back to Library

142

| Chapter 6
Attribute

Administering Process Attributes

Description Defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by the BG process when writing to a WISMBD process. Defines the amount of disk space (in Kilobytes) required for the background process to run. Defines whether or not case data normalization is enabled. Defines where the iProcess Engine should obtain the list of users when it populates the Possible iProcess User List in the User Manager tool of the TIBCO iProcess Administrator. Defines whether or not the Process Sentinels automatically start the server processes after the Process Sentinels have started. Defines the time zone that this node will operate in. Defines whether or not, in the TIBCO iProcess Modeler, a user has to enter a comment whenever they save a procedure. Defines whether or not, in the TIBCO iProcess Modeler, a procedures version number will be incremented whenever it is saved. Defines the maximum number of instances of a procedure version. Defines whether or not, if a process fails, the Process Sentinels automatically write to disk the contents of that process debug shared memory segment. Defines whether or not a server process will automatically restart after a failure. Defines the maximum number of times the Process Sentinels will attempt to restart a failed process.

MBSET_WRITE_WIS

MINFREEKB NORMALISE_CASE_DATA OS_USER_LOCATIONS

PM_AUTO_BOOT

TIMEZONE PROC_VER_COMMENT

PROC_VER_INC

PROC_VER_NUM_INSTANCES PROCESS_AUTO_DUMPLOG

PROCESS_AUTO_RESTARTS PROCESS_MAX_RESTARTS

TIBCO iProcess Engine Administrators Guide

Back to Library

Alphabetical List of Process Attributes 143

Attribute PROCESS_MIN_RESTART_PERIOD

Description Defines the time interval (in seconds) that the Process Sentinels will wait between attempts to restart a failed process. Defines the amount of time the Process Sentinels will sleep for. Defines the number of REQ IDs to be cached. Allows the batching of RPC calls to reduce the overhead in processing RPC calls individually. Defines the maximum number of threads that the WIS and WQS processes can use to process RPC requests from client applications. Configures the iProcess Server Manager with the daemon used to handle session communication in TIBCO Rendezvous. Configures the iProcess Server Manager with the network used to handle outbound session communication in TIBCO Rendezvous. Configures the iProcess Server Manager with the User Datagram Protocol (UDP) service group used to handle session communication in TIBCO Rendezvous. Defines the UNIX shared memory key that is allocated (using the ftok system call) when the WQS process is started. Defines the directory where the IAPJMS process will look for the Java libraries that it needs. Defines the time zone that this node will operate in. Sets a limit on the number of unprocessed deadline messages that are posted by the Deadline Manager. Defines the number of Wait IDs to be cached.

PROCESS_SLEEP REQID_SEQ_CACHE RPC_SVR_CONTROL RPC_SVR_NUM_THREADS

RV_DAEMON

RV_NETWORK

RV_SERVICE

SHMKEY_ID

SWLIB_PATH TIMEZONE UNPROCESSED_DL_POST_LIMIT WAITID_SEQ_CACHE

TIBCO iProcess Engine Administrators Guide

Back to Library

144

| Chapter 6
Attribute

Administering Process Attributes

Description Defines the notice period (in seconds) that iProcess Engine processes are given before a resynchronization takes place. Defines the interval (in seconds) at which the iProcess Engine checks to see if its timestamps are in step with Windows system time. Defines the interval (in seconds) at which the iProcess Engine checks to see if its timestamps are in step with Windows system time. Defines the size (in threads) of the pool of threads that is used to perform caching of work queues. Defines the number of items that must exist in a work queue for it to be cached when the WIS process first handles it. Defines the maximum amount of time (in seconds) that an RPC processing thread in the WIS process waits for a work queue to be cached. Defines the number of work items that the CDQP update thread will update in a single operation when updating CDQP field values for a WIS process queues. Defines the count boundary at which a work queue will be split into multiple blocks of work for filtering purposes, based on the number of work items in the queue Defines the number of threads in the queue filtering thread pool, used to process additional blocks of filtering work Defines the interval (in seconds) after which an index on a queue will be refreshed by a WIS process. Defines the number of locks in the internal lock pool used by the WIS process

WINTIME_RESYNC_NOTICE

WINTIME_RESYNC_PERIOD

WINTIME_RESYNC_TOLERANCE

WIS_CACHE_POOL_SIZE WIS_CACHE_THRESHOLD

WIS_CACHE_WAIT_TIME

WIS_CDQP_DATA_RECACHE_BATCH

WIS_FILTER_THREAD_BOUNDARIES

WIS_FILTER_THREAD_POOL_SIZE

WIS_INDEX_REFRESH WIS_LOCK_POOL_SIZES

TIBCO iProcess Engine Administrators Guide

Back to Library

Alphabetical List of Process Attributes 145

Attribute WIS_NEW_ITEM_BATCH_SIZE WIS_QCHANGE_EXTENDED_CHECK WIS_SESSION_TIMEOUT

Description Defines the number of new item requests to be batched together. Defines whether or not a change in the lock status of a work item is counted as a change to the work item. Defines the timeout period (in seconds) after which a WIS process will automatically shut down, starting from the time at which it was last accessed (by a TIBCO iProcess Workspace, SAL application or TIBCO iProcess Objects Server). Defines the timeout period (in seconds) after which a WIS process will automatically shut down, starting from the time at which the iProcess Engine was shut down. Defines the maximum amount of time (in seconds) that the queue update thread in the WIS process performs updates for before going back to sleep Defines how often the queue update thread in the WIS process wakes up and updates the queues handled by the WIS process. Allows the use of priority escalation in the WIS process to be disabled. Defines the port number that is used for work queue delta messages between the WIS process and the IAPJMS process. Defines the default topic name for the JMS destination used by the WIS process for work queue delta publication. Allows the gathering of RPC call stats within the WQS process to be configurable. Defines the maximum number of slots available in the SWRPCMTS multi-threaded RPC server shared library for threads to perform queue searching.

WIS_SESSION_TIMEOUT_SHUTDOWN

WIS_UPDATE_LENGTH

WIS_UPDATE_PERIOD

WIS_USE_PRIORITY_ESCALATION WQDJMS_PORTNO

WQDJMS_TOPICNAME

WQS_GATHER_RPC_STATS WQS_NUM_SEARCH_SLOTS

TIBCO iProcess Engine Administrators Guide

Back to Library

146

| Chapter 6
Attribute

Administering Process Attributes

Description Defines how often (in seconds) the contents of the WQS/WIS shared memory are written to the wqs_index table in the database. Defines the number of WIS processes that should be dedicated to handling user queues and group queues respectively. Allows configuration of uncommitted reads during an XPC SELECT.

WQS_PERSIST_SHMEM

WQS_WIS_USER_COUNT

XPC_READ_UNCOMMITTED

TIBCO iProcess Engine Administrators Guide

Back to Library

General iProcess Engine Configuration 147

General iProcess Engine Configuration

The following process attributes allow you to configure general aspects of iProcess Engine behavior. Attribute DBGMEMSIZE_KB Description Defines the size of shared memory segment (in Kb) that should be allocated for shared memory debug logs. Defines the character set to be used for output encoding. Defines the EAI server plug-ins that need to use the Microsoft Distributed Transaction Coordinator (MSDTC). This attribute turns on and off the LDAP integral User Validation API. Defines the default location where passwords should be validated when a user attempts to logon to this iProcess Engine. Defines whether or not case data normalization is enabled. Defines the time zone that this node will operate in. Defines the notice period (in seconds) that iProcess Engine processes are given before a resynchronization takes place. Defines the interval (in seconds) at which the iProcess Engine checks to see if its timestamps are in step with Windows system time. Defines the interval (in seconds) at which the iProcess Engine checks to see if its timestamps are in step with Windows system time. Allows configuration of uncommitted reads during an XPC SELECT.

DEPLOY_XSL_OUT_ENCODING EAI_NEEDS_MSDTC

LDAP_UV LOGON_OS_LOCATION

NORMALISE_CASE_DATA TIMEZONE WINTIME_RESYNC_NOTICE

WINTIME_RESYNC_PERIOD

WINTIME_RESYNC_TOLERANCE

XPC_READ_UNCOMMITTED

TIBCO iProcess Engine Administrators Guide

Back to Library

148

| Chapter 6

Administering Process Attributes

DBGMEMSIZE_KB
General iProcess Engine Configuration Summary

This attribute specifies the size of shared memory segment (in Kb) that should be allocated for shared memory debug logs created either by the TIBCO iProcess Objects Server, or by using the SWDIR\util\swsvrmgr DUMPLOG command. The attribute must be set for ALL processes. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

Setting this attribute allows the TIBCO iProcess Objects Server to size the shared memory segment that it uses to create shared memory debugging, without having to set a SAL debug string.

TIBCO iProcess Engine Administrators Guide

Back to Library

256

DEPLOY_XSL_OUT_ENCODING 149

DEPLOY_XSL_OUT_ENCODING
General iProcess Engine Configuration Summary

This attribute defines the character set to be used for output encoding for procedures imported to iProcess from TIBCO Business Studio. Specifying the correct character set ensures that the Description and Extended Description fields are displayed correctly. The attribute must be set for ALL processes. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value iso-8859-1

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

The value of this attribute overrides any setting in the xpdl2xfr.xslt file.

TIBCO iProcess Engine Administrators Guide

Back to Library

150

| Chapter 6

Administering Process Attributes

EAI_NEEDS_MSDTC
General iProcess Engine Configuration

This attribute is only relevant to the Windows version of the iProcess Engine. It has no effect on the UNIX version.
Summary

This attribute defines the EAI server plug-ins that need to use the Microsoft Distributed Transaction Coordinator (MSDTC). The attribute can be set for the BG, BGPRDICT and RPCBG processes. The attribute value must be a comma-delimited list of EAI step names. The name used should be the same name used to register the EAI server plug-in. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 0 0 Process BG BGPREDICT RPCBG Instance 0 0 0 Value EAICOM EAICOM EAICOM

Applies To Permissible Values Default Value

Notes

You should set this attribute for any EAI server plug-ins that you develop that require the use of the MSDTC. If you dont do so, EAI steps using the plug-in may not function correctly or in a fully transactional manner. Currently, the only TIBCO iProcess server plug-in that requires the use of the MSDTC is the TIBCO iProcess COM Server Plug-in. The default value for this attribute is therefore set to EAICOM. When a BG process loads an EAI server plug-in, it will check to see if the plug-ins name is specified in the EAI_NEEDS_MSDTC value. If it is, it turns on the use of the MSDTC. For more information about: the MSDTC, see What is MSDTC in the TIBCO iProcess Engine: Architecture Guide. EAI server plug-ins, see Managing EAI Step Server Plug-ins on page 367, and Using Enterprise Application Integration (EAI) Steps in the TIBCO iProcess Modeler - Integration Techniques Guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

EAI_NEEDS_MSDTC 151

the EAI COM server plug-in, see the TIBCO iProcess COM Plug-in: Users Guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

152

| Chapter 6

Administering Process Attributes

LDAP_UV
General iProcess Engine Configuration Summary

This attribute turns on and off the LDAP User Validation API. See the LDAPCONF Utility Users Guide for further details of user validation using LDAP. The attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning LDAP user validation is disabled.

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 0

TIBCO iProcess Engine Administrators Guide

Back to Library

LDAP user validation is enabled.

LOGON_OS_LOCATION 153

LOGON_OS_LOCATION
General iProcess Engine Configuration Summary

This attribute defines the default location where passwords should be validated when a user attempts to logon to this iProcess Engine. This attribute is only used on the Windows variant of the iProcess Engine. It has no effect if it is set on a UNIX system.

Applies To Permissible Values Default Value

The attribute must be set for ALL processes. The attribute value must be a text string containing a single valid machine name or domain name. This attribute is not defined automatically when you install or upgrade the iProcess Engine. To use this attribute, you must explicitly assign a value to it using the SET_ATTRIBUTE command. The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command.

Notes

If the iProcess Engine is running on a machine that is a domain member or domain controller, the user account could exist in multiple places. The iProcess Engine therefore uses the following search path to find the location it should use to validate the users password: 1. the value of the users SW_DOMAIN user attribute (if defined). This attribute specifies a single valid machine name or domain name that should be used to validate a particular users password. (See the TIBCO iProcess Windows (Workspace) Managers Guide for more information about this attribute and how to set it.) 2. the LOGON_OS_LOCATION value (if defined). 3. the search path provided by the Windows LookupAccountName function (which the iProcess Engine uses to find the users account name). This path is: a. well-known Windows security identifiers. (A security identifier (SID) is a unique value that identifies a security principal or security group in

TIBCO iProcess Engine Administrators Guide

Back to Library

154

| Chapter 6

Administering Process Attributes

Windows operating systems. Well-known SIDs are a group of SIDs that identify generic users or generic groups.) b. built-in and administratively defined local accounts. c. the primary domain. d. trusted domains. Note that: If both attributes are set, the SW_DOMAIN value takes precedence over the LOGON_OS_LOCATION value. If the iProcess Engine is running on a standalone machine, passwords are always validated against local machine accounts. The SW_DOMAIN and LOGON_OS_LOCATION attributes are ignored even if they are set.

If the SW_DOMAIN or LOGON_OS_LOCATION attribute is defined, the iProcess Engine checks to see if the user account exists in that location. If the account does not exist there, or if the password does not match the one defined, password validation fails. An error is also written to the SWDIR\logs\sw_warn file indicating that a mismatch has occurred. For example:
2006/11/30 13:23:16(BENCHTST:1968:1968:0:aduser1:filosuvm.c:1.18:373): 1631-WARNING: <LogonStaffwareUser (): LookupAccountName(ssfsf) failed: No mapping between account names and security IDs was done.> <> <> <> 2006/11/30 13:23:16(BENCHTST:1968:1968:0:aduser1:filosuvm.c:1.18:373): 1631-WARNING: <LogonStaffwareUser (): LogonUser(auser1@UK-BONDIC) failed: Logon failure: unknown user name or bad password.> <> <> <>

You should define LOGON_OS_LOCATION (or the SW_DOMAIN user attribute) if user accounts with the same name exist in two or more trusted domains, because you cannot guarantee which domain the LookupAccountName function will check first, and so pick the account information from. Consequently, a logon attempt may fail because it is validated against the wrong domain.

TIBCO iProcess Engine Administrators Guide

Back to Library

LOGON_OS_LOCATION 155

If you use a UVAPI package to perform password validation, you should note that using the LOGON_OS_LOCATION and/or SW_DOMAIN attributes requires that you use extended (_ex) versions of some UVAPI interfaces. The extended interfaces support the passing in and out of user location information from the SW_DOMAIN user attribute and/or LOGON_OS_LOCATION process attribute. (The old interfaces are still supported, but if you use them the location of the user is not passed down from LOGON_OS_LOCATION or SW_DOMAIN attributes.) See the TIBCO iProcess User Validation API Users Guide for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

156

| Chapter 6

Administering Process Attributes

NORMALISE_CASE_DATA
General iProcess Engine Configuration Summary Applies To Permissible Values

This attribute defines whether or not case data normalization is enabled. The attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning Case data normalization is disabled. Case data normalization is enabled.

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 0 or 1

The default value is chosen by the user when they install or upgrade the iProcess Engine.
Notes

This attribute can be set during an installation/upgrade, or by using SWDIR\util\swadm. See Administering Case Data Normalization on page 361 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

TIMEZONE 157

TIMEZONE
General iProcess Engine Configuration Summary Applies To Permissible Values

This attribute defines the time zone that this iProcess Engine will operate in. The attribute must be set for ALL processes. The TIMEZONE value must be a valid time zone recognized by the operating system. It should be specified as a string in the following format:
tzn[+|-]hh[:mm[:ss]][dzn]

where: tzn is a 3-letter name that identifies the time zone, such as GMT or EST. Any meaningful name can be used. [+|-]hh[:mm[:ss] defines the number of hours (and, optionally, minutes and seconds) that the time zone is ahead of or behind GMT. This number represents an offset i.e. the figure to be subtracted from GMT, so timezones that are: behind GMT should be specified as a positive value. ahead of GMT should be specified as a negative value. dzn is a 3-letter name that identifies a daylight-saving time zone, such as BST. If dzn is set daylight saving is enabled and the date and time are adjusted accordingly. Any meaningful name can be used.

Examples

Any of the following strings can be used to define the TIMEZONE value for Washington D.C. (Eastern Standard Time, GMT-05:00):
5 EST5 EST+5 EST05:00

Any of the following strings can be used to define the TIMEZONE value for Sydney, Australia (Western Standard Tim, GMT+10:00):
-10 GMT-10 GMT-10:00:00

Default Value

This attribute is not defined on a newly installed iProcess Engine. If required, it must be explicitly set up using the SET_ATTRIBUTE command. By default, the iProcess Engine will use the host computers local time.

TIBCO iProcess Engine Administrators Guide

Back to Library

158

| Chapter 6

Administering Process Attributes

Notes

This attribute should be set if an iProcess Engine installed on a computer operating in one time zone is being accessed by TIBCO iProcess Workspace instances that are operating in different time zones, to avoid discrepancies between the server and client timestamps. See Configuring the Time Zone for the iProcess Engine on page 14 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

WINTIME_RESYNC_NOTICE 159

WINTIME_RESYNC_NOTICE
General iProcess Engine Configuration Summary

This attribute defines the notice period (in seconds) that iProcess Engine processes are given before a resynchronization takes place. The attribute must be set for ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 60

Applies To Default Value

Notes

See WINTIME_RESYNC_PERIOD on page 160 for more information about the use of this attribute. WINTIME_RESYNC_PERIOD, WINTIME_RESYNC_TOLERANCE

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

160

| Chapter 6

Administering Process Attributes

WINTIME_RESYNC_PERIOD
General iProcess Engine Configuration Summary

This attribute defines the interval (in seconds) at which the iProcess Engine checks to see if its timestamps are in step with Windows system time. The attribute must be set for ALL processes. An integer that is greater than or equal to 0. If this attribute is set to 0 then no checks are performed. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 300

Applies To Permissible Values Default Value

Notes

The iProcess Engine records audit trail timestamps to microsecond precision, and sorts the audit trail based on the timestamp. Because the Windows system timer only returns time to millisecond accuracy, the iProcess Engine uses two system timers to generate its audit trail timestamps - the system timer (GetSystemTime function) and a high-resolution performance counter (QueryPerformanceCounter function) which can be used to provide extra precision. However, it has been found that these timers do not keep in step with each other, and can diverge by up to several seconds over a period of days. This can result in two problems: iProcess Engine timestamps do not correspond to the current Windows time when they are generated. If BG processes are started at different times, any timestamps they generate will be out of synchronization with each other. This can result in audit trail entries appearing out of order.

To deal with these problems, you can use the WINTIME_RESYNC_* process attributes to configure how the iProcess Engine synchronizes its timestamps with Windows system time.

TIBCO iProcess Engine Administrators Guide

Back to Library

WINTIME_RESYNC_PERIOD 161

Every WINTIME_RESYNC_PERIOD seconds the iProcess Engine checks to see if its timestamps are in step with Windows system time. If the timestamps differ by more than WINTIME_RESYNC_TOLERANCE milliseconds the iProcess Engine resynchronizes its timers with Windows system time. iProcess Engine processes are given WINTIME_RESYNC_NOTICE seconds notice before the resynchronization takes place. You can also manually force the iProcess Engine to resynchronize its timestamps with Windows system time by using the SWDIR\util\swsvrmgr RESYNCTIME command. See page 121 for more information.
See Also

WINTIME_RESYNC_NOTICE, WINTIME_RESYNC_TOLERANCE

TIBCO iProcess Engine Administrators Guide

Back to Library

162

| Chapter 6

Administering Process Attributes

WINTIME_RESYNC_TOLERANCE
General iProcess Engine Configuration Summary

This attribute defines the interval (in seconds) at which the iProcess Engine checks to see if its timestamps are in step with Windows system time. The attribute must be set for ALL processes. This value must be an integer that is greater than or equal to 20 (as Windows system time is only accurate to within 15.625ms). Lower values cannot be specified. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 50

Applies To Permissible Values

Default Value

Notes

The tolerance (in milliseconds) by which the TIBCO timestamp and Windows system time can differ. If this value is exceeded, the iProcess Engine resynchronizes its timers with Windows system time. See WINTIME_RESYNC_PERIOD on page 160 for more information about the use of this attribute.

See Also

WINTIME_RESYNC_NOTICE, WINTIME_RESYNC_PERIOD

TIBCO iProcess Engine Administrators Guide

Back to Library

XPC_READ_UNCOMMITTED 163

XPC_READ_UNCOMMITTED
General iProcess Engine Configuration Summary

This attribute applies to SQL Server only. Allows configuration of uncommitted reads during an XPC SELECT.

Applies To Permissible Values

The attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning Uncommitted reads cannot be used. XPC is enabled to use uncommitted reads.

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 0

Notes See Also

None. None.

TIBCO iProcess Engine Administrators Guide

Back to Library

164

| Chapter 6

Administering Process Attributes

Process Management Configuration

The following process attributes allow you to configure the behavior of the iProcess Engine Process Sentinels and server processes. A further set of process attributes allow you to configure specific WIS and WQS behavior - see page 178 for more information.

Attribute CHECKFREQ

Description Defines the number of loops to process before the Process Sentinels checks for SWDIR\logs\sw_error files and available disk space. Defines the times during the day when the Deadline Manager checks the iProcess database for expired deadlines. Defines the time limit in seconds before the Deadline Manager will re-post unprocessed deadline messages. Defines the amount of disk space (in Kilobytes) required for the BG process to run. Defines whether or not the Process Sentinels automatically start the server processes after the Process Sentinels have started. Defines whether or not, if a process fails, the Process Sentinels automatically write to disk the contents of that process debug shared memory segment. Defines whether or not a server process will automatically restart after a failure. Defines the maximum number of times the Process Sentinels will attempt to restart a failed process. Defines the time interval (in seconds) that the Process Sentinels will wait between attempts to restart a failed process.

DMD_PROCESS_INTERVAL

MAX_AGE_BEFORE_RESETPOST MINFREEKB PM_AUTO_BOOT

PROCESS_AUTO_DUMPLOG

PROCESS_AUTO_RESTARTS PROCESS_MAX_RESTARTS PROCESS_MIN_RESTART_PERIOD

TIBCO iProcess Engine Administrators Guide

Back to Library

Process Management Configuration 165

Attribute PROCESS_SLEEP UNPROCESSED_DL_POST_LIMIT

Description Defines the amount of time the Process Sentinels will sleep for. Sets a limit on the number of unprocessed deadline messages that are posted by the Deadline Manager.

TIBCO iProcess Engine Administrators Guide

Back to Library

166

| Chapter 6

Administering Process Attributes

CHECKFREQ
Process Management Configuration Summary

This attribute defines the number of processing loops that the Process Sentinels will cycle through before checking: for SWDIR\logs\sw_error files that the system has sufficient available disk space.

Applies To Default Value

The attribute must be set for ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 50

Notes

The actual time between these checks will therefore be CHECKFREQ * PROCESS_SLEEP seconds. PROCESS_SLEEP

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

DMD_PROCESS_INTERVAL 167

DMD_PROCESS_INTERVAL
Process Management Configuration Summary

This attribute defines the times during the day when the Deadline Manager checks the iProcess database for expired deadlines. The attribute can be set for the DLMGR process. The attribute value must be an integer in the range -1439 to +720, representing a processing interval, in minutes, calculated relative to midnight local time on the server where the DLMGR process is running. If this value is:

Applies To Permissible Values

greater than zero, the processing interval is interpreted as a repeating interval. A repeating interval is used to process deadlines at regular intervals and at set times throughout the day, on each day. If an interval crosses the midnight boundary, the calculation is reset to start from midnight again (so that deadlines are processed at the same times each day).

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 1

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed.

TIBCO iProcess Engine Administrators Guide

Back to Library

zero or less than zero, the processing interval is interpreted as an absolute interval. An absolute interval is used to process deadlines once per day at a set time. A value of zero means exactly midnight.

168

| Chapter 6

Administering Process Attributes

Notes

The following table shows some example settings and the intervals they represent. Value -720 60 0 360 300 Type Absolute Repeating Absolute Repeating Repeating Deadlines will be processed at 12 noon every day. 1am, 2am, 3am...and every hour thereafter. Midnight every day. 6am, 12pm, 6pm, 12am every day 5am, 10am, 3pm, 8pm every day.

See Also

MAX_AGE_BEFORE_RESETPOST, UNPROCESSED_DL_POST_LIMIT

TIBCO iProcess Engine Administrators Guide

Back to Library

Note: Processing on the second day does NOT start at 1am (8pm + 5 hrs)

MAX_AGE_BEFORE_RESETPOST 169

MAX_AGE_BEFORE_RESETPOST
Process Management Configuration Summary

This attribute defines the time limit in seconds before the Deadline Manager will re-post unprocessed deadline messages. This specifies the time period before the Deadline Manager resets its internal marker of the last deadline it has processed to 0 (beginning of time). The attribute can be set for the DLMGR process. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process DLMGR Instance 0 Value 3600

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

DMD_PROCESS_INTERVAL, UNPROCESSED_DL_POST_LIMIT

TIBCO iProcess Engine Administrators Guide

Back to Library

170

| Chapter 6

Administering Process Attributes

MINFREEKB
Process Management Configuration Summary Applies To Default Value

This attribute defines the amount of disk space required for a BG process to run. The attribute can be set for the PROCMGR process. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 10000

TIBCO iProcess Engine Administrators Guide

Back to Library

PM_AUTO_BOOT 171

PM_AUTO_BOOT
Process Management Configuration Summary

This attribute defines whether or not the Process Sentinels automatically start the server processes after the Process Sentinels have started. The attribute can be set for the PROCMGR process. The attribute value must be one of the following: Value 0 1 Meaning The Process Sentinels will not automatically start the server processes.

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process PROCMGR Instance 0 Value 1

This value is the default for a UNIX system. On a Windows system, the value is set by the user when they install or upgrade the iProcess Engine.

TIBCO iProcess Engine Administrators Guide

Back to Library

The Process Sentinels will automatically start the server processes.

172

| Chapter 6

Administering Process Attributes

PROCESS_AUTO_DUMPLOG
Process Management Configuration

You should only use this attribute when explicitly requested to do so by TIBCO Support.
Summary

This attribute defines whether or not, if a process fails, the Process Sentinels automatically write to disk the contents of that process debug shared memory segment. The attribute can be set for any process. The attribute must be assigned one of the following values. Value 0 1 Meaning No debug is written to disk if the process fails. All debug in the process debug shared memory segment is written to disk if the process fails.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 1

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed

TIBCO iProcess Engine Administrators Guide

Back to Library

PROCESS_AUTO_RESTARTS 173

PROCESS_AUTO_RESTARTS
Process Management Configuration Summary

This attribute defines whether or not a server process will automatically restart after a failure. The attribute can be set for any process. The attribute value must be one of the following: Value 0 1 Meaning The process will not automatically restart after a failure.

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 1

See Also

PROCESS_MAX_RESTARTS, PROCESS_MIN_RESTART_PERIOD

TIBCO iProcess Engine Administrators Guide

Back to Library

The process will automatically restart after a failure.

174

| Chapter 6

Administering Process Attributes

PROCESS_MAX_RESTARTS
Process Management Configuration Summary

This attribute defines the maximum number of times the Process Sentinels will attempt to restart a failed process. The attribute can be set for any process. The attribute value must be one of the following: Value 0 n Meaning The Process Sentinels will keep attempting to restart the failed process. The Process Sentinels will attempt to restart the failed process n times (where n is a positive integer).

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 5

See Also

PROCESS_AUTO_RESTARTS, PROCESS_MIN_RESTART_PERIOD

TIBCO iProcess Engine Administrators Guide

Back to Library

PROCESS_MIN_RESTART_PERIOD 175

PROCESS_MIN_RESTART_PERIOD
Process Management Configuration Summary

This attribute defines the time interval (in seconds) that the Process Sentinels will wait between attempts to restart a failed process. The attribute can be set for any process. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 120

Applies To Default Value

See Also

PROCESS_AUTO_RESTARTS, PROCESS_MAX_RESTARTS

TIBCO iProcess Engine Administrators Guide

Back to Library

176

| Chapter 6

Administering Process Attributes

PROCESS_SLEEP
Process Management Configuration Summary

This attribute defines the amount of time (in seconds) the Process Sentinels will sleep for. The attribute can be set for the PROCMGR process. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 5

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed.
Notes

The Process Sentinels go into a sleep/process loop once they have done their initial job of starting all processes. This means that they will sleep for a configurable amount of time in between actively monitoring processes. CHECKFREQ

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

UNPROCESSED_DL_POST_LIMIT 177

UNPROCESSED_DL_POST_LIMIT
Process Management Configuration Summary

This attribute is used to set a limit on the number of unprocessed deadline messages that are posted by the Deadline Manager. This attribute can be set for the DLMGR process. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 10000

Applies To Default Value

This attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed.
Notes

When the UNPROCESSED_DL_POST_LIMIT value is exceeded, the Deadline Manager stops sending deadline messages until the number of deadline messages in the Mbox queue drops below the value that is currently set for this process attribute. If both the UNPROCESSED_DL_POST_LIMIT and MAX_AGE_BEFORE_RESETPOST are reached at the same time, then all the deadline messages are resent.

See Also

MAX_AGE_BEFORE_RESETPOST

TIBCO iProcess Engine Administrators Guide

Back to Library

178

| Chapter 6

Administering Process Attributes

WIS and WQS Process Configuration

The following process attributes allow you to configure the behavior of the WQS and WIS processes. Attribute AUDIT_OPENKEEP CCOUNT_CACHE_REFRESH Description Controls whether the Open Work Item and Keep Work Item audit trail entries are enabled. Enables you to define the refresh period for updating the cached list of cases currently on the system. Defines whether users may keep or release work items even if pack data has changed. Allows the batching of RPC calls to reduce the overhead in processing RPC calls individually. Defines the maximum number of threads that the WIS and WQS processes can use to process RPC requests from client applications. Defines the UNIX shared memory key that is allocated (using the ftok system call) when the WQS process is started. Defines the size (in threads) of the pool of threads that is used to perform caching of work queues. Defines the number of items that must exist in a work queue for it to be cached when the WIS process first handles it. Defines the maximum amount of time (in seconds) that an RPC processing thread in the WIS process waits for a work queue to be cached.

IGNORE_PACK_CHANGED RPC_SVR_CONTROL RPC_SVR_NUM_THREADS

SHMKEY_ID

WIS_CACHE_POOL_SIZE

WIS_CACHE_THRESHOLD

WIS_CACHE_WAIT_TIME

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS and WQS Process Configuration 179

Attribute WIS_CDQP_DATA_RECACHE_BATCH

Description Defines the number of work items that the CDQP update thread will update in a single operation when updating CDQP field values for a WIS process queues. Defines the count boundary at which a work queue will be split into multiple blocks of work for filtering purposes, based on the number of work items in the queue Defines the number of threads in the queue filtering thread pool, used to process additional blocks of filtering work Defines the interval (in seconds) after which an index on a queue will be refreshed by a WIS process. Defines the number of locks in the internal lock pool used by the WIS process Defines the number of new item requests to be batched together. Defines whether or not a change in the lock status of a work item is counted as a change to the work item. Defines the timeout period (in seconds) after which a WIS process will automatically shut down, starting from the time at which it was last accessed (by a TIBCO iProcess Workspace, SAL application or TIBCO iProcess Objects Server). Defines the timeout period (in seconds) after which a WIS process will automatically shut down, starting from the time at which the iProcess Engine was shut down. Defines the maximum amount of time (in seconds) that the queue update thread in the WIS process performs updates for before going back to sleep.

WIS_FILTER_THREAD_BOUNDARIES

WIS_FILTER_THREAD_POOL_SIZE

WIS_INDEX_REFRESH

WIS_LOCK_POOL_SIZES WIS_NEW_ITEM_BATCH_SIZE WIS_QCHANGE_EXTENDED_CHECK

WIS_SESSION_TIMEOUT

WIS_SESSION_TIMEOUT_SHUTDOWN

WIS_UPDATE_LENGTH

TIBCO iProcess Engine Administrators Guide

Back to Library

180

| Chapter 6
Attribute

Administering Process Attributes

Description Defines how often the queue update thread in the WIS process wakes up and updates the queues handled by the WIS process. Allows the use of priority escalation in the WIS process to be disabled. Allows the gathering of RPC call stats within the WQS process to be configurable. Defines the maximum number of slots available in the SWRPCMTS multi-threaded RPC server shared library for threads to perform queue searching. Defines how often (in seconds) the contents of the WQS/WIS shared memory are written to the wqs_index database table. Defines the number of WIS processes that should be dedicated to handling user queues and group queues respectively.

WIS_UPDATE_PERIOD

WIS_USE_PRIORITY_ESCALATION WQS_GATHER_RPC_STATS WQS_NUM_SEARCH_SLOTS

WQS_PERSIST_SHMEM

WQS_WIS_USER_COUNT

TIBCO iProcess Engine Administrators Guide

Back to Library

AUDIT_OPENKEEP 181

AUDIT_OPENKEEP
WIS and WQS Process Configuration Summary

This attribute determines if opening or keeping a work item generates an audit trail entry. The default behavior is not to produce audit trail entries when a work item is opened or kept. Enabling this option may cause opening and keeping activities to be marginally slower, and could significantly increase the size of an audit trail. This attribute should be set for ALL processes. The attribute must be assigned one of the following values. Value 0 1 Meaning Open and Keep audit messages are not posted. Open and Keep audit messages are posted.

Applies to Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 0

Notes

If this attribute is set to 1, the WIS posts an audit message to the BG process whenever an Open or a Keep operation is performed on a work item. See messages 059 and 060 in Appendix D, Understanding Audit Trails.

TIBCO iProcess Engine Administrators Guide

Back to Library

182

| Chapter 6

Administering Process Attributes

CCOUNT_CACHE_REFRESH
WIS and WQS Process Configuration Summary

This attribute enables you to define the refresh period for updating the cached list of cases currently on the system. The Background process can retrieve a case count list from the database by looking at which procedures have cases running. The case count list is used by utilities such as Audit Trail and Case Administration. These utilities refer to the cached list so that they do not have to retrieve a list of cases from the database every time, thereby improving performance. This attribute should be set for ALL processes. The attribute must be assigned one of the following values. Value n Meaning The number of seconds between refreshes of the cached list.

Applies to Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 30

TIBCO iProcess Engine Administrators Guide

Back to Library

IGNORE_PACK_CHANGED 183

IGNORE_PACK_CHANGED
WIS and WQS Process Configuration Summary

This attribute defines whether users can Keep or Release work items even if the items pack data has changed since they opened it. This attribute can be set for a WIS process (only). The attribute must be assigned one of the following values. Value 0 1 Meaning Pack data changes lock work items. A user cannot Keep or Release a work item that has had its pack data updated since the user opened it. Pack data changes are ignored. A user may Keep or Release a work item that has had its pack data updated since the user opened it. If any of the users changes to the work item conflict with the changed pack data, the users changes overwrite them.

Applies to Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value 0

This attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed.
Notes

In earlier iProcess Engine versions, if pack data is updated for a work item while a user has that work item open (for example, via a SWDIR\bin\swutil EVENT -p command), the WIS process locks the work item and does not allow the user to Keep or Release it. The following error is displayed to the user when they try to Keep or Release the work item: Error case data updated elsewhere since item opened. Please open item and edit it again. Setting IGNORE_PACK_CHANGED to 1 allows users to Keep or Release work items even if the items pack data has changed since they opened it.

TIBCO iProcess Engine Administrators Guide

Back to Library

184

| Chapter 6

Administering Process Attributes

RPC_SVR_CONTROL
WIS and WQS Process Configuration Summary

This attribute allows the batching of RPC calls to reduce the overhead of processing RPC calls individually. This attribute should be set for ALL processes. This attribute must be in the form B[,<batch size>] where <batch size> specifies either 0 to turn off batching or the number of items to be batched. The default value is 20. For example, B = Set batch size to default (20)

Applies To Permissible Values

B,0 = Turn off batching of RPC calls B,10 = Set batch size to 10
Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value B

Notes

Using this attribute reduces the overhead in processing RPC calls individually. Any slight overhead in waiting for 20 (or the number specified) to be batched should not be noticeable. N/A.

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

RPC_SVR_NUM_THREADS 185

RPC_SVR_NUM_THREADS
WIS and WQS Process Configuration Summary

This attribute defines the maximum number of threads that the WIS and WQS processes can use to process RPC requests from client applications. This attribute should be set for ALL processes. This attribute must be an integer in the range 1 to 100 (but see the Notes below). The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 5

Applies To Permissible Values Default Value

Notes

To process RPC requests, both the WIS and WQS processes access a pool of worker threads that is provided by a multi-threaded RPC server shared library (SWRPCMTS). This attribute defines the number of threads that are available in the SWRPCMTS library to process RPC requests. The maximum RPC_SVR_NUM_THREADS value is also limited by the value of the WQS_NUM_SEARCH_SLOTS process attribute. If you want to increase the RPC_SVR_NUM_THREADS value beyond the WQS_NUM_SEARCH_SLOTS value, you must stop the iProcess Engine, change the RPC_SVR_NUM_THREADS value and then restart the iProcess Engine. If you try to increase RPC_SVR_NUM_THREADS beyond WQS_NUM_SEARCH_SLOTS without stopping the iProcess Engine, the RPC_SVR_NUM_THREADS value will instead be set to the WQS_NUM_SEARCH_SLOTS value. You can adjust the value of this process attribute to optimize the WQS and WIS process response times when processing RPC requests against available CPU capacity. Increasing the number of threads will improve the throughput of client RPC requests, but at the cost of increased CPU usage.

See Also

WIS_FILTER_THREAD_BOUNDARIES, WIS_FILTER_THREAD_POOL_SIZE, WQS_NUM_SEARCH_SLOTS

TIBCO iProcess Engine Administrators Guide

Back to Library

186

| Chapter 6

Administering Process Attributes

SHMKEY_ID
WIS and WQS Process Configuration

TIBCO recommend that you do not change the value of this attribute unless you are instructed to do so by TIBCO Support, or you are fully familiar with the use of UNIX shared memory and the operation of the ftok system call.
Summary

This attribute defines the UNIX shared memory key that is allocated (using the ftok system call) when the WQS process is started This attribute must be set for ALL processes. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value x

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

The default value should work correctly in most situations. However, it is possible for a shared memory conflict to occur - for example, if the iProcess Engine is restarted, another application may allocate to itself the shared memory key that iProcess expects to use when it restarts. If this happens, the WQS process will fail to start, and the following error message is written to the SWDIR\logs\sw_error file:
WQS initialise failed, connected to shared memory for

nodename

where nodename is either a valid nodename, or blank. If such a shared memory conflict does occur you can change the SHMKEY_ID value to resolve it.

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_CACHE_POOL_SIZE 187

WIS_CACHE_POOL_SIZE
WIS and WQS Process Configuration Summary

This attribute defines the size (in threads) of the pool of threads that is used to perform caching of work queues. This attribute can be set for a WIS process (only). This attribute must be an integer in the range 1 to 100. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 4

Applies To Permissible Values Default Value

Notes

You may want to increase the WIS_CACHE_POOL_SIZE value if there are a large number of work queues that need caching at one time. When all the work queues have been cached you may want to reduce the value again, as the threads in this pool will not be used until a new queue is first handled by a WIS process. See Configuring When WIS Processes Cache Their Queues on page 355 for more information.

See Also

WIS_CACHE_THRESHOLD, WIS_CACHE_WAIT_TIME

TIBCO iProcess Engine Administrators Guide

Back to Library

188

| Chapter 6

Administering Process Attributes

WIS_CACHE_THRESHOLD
WIS and WQS Process Configuration Summary

This attribute defines the number of items that must exist in a work queue for it to be cached when the WIS process first handles it. This attribute can be set for a WIS process (only). This attribute must be an integer in the range 0 to 500000. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is:. Machine ID 0 Process WIS Instance 0 Value 1000

Applies To Permissible Values Default Value

This attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed.
Notes

This attribute is used in conjunction with the WISCACHE queue attribute to control when a queue is cached, either: when the WIS process first handles it (either on startup or after a MoveSysInfo operation), or when it is first accessed by a client application.

When the WIS process first handles a queue it checks the value of the WISCACHE queue attribute: If WISCACHE is set to YES, the WIS process caches the queue (irrespective of how many work items it contains). If WISCACHE has not been created, or is not set, the WIS process caches the queue if it contains a number of work items that equals or exceeds the value of this attribute.

You may want to increase the value of this attribute if work queues have very few or no CDQPs defined, which means that they can be cached relatively quickly. Increasing the WIS_CACHE_THRESHOLD value can improve WIS process startup times, as less queues are cached when they are first handled by the WIS processes. Conversely, if too many queues are being cached on demand, client applications may have to wait for queues to become available while they are being cached.

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_CACHE_THRESHOLD 189

See Configuring When WIS Processes Cache Their Queues on page 355 for more information.
See Also

WIS_CACHE_POOL_SIZE, WIS_CACHE_WAIT_TIME, WQS_PERSIST_SHMEM

TIBCO iProcess Engine Administrators Guide

Back to Library

190

| Chapter 6

Administering Process Attributes

WIS_CACHE_WAIT_TIME
WIS and WQS Process Configuration Summary

This attribute defines the maximum amount of time (in seconds) that an RPC processing thread in the WIS process waits for a work queue to be cached. This attribute can be set for a WIS process (only). This attribute must be an integer in the range 0 to unlimited.

Applies To Permissible Values

This value must be set to a value less than:

The iProcess Objects SAL RPC Timeout (the default is 25 seconds). See the TIBCO iProcess Objects Programmers Guide for information.

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 5

Notes

When a client application makes an RPC call to a work queue that has not already been cached, the WIS process immediately begins caching it. If the WIS_CACHE_WAIT_TIME value is reached and the work queue has still not been cached, the WIS process returns an ER_CACHING error to the client application. See Configuring When WIS Processes Cache Their Queues on page 355 for more information.

See Also

WIS_CACHE_POOL_SIZE, WIS_CACHE_THRESHOLD

TIBCO iProcess Engine Administrators Guide

Back to Library

The iProcess Workspace RPC Timeout period (the default is 25 seconds). See the TIBCO iProcess Workspace Managerss Guide for information.

WIS_CDQP_DATA_RECACHE_BATCH 191

WIS_CDQP_DATA_RECACHE_BATCH
WIS and WQS Process Configuration Summary

This attribute defines the number of work items that the CDQP update thread will update in a single operation when updating CDQP field values for a WIS process queues. This attribute should be set for a WIS process (only). This attribute must be an integer in the range 1000 to 500000.

Applies To Permissible Values Default Value

Machine ID 0
Notes

Process WIS

Instance 0

Value 5000

The WIS process CDQP update thread is used to update CDQP field values for work items in its queues following a SWDIR\bin\swutil QINFO PUBLISH command. The CDQP update thread updates each work item in each queue handled by the WIS process, updating WIS_CDQP_DATA_RECACHE_BATCH items at the same time. The CDQP update thread obtains the updated CDQP field values from the pack_data database table, which prevents other processes from updating or deleting any rows in the table that the CDQP update thread is accessing. If you find that performance is impacted after a SWDIR\bin\swutil QINFO PUBLISH command, you should reduce the WIS_CDQP_DATA_RECACHE_BATCH value. See Configuring CDQP Updates on page 357 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

The attribute is assigned the following default value when the iProcess Engine is installed.

192

| Chapter 6

Administering Process Attributes

WIS_FILTER_THREAD_BOUNDARIES
WIS and WQS Process Configuration Summary

This attribute defines the count boundary at which a work queue will be split into multiple blocks of work for filtering purposes, based on the number of work items in the queue. This attribute can be set for the WIS process (only). This attribute must be a string in the following format:
Threshold1[:Threshold2[:Threshold3[:Threshold4]]]

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 100,000

Notes

By default, the WIS process uses the thread that is processing an RPC request to perform any work queue filtering required by that RPC request. When the number of items in a work queue reaches one of the threshold values defined in this attribute, the queue is split into equal blocks of filtering work. The first block is still handled by the RPC processing thread. Subsequent blocks are handled by threads from the queue filtering thread pool (the number of which is defined by the WIS_FILTER_THREAD_POOL_SIZE attribute). Modifying this attribute can therefore reduce the time taken by the WIS process to filter work queues, particularly when queues are large or use complex filter criteria involving expressions or CDQPs. See Configuring How Work Queues are Filtered on page 353 for more information.

Examples

The following example means that the queue will be split into two blocks of work for filtering purposes when the number of work items in the queue reaches 100000. The queue is split into two equal blocks of 50000 work items. The first block is handled by the original RPC processing thread and the second is handled by one of the queue filtering threads.
100000

TIBCO iProcess Engine Administrators Guide

Back to Library

where the four Threshold parameters are numeric values indicating the number of work items in a work queue at which an additional block of filtering work will be created. Each subsequent value, if used, must be greater than the preceding value.

WIS_FILTER_THREAD_BOUNDARIES 193

The following example means that the queue will be split into two filtering blocks (each of 50000 work items) when the number of work items in the queue reaches 100000, and into three blocks (each of 60000 work items) when the number of items reaches 180000. The first block is handled by the original RPC processing thread. The second and third blocks are handled by the queue filtering threads.
100000:180000

See Also

RPC_SVR_CONTROL, WIS_FILTER_THREAD_POOL_SIZE

TIBCO iProcess Engine Administrators Guide

Back to Library

194

| Chapter 6

Administering Process Attributes

WIS_FILTER_THREAD_POOL_SIZE
WIS and WQS Process Configuration Summary

This attribute defines the number of threads in the queue filtering thread pool, used to process additional blocks of filtering work. This attribute can be set for the WIS process (only). This attribute must be an integer that is greater than or equal to 1. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 8

Applies To Permissible Values Default Value

Notes

By default, the WIS process uses the thread that is processing an RPC request to perform any work queue filtering required by that RPC request. When the number of items in a work queue reaches one of the threshold values defined in the WIS_FILTER_THREAD_BOUNDARIES attribute, the queue is split into equal blocks of filtering work. The first block is still handled by the RPC processing thread. Subsequent blocks are handled by threads from the queue filtering thread pool (the number of which is defined by this attribute). Modifying this attribute can therefore reduce the time taken by the WIS process to filter work queues, particularly when queues are large or use complex filter criteria involving expressions or CDQPs. See Configuring How Work Queues are Filtered on page 353 for more information.

See Also

RPC_SVR_CONTROL, WIS_FILTER_THREAD_BOUNDARIES

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_INDEX_REFRESH 195

WIS_INDEX_REFRESH
WIS and WQS Process Configuration Summary

This attribute value defines the interval (in seconds) after which an index on a work queue will be refreshed by a WIS process. You can set this attribute to fine tune the memory footprint of a WIS process. The attribute can be set for a WIS process. The attribute value must be an integer, with a minimum value of 10. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value 300

Applies To Permissible Values Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

When a user or process accesses a work queue, the WIS process creates an index in memory for subsequent use with that view of the queue. The WIS process holds a copy of all work item data for the queue in memory, referenced by the index, until the data is no longer needed. Refreshing the index clears out any information that is no longer needed for that view, thus reducing the memory footprint of the WIS process. If users or processes have indexes onto a busy queue and these indexes are not refreshed, the WIS memory footprint grows (because old records are not released and new memory is required for new items entering the queue). For example, if a user leaves a TIBCO iProcess Workspace session logged in on a queue and does not refresh that queue, any items removed from the queue (through purging, forwarding or releasing) will still be held in memory, causing the WIS memory footprint to grow.

TIBCO iProcess Engine Administrators Guide

Back to Library

196

| Chapter 6

Administering Process Attributes

WIS_LOCK_POOL_SIZES
WIS and WQS Process Configuration Summary

This attribute defines the number of locks in the internal lock pool used by the WIS process. Do not change the value of this process attribute unless you are advised to do by TIBCO Support.

Applies To Permissible Values

The attribute can be set for a WIS process (only). The attribute value must be one of the following: Value TINY SMALL MEDIUM LARGE HUGE GIGANTIC VAST Meaning Sets the size of the internal lock pool. (The actual numbers represented by these values are set internally by the iProcess Engine.)

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value MEDIUM

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_LOCK_POOL_SIZES 197

Notes

The WIS process uses pools of locks to reduce its resource usage when handling large numbers of queues and work items. Because these locks are in pools, the resources required for locking do not increase as the number of work queues and work items increases. This attribute is only read when the iProcess Engine starts up. Any changes that are made when the iProcess Engine is running are ignored.

TIBCO iProcess Engine Administrators Guide

Back to Library

198

| Chapter 6

Administering Process Attributes

WIS_NEW_ITEM_BATCH_SIZE
WIS and WQS Process Configuration Summary

This attribute value defines the number of new item requests to be batched together so more can be processed in a single write lock. The attribute can be set for a WIS process. The attribute value must be an integer between 0 and 500000 where 0 means that batching is not used. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value 0

Applies To Permissible Values Default Value

Notes

If you have batching turned on and less than the batch size value number of items come into the queue, then the update thread, when it next wakes up, will process any items batched up. Or, if another RPC request comes in to add a new item that takes the batch size over the configured value, then all items will be processed. Using this attribute means that incoming items from the WISMBD are batched up before the index is updated (similar to pre 10.3 versions). This reduces the load on the system, but does mean that new items take longer to appear in the queue (by at most the WIS_INDEX_REFRESH period of time).

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_QCHANGE_EXTENDED_CHECK 199

WIS_QCHANGE_EXTENDED_CHECK
WIS and WQS Process Configuration Summary

This attribute changes the behavior of a WIS process as to whether it counts changes to the lock status of work items as changes to the work items and work queues. The attribute can be set for a WIS process. The attribute value must be one of the following: Value 0 1 Meaning

Applies To Permissible Values

A change to the lock status of a work item is counted as a change to the work item.

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed.
Notes

If this attribute is not set, changes to the lock status of work items are not counted as changes to queues for the purpose of monitoring changes in queues. This means that if a user just locks or keeps an item without making any other changes to a queue, then iProcess Objects or the SAL does not flag that any changes have been made to the queue, and even if the queue is refreshed, no changes are apparent. If this attribute is set then the lock status is changed (the QPAR version number is updated and the OREC version number is incremented) in the following situations: when a work item is opened when the first work item that is not locked is opened when a work item is kept
TIBCO iProcess Engine Administrators Guide

Back to Library

A change in the lock status of a work item is not counted as a change to the work item.

200

| Chapter 6

Administering Process Attributes

This allows the iProcess Engine to detect these changes in the queue.

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_SESSION_TIMEOUT 201

WIS_SESSION_TIMEOUT
WIS and WQS Process Configuration Summary

This attribute defines the timeout period (in seconds) after which a WIS process will automatically shut down, starting from the time at which it was last accessed (by a TIBCO iProcess Workspace, SAL application or iProcess Objects Server). The attribute can be set for a WIS process. The attribute value must be one of the following: Value 0 n Meaning Do not timeout WIS processes. The timeout period, where n is any integer value equal to or greater than 60.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value 28800

The default value gives a timeout period of 8 hours. The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

WIS_SESSION_TIMEOUT_SHUTDOWN

TIBCO iProcess Engine Administrators Guide

Back to Library

202

| Chapter 6

Administering Process Attributes

WIS_SESSION_TIMEOUT_SHUTDOWN
WIS and WQS Process Configuration Summary

This attribute defines the timeout period (in seconds) after which a WIS process will automatically shut down, starting from the time at which the iProcess Engine was shut down. The attribute can be set for a WIS process. The attribute value must be an integer, with a minimum value of 60. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process WIS Instance 0 Value 300

Applies To Permissible Values Default Value

The default value gives a timeout period of 5 minutes. The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

WIS_SESSION_TIMEOUT

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_UPDATE_LENGTH 203

WIS_UPDATE_LENGTH
WIS and WQS Process Configuration Summary

This attribute defines the maximum amount of time (in seconds) that the queue update thread in the WIS process performs updates for before going back to sleep. This attribute can be set for the WIS process (only). This attribute must be an integer with a minimum value of 5. There is no maximum value. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 120

Applies To Permissible Values Default Value

Notes

The queue update thread wakes up every WIS_UPDATE_PERIOD seconds. It updates work queues for WIS_UPDATE_LENGTH seconds, then goes back to sleep. If it has updated all the queues before the WIS_UPDATE_LENGTH period has expired, it goes back to sleep immediately. You should decrease the WIS_UPDATE_LENGTH value if you find that the update thread in the WIS process is using too much CPU. See Configuring Queue Updates on page 354 for more information.

See Also

WIS_UPDATE_PERIOD

TIBCO iProcess Engine Administrators Guide

Back to Library

204

| Chapter 6

Administering Process Attributes

WIS_UPDATE_PERIOD
WIS and WQS Process Configuration Summary

This attribute defines how often the queue update thread in the WIS process wakes up and updates the queues handled by the WIS process. This attribute can be set for the WIS process (only). This attribute must be an integer in the range 10 to 3600. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 5

Applies To Permissible Values Default Value

Notes

The queue update thread wakes up every WIS_UPDATE_PERIOD seconds. It updates work queues for WIS_UPDATE_LENGTH seconds, then goes back to sleep. If it has updated all the queues before the WIS_UPDATE_LENGTH period has expired, it goes back to sleep immediately. See Configuring Queue Updates on page 354 for more information.

See Also

WIS_UPDATE_LENGTH

TIBCO iProcess Engine Administrators Guide

Back to Library

WIS_USE_PRIORITY_ESCALATION 205

WIS_USE_PRIORITY_ESCALATION
WIS and WQS Process Configuration Summary

This attribute allows the use of priority escalation in the WIS process to be disabled. This attribute can be set for the WIS process (only). The attribute value must be one of the following: Value 0 Meaning Priority ageing will no longer be processed. Every item that is displayed will use the default priority as set in the staffcfg file. Changes to priority fields will not affect the current priority value of a work item. Priority ageing will still function.

Applies To Permissible Values

1
Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WIS Instance 0 Value 1

Notes

This attribute can be turned off for a small performance and CPU benefit. However, you should only do this if you are not using the Priority escalation feature as switching it off will prevent the priority value being automatically decremented. Be careful to ensure you are not using this feature before disabling it. n/a

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

206

| Chapter 6

Administering Process Attributes

WQS_GATHER_RPC_STATS
WIS and WQS Process Configuration Summary

This attribute allows the gathering of RPC call stats within the WQS process to be configurable. This attribute should be set for the WQS process. The attribute value must be one of the following: Value 0 1 Meaning RPC stats gathering is turned off.

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WQS Instance 0 Value 0

Notes

When the attribute is turned off and then on again, any previously gathered stats are not retained. To use the attribute, turn on R=2 debug on the WQS process, set the process attribute and the stats will be seen in the debug log. TIBCO recommend that this attribute be turned off unless you specifically require these stats.

See Also

N/A

TIBCO iProcess Engine Administrators Guide

Back to Library

RPC stats gathering is turned on.

WQS_NUM_SEARCH_SLOTS 207

WQS_NUM_SEARCH_SLOTS
WIS and WQS Process Configuration Summary

This attribute defines the maximum number of slots available in the SWRPCMTS multi-threaded RPC server shared library for threads to perform queue searching. This is an internal design feature that limits the number of worker threads available for the WQS process to use to process RPC requests. Do not change the value of this process attribute unless you are advised to do so by TIBCO Support.

Applies To Permissible Values Default Value

This attribute should be set for ALL processes.

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 50

Notes

This attribute cannot be set when the WQS process is running. You must stop the iProcess Engine if you want to change the value of this attribute. When the iProcess Engine starts up the WQS process checks the value of the RPC_SVR_CONTROL process attribute. If it is: less than or equal to the WQS_NUM_SEARCH_SLOTS value, the WQS_NUM_SEARCH_SLOTS value is left unchanged. greater than the WQS_NUM_SEARCH_SLOTS value, WQS_NUM_SEARCH_SLOTS is reset to 2 * RPC_SVR_NUM_THREADS.

See Also

RPC_SVR_CONTROL

TIBCO iProcess Engine Administrators Guide

Back to Library

This attribute must be an integer that is greater than or equal to the value of the RPC_SVR_CONTROL process attribute.

208

| Chapter 6

Administering Process Attributes

WQS_PERSIST_SHMEM
WIS and WQS Process Configuration Summary

This attribute defines how often (in seconds) the contents of the WQS/WIS shared memory are written to the wqs_index table in the database. This attribute can be set for the WQS process (only). The attribute value must be an integer in the range 1 to 3600. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process WQS Instance 0 Value 300

Applies To Permissible Values Default Value

Notes

When the WIS process starts up, it uses the total_items column in the wqs_index table to determine the number of work items in each work queue. It compares this value to the WIS_CACHE_THRESHOLD value to determine whether to cache the work queue. If the TIBCO iProcess Engine is started, cases are loaded into a work queue, then the system is shut down again within the WQS_PERSIST_SHMEM value, the item counts in the wqs_index table will not match the actual item counts. See Configuring When WIS Processes Cache Their Queues on page 355 for more information.

See Also

WIS_CACHE_THRESHOLD

TIBCO iProcess Engine Administrators Guide

Back to Library

WQS_WIS_USER_COUNT 209

WQS_WIS_USER_COUNT
WIS and WQS Process Configuration Summary

This attribute defines the number of WIS processes that should be dedicated to handling user queues and group queues respectively. The attribute can be set for the WQS process. The attribute value must be a string, and can be either: a number, indicating the number of WIS processes that should be dedicated to handling user queues. For example:
"2"

Applies To Permissible Values

"20%"

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case (or if the attribute is defined incorrectly), queues are allocated to WIS processes alphabetically, irrespective of whether they are user or group queues (either by round robin or on-demand allocation - see WQS_ROUND_ROBIN on page 47). The remaining WIS processes will be dedicated to handling group queues. Note that: There must always be at least one WIS available to handle user queues and one WIS to handle group queues if the attribute is defined. The attribute value should be set accordingly. If a percentage value is used, iProcess will round this figure down, subject to there being at least one WIS available to handle user queues. For example, the following table shows how different WQS_WIS_USER_COUNT values are interpreted, depending on the number of available WIS processes. Value "20%" "50%" "50%" "90%" Number of WIS processes 5 5 6 5 Resulting allocation for: User queues 1 2 3 4 Group queues 4 3 3 1

Notes

TIBCO iProcess Engine Administrators Guide

Back to Library

a percentage in the range 1% to 99%, indicating the percentage of WIS processes that should be dedicated to handling user queues. For example:

210

| Chapter 6

Administering Process Attributes

Value "90%" "10%"

Number of WIS processes 20 5

Resulting allocation for: User queues 18 1 Group queues 2 4

If there are not enough WIS processes configured to create the specified allocation, the WQS_WIS_USER_COUNT value is ignored, default queue allocation is used, and one of the following messages is written to the SWDIR\logs\sw_warn file:
WQS_WIS_USER_COUNT ignored - too big

or
WQS_WIS_USER_COUNT ignored - percentage too big

For example, if there are 5 WIS processes configured, the following WQS_WIS_USER_COUNT values would all generate an error as described: "0" "0%" "5" "6" "100%" "150%" WIS processes can also be dedicated to handling explicitly specified queues see Assigning a Queue Explicitly to a WIS Process on page 347. Dedicated queues are not considered when calculating the allocation of WIS processes to user queue or group queue pools. The following table shows how the allocations described in the example above would be affected if one of the WIS processes was subsequently dedicated to handling a specific queue. (The red values show the changes.) Number of non-dedicated WIS processes 4 4 5 4 Resulting allocation for: User queues 1 2 2 3 Group queues 3 2 3 1

Value "20%" "50%" "50%" "90%"

TIBCO iProcess Engine Administrators Guide

Back to Library

WQS_WIS_USER_COUNT 211

Value "90%" "10%"

Number of non-dedicated WIS processes 19 4

Resulting allocation for: User queues 17 1 Group queues 2 3

TIBCO iProcess Engine Administrators Guide

Back to Library

212

| Chapter 6

Administering Process Attributes

Message and Mbox Processing Configuration

The following process attributes allow you to configure how the iProcess Engine processes messages. Attribute DBQD_MAX_CACHED_MESSAGES Description Defines the number of messages that are cached by the DBQD process when it requests a block of messages from a database message queue. Defines the number of concurrent threads that the DBQD process uses to process RPC requests for messages from its cache from BG or WISMBD processes. Defines how long the Mbox Daemons will sleep when all Mbox queues in the Mbox set are empty. Defines the number of seconds to increment the EMPTYMBOXSLEEP value by when a BG or WISMBD process requests a message from an empty Mbox. Defines the maximum value (in seconds) that EMPTYMBOXSLEEP can be set to. Defines how many times a failed message in a message queue is retried before being moved to the exception queue. Defines the delay (in seconds) between each retry attempt for a failed message in a message queue, before the message is moved to the exception queue. Defines the unique identifier of the Mbox set to be used by a BG process when dequeuing messages received from a WISMBD process. Defines the unique identifier of the Mbox set to be used by a BGPREDICT process when posting case changes messages to a BG process.

DBQD_MAX_FIL_SESSIONS

EMPTYMBOXSLEEP EMPTYMBOXSLEEP_INC

EMPTYMBOXSLEEP_MAX IQL_RETRY_COUNT

IQL_RETRY_DELAY

MBSET_READ_BG

MBSET_READ_PREDICT

TIBCO iProcess Engine Administrators Guide

Back to Library

Message and Mbox Processing Configuration 213

Attribute MBSET_READ_WIS

Description Defines the unique identifier of the Mbox set to be used by a WISMBD process when dequeuing messages received from a BG process. Defines the unique identifier of the Mbox set to be used by a process when writing to a BG process. Defines the unique identifier of the Mbox set to be used by a BGPREDICT process when posting case changes messages to a BG process. Defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by the BG process when writing to a WISMBD process. Defines how many times a failed message in a message queue is retried before sending a message to the Process Sentinels.

MBSET_WRITE_BG MBSET_WRITE_PREDICT

MBSET_WRITE_WIS

THRESHOLD_FAIL_TIMES_TO_REPOR T_IQL_MESSAGE

TIBCO iProcess Engine Administrators Guide

Back to Library

214

| Chapter 6

Administering Process Attributes

DBQD_MAX_CACHED_MESSAGES
Message and Mbox Processing Configuration

This attribute is currently only used on the DB2 version of the iProcess Engine. It has no effect on the Oracle or SQL Server versions.
Summary

This attribute defines the number of messages that are cached by the DBQD process when it requests a block of messages from a database message queue. This attribute can be set for the DBQD process (only). The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process DBQD Instance 0 Value 1000

Applies To Default Value

Notes

Each BG and WISMBD process requests a message from one of its allocated message queues whenever it is not either already processing a message or sleeping. The DBQD process receives this request and returns a message from its cache for the specified queue. If the cache is empty, the DBQD process requests another block of DBQD_MAX_CACHED_MESSAGES messages from the database message queue to refill the cache. The rate at which messages are processed from the cache depends upon the number of BG and WISMBD processes that are running, and the type of procedure being processed. For example, procedures involving significant use of deadlines or EAI steps would take longer to process than those involving normal steps. Increasing the DBQD_MAX_CACHED_MESSAGES value increases the amount of memory used by the DBQD process and the time required to perform the caching operation. Decreasing this value means that the process needs to access the database to refill its cache more often.

See Also

DBQD_MAX_FIL_SESSIONS, EMPTYMBOXSLEEP

TIBCO iProcess Engine Administrators Guide

Back to Library

DBQD_MAX_FIL_SESSIONS 215

DBQD_MAX_FIL_SESSIONS
Message and Mbox Processing Configuration

This attribute is currently only used on the DB2 version of the iProcess Engine. It has no effect on the Oracle or SQL Server versions.
Summary

This attribute defines the number of concurrent threads that the DBQD process uses to process RPC requests for messages from its cache from BG or WISMBD processes. You may need to alter this value according to the number of BG and WISMBD processes you have configured on the system. This attribute can be set for the DBQD process (only).

Applies To Default Value

Machine ID 0
See Also

Process DBQD

Instance 0

Value 5

DBQD_MAX_CACHED_MESSAGES

TIBCO iProcess Engine Administrators Guide

Back to Library

The attribute is assigned the following default value when the iProcess Engine is installed.

216

| Chapter 6

Administering Process Attributes

EMPTYMBOXSLEEP
Message and Mbox Processing Configuration Summary

This attribute defines the number of seconds that a BG or WISMBD process sleeps when all Mbox queues in its Mbox set are empty. This attribute can be set for BG, WISMBD or ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 2

Applies To Default Value

Notes

Whenever a BG or WISMBD process requests a message from an empty Mbox, the EMPTYMBOXSLEEP value is incremented by the EMPTYMBOXSLEEP_INC value until either: the EMPTYMBOXSLEEP_MAX value is reached, or a message is returned from the Mbox, in which case EMPTYMBOXSLEEP is reset to its configured value.

By tailoring the values of these three attributes to your particular system configuration, you can avoid unnecessary system overhead resulting from polling for messages on empty queues. You may notice a delay in processing messages if the system is very quiet and the EMPTYMBOXSLEEP value has increased to its maximum. For example: A user releases a work item just after the BG process has polled the Mbox. The message remains in the Mbox until the sleep period has expired. The BG processes the release instruction and sends out the next work item. That message arrives in its Mbox just after the WISMBD process has polled it, and so remains there until the next sleep period has expired.

In this way, there could be a delay between the work item being released and the next work item arriving of approximately twice the EMPTYMBOXSLEEP_MAX value, even though the system is otherwise idle.
See Also

EMPTYMBOXSLEEP_INC, EMPTYMBOXSLEEP_MAX

TIBCO iProcess Engine Administrators Guide

Back to Library

EMPTYMBOXSLEEP_INC 217

EMPTYMBOXSLEEP_INC
Message and Mbox Processing Configuration Summary

This attribute defines the number of seconds to increment the EMPTYMBOXSLEEP value by when a BG or WISMBD process requests a message from an empty Mbox. This attribute can be set for BG, WISMBD or ALL processes. The attribute value must be a numeric value in the range 0 to EMPTYMBOXSLEEP_MAX. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 2

Applies To Permissible Values Default Value

See Also

EMPTYMBOXSLEEP, EMPTYMBOXSLEEP_MAX

TIBCO iProcess Engine Administrators Guide

Back to Library

218

| Chapter 6

Administering Process Attributes

EMPTYMBOXSLEEP_MAX
Message and Mbox Processing Configuration Summary

This attribute defines the maximum value (in seconds) that EMPTYMBOXSLEEP can be set to. This attribute can be set for BG, WISMBD or ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 2

Applies To Default Value

See Also

EMPTYMBOXSLEEP, EMPTYMBOXSLEEP_INC

TIBCO iProcess Engine Administrators Guide

Back to Library

IQL_RETRY_COUNT 219

IQL_RETRY_COUNT
Message and Mbox Processing Configuration

This attribute value is only used on the SQL Server and DB2 iProcess Engine variants. On the Oracle variant this value is set using Oracle AQ parameters.
Summary

This attribute defines how many times a failed message in a message queue is retried before being moved to the exception queue. This attribute can be set for the BG process. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process BG Instance 0 Value 12

Applies To Default Value

Notes

If the IQL_RETRY_COUNT limit is exceeded, the message is moved to the exception queue (also known as the dead queue or poison queue), and manual intervention by a system administrator will be necessary to resolve the problem and progress the case that the message belongs to. IQL_RETRY_DELAY, THRESHOLD_FAIL_TIMES_TO_REPORT_IQL_MESSAGE.

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

220

| Chapter 6

Administering Process Attributes

IQL_RETRY_DELAY
Message and Mbox Processing Configuration

This attribute value is only used on the SQL Server and DB2 iProcess Engine variants. On the Oracle variant this value is set using Oracle AQ parameters.
Summary

This attribute defines the delay (in seconds) between each retry attempt for a failed message in a message queue, before the message is moved to the exception queue. This attribute can be set for the BG process. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process BG Instance 0 Value 300

Applies To Default Value

Notes

A failed message is retried a number of times up to the IQL_RETRY_COUNT limit. If that limit is exceeded the message is moved to the exception queue (also known as the dead queue or poison queue), and manual intervention by a system administrator will be necessary to resolve the problem and progress the case that the message belongs to. IQL_RETRY_COUNT, THRESHOLD_FAIL_TIMES_TO_REPORT_IQL_MESSAGE.

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

MBSET_READ_BG 221

MBSET_READ_BG
Message and Mbox Processing Configuration Summary

This attribute defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by a BG process when dequeuing messages received from a process. This attribute can be set for BG or ALL processes. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 0 0 0 0 Process BG BG BG BG ALL Instance 1 2 3 4 0 Value 3 3 4 4 1 Notes for Mbox set WISBGMBSET1 for Mbox set WISBGMBSET1 for Mbox set WISBGMBSET2 for Mbox set WISBGMBSET2 for all other processes (TIBCO iProcess Objects, swbatch etc.)

Applies To Default Value

Notes

See Default Message Handling Configuration on page 301 for more information about how these default values are used.

TIBCO iProcess Engine Administrators Guide

Back to Library

222

| Chapter 6

Administering Process Attributes

MBSET_READ_PREDICT
Message and Mbox Processing Configuration Summary

This attribute defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by a BGPREDICT process when dequeuing case change messages received from a BG process. This attribute can be set for BGPREDICT or ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

TIBCO iProcess Engine Administrators Guide

Back to Library

MBSET_READ_WIS 223

MBSET_READ_WIS
Message and Mbox Processing Configuration Summary

This attribute defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by a WISMBD process when dequeuing messages received from a BG process. This attribute can be set for WISMBD or ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

TIBCO iProcess Engine Administrators Guide

Back to Library

224

| Chapter 6

Administering Process Attributes

MBSET_WRITE_BG
Message and Mbox Processing Configuration Summary

This attribute defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by a process when posting messages to a BG process. This attribute can be set for BG, WIS, SPO, RPC_POOL or ALL processes. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 0 0 0 0 0 0 Process WIS WIS WIS WIS WIS WIS ALL Instance 1 2 3 4 4 4 0 Value 3 3 3 4 4 4 1 Notes

Applies To Default Value

for Mbox set WISBGMBSET1 for Mbox set WISBGMBSET1 for Mbox set WISBGMBSET2 for Mbox set WISBGMBSET2 for Mbox set WISBGMBSET2 for all other processes (TIBCO iProcess Objects, swbatch etc.)

Notes

See Default Message Handling Configuration on page 301 for more information about how these default values are used.

TIBCO iProcess Engine Administrators Guide

Back to Library

for Mbox set WISBGMBSET1

MBSET_WRITE_PREDICT 225

MBSET_WRITE_PREDICT
Message and Mbox Processing Configuration Summary

This attribute defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by a BG process when posting case change messages to a BGPREDICT process. This attribute can be set for BG or ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

TIBCO iProcess Engine Administrators Guide

Back to Library

226

| Chapter 6

Administering Process Attributes

MBSET_WRITE_WIS
Message and Mbox Processing Configuration Summary

This attribute defines the unique identifier of the Mbox set (as defined in the mbox_set table) to be used by a BG process when posting messages to a WISMBD process. This attribute can be set for BG, RPCBG or ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

TIBCO iProcess Engine Administrators Guide

Back to Library

THRESHOLD_FAIL_TIMES_TO_REPORT_IQL_MESSAGE 227

THRESHOLD_FAIL_TIMES_TO_REPORT_IQL_MESSAGE
Message and Mbox Processing Configuration Summary

When a process fails to send an IQL message, it will try again for the number of times defined by IQL_RETRY_COUNT. During this retry procedure, if the number of retries exceeds the value of this attribute (but does not reach the value of IQL_RETRY_COUNT), the process sends a warning message to the Process Sentinels. This attribute can be set for the BG process. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process BG Instance 0 Value 3

Applies To Default Value

See Also

IQL_RETRY_COUNT, IQL_RETRY_DELAY.

TIBCO iProcess Engine Administrators Guide

Back to Library

228

| Chapter 6

Administering Process Attributes

Sequence Numbering Configuration

The following process attributes allow you to configure how the iProcess Engine caches sequence numbers. For more information about sequence numbers see Sequence Number Caching on page 102. Attribute CNUM_SEQ_CACHE REQID_SEQ_CACHE WIS_INDEX_REFRESH Description Defines the number of case numbers to be cached. Defines the number of REQ IDs to be cached. Defines the number of Wait IDs to be cached.

TIBCO iProcess Engine Administrators Guide

Back to Library

CNUM_SEQ_CACHE 229

CNUM_SEQ_CACHE
Sequence Numbering Configuration Summary Applies To Default Value

This attribute defines the number of case numbers to be cached. This attribute can be set for BG, SWBATCH, WIS or ALL processes. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 0 0 Process BG SWBATCH WIS Instance 0 0 0 Value 50

50

Notes

Case number caching can provide a performance benefit when applied to the BG, WIS, RPC_POOL and SWBATCH processes. It should not be used with other processes. For more information see Sequence Number Caching on page 102. If you use case number caching, you should note that it is possible for a lower case number to be started after a higher case number. For example, suppose that a WIS process has 50 case numbers (1 to 50) cached, and a user uses SWDIR\bin\SWUTIL CSTART to start a case. The case will have case number 51 - the next available number obtained from the cnum_sequence table. 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.

See Also

REQID_SEQ_CACHE, WIS_INDEX_REFRESH.

TIBCO iProcess Engine Administrators Guide

Back to Library

50

230

| Chapter 6

Administering Process Attributes

REQID_SEQ_CACHE
Sequence Numbering Configuration Summary Applies To Default Value

This attribute defines the number of REQ IDs to be cached. This attribute can be set for BG, SWBATCH, WIS or ALL processes. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 0 0 Process BG SWBATCH WIS Instance 0 0 0 Value 50

50

Notes

REQ ID caching can provide a performance benefit when applied to the BG, WIS, RPC_POOL and SWBATCH processes. It should not be used with other processes. For more information see Sequence Number Caching on page 102. CNUM_SEQ_CACHE, WIS_INDEX_REFRESH

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

50

WAITID_SEQ_CACHE 231

WAITID_SEQ_CACHE
Sequence Numbering Configuration Summary Applies To Default Value

This attribute defines the number of Wait IDs to be cached. This attribute can be set for BG or ALL processes. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

Case number caching can provide a performance benefit when applied to the BG process (if waits are used in procedures being processed by the BG process). It should not be used with other processes. For more information see Sequence Number Caching on page 102. CNUM_SEQ_CACHE, REQID_SEQ_CACHE

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

232

| Chapter 6

Administering Process Attributes

Transaction Control Configuration

The following process attributes allow you to configure how the iProcess Engine handles transactions. Attribute BG_MAX_ACTIONS_PER_TRANS CHECK_EAIWITHDRAW_ONPURGE Description Defines the limit of actions per workflow transaction. Defines whether or not iProcess checks if any outstanding delayed release EAI steps have been successfully withdrawn before committing the purge transaction.

TIBCO iProcess Engine Administrators Guide

Back to Library

BG_MAX_ACTIONS_PER_TRANS 233

BG_MAX_ACTIONS_PER_TRANS
Transaction Control Configuration Summary

This attribute limits the number of steps sent or withdrawn during the processing of a single workflow transaction (i.e. the number of EAI steps that can be processed in one transaction without any other step types in between). This attribute can be defined for the BG, RPCBG and BGPREDICT processes. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

When this limit is reached the workflow transaction is aborted and an appropriate message is logged to the SWDIR\logs\sw_warn log file.

TIBCO iProcess Engine Administrators Guide

Back to Library

1000

234

| Chapter 6

Administering Process Attributes

CHECK_EAIWITHDRAW_ONPURGE
Sequence Numbering Configuration Summary

When you purge a case that contains an outstanding delayed release EAI step, the BG process attempts to withdraw the EAI step (sending an instruction to the external system to remove any data associated with that step). By default, iProcess checks if any outstanding delayed release EAI steps have been successfully withdrawn before committing the purge transaction. The CHECK_EAIWITHDRAW_ONPURGE process attribute allows you to configure this behavior to suit your requirements. If the withdrawal fails, the data is left in the external system even though the case is purged. The external system and iProcess case are thus out of synchronization with each other. Therefore, TIBCO recommend that the default setting (1) is used instead.

Applies To Permissible Values

This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 Meaning iProcess assumes that the EAI step is successfully withdrawn, commits the transaction and purges the case. If the value is set to 0, iProcess assumes that the withdrawal succeeds, commits the transaction and purges the case. iProcess checks whether the EAI step is successfully withdrawn or not. If the withdraw: succeeds, iProcess commits the transaction and purges the case. fails, iProcess rolls back the transaction and does not purge the case.

This is the default value.

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 1

TIBCO iProcess Engine Administrators Guide

Back to Library

CHECK_EAIWITHDRAW_ONPURGE 235

Notes

If CHECK_EAIWITHDRAW_ONPURGE is set to 1 you should note the following implications: If you are using a custom shell EAI Server Plug-in (developed using the EAI SDK), and you want to use delayed release EAI steps, you must implement the EAIRun_Withdraw() function. The iProcess Suite uses the return value from this function to determine whether it should commit (EAI_SUCCESS) or rollback (any return value other than EAI_SUCCESS) the purge transaction. If the purge transaction fails, it will be automatically re-queued and retried a number of times, as determined by the values of the IQL_RETRY_COUNT and IQL_RETRY_DELAY process attributes. The external system is responsible for handling failed withdraws, and ensuring that the withdraw attempt ultimately succeeds. Otherwise, cases will be left in iProcess that cannot be purged. If you use the TIBCO iProcess Workspaces Case Administration tool to purge cases (by selecting a case and clicking Purge Case(s)), if the purge transaction fails the case will still be visible when you click Refresh.

TIBCO iProcess Engine Administrators Guide

Back to Library

236

| Chapter 6

Administering Process Attributes

Activity Monitoring and Work Queue Delta Configuration

The following process attributes allow you to configure how the iProcess Engine performs activity monitoring and Work Queue Delta publication. For more information about: administering activity monitoring and Work Queue Delta publication, see Administering Activity Monitoring and Work Queue Delta Publication on page 329. configuring activity monitoring, see "Configuring Activity Monitoring" in the TIBCO iProcess Modeler - Integration Techniques Guide.

IAPJMS_PORTNO

Defines the port number that is used for message communications between the BG process and the IAPJMS library. Defines whether or not the BG process is enabled to publish audit activities to the IAPJMS process. Defines whether or not failed message transactions should be rolled back. Defines whether or not the JMS topic name is static or dynamically configured at run-time. Defines whether message delivery is synchronous or asynchronous. Defines how long the IAPJMS process should wait before it times out if there is a network error. Defines the topic name for the JMS destination if activity monitoring is enabled. Defines the JVM attributes that should be specified for the Java Virtual Machine when it is started. Defines the directory where the IAPJMS process will look for the Java libraries that it needs.

IAPJMS_PUBLISH IAPJMS_ROLLBACK IAPJMS_SIMPLETOPIC IAPJMS_SYNCHRONOUS IAPJMS_TIMEOUT IAPJMS_TOPICNAME JVMPROPS SWLIB_PATH

TIBCO iProcess Engine Administrators Guide

Back to Library

Attribute

Description

Activity Monitoring and Work Queue Delta Configuration 237

Attribute WQDJMS_PORTNO

Description Defines the port number that is used for work queue delta messages between the WIS process and the IAPJMS process. Defines the default topic name for the JMS destination used by the WIS process for work queue delta publication.

WQDJMS_TOPICNAME

TIBCO iProcess Engine Administrators Guide

Back to Library

238

| Chapter 6

Administering Process Attributes

IAPJMS_PORTNO
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the port number that is used for message communications between the BG process and the IAPJMS process. The attribute should be set for ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 9071

Applies To Default Value

Notes

If you change the value of this attribute, the change does not take effect until you stop and restart the iProcess Engine. IAPJMS_PUBLISH, IAPJMS_SYNCHRONOUS, IAPJMS_ROLLBACK, IAPJMS_TIMEOUT, IAPJMS_TOPICNAME, IAPJMS_SIMPLETOPIC, JVMPROPS, SWLIB_PATH

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

IAPJMS_PUBLISH 239

IAPJMS_PUBLISH
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines whether or not the BG process is enabled to publish monitored activities to the IAPJMS process. The attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning Activity monitoring is disabled.

Applies To Permissible Values

Default Value

The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 0

Notes

If activity monitoring is enabled then activity information about auditable objects (for example, procedures and steps) can be published to an external application. This enables real-time monitoring of auditable objects so that mission critical or important business events can be easily monitored. IAPJMS_PORTNO, IAPJMS_SYNCHRONOUS, IAPJMS_ROLLBACK, IAPJMS_TOPICNAME, IAPJMS_SIMPLETOPIC, JVMPROPS, SWLIB_PATH

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

Activity monitoring is enabled.

240

| Chapter 6

Administering Process Attributes

IAPJMS_ROLLBACK
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines whether or not failed message transactions should be rolled back. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 Meaning The iPE transaction succeeds and is committed even if the message fails. This means that failed JMS messages cause an error to be written to the SWDIR/logs/sw_error file but the failed message transaction is not rolled back. Any error causes the BG process to fail the current instruction and roll back any outstanding iPE transactions.

Applies To Permissible Values

Default Value

The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 1

Notes

To ensure reliable message delivery, TIBCO recommend that the value of this attribute be set to 1. This means that failed JMS messages cause an error to be written to the SWDIR/logs/sw_error file and are rolled back. IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_SYNCHRONOUS, IAPJMS_TOPICNAME, IAPJMS_SIMPLETOPIC, JVMPROPS, SWLIB_PATH

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

IAPJMS_SYNCHRONOUS 241

IAPJMS_SYNCHRONOUS
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the JMS message delivery method. There are two delivery methods, synchronous or asynchronous. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 Meaning The JMS message delivery method is asynchronous. The message is assumed to have been processed correctly if the message was sent successfully to the IAPJMS process. The JMS message delivery method is synchronous. When the message is sent, a receipt is requested. The BG process waits until the IAPJMS process has confirmed the message has been published. If the message is not published, an error is written to the SWDIR/logs/sw_error file.

Applies To Permissible Values

Default Value

The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 1

Notes

If you chose the synchronous message delivery method, there will be an impact on the performance of your iProcess Engine. IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_ROLLBACK, IAPJMS_TIMEOUT, IAPJMS_TOPICNAME, IAPJMS_SIMPLETOPIC, JVMPROPS, SWLIB_PATH

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

242

| Chapter 6

Administering Process Attributes

IAPJMS_TIMEOUT
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the amount of time (in seconds) before the IAPJMS process should timeout, for example, if there is a network error. This attribute must be set for ALL processes. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 30

Applies To Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

If you change the value of this attribute, the change does not take effect until you stop and restart the iProcess Engine. IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_SYNCHRONOUS, IAPJMS_TOPICNAME, IAPJMS_SIMPLETOPIC, JVMPROPS, SWLIB_PATH

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

IAPJMS_TOPICNAME 243

IAPJMS_TOPICNAME
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the JMS topic name for the JMS destination, if activity monitoring is enabled. This attribute must be set for ALL processes. The attribute value must be a string. The JMS topic name format depends on your J2EE environment. See the documentation supplied with your J2EE Application Server for more information about how you should format your JMS topic name for your J2EE environment. However, the iProcess Engine forces a maximum length of 511 characters for the length of the process attribute. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value IATOPIC

Applies To Permissible Values

Default Value

Notes

If activity monitoring is enabled, the BG process sends JMS messages to a JMS topic name that you can specify using this attribute. The JMS topic name can be static or dynamically configured at run-time. This attribute is used with the IAPJMS_SIMPLETOPIC process attribute: If the value of IAPJMS_SIMPLETOPIC is 1, the JMS topic name specified in the IAPJMS_TOPICNAME process attribute is static. If the value of IAPJMS_SIMPLETOPIC is 0, the JMS topic name specified in the IAPJMS_TOPICNAME process attribute is dynamically configured at run-time to include the iProcess procedure name and step name. For example, if the IAPJMS_TOPICNAME is IAPTOPIC and IAPJMS_SIMPLETOPIC is 0, then all messages are addressed to one of the following JMS topic names, depending on the activity being audited: IAPTopic.procedurename.START IAPTopic.procedurename.stepname.START IAPTopic.procedurename.stepname.END IAPTopic.procedurename.END

TIBCO iProcess Engine Administrators Guide

Back to Library

244

| Chapter 6

Administering Process Attributes

where: procedurename is the name of the iProcess procedure stepname is the name of the step in the iProcess procedure. Some applications demand that the JMS topic name be configured this way. However, you may want to configure the JMS topic name this way if you want to use lots of small topics as opposed to one single large topic. The following table shows which audit trail messages are logged to which topics. (See Appendix D on page 389 for a complete listing of audit trail messages and their corresponding Message IDs). JNDI Name IAPTopic.procedurename.START IAPTopic.procedurename.stepname.START Activity (Message ID) Case started by UserName (000) StepDescription processed to UserName (001) StepDescription forwarded to UserName (004) Sub-Case started from StepDescription (016) IAPTopic.procedurename.stepname.END IAPTopic.procedurename.END All activities not covered by any of the other listed topics. Case terminated normally (009) Case terminated prematurely by UserName (008) Case terminated abnormally (007) Any other activity that has a blank stepname
See Also

IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_ROLLBACK, IAPJMS_SYNCHRONOUS, IAPJMS_SIMPLETOPIC, IAPJMS_TIMEOUT, JVMPROPS, SWLIB_PATH

TIBCO iProcess Engine Administrators Guide

Back to Library

IAPJMS_SIMPLETOPIC 245

IAPJMS_SIMPLETOPIC
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines whether or not the JMS topic is static or dynamically configured at run-time. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 1 0 Meaning The JMS topic name is static.

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 1

Notes See Also

This attribute is used with the IAPJMS_TOPICNAME process attribute. IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_SYNCHRONOUS, IAPJMS_ROLLBACK, IAPJMS_TIMEOUT, IAPJMS_TOPICNAME, JVMPROPS, SWLIB_PATH

TIBCO iProcess Engine Administrators Guide

Back to Library

The JMS topic name is dynamically configured at run-time.

246

| Chapter 6

Administering Process Attributes

JVMPROPS
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the JVM attributes that should be specified for the Java Virtual Machine when it is started. This attribute can be set for ALL processes. The attribute value must be a string. See the documentation supplied with your J2DK application for more information about how you should format the JVMPROPS attribute for your J2DK environment. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value NULL

Applies To Permissible Values

Default Value

Notes

If activity monitoring is enabled, you can use this process attribute to configure any JVM attributes, for example debug values, that should be specified for the Java Virtual Machine when it is started. If you change the value of this attribute, the change does not take effect until you stop and restart the process that you have changed the attribute value for.

See Also

IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_ROLLBACK, IAPJMS_SIMPLETOPIC, IAPJMS_SYNCHRONOUS, IAPJMS_TIMEOUT, IAPJMS_TOPICNAME, SWLIB_PATH

TIBCO iProcess Engine Administrators Guide

Back to Library

SWLIB_PATH 247

SWLIB_PATH
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the directory where the IAPJMS process will look for the Java libraries that it needs. This attribute can be set for ALL processes, but is currently only used by the IAPJMS, BG, BGPREDICT and RPCBG process. The attribute value must be a fully qualified pathname to a directory that contains a full Java Runtime Environment (JRE). The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value See the Notes below.

Applies To

Permissible Values Default Value

Notes

When a process that uses this attribute starts up, it searches the systems shared library/command path for the Java libraries that it needs. When SWLIB_PATH is set its value is prefixed to the systems shared library/command path. The default value points to the Java libraries that are distributed with the iProcess Engine, as shown in the following table. Platform HP-UX (HP) Default SWLIB_PATH Value... On HP-9000: $SWDIR/java/lib/PA_RISC2.0/ server:$SWDIR/java/lib/ PA_RISC2.0 ...is prefixed to the environment variable SHLIB_PATH

On HP-Itanium: AIX SunOS $SWDIR/java/lib/IA64N/server: $SWDIR/java/lib/IA64N LIBPATH LD_LIBRARY_PATH

$SWDIR/java/bin/classic: $SWDIR/java/bin $SWDIR/java/lib/sparc/server: $SWDIR/java/lib/sparc

TIBCO iProcess Engine Administrators Guide

Back to Library

248

| Chapter 6

Administering Process Attributes

Platform Linux Windows

Default SWLIB_PATH Value... $SWDIR/java/lib/i386/server: $SWDIR/java/lib/i386 %SWDIR%java\bin\client

...is prefixed to the environment variable LD_LIBRARY_PATH PATH

You should only change SWLIB_PATH if you have a specific requirement to use different Java libraries from the default versions distributed with the iProcess Engine. If you specify a directory that does not contain the necessary Java libraries, the process using the attribute will fail. On AIX, the IAPJMS process is linked to the libjvm.a Java library. Some Java 1.5 builds, however, supply a libjvm.so library either in addition to, or instead of, the libjvm.a library. If the particular build of Java 1.5 that you wish to use in SWLIB_PATH only includes a libjvm.so library, you must either:
See Also

copy it to libjvm.a, or create a symbolic link called libjvm.a, which links to the provided libjvm.so.

IAPJMS_PUBLISH, IAPJMS_PORTNO, IAPJMS_ROLLBACK, IAPJMS_SIMPLETOPIC, IAPJMS_SYNCHRONOUS, IAPJMS_TIMEOUT, IAPJMS_TOPICNAME

TIBCO iProcess Engine Administrators Guide

Back to Library

WQDJMS_PORTNO 249

WQDJMS_PORTNO
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the port number that is used for work queue delta message communications between the WIS processes and the IAPJMS process. It is read when the iProcess Engine starts up. The attribute should be set for ALL processes. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value

Applies To Default Value

Notes

If you change the value of this attribute, the change does not take effect until you stop and restart the iProcess Engine. WQDJMS_TOPICNAME

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

9075

250

| Chapter 6

Administering Process Attributes

WQDJMS_TOPICNAME
Activity Monitoring and Work Queue Delta Configuration Summary

This attribute defines the default JMS topic name for the JMS destination used for work queue delta messages, if Work Queue Delta Publication via JMS is in use. This default can be overridden for an individual subscription, if that subscription supplies a different topic name. By default this attribute applies to ALL processes. The attribute value must be a string. The JMS topic name format depends on your J2EE environment. See the documentation supplied with your J2EE Application Server for more information about how you should format your JMS topic name for your J2EE environment. However, the iProcess Engine forces a maximum length of 511 characters for the length of the process attribute. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value WQDTOPIC

Applies To Permissible Values

Default Value

Notes

If work queue delta monitoring is enabled, the WIS process sends JMS messages to a JMS topic name that you can specify using this attribute. The JMS topic name can be static or dynamically configured at run-time. WQDJMS_PORTNO

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

TIBCO Rendezvous Configuration 251

TIBCO Rendezvous Configuration

The following process attributes allow you to configure how the iProcess Engine communicates with TIBCO Rendezvous. Attribute RV_DAEMON Description Configures the iProcess Server Manager with the daemon used to handle session communication in TIBCO Rendezvous. Configures the iProcess Server Manager with the network used to handle outbound session communication in TIBCO Rendezvous. Configures the iProcess Server Manager with the User Datagram Protocol (UDP) service group used to handle session communication in TIBCO Rendezvous.

RV_NETWORK

RV_SERVICE

TIBCO iProcess Engine Administrators Guide

Back to Library

252

| Chapter 6

Administering Process Attributes

RV_DAEMON
TIBCO Rendezvous Configuration Summary

This attribute is used to configure the iProcess Server Manager with the daemon used to handle session communication in TIBCO Rendezvous. This attribute must be set for ALL processes. If you are using the iProcess Server Manager, the setting of this process attribute must correspond to the daemon configuration parameter in TIBCO Rendezvous. By default, TIBCO Rendezvous uses the local daemon with the TCP socket number 7474. You do not need to change this attribute if your configuration uses this default port number. If your TIBCO Rendezvous configuration does not use the default port number you must specify the TIBCO Rendezvous daemon being used. For more information about the daemon configuration parameter, see the TIBCO Hawk Installation and Configuration guide.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value tcp:7474

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

RV_NETWORK, RV_SERVICE and Configuring the iProcess Server Manager on page 125

TIBCO iProcess Engine Administrators Guide

Back to Library

RV_NETWORK 253

RV_NETWORK
TIBCO Rendezvous Configuration Summary

This attribute is used to configure the iProcess Server Manager with the network used for outbound session communications in TIBCO Rendezvous. This attribute must be set for ALL processes. If you are using the iProcess Server Manager, the setting of this process attribute must correspond to the network configuration parameter in TIBCO Rendezvous. By default, TIBCO Rendezvous uses a null value for this parameter (indicated by a semi-colon or white space). You do not need to change this attribute if your configuration uses this default. If your TIBCO Rendezvous installation does not use the default configuration, you must ensure that the setting of this attribute matches the setting of the network configuration parameter in TIBCO Rendezvous. For more information about the network configuration parameter, see the TIBCO Hawk Installation and Configuration guide.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value Null

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

RV_DAEMON, RV_SERVICE and Configuring the iProcess Server Manager on page 125

TIBCO iProcess Engine Administrators Guide

Back to Library

254

| Chapter 6

Administering Process Attributes

RV_SERVICE
TIBCO Rendezvous Configuration Summary

This attribute is used to configure the iProcess Server Manager with the User Datagram Protocol (UDP) service group used for session communications in TIBCO Rendezvous. This attribute must be set for ALL processes. If you are using the iProcess Server Manager, the setting of this process attribute must correspond to the service configuration parameter in TIBCO Rendezvous. By default, TIBCO Rendezvous uses the service port number 7474. You do not need to change this attribute if your configuration uses this default port number. If your TIBCO Rendezvous configuration does not use the default port number you must specify the service being used, either by its name or its port number. For more information about the service configuration parameter, see the TIBCO Hawk Installation and Configuration guide.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 7474

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

RV_DAEMON, RV_NETWORK and Configuring the iProcess Server Manager on page 125

TIBCO iProcess Engine Administrators Guide

Back to Library

Case Prediction Configuration 255

Case Prediction Configuration

The following process attributes allow you to configure the use of case prediction on the iProcess Engine. Attribute ENABLE_CASE_PREDICTION Description Defines whether or not background case prediction is enabled on the node. Note: This attribute has no effect on live case prediction or case simulation. MAX_PREDICTION_LOOPS

TIBCO iProcess Engine Administrators Guide

Back to Library

Defines the maximum number of times to loop during the prediction process.

256

| Chapter 6

Administering Process Attributes

ENABLE_CASE_PREDICTION
Case Prediction Configuration Summary

This attribute defines whether or not the case prediction server process (BGPREDICT) is enabled for the iProcess system. This attribute can be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning BGPREDICT is disabled.

Applies To Permissible Values

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 0

Notes

This attribute only affects background case prediction. It has no effect on live case prediction or case simulation. For more information about the use of case prediction, see Using Case Prediction to Forecast Outstanding Work Items in the TIBCO iProcess Modeler - Advanced Design Guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

BGPREDICT is enabled.

MAX_PREDICTION_LOOPS 257

MAX_PREDICTION_LOOPS
Case Prediction Configuration Summary

This attribute defines the maximum number of times to loop during the prediction process. An error is reported if this value is exceeded - this prevents infinite loops occurring as a result of loops in the procedure. This attribute applies to the BGPREDICT process. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process BGPREDICT Instance 0 Value

Applies To Default Value

TIBCO iProcess Engine Administrators Guide

Back to Library

500

258

| Chapter 6

Administering Process Attributes

TIBCO iProcess Workspace (Windows) Configuration

The following process attributes allow you to configure aspects of TIBCO iProcess Workspace (Windows) behavior. Attribute CSTART_AUTO_REFRESH Description Defines whether or not the list of available procedures in the TIBCO iProcess Workspaces Case Start dialog is automatically refreshed. Defines whether case counts are displayed for procedures in the Live (Dead) Cases column of the Case Administrator dialog, when a user starts the iProcess Administrator from iProcess Workspace (Windows) Defines whether or not a new user name is validated as an O/S user account when you add an iProcess user from the User Manager tool of the TIBCO iProcess Administrator. Defines whether or not the Possible iProcess User List button is displayed in the User Manager tool of the TIBCO iProcess Administrator. Defines where the iProcess Engine should obtain the list of users when it populates the Possible iProcess User List in the User Manager tool of the TIBCO iProcess Administrator.

DISABLE_CASE_COUNTING

DISABLE_USER_CHECK

DISABLE_USER_LIST

OS_USER_LOCATIONS

TIBCO iProcess Engine Administrators Guide

Back to Library

CSTART_AUTO_REFRESH 259

CSTART_AUTO_REFRESH
TIBCO iProcess Workspace (Windows) Configuration Summary

This attribute defines whether or not the list of available procedures in the TIBCO iProcess Workspaces Case Start dialog is automatically refreshed. This attribute can be set for ALL processes. The attribute value must be one of the following: Value 0 Meaning The procedure list in the Case Start dialog is not automatically refreshed when the dialog is opened. The user must click Refresh to update the procedure list. The procedure list in the Case Start dialog is automatically refreshed when the dialog is opened.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 1

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

When automatic refresh is enabled, the dialog is refreshed when it is opened. This ensures that the list of available procedures and versions shown to the user is accurate. However, you can disable automatic refresh if you wish. You may want to do this if you have very large numbers of procedures, so that the refresh takes a noticeable time.

TIBCO iProcess Engine Administrators Guide

Back to Library

260

| Chapter 6

Administering Process Attributes

DISABLE_CASE_COUNTING
TIBCO iProcess Workspace (Windows) Configuration Summary

This attribute defines whether case counts are displayed for procedures in the Live (Dead) Cases column of the Case Administrator dialog, when a user starts the iProcess Administrator from the iProcess Workspace (Windows). This attribute can be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning

Applies To Permissible Values

The Live (Dead) Cases column is not populated when the Case Administrator dialog loads. This improves the dialogs loading time.

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

Normally, procedures are only displayed in the Case Administrator dialog if they have Case Administration access, have started cases, and the user is logged in as either the procedure owner or the IPEADMIN user. However, when DISABLE_CASE_COUNTING=1, all procedures on the system are displayed in the Case Administrator dialog.

TIBCO iProcess Engine Administrators Guide

Back to Library

The Live (Dead) Cases column is populated when the Case Administrator dialog loads.

DISABLE_USER_CHECK 261

DISABLE_USER_CHECK
TIBCO iProcess Workspace (Windows) Configuration

This attribute has no effect if you are validating iProcess users against an external validation package rather than against the O/S. See Specifying How iProcess Validates Users on page 29.
Summary

This attribute defines whether or not a new user name is validated as an O/S user account when you add an iProcess user (from the User Manager tool of the TIBCO iProcess Administrator). This attribute must be set for ALL processes.

Applies To Permissible Values

Value 0

Meaning When you use User Manager to add a new user, the iProcess Suite checks if the username is a valid O/S user account. If it is not, the user is not created and an Invalid User error is displayed. When you use User Manager to add a new user, the iProcess Suite does not check if the username is a valid O/S user account. The user is created even if it is not a valid O/S user account.

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
See Also

DISABLE_USER_LIST

TIBCO iProcess Engine Administrators Guide

Back to Library

The attribute value must be one of the following:

262

| Chapter 6

Administering Process Attributes

DISABLE_USER_LIST
TIBCO iProcess Workspace (Windows) Configuration Summary

This attribute defines whether or not the Possible iProcess User List button is displayed in the User Manager tool of the TIBCO iProcess Administrator. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning The Possible iProcess User List button is displayed in User Manager.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

By default, the iProcess Suite requires that an iProcess user is also a valid O/S user account. When you add a user in the User Manager, you can click Possible iProcess User List to display a list of valid O/S accounts, and thus choose a user name that you know will be valid as an iProcess user name. However, if this model does not meet your security requirements, you can use the TIBCO iProcess User Validation API to create your own user validation method that matches your business requirements. You may, for example, want to maintain the list of users (and their passwords) in a separate database, separating them entirely from O/S accounts. In this case, there is no requirement to display a list of O/S accounts in the User Manager. Indeed, for security reasons, you can choose not to display the list.

See Also

DISABLE_USER_CHECK

TIBCO iProcess Engine Administrators Guide

Back to Library

The Possible iProcess User List button is not displayed in User Manager. You should use this setting if you want to prevent users from accessing the list of valid O/S users.

OS_USER_LOCATIONS 263

OS_USER_LOCATIONS
TIBCO iProcess Workspace (Windows) Configuration Summary

This attribute defines where the iProcess Engine should obtain the list of users when it populates the Possible iProcess User List in the User Manager tool of the TIBCO iProcess Administrator. This attribute is only used on the Windows variant of the iProcess Engine. It has no effect if it is set on a UNIX system.

Applies To Permissible Values

This attribute must be set for ALL processes. The attribute value must be a text string of 1024 characters or less, which consists of a comma-delimited list of machine and/or domain names in the following format:
machine[,machine[,M:machine][,D:domain]...]

Each name in the list can be explicitly identified as either: a machine, by using the M: prefix. a domain, by using the D: prefix. A domain name can be specified either as a simple name (for example, EMEA), or as a fully qualified domain name (for example, xyzCorp.dev.EMEA).

A name is treated as a machine name in the absence of either prefix.

Default Value

The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 The default value is: machine,user where: machine is the name of the computer hosting this iProcess Engine installation. user is the location of the user that ran the Setup program to install this iProcess Engine. (If machine is a standalone computer, rather than a member of a domain, user is blank.) Process ALL Instance 0 Value See below

TIBCO iProcess Engine Administrators Guide

Back to Library

264

| Chapter 6

Administering Process Attributes

For example, if the iProcess Engine was installed on a computer called SERVER_TIB3 using the domain user account \\EMEA\AJones, the default value for this attribute would be:
SERVER_TIB3,D:EMEA

If SERVER_TIB3 was a standalone computer and AJones a local account, the default value would be:
SERVER_TIB3

The existing attribute value is preserved when you upgrade the iProcess Engine.
Notes

When a user clicks the Possible iProcess User List button in the User Manager tool of the TIBCO iProcess Administrator, the iProcess Engine populates the displayed list of operating system (OS) logins with all the user names found in each location specified in this attribute value. User names are displayed in the format:
location\user

where location is the machine or domain specified in the OS_USER_LOCATIONS attribute, and name is the user name found in that location. You can use the SWDIR\util\plist -U command to display the list of OS users that will be generated by the current setting of the OS_USERS_LOCATION value. If the iProcess Engine is unable to contact a specified machine or domain for any reason, it writes an appropriate error message (with message ID 1631) to the SWDIR\logs\sw_warn file. For example:
2006/11/30 14:07:47(plist:2784:2784:0:stevec:filosuvm.c:1.18:341): 1631-WARNING: <osuv_get_nxt_user (): NetQueryDisplayInformation(dev1) failed: Access is denied.><> <> <> 2006/11/30 14:07:54(plist:2784:2784:0:stevec:filosuvm.c:1.18:341): 1631-WARNING: <osuv_get_nxt_user (): NetQueryDisplayInformation(invalid) failed: The RPC server is unavailable.> <> <> <> 2006/11/30 14:08:06(plist:2784:2784:0:stevec:filosuvm.c:1.18:341): 1631-WARNING: <priv_GetLocationMachineName (): GetDomainController(ff) failed: The specified domain either does not exist or could not be contacted.> <> <> <>

TIBCO iProcess Engine Administrators Guide

Back to Library

Procedure Configuration 265

Procedure Configuration
The following process attributes allow you to configure how the iProcess Engine handles iProcess procedures. Attribute DEF_MAJOR_VERS Description Defines the default major version number that the TIBCO iProcess Modeler will use when a new procedure is saved. Defines the default minor version number that the TIBCO iProcess Modeler will use when a new procedure is saved. Defines the maximum number of procedure definitions that can be cached in memory by the BG, WIS and SPO processes. Determines the maximum number of nested sub-procedures supported by the server. Defines whether or not, in the TIBCO iProcess Modeler, a user has to enter a comment whenever they save a procedure. Defines whether or not, in the TIBCO iProcess Modeler, a procedures version number will be incremented whenever it is saved. Defines the maximum number of instances of a procedure version.

DEF_MINOR_VERS

FIL_PROCDEF_CACHE_SIZE

MBSET_READ_BG PROC_VER_COMMENT

PROC_VER_INC

PROC_VER_NUM_INSTANCES

TIBCO iProcess Engine Administrators Guide

Back to Library

266

| Chapter 6

Administering Process Attributes

DEF_MAJOR_VERS
Procedure Configuration Summary

This attribute defines the default major version number that the TIBCO iProcess Modeler will use when a new procedure is saved. This attribute must be set for ALL processes. The attribute value must be a numeric value greater than or equal to 0. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

Applies To Permissible Values Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

For more information about the use of version numbering with procedures, see Using Version Control in the TIBCO iProcess Modeler - Procedure Management Guide. DEF_MINOR_VERS, PROC_VER_COMMENT, PROC_VER_INC

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

DEF_MINOR_VERS 267

DEF_MINOR_VERS
Procedure Configuration Summary

This attribute defines the default minor version number that the TIBCO iProcess Modeler will use when a new procedure is saved. This attribute must be set for ALL processes. The attribute value must be a numeric value greater than or equal to 0. This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

Applies To Permissible Values Default Value

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

For more information about the use of version numbering with procedures, see Using Version Control in the TIBCO iProcess Modeler - Procedure Management Guide. DEF_MAJOR_VERS, PROC_VER_COMMENT, PROC_VER_INC.

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

268

| Chapter 6

Administering Process Attributes

FIL_PROCDEF_CACHE_SIZE
Procedure Configuration Summary

This attribute defines the maximum number of procedure definitions that can be cached in memory by the BG and WIS processes. This attribute can be set for the WIS, BG, SPO or ALL processes. The attribute value must be a numeric value greater than or equal to 1. The attribute is assigned the following default value when the iProcess Engine is installed. Machine ID 0 Process ALL Instance 0 Value 64

Applies To Permissible Values Default Value

Notes

The in-memory procedure definition cache is used by the BG, WIS and SPO processes for rapid access to recently-used procedure definitions. When a BG, WIS or SPO process first accesses a procedure definition, the definition is fetched from the database and written to the cache. Subsequent accesses will use the definition from the cache rather than from the database, and so will be faster. The BG process uses the procedure definition cache for all procedures that it processes. The WIS and SPO processes use it to filter queues that contain CDQP definitions. This attribute defines the maximum number of procedure definitions that can be cached by the specified process. Increasing this value: increases the number of procedure definitions that can be rapidly accessed from the cache, but also increases the memory footprint of the process. can speed up work item filtering on large queues by the WIS or SPO processes.

Once the FIL_PROCDEF_CACHE_SIZE limit is reached for a process, if a new procedure definition needs to be added to the cache, the oldest procedure definition is removed. When this happens, the following message (with ID 1631) is written to the SWDIR\logs\sw_warn file:
proc_name has been bumped from the FIL procedure definition cache

where proc_name is the name of the procedure definition that has been deleted from the cache. If this occurs you may want to increase the FIL_PROCDEF_CACHE_SIZE value.

TIBCO iProcess Engine Administrators Guide

Back to Library

FIL_PROCDEF_CACHE_SIZE 269

The SPO process caches every procedure version of every procedure. This means that if your iProcess Engine has many procedures each of which has many procedure versions, the FIL_PROCDEF_CACHE_SIZE limit may easily be reached, causing a SWDIR\logs\sw_warn file to be generated. To avoid this, you should reset the value of the FIL_PROCDEF_CACHE _SIZE to be (number of procedures) * (number of procedure versions). The SWDIR\logs\sw_warn file that is generated contains messages like the example below:
2007/04/05 08:42:39(SPO:1:2180:0:swadmin:\filpdcc.c::1253): 1631-WARNING: <'$EMAIL' has been bumped from the FIL procedure definition cache> <> <> <>

You should be aware that if you do increase the FIL_PROCDEF_CACHE_SIZE value, the process uses more memory so you may reach the Operating System memory limit sooner.

TIBCO iProcess Engine Administrators Guide

Back to Library

The number and frequency of these messages indicates whether you need to amend the FIL_PROCDEF_CACHE_SIZE limit. For example, a couple of messages generated over a few minutes means there is no need to alter the FIL_PROCDEF_CACHE_SIZE value. However, lots of messages generated in a short space of time means the FIL_PROCDEF_CACHE_SIZE has been greatly exceeded.

270

| Chapter 6

Administering Process Attributes

MAX_SUB_PROCEDURE_DEPTH
Procedure Configuration Summary

This attribute defines the maximum number of nested sub-procedures supported by the iProcess Engine. This attribute can be set for the BG, RPCBG and BGPREDICT processes. The attribute is assigned the following default values when the iProcess Engine is installed. Machine ID 0 0 Process BG BGPREDICT Instance 0 0 Value 100 100

Applies To Default Value

TIBCO iProcess Engine Administrators Guide

Back to Library

PROC_VER_COMMENT 271

PROC_VER_COMMENT
Procedure Configuration Summary

This attribute defines whether or not, in the TIBCO iProcess Modeler, a user has to enter a comment whenever they save a procedure. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning Not supported. The comment field is not displayed in the Procedure > Save dialog(s) in the TIBCO iProcess Modeler. Optional. The comment field is displayed in the Procedure > Save dialog(s) in the TIBCO iProcess Modeler. The user can leave it blank if desired. Required. The comment field is displayed in the Procedure > Save dialog(s) in the TIBCO iProcess Modeler. The user must fill it in before they can save the procedure.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 1

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

For more information about the use of version numbering with procedures, see Using Version Control in the TIBCO iProcess Modeler - Procedure Management Guide. DEF_MAJOR_VERS, DEF_MINOR_VERS, PROC_VER_INC, PROC_VER_NUM_INSTANCES

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

272

| Chapter 6

Administering Process Attributes

PROC_VER_INC
Procedure Configuration Summary

This attribute defines whether or not, in the TIBCO iProcess Modeler, a procedures version number will be incremented whenever it is saved. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 1 Meaning The version number will be incremented only when a new version of the procedure is explicitly created. The version number will be incremented every time the procedure is saved.

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

For more information about the use of version numbering with procedures, see Using Version Control in the TIBCO iProcess Modeler - Procedure Management Guide. DEF_MAJOR_VERS, DEF_MINOR_VERS, PROC_VER_COMMENT, PROC_VER_NUM_INSTANCES

See Also

TIBCO iProcess Engine Administrators Guide

Back to Library

PROC_VER_NUM_INSTANCES 273

PROC_VER_NUM_INSTANCES
Procedure Configuration Summary

This attribute defines how many old instances of a procedure are kept in the iProcess database. The most recent instance of a procedure version is always kept. This attribute must be set for ALL processes. The attribute value must be one of the following: Value 0 n Meaning There is no limit to the number of instances of a procedure that are kept. This is the default value. n number of instances of a procedure will be kept in the iProcess database (where n is a positive integer).

Applies To Permissible Values

Default Value

This attribute is not defined on a newly installed iProcess Engine. In this case, the default value is: Machine ID 0 Process ALL Instance 0 Value 0

The attribute only appears in the output of the SHOW_ALL_ATTRIBUTES command if you have explicitly assigned a value to it using the SET_ATTRIBUTE command. The default setting is not displayed
Notes

Every time you edit and save a version of a procedure, iProcess creates a new instance of that procedure version. The PROC_VER_NUM_INSTANCES attribute applies to all old instances of a procedure. Each procedure instance is allocated an instance identifier. Each time a new instance is created the instance identifier is incremented by one. The instances of a procedure are tidied up as when a procedure is saved. This is because a tidy operation is performed each time a procedure is saved which tidies up the number of instances according to the attribute value you have set. The first time you set the attribute you can run the swadm tidy_instances command to force a tidy operation to tidy up the number of instances of some or all of your procedures, depending on your requirements. To do this you need to run the SWDIR\util\swadm tidy_instances command. See Tidy Instances of Procedures on page 312 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

274

| Chapter 6

Administering Process Attributes

For more information about the use of version numbering with procedures, see Using Version Control in the TIBCO iProcess Modeler - Procedure Management Guide.
See Also

DEF_MAJOR_VERS, DEF_MINOR_VERS, PROC_VER_COMMENT,PROC_VER_INC

TIBCO iProcess Engine Administrators Guide

Back to Library

iProcess Objects Director 275

iProcess Objects Director

Process attributes that are used by the DIRECTOR process are not documented in this guide. For more information about attributes that are used by the DIRECTOR process, see the TIBCO iProcess Objects Director Administrators Guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

276

| Chapter 6

Administering Process Attributes

TIBCO iProcess Engine Administrators Guide

Back to Library

| 277
Chapter 7

Administering Message Queues and Mbox Sets

This chapter describes how to use the server configuration utility SWDIR\util\swadm to administer Mbox sets, message queues and message instructions. Refer to iProcess Mbox Sets in the TIBCO iProcess Engine: Architecture Guide for more information about how the iProcess Engine uses Mbox sets, message queues and messages.

Topics
Introduction, page 278 Using SWDIR\util\swadm to Administer Mbox Sets, Message Queues and Messages, page 279 Using the iProcess Server Manager to Administer Message Queues, page 300 Default Message Handling Configuration, page 301

TIBCO iProcess Engine Administrators Guide

Back to Library

278

| Chapter 7

Administering Message Queues and Mbox Sets

Introduction
There are two utilities that you can use to administer iProcess message queues: the SWDIR\util\swadm utility, which you can use to directly administer Mbox sets, queues and messages. See Using SWDIR\util\swadm to Administer Mbox Sets, Message Queues and Messages on page 279 for more information. the iProcess Server Manager, which provides a graphical view of message queues. You can use it to administer single messages or queues. See Using the iProcess Server Manager to Administer Message Queues on page 300 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

Using SWDIR\util\swadm to Administer Mbox Sets, Message Queues and Messages 279

Using SWDIR\util\swadm to Administer Mbox Sets, Message Queues and Messages

You can use the SWDIR\util\swadm utility to administer (view, add, delete and modify) Mbox sets, queues and messages. Note that: To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user. If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance).

TIBCO iProcess Engine Administrators Guide

Back to Library

280

| Chapter 7

Administering Message Queues and Mbox Sets

The following table summarizes the commands you can use to administer Mbox sets, message queues and messages. Area Mbox sets Task Show Mbox Sets Add an Mbox Set Add a Message Queue to an Mbox Set Delete a Message Queue From an Mbox Set Rename an Mbox Set Delete an Mbox Set Queues Show Message Queues Add a Message Queue Update a Message Queue Delete a Message Queue Messages Show Messages in a Queue Count Messages in a Queue Show Details of a Message Restore Dead Messages to a Queue Delete Messages From a Queue swadm Command show_mboxsets add_mboxset add_queue_to_mboxset delete_queue_from_mboxset update_mboxset delete_mboxset show_queues add_queue update_queue delete_queue show_messages count_messages detail_message restore_dead_messages delete_messages

These commands read and update the mbox_set, mbox_set_group and iql_queues database tables.

TIBCO iProcess Engine Administrators Guide

Back to Library

Show Mbox Sets 281

Show Mbox Sets

To display a list of current Mbox sets defined on the iProcess Engine, use the following command:
swadm show_mboxsets [v]

The command lists the following information for each Mbox set: Mboxset ID is the unique identifier for the Mboxset, assigned when the Mbox set is created. Mboxset Name is the descriptive name of the Mbox set. Queue Type identifies the type of messages held in queues in the Mbox set. This will be Local (for local messages).

If the v option has been specified, the following information is also displayed: Queues in MBOX Set lists the queues that belong to the Mbox set. Queues are listed by their unique queue identifier. (You can use the show_queues command to find out more about each queue.)

The following example shows the use of the basic show_mboxsets command.
swadm show_mboxsets Mboxset ID 1 2 3 Mboxset Name BGMBSET WMDMBSET PREDICTMBSET Queue Type Local Local Local

The following example shows the use of the show_mboxsets v command.

swadm show_mboxsets v Mboxset ID 1 2 3 Mboxset Name BGMBSET WMDMBSET PREDICTMBSET Queue Type Local Local Local Queues in MBOX Set 1,2 3,4 6,7

TIBCO iProcess Engine Administrators Guide

Back to Library

282

| Chapter 7

Administering Message Queues and Mbox Sets

Add an Mbox Set

To add a new Mbox set to the iProcess Engine, use the following command:
swadm add_mboxset

mboxset_name message_type

where: mboxset_name is the name of the new Mbox set (up to a maximum of 32 characters). You can use this to identify what the Mbox set is used for, for example, processing Background messages. message_type is used to identify the message type. This should be Local (for local messages).

The following example adds a new Mbox set BGMBSET2 to the iProcess Engine.
swadm add_mboxset BGMBSET2 Local

TIBCO iProcess Engine Administrators Guide

Back to Library

Add a Message Queue to an Mbox Set 283

Add a Message Queue to an Mbox Set

You can add or remove message queues to Mbox sets at any time to alter the Mbox set configuration. For example, you might want to increase the number of queues in an Mbox to handle a larger volume of messages. You must explicitly create a queue before you can add it to an Mbox set. You can do this using the add_queue command. To add a queue to an Mbox set, use the following command:
swadm add_queue_to_mboxset

mboxset_id queue_id

where:

queue_id is the unique identifier of the queue you want to add. You can find a queues identifier using the show_queues command.

The following example adds the queue BGMBOX3 to the BGMBSET Mbox set. (The show_mboxsets command is used first to identify the BGMBSET Mbox sets mboxset_id, which is 1.)
swadm show_mboxsets Mboxset ID 1 2 3 Mboxset Name BGMBSET WMDMBSET PREDICTMBSET Queue Type Local Local Local

swadm add_queue_to_mboxset 1 BGMBOX3

TIBCO iProcess Engine Administrators Guide

Back to Library

mboxset_id is the unique identifier for the Mbox set. You can find an Mbox sets identifier using the show_mboxsets command.

284

| Chapter 7

Administering Message Queues and Mbox Sets

Delete a Message Queue From an Mbox Set

To remove a queue from an Mbox set, use the following command:
swadm delete_queue_from_mboxset

mboxset_id queue_id

where: mboxset_id is the unique identifier for the Mbox set. You can find an Mbox sets identifier using the show_mboxsets command. queue_id is the unique identifier for the queue you want to delete. You can find a queues identifier using the show_queues command.

swadm show_mboxsets Mboxset ID 1 2 3 Mboxset Name BGMBSET WMDMBSET PREDICTMBSET Queue Type Local Local Local

swadm delete_queue_from_mboxset 1 BGMBOX3

TIBCO iProcess Engine Administrators Guide

Back to Library

The following example deletes the queue BGMBOX3 from the BGMBSET Mbox set. (The show_mboxsets command is used first to identify the BGMBSET Mbox sets mboxset_id, which is 1.)

Rename an Mbox Set 285

Rename an Mbox Set

To change the name of an Mbox set, use the following command:
swadm update_mboxset

mboxset_id new_name

where: mboxset_id is the unique identifier for the Mbox set. You can find an Mbox sets identifier using the show_mboxsets command. new_name is the new name for this Mbox set (up to a maximum of 32 characters).

swadm show_mboxsets Mboxset ID 1 2 3 4 Mboxset Name BGMBSET WMDMBSET PREDICTMBSET BGMBSET2 Queue Type Local Local Local Local

swadm update_mboxset 4 BGMBSET3

TIBCO iProcess Engine Administrators Guide

Back to Library

The following example renames the BGMBSET2 Mbox set as BGMBSET3. (The show_mboxsets command is used first to identify the BGMBSET2 Mbox sets mboxset_id, which is 4.)

286

| Chapter 7

Administering Message Queues and Mbox Sets

Delete an Mbox Set

To delete an Mbox set, use the following command:
swadm delete_mboxset

mboxset_id

where mboxset_id is the unique identifier of the Mbox set. You can find an Mbox sets identifier using the show_mboxsets command. Any queues contained in the Mbox set are not affected by this command. If you also want to delete the queues you must use the delete_queue command after you have deleted the Mbox set. The following example deletes the PREDICTMBSET Mbox set. (The show_mboxsets command is used first to identify the PREDICTMBSET Mbox sets mboxset_id, which is 3.)
swadm show_mboxsets Mboxset ID 1 2 3 Mboxset Name BGMBSET WMDMBSET PREDICTMBSET Queue Type Local Local Local

swadm delete_mboxset 3

TIBCO iProcess Engine Administrators Guide

Back to Library

Show Message Queues 287

Show Message Queues

To display a list of all the message queues currently set up on your system and view their queue names and identifiers, use the following command:
swadm show_queues [queue_name]

where queue_name is the optional name of a queue, which you can use to only display queues matching this name. The command lists the following information for each queue: Queue ID is the unique identifier for the queue, assigned when the queue is created. Queue Name is the descriptive name of the queue. Queue Type identifies the type of messages held in the queue. This will be Local (for local messages). Queues Desc specifies the physical database table that is used to hold the queue. See the add_queue command for a full description of the format of this entry.

The following example lists all the queues currently defined on the iProcess Engine (Windows version).
swadm show_queues Queue ID Queue Name Queue Type Queue Desc

1 2 3 4 5 6 7

BGMBOX1 BGMBOX2 WISMBOX1 WISMBOX2 DEADQUEUE PREDICTMBOX1 PREDICTMBOX2

Local Local Local Local Local Local Local

0003:swpro.sw_db_bgqueue_1 0003:swpro.sw_db_bgqueue_2 0003:swpro.sw_db_wisqueue_1 0003:swpro.sw_db_wisqueue_2 0003:swpro.sw_db_deadqueue 0003:swpro.sw_db_predictqueue_1 0003:swpro.sw_db_predictqueue_2

TIBCO iProcess Engine Administrators Guide

Back to Library

288

| Chapter 7

Administering Message Queues and Mbox Sets

Add a Message Queue

When adding queues, you have to add: 1. a queue 2. an Mbox set 3. the queue to the Mbox set. To set up a new queue on your system (so that you can then add it to an Mbox set), use the following command:
swadm add_queue

queue_name message_type queue_description

where:

message_type is used to identify the message type. This should be Local (for local messages). queue_description specifies the physical database table that is used to hold the queue, in the following format:
version:table

where: version is an internal number used by the iProcess Suite to identify the physical syntax of the string that follows it. This should be either: 0001, for Oracle AQ. 0003, for queues that are held in the iProcess database.

table is the name of the database table that holds the queue, and must be specified in the format needed to access the table (e.g. MS-SQL, DB2 or Oracle AQ). The database table used to hold the queue must already exist, and must conform to the appropriate format. If it does not, messages will not be able to be added to or read from the queue and the iProcess Engine will not function correctly. For more information, see: Oracle AQ Queue Tables and Queues in the TIBCO iProcess Engine (Oracle): Administrator's Guide (for Oracle AQ tables). iProcess DB2 Database Queues in the TIBCO iProcess Engine (DB2): Administrator's Guide (for iProcess database tables in a DB2 database).

TIBCO iProcess Engine Administrators Guide

Back to Library

queue_name is a descriptive alphanumeric name for the queue.

Add a Message Queue 289

iProcess SQL Server Database Queues in the TIBCO iProcess Engine (SQL): Administrator's Guide (for iProcess database tables in a SQL Server database).

IMPORTANT! If you are using queues held in the iProcess database (version = 0003), you should note that: Each individual queue used by the iProcess Engine must be held in its own database table. These tables must be held in either: the database being used by the iProcess Suite (the default option). a different database on the same database server. Wherever the tables are held, the following permissions must be set up:

The iProcess Engine database user (default swuser) must have at least insert permissions on the database table used to hold the queue.
Examples

1. This example (for Windows/SQL Server) adds a queue called BGMBOX3. This queue is the physical queue sw_db_wisqueue3, owned by swpro, in the current iProcess database.
swadm add_queue BGMBOX3 Local 0003:swpro.sw_db_wisqueue3

2. This example (for Windows/SQL Server) adds a queue called BGMBOX4. This queue is the physical queue sw_db_bgqueue4 owned by user bart, in the sw database (on the SQL server hosting the iProcess database).
swadm add_queue BGMBOX4 Local 0003:sw.bart.sw_db_bgqueue4

TIBCO iProcess Engine Administrators Guide

Back to Library

The iProcess Engine database schema owner (default swpro) must have at least insert, select and delete permissions on the database table used to hold the queue.

290

| Chapter 7

Administering Message Queues and Mbox Sets

Update a Message Queue

You can change the queue name, message type and/or queue description using the following command:
swadm update_queue

queue_id | queue_name new_name message_type

queue_description

where: queue_id is the unique identifier for the queue. You can find a queues identifier using the show_queues command. queue_name is the descriptive alphanumeric name for the queue.

message_type is used to identify the message type. This value must be either Local (for local messages), or a hyphen - (to leave the value unchanged). queue_description specifies the physical database table that holds the queue. If you want to leave the existing name unchanged, use a hyphen -. See the description of this parameter under the add_queue command for a full description of the syntax and requirements for this parameter.

Examples

1. This example (for Windows/SQL Server) points the queue BGMBOX3 to use a different physical queue, sw_db_bgqueue5 owned by swpro (in the current database used by the iProcess Engine). The queues current name and message type are left unchanged.
swadm update_queue BGMBOX3 - - 0003:swpro.sw_db_bgqueue5

2. This example renames the queue BGMBOX3 to BGMBOX5. The queue will continue to use its existing message type and physical queue.
swadm update_queue BGMBOX3 BGMBOX5 - -

TIBCO iProcess Engine Administrators Guide

Back to Library

new_name is the new name to be used for this queue. If you want to leave the existing name unchanged, use a hyphen -.

Delete a Message Queue 291

Delete a Message Queue

Before deleting a queue you should remove it from the Mbox set, using the delete_queue_from_mboxset command. To delete a queue, use the following command:
delete_queue

queue_id | queue_name

where: queue_id is the unique identifier for the queue. You can find a queues identifier using the show_queues command. queue_name is the descriptive alphanumeric name for the queue.

The following example deletes the BGMBOX3 queue.

swadm delete_queue BGMBOX3

TIBCO iProcess Engine Administrators Guide

Back to Library

swadm displays a warning message if you have not already removed the queue from the Mbox set.

292

| Chapter 7

Administering Message Queues and Mbox Sets

Show Messages in a Queue

To display a summary list of all the iProcess messages that are currently in a queue, use the following command:
swadm show_messages

queue_id|ALL [EXP] [-x]

where: queue_id is the unique identifier of the queue you want to view messages for. You can find a queues identifier using the show_queues command. Enter ALL to show the messages in all queues. EXP is an optional parameter used with Oracle databases only. Use it to show all the Oracle exception messages. If this parameter is not specified, show_messages when used on an Oracle system will only list normal messages; with other types of database it will show all the messages. -x is an optional parameter that changes the format in which messages are displayed. If this parameter is specified, one message is displayed per line and fields in the message are separated by '|' characters.

TIBCO iProcess Engine Administrators Guide

Back to Library

Show Messages in a Queue 293

The following example (for Windows/SQL Server) lists all the messages in the DEADQUEUE queue. (The show_queues command is used first to identify the DEADQUEUEs queue_id, which is 5.) In this case the DEADQUEUE contains just a single RELEASE instruction that has failed to be processed.
swadm_show_queues Queue ID Queue Name Queue Type Queue Desc

1 2 3 4 5

BGMBOX1 BGMBOX2 WISMBOX1 WISMBOX2 DEADQUEUE

Local Local Local Local Local

0003:swpro.sw_db_bgqueue_1 0003:swpro.sw_db_bgqueue_2 0003:swpro.sw_db_wisqueue_1 0003:swpro.sw_db_wisqueue_2

swadm show_messages 5 Queue ID 5 Message ID: Instruction: Addressee: Procedure: Step Name: Case Number: Req ID: Failed Count: Failed By: 291E84BA-A898-4D6A-A812-A76BE108B21D RELEASE pro TESTBW2 STEP1 1253 2504 0 BG

The following command displays the same messages in the alternative format:
swadm show_messages 5 -x 5|291E84BA-A898-4D6A-A812-A76BE108B21D|RELEASE|pro|TESTBW2|STEP1| 1253|2504|0|BG

TIBCO iProcess Engine Administrators Guide

Back to Library

0003:swpro.sw_db_deadqueue

294

| Chapter 7

Administering Message Queues and Mbox Sets

Count Messages in a Queue

To display the total count of all the iProcess messages that are currently in a given queue, use the following command:
swadm count_messages

queue_id|ALL [EXP]

where: queue_id is the unique identifier of the queue you want to count messages for. You can find a queues identifier using the show_queues command. Enter ALL to count the messages in all queues. EXP is an optional parameter used with Oracle databases only. Use it to count all the Oracle exception messages. If this parameter is not specified, count _messages when used on an Oracle system will only include normal messages; with other types of database it will count all the messages.

The following example counts the messages in queue 5:

swadm count_messages 5 The total count of the messages in the queue 5: 6

The following example counts the messages in all queues:

swadm count_messages all The The The The The The The total total total total total total total count count count count count count count of of of of of of of the the the the the the the messages messages messages messages messages messages messages in in in in in in in the the the the the the the queue queue queue queue queue queue queue 1: 2: 3: 4: 5: 6: 7: 0 0 0 0 6 0 0

TIBCO iProcess Engine Administrators Guide

Back to Library

Show Details of a Message 295

Show Details of a Message

To display the header and body information of a message, use the following command:
swadm detail_message

queue_id message_id [-x]

where queue_id is the unique identifier of the queue containing the message for which you want to display details. You can find a queues identifier using the show_queues command. message_id is the identifier of a specific message in the queue queue_id. This ID is part of the information displayed by swadm show_messages - see Show Messages in a Queue on page 292. -x is an optional parameter that changes the format in which messages are displayed. If this parameter is specified, the message is displayed on one line and fields in the message are separated by '|' characters.

The following example shows the detail of one message in queue 5:

swadm detail_message 5 291E84BA-A898-4D6A-A812-A76BE108B21D Queue ID 5 Message ID: Instruction: Procedure Number: Case Number: User Name: Step Name: Step Desc: Release Date: Release Time: Addressee User: Message 291E84BA-A898-4D6A-A812-A76BE108B21D RELEASE 16:0:0 1253 swpro STEP1 13/03/2008 09:07 swpro RELEASE^staffw_107^16:0.0^1^staffw_107,swpro, 2504,staffw_107^1253^1253^staffw_107^swpro^ST EP1^^3^13/03/2008^09:07^2504^staffw_107^swpro ^1^

The following example shows the same message using the alternative display option:
swadm detail_message 5 291E84BA-A898-4D6A-A812-A76BE108B21D -x

TIBCO iProcess Engine Administrators Guide

Back to Library

296

| Chapter 7

Administering Message Queues and Mbox Sets

5|291E84BA-A898-4D6A-A812-A76BE108B21D|RELEASE|16:0.0|1253|swpro|S TEP1||13/03/2008|09:07|swpro|RELEASE^staffw_107^16:0.0^1^staffw_10 7,swpro,2504,staffw_107^1253^1253^staffw_107^swpro^STEP1^^3^13/03/ 2008^09:07^2504^staffw_107^swpro^1^

TIBCO iProcess Engine Administrators Guide

Back to Library

Restore Dead Messages to a Queue 297

Restore Dead Messages to a Queue

To restore one or more dead iProcess messages to the queue from which they came, and make the messages live again, use the following command:
swadm restore_dead_messages to_queue_id ALL [BG|WISMBD|BGPREDICT]|message_id|-f file_name

where: to_queue_id is the queue identifier of the destination queue, the queue to which you want to restore messages. The usage of the parameter ALL [BG|WISMBD|BGPREDICT] varies according
to database type:

BG: the dead message comes from a BG queue WISMBD: the dead message comes from a WISMBD queue BGPREDICT: the dead message comes from a BGPREDICT queue

Because there is more than one BG, WIS or BGPREDICT queue in the system, you must tell this command what type of dead message you want to move from the dead queue (one of BG, WIS or BGPREDICT), and the number of the live queue to which the message is to be restored. For example, the command:
RESTORE_DEAD_MESSAGES 1 ALL BG

moves all dead messages failed from the BG queue from the dead queue to queue 1. In DB2 usage is similar because the DB2 version has the same database structure as SQL Server, but there is one difference. The FAILED_BY field contains the name of the actual queue from which the dead message was failed, instead of a queue type. Neither this queue name nor the queue type needs to be specified in the command line. For example, the command:
RESTORE_DEAD_MESSAGES 1 ALL

moves all the dead messages failed by queue 1 from the dead queue to queue 1. In Oracle, there is no specific dead queue. If a message in any given queue is failed, it is stored in that same queue and is just marked as a dead
TIBCO iProcess Engine Administrators Guide

Back to Library

In SQL Server, there is a specific dead queue that holds all the dead messages that have been failed from any of the live queues. Messages in this dead queue have a unique additional field, called FAILED_BY, which identifies the type of queue from which the dead message comes. This field has one of three values:

298

| Chapter 7

Administering Message Queues and Mbox Sets

message. This command therefore does not actually move messages from one queue to another; it merely changes them from dead messages to live messages within the same queue. It is therefore only necessary to specify in the command which queue you want to restore. For example, the command:
RESTORE_DEAD_MESSAGES 1 ALL

restores all the dead messages in queue 1 to being live messages in queue 1. message_id specifies the ID of the message that you want to restore. The following example restores an exception message to queue 1:
swadm restore_dead_messages 1 291E84BA-A898-4D6A-A812-A76BE108B21D

TIBCO iProcess Engine Administrators Guide

Back to Library

-f file_name identifies a text file that contains one or more message IDs, separated from each other by a return character. If the beginning of a line has a semi-colon (;) character, that line is treated as a comment and all the content in the line is omitted.

Delete Messages From a Queue 299

Delete Messages From a Queue

To delete one or more iProcess messages from a queue, use the following command:
swadm delete_messages

queue_id ALL [EXP]| message_id|-f file_name

where queue_id is the unique identifier of the queue containing the messages which you wish to delete. You can find a queues identifier using the show_queues command. Enter ALL to delete the messages in all queues. EXP is an optional parameter used with Oracle databases only. Use it to delete all the Oracle exception messages in the queue. If this parameter is not specified, only normal messages will be deleted on an Oracle system; with other types of database, all types of message are deleted. message_id specifies the ID of the message that you want to delete. The following example deletes an exception message from queue 1:
swadm delete_messages 1 291E84BA-A898-4D6A-A812-A76BE108B21D

-f file_name identifies a text file that contains one or more message IDs for deletion. The file must be located in the SWDIR/util directory. Message IDs are separated from each other by a return character. If the beginning of a line has a semi-colon (;) character, that line is treated as a comment and all the content in the line is omitted.

Example

The following command deletes the specified message from queue 5:

swadm delete_messages 5 AB87DAEF-CEAD-4EC2-A44B-6F5DF716E4D6

TIBCO iProcess Engine Administrators Guide

Back to Library

300

| Chapter 7

Administering Message Queues and Mbox Sets

Using the iProcess Server Manager to Administer Message Queues

The iProcess Server Manager is a JSP web client application that utilizes TIBCO Hawk to provide a graphical view of the messages and message queues on a machine or a node cluster. You can also use the iProcess Server Manager to administer server processes. See Using the iProcess Server Manager to Administer Server Processes on page 122 for details of TIBCO Hawk requirements, and of how to set up and start the iProcess Server Manager.

Controlling Message Queues

To view the Message Queue Management pane, expand iProcess Management > Queue Management. The iProcess Management page shows information for the server you selected on the Configuration pane - see Configuring the iProcess Server Manager on page 125. The view is hierarchical, so expand a server or a node in a cluster to show individual message queues running on each. Alerts The iProcess Server Manager sends warning messages when: A message is retried a configurable number of times, or more. This value defaults to three times. Any queue contains more than 50 messages. A message is put in the exception queue.

TIBCO iProcess Engine Administrators Guide

Back to Library

Default Message Handling Configuration 301

Default Message Handling Configuration

This section describes the message handling configuration that is used on a default iProcess Engine installation.

Default Mbox Sets

The following table shows the default Mbox sets that are created when the iProcess Engine is installed. See Show Mbox Sets on page 281 for an explanation of the Mboxset ID, Mboxset Name and Queues in Mboxset columns. Mboxset ID 1 2 3 4 5 Mboxset Name BGMBSET WMDMBSET WISBGMBSET1 WISBGMBSET2 PREDICTMBSET Queues in Mboxset

WISMBOX1, WISMBOX2 BGMBOX1 BGMBOX2 PREDICTMBOX1, PREDICTMBOX2

Default Message Queues

The following sections describe the default message queues that are created when the iProcess Engine is installed on a Windows or UNIX system. See Add a Message Queue on page 288 for an explanation of the Queue Name and Queue Description columns.

TIBCO iProcess Engine Administrators Guide

Back to Library

BGMBOX1, BGMBOX2

302

| Chapter 7

Administering Message Queues and Mbox Sets

Windows/SQL Server or UNIX/DB2 The following tables shows the default message queues that are created when the iProcess Engine is installed on a Windows/SQL Server or UNIX/DB2 system. Queue Name BGMBOX1 BGMBOX2 WISMBOX1 WISMBOX2 DEADQUEUE PREDICTMBOX1 PREDICTMBOX2 Queue Description 0003:swpro.sw_db_bgqueue_1 0003:swpro.sw_db_bgqueue_2 0003:swpro.sw_db_wisqueue_1 0003:swpro.sw_db_wisqueue_2 0003:swpro.sw_db_deadqueue 0003:swpro.sw_db_predictqueue_1 0003:swpro.sw_db_predictqueue_2

Each individual queue used by the iProcess Engine must be held in its own database table. These tables exist by default in the same database as the other iProcess tables, but they do not have to be held there. See Add a Message Queue on page 288 for more information. UNIX/Oracle or Windows/Oracle The following table shows the default Oracle AQ message queues that are created when the iProcess Engine is installed on a UNIX/Oracle or Windows/Oracle system. Queue Name BGMBOX1 BGMBOX2 WISMBOX1 WISMBOX2 PREDICTMBOX1 PREDICTMBOX2 Parameters 0001::bgmboxtable1:bgmboxqueue1 0001::bgmboxtable2:bgmboxqueue2 0001::wismboxtable1:wismboxqueue1 0001::wismboxtable2:wismboxqueue2 0001::predictmboxtable1:predictmboxqueue1 0001::predictmboxtable2:predictmboxqueue2

TIBCO iProcess Engine Administrators Guide

Back to Library

Default Message Handling Configuration 303

How WIS Processes Send Messages to BG Processes

The following diagram shows how the WIS processes send messages to the BG processes using the default configuration.

Process
WIS1

Mbox Set
MBSET_WRITE_BG

Queue

BG1, BG2
MBSET_READ_BG

WISBGMBSET1

BGMBOX1

BG3, BG4

WISBGMBSET2 WISBGMBSET1

BGMBOX2

WIS2

MBSET_WRITE_BG

1. One WIS process is configured to write messages to each WISBGMBSET Mbox set. 2. Each WISBGMBSET Mbox set contains a single message queue, BGMBOX. 3. Two BG processes are configured to read messages from each WISBGMBSET Mbox set.

TIBCO iProcess Engine Administrators Guide

Back to Library

304

| Chapter 7

Administering Message Queues and Mbox Sets

How non-WIS Processes Send Messages to BG Processes

The following diagram shows how non-WIS processes send messages to the BG processes using the default configuration.

Process

Mbox Set
MBSET_WRITE_BG

Queue

swbatch, spo etc.

BGMBOX1

BGMBSET BG1-4
MBSET_READ_BG

BGMBOX2

1. All non-WIS processes (such as swbatch) are configured to write messages to the BGMBSET Mbox set. 2. The BGMBSET Mbox set contains two message queues, BGMBOX1 and BGMBOX2. 3. All BG processes are configured to read messages from the BGMBSET Mbox set.

TIBCO iProcess Engine Administrators Guide

Back to Library

Default Message Handling Configuration 305

How BG Processes Send Messages to WIS Processes

The following diagram shows how the BG processes send messages to the WIS processes using the default configuration.

Process
MBSET_WRITE_WIS

Mbox Set
WMDMBSET

Queue
WISMBOX1

BG1,2,3,4

1. All four BG processes are configured to write messages to a single Mbox set, WMDMBSET. 2. The WMDMBSET Mbox set contains two message queues, WISMBOX1 and WISMBOX2. 3. Both WISMBD processes are configured to read messages from the WMDMBSET Mbox set. (Each WISMBD process then forwards each message to the appropriate WIS process via RPC.)

TIBCO iProcess Engine Administrators Guide

Back to Library

WISMBD1, WISMBD2 (via RPC -> WIS)

MBSET_READ_WIS

WISMBOX2

306

| Chapter 7

Administering Message Queues and Mbox Sets

How BG Processes Send Messages to the Prediction Process

The following diagram shows how the BG processes send messages to the BGPREDICT process using the default configuration.

Process

Mbox Set
MBSET_WRITE_PREDICT

Queue

BG1, 2, 3, 4

PREDICTMBSET

PREDICTMBOX1

BGPREDICT

MBSET_READ_PREDICT

PREDICTMBOX2

1. All four BG processes write messages to the PREDICTMBSET Mbox set. 2. The PREDICTMBSET Mbox set contains two Mboxes, PREDICTMBOX1 and PREDICTMBOX2. 3. The BGPREDICT process reads messages from the PREDICTMBSET Mbox set.

TIBCO iProcess Engine Administrators Guide

Back to Library

| 307
Chapter 8

Administering Procedure Objects

This chapter explains how to use the server configuration utility SWDIR\util\swadm to administer the procedures (including sub-procedures and sub-procedure parameter templates) and libraries that are defined on this iProcess Engine. To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user.

These commands read and update data in the pm_objects, proc_index, proc_version, proc_instance, proc_audit, proc_defn and proc_mgt_hierarchy database tables.

Topics
Show Procedures and Libraries, page 308 Tidy Instances of Procedures, page 312

TIBCO iProcess Engine Administrators Guide

Back to Library

If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance).

308

| Chapter 8

Administering Procedure Objects

Show Procedures and Libraries

TIBCO recommend that you run this command if you have experienced problems when importing procedures or procedure libraries. To display a list of procedures and libraries that are defined on this iProcess Engine, enter the following command:
swadm show_procedures [fix]

where fix is an optional parameter that you can use to fix any errors that are reported - for example, if a database record in the pm_objects table has become corrupt. (See Errors on page 309.)

Output
The list of procedures and libraries (objects) is displayed. The following information is displayed about each object:
(type)

ObjectName - ObjectGUID

where: type is one of the following single characters that indicates what the object is: F is a library. P is a procedure. S is a sub-procedure. T is a sub-procedure parameter template. ObjectName is the name of the procedure or library. ObjectGUID is the unique identifier for this procedure or library.

The contents of libraries are indented to indicate their hierarchical relationship.

TIBCO iProcess Engine Administrators Guide

Back to Library

Show Procedures and Libraries 309

Errors
ERROR messages are displayed if any errors are detected. If the fix parameter has been specified, and the error is one that can be fixed, a FIX message is displayed immediately after the ERROR message, indicating what has been done. The following list shows the errors that can occur and be fixed, and the fixes that are applied if you specify the fix parameter:
ERROR: PM_OBJECTS ObjectName - ObjectGUID refers to proc_id: proc_id which does not exist FIX: delete PM_OBJECTS record ObjectName - ObjectGUID ERROR: PM_OBJECTS ObjectName - ObjectGUID refers to proc_id: proc_id which is the proc_id for procedure proc_name FIX: delete PM_OBJECTS record ObjectName - ObjectGUID ERROR: PROC_MGT_HIERARCHY record refers to non existent object ObjectGUID FIX: delete PROC_MGT_HIERARCHY record ObjectGUID ERROR: PROC_MGT_HIERARCHY record refers to non existent folder ParentGUID FIX: change PROC_MGT_HIERARCHY record ObjectGUID to point to Root ERROR: PM_OBJECTS ObjectName - ObjectGUID not in hierarchy FIX: add PROC_MGT_HIERARCHY record ObjectGUID to point to Root

The following list shows the errors that can occur but that cannot currently be fixed by specifying the fix parameter. If any of these errors occur you should contact TIBCO Support for further assistance.
ERROR: PM_OBJECTS ObjectName - ObjectGUID refers to proc_id: proc_id which is too small ERROR: PM_OBJECTS ObjectName - ObjectGUID refers to proc_id: proc_id which is too big(>pcount) ERROR: PM_OBJECTS ObjectName - ObjectGUID refers to proc_id: proc_id which is referred to by other record(s) ERROR: PM_OBJECTS ObjectName - ObjectGUID (PROC) refer to proc_id: proc_id which is a SUBPROC ERROR: PM_OBJECTS ObjectName - ObjectGUID (SUBPROC) refers to proc_id: proc_id which is a PROC ERROR: PROC_INDEX p_ix - proc_name is not referred to by any PM_OBJECTS records

TIBCO iProcess Engine Administrators Guide

Back to Library

310

| Chapter 8

Administering Procedure Objects

Examples
1. This example shows the output from the swadm show_servers command. The root library contains the CARPOOL, HIRING and QUOTA procedures and two libraries - Purchasing and Admin, each of which contains further procedures. A corrupt TEST3 record, which references a procedure that does not exist, has also been found.
# swadm show_procedures ERROR: PM_OBJECTS TEST3 - DA22EA30-FE69-11D7-A619-0050DAC9102A refers to proc_id: -1 which does not exist (F) ROOT_LIBRARY - ROOT_LIBRARY_GUID (F) Purchasing - A14E77B0-D268-11D7-BE25-0050DAC9102A (P) PROC1 - 96EFB7C0-F5D0-11D7-BAB5-0050DAC9102A (P) TEST1 - ACABECB0-D268-11D7-9833-0050DAC9102A (P) TEST3 - DA22EA30-FE69-11D7-A619-0050DAC9102A (S) DOCHECK - 99C651A0-E3C8-11D7-911C-0050DAC9102A (S) SUB1 - 306F0B50-DFD9-11D7-A8AC-0050DAC9102A (T) TEMPL1 - 3F956EB0-DFDA-11D7-A683-0050DAC9102A (F) Admin - 66D85000-E321-11D7-B184-0050DAC9102A (P) DYNAMIC1 - 272CA750-E3C7-11D7-A96A-0050DAC9102A (P) TEST2 - 43F72230-F507-11D7-BFCF-0050DAC9102A (P) WAIT1 - C88236B0-E329-11D7-BCB9-0050DAC9102A (S) DOCHECK - 99C651A0-E3C8-11D7-911C-0050DAC9102A (T) TEMPL1 - 3F956EB0-DFDA-11D7-A683-0050DAC9102A (P) CARPOOL - 9E697DC0-D4F7-11D7-B115-0050DAC9102A (P) HIRING - 75A4BB20-D4F7-11D7-9E50-0050DAC9102A (P) QUOTA - 94A58F00-D4F7-11D7-88D0-0050DAC9102A

TIBCO iProcess Engine Administrators Guide

Back to Library

Show Procedures and Libraries 311

2. This example shows the output when the swadm show_servers fix command is used to correct the problem found in the previous example. The corrupt TEST3 record is deleted.
# swadm show_procedures fix ERROR: PM_OBJECTS TEST3 - DA22EA30-FE69-11D7-A619-0050DAC9102A refers to proc_id: -1 which does not exist FIX: delete PM_OBJECTS record TEST3 - DA22EA30-FE69-11D7-A619-0050DAC9102A (F) ROOT_LIBRARY - ROOT_LIBRARY_GUID (F) Purchasing - A14E77B0-D268-11D7-BE25-0050DAC9102A (P) PROC1 - 96EFB7C0-F5D0-11D7-BAB5-0050DAC9102A (P) TEST1 - ACABECB0-D268-11D7-9833-0050DAC9102A (S) DOCHECK - 99C651A0-E3C8-11D7-911C-0050DAC9102A (S) SUB1 - 306F0B50-DFD9-11D7-A8AC-0050DAC9102A (T) TEMPL1 - 3F956EB0-DFDA-11D7-A683-0050DAC9102A (F) Admin - 66D85000-E321-11D7-B184-0050DAC9102A (P) DYNAMIC1 - 272CA750-E3C7-11D7-A96A-0050DAC9102A (P) TEST2 - 43F72230-F507-11D7-BFCF-0050DAC9102A (P) WAIT1 - C88236B0-E329-11D7-BCB9-0050DAC9102A (S) DOCHECK - 99C651A0-E3C8-11D7-911C-0050DAC9102A (T) TEMPL1 - 3F956EB0-DFDA-11D7-A683-0050DAC9102A (P) CARPOOL - 9E697DC0-D4F7-11D7-B115-0050DAC9102A (P) HIRING - 75A4BB20-D4F7-11D7-9E50-0050DAC9102A (P) QUOTA - 94A58F00-D4F7-11D7-88D0-0050DAC9102A

TIBCO iProcess Engine Administrators Guide

Back to Library

312

| Chapter 8

Administering Procedure Objects

Tidy Instances of Procedures

Each time you edit and save a version of a procedure, a new instance of the procedure version is created. By default, all the instances of a procedure are kept. If you want to limit the amount of old instances that are kept for each procedure (for example, in order to save space in the iProcess database), you need to set the PROC_VER_NUM_INSTANCES attribute. Even if you have set the PROC_VER_NUM_INSTANCES attribute, the most recent instance of a procedure version is always kept. The first time you set the PROC_VER_NUM_INSTANCES attribute, you can use the swadm tidy_instances command to tidy up the old instances of a procedure so that they match the value you have set for the PROC_VER_NUM_INSTANCES attribute. Otherwise, the instances of a procedure are tidied up as and when a procedure is saved. This is because a tidy operation is performed each time a procedure is saved. To tidy up the instances of a procedure defined on the iProcess Engine, enter the following command:
swadm tidy_instances

machine_id proc_id

where: machine_id is the unique identifier for the server. If you specify a value of 0, the command will apply to all servers in the iProcess Engine. proc_id is the unique identifier for the procedure. If you specify a value of 0, the command will apply to all procedures in the iProcess Engine.

TIBCO iProcess Engine Administrators Guide

Back to Library

| 313
Chapter 9

Administering Firewall Port Ranges

This chapter explains how to use the server configuration utility SWDIR\util\swadm to set up and use port ranges for the iProcess Engine, for use with firewall filters when the iProcess Engine is being used in a firewalled environment. To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user.

Topics
Overview, page 314 ADD_RANGE, page 316 DEL_RANGE, page 318 MOD_RANGE, page 320 SET_RANGE, page 321 SHOW_PORTS, page 323 SHOW_RANGES, page 325 ADD_AQ_PORT_RANGE, page 326 MOD_AQ_PORT_RANGE, page 327 DEL_AQ_PORT_RANGE, page 328

TIBCO iProcess Engine Administrators Guide

Back to Library

If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance).

314

| Chapter 9

Administering Firewall Port Ranges

Overview
If you are using the iProcess Engine in a firewalled environment, you can define specific port ranges which the firewall administrator can add to the network firewall filter. A port range is a specific range of either port numbers, RPC numbers or both. Once you have defined a port range, you can place the iProcess Engine node behind it. iProcess Engine processes will then only accept incoming RPC requests from within that port range. For more information about how the iProcess Engine works in a firewalled environment, see "Using the iProcess Engine in a Firewalled Environment", in the TIBCO iProcess Engine: Architecture Guide.

Using Port Ranges with a Node Cluster

If your iProcess Engine uses a node cluster configuration, each server in the iProcess Engine node can sit behind the same port range, sit behind a different port range, or not sit behind a port range at all, according to your network configuration requirements.

How Port Range Information is Stored

Port range information is stored in the following tables in the iProcess Engine database: port_range - contains the firewall data about individual port/RPC numbers that lie within each port range defined on this iProcess Engine port_range_active - lists what port/RPC numbers are being actively used to provide RPC services by iProcess Engine processes port_range_conf - lists the port ranges currently defined for this iProcess Engine. port_range_nodes - lists which port range configurations are being used by which machines in the iProcess Engine node.

See "Firewall Port Ranges" in the appropriate database guide for more information about these tables.

TIBCO iProcess Engine Administrators Guide

Back to Library

Overview 315

How to Set up and use a Port Range

To set up and use a port range on the iProcess Engine: 1. Use the ADD_RANGE command to define the port range. 2. Use the SET_RANGE command to place the required iProcess Engine server(s) behind the defined port range. 3. Pass the details of the port range to the firewall administrator, to include in the network firewall filter. If iProcess Engine servers are configured to run behind port ranges, a log file detailing the resource allocation is stored in SWDIR\logs\rpcport.log. See iProcess Engine Log Files on page 379 for more information.

Port Range swadm Commands

The following table summarizes all the SWDIR\util\swadm commands that you can use to administer port ranges. Each command is fully described in the following sections. To do this... Define a new port range. Delete an existing port range. Modify an existing port range (for example, to change the number range or operating mode). Place an iProcess Engine server behind a defined port range, or remove an iProcess Engine server from behind a defined port range. Show how the ports for a particular port range are currently allocated. Show the details of all defined port ranges and the iProcess Engine servers that are sitting behind them. Use this command... ADD_RANGE DEL_RANGE MOD_RANGE SET_RANGE SHOW_PORTS SHOW_RANGES

TIBCO iProcess Engine Administrators Guide

Back to Library

316

| Chapter 9

Administering Firewall Port Ranges

ADD_RANGE
swadm command Syntax
swadm ADD_RANGE [-m [-s

Range_mode] [-p Port_range_start] [-r RPC_range_start] Range_size]

Description

This command defines a new port range for use with this iProcess Engine node. You can then use the SET_RANGE command to place a server behind this port range. The port range is stored as a record in the port_range_conf table.

Options

Option
-m

Description

Range_mode

0 - Do not use port or RPC ranges. A process can use any port number and RPC number (as assigned by the operating system). 1 - Use port ranges. A process must use a port number allocated from within the defined range, but can use any RPC number. 2 - Use RPC ranges. A process must use an RPC number allocated from within the defined range, but can use any port number. 3 - Use port ranges and RPC ranges. A process must use both a port number and an RPC number allocated from within the defined ranges.

If this value is omitted the range mode defaults to 3.

-p

Port_range_start

The port number that the range should start from. (The range will therefore end at Port_range_start + Range_size.) If this value is omitted the port range start defaults to 10000.

-r

RPC_range_start

The RPC number that the range should start from. (The range will therefore end at RPC_range_start + Range_size.) If this value is omitted the RPC range start defaults to 400000.

TIBCO iProcess Engine Administrators Guide

Back to Library

Defines how servers that use this port range configuration should allocate ports. Specify one of the following values:

ADD_RANGE 317

Option
-s

Description The number of slots in the defined port and/or RPC number ranges. If this value is omitted the range size defaults to 20.

Range_size

Errors

The following error messages may be returned by this command. Message

Unable to access the port_range_conf table

Description swadm cannot update the iProcess Engine database. Examine the SWDIR\logs\sw_error and sw_warn files for more information about the cause of the error.

See Also

DEL_RANGE, MOD_RANGE, SET_RANGE, SHOW_PORTS, SHOW_RANGES

TIBCO iProcess Engine Administrators Guide

Back to Library

318

| Chapter 9

Administering Firewall Port Ranges

DEL_RANGE
swadm command Syntax Description
swadm DEL_RANGE

Port_range_ID

This command deletes an existing port range from the iProcess Engine. The port range is deleted from the port_range_conf table. When you run this command, if any servers are currently configured to run behind this port range the following prompt is displayed:
Deleting this port range will cause the following servers to be removed from the port_range_nodes table:

Are you sure you want to do this (Y/N)?

where server_ids is a comma-separated list of server identifiers and names for the servers that are currently configured to run behind this port range. If you answer: Y, the port range is deleted.The indicated servers are no longer running behind a port range. (The appropriate entries are deleted from the port_range_nodes table.) N, the port range is not deleted. The indicated servers are still running behind it. Description The ID of the port range that you want to delete. You can use the SHOW_RANGES command to find out what port range IDs are defined.
Errors

Options

Option
Port_range_ID

The following error messages may be returned by this command. Message

The specified port_range_id paramater Port_range_ID is invalid.

Description You have used a Port_range_ID value that does not exist. Re-run the command using the correct Port_range_ID value.

TIBCO iProcess Engine Administrators Guide

Back to Library

server_ids, ...

DEL_RANGE 319

Message
Unable to access the database table

Description swadm cannot update the iProcess Engine database. Examine the SWDIR\logs\sw_error and sw_warn files for more information about the cause of the error.

See Also

ADD_RANGE, MOD_RANGE, SET_RANGE, SHOW_PORTS, SHOW_RANGES

TIBCO iProcess Engine Administrators Guide

Back to Library

320

| Chapter 9

Administering Firewall Port Ranges

MOD_RANGE
swadm command Syntax
swadm MOD_RANGE

Port_range_id [-m Range_mode] [-p Port_range_start] [-r RPC_range_start] [-s Range_size]

Description

This command modifies one or more values for an existing port range. The port range record in the port_range_conf table is updated. You cannot use this command if the port range you want to modify is currently in use i.e. if any of the ports within the range are currently allocated to iProcess Engine processes. You can check this using the SHOW_PORTS command.

Options

Port_range_id

The ID of the port range that you want to modify. You can use the SHOW_RANGES command to find out what port range IDs are defined.

-m -p -r -s

Range_mode Port_range_start RPC_range_start Range_size

Specify an allowed value as defined for the same parameter in the ADD_RANGE command. If one or more of these parameters is omitted the current value is left unchanged.

Errors

The following error messages may be returned by this command. Message

There are currently n records allocated from this port range configuration. Unable to access the port_range_conf table.

Description You cannot update the Port_range_id port range because it is currently in use.

swadm cannot update the iProcess Engine database. Examine the SWDIR\logs\sw_error and sw_warn files for more information about the cause of the error.

See Also

ADD_RANGE, DEL_RANGE, SET_RANGE, SHOW_PORTS, SHOW_RANGES

TIBCO iProcess Engine Administrators Guide

Back to Library

Option

Description

SET_RANGE 321

SET_RANGE
swadm command Syntax Description
swadm SET_RANGE

Machine_id

[Port_range_id]

This command can be used to: place an iProcess Engine server behind a defined port range. remove an iProcess Engine server from behind a defined port range.

This information is updated in the port_range_nodes table.

Options

Option Machine_id

Description

You can use the SHOW_SERVERS command to find out the server IDs of servers in this iProcess Engine node.
Port_range_id

If you want to: add the specified Machine_id to a port range, specify the ID of the port range that you want to place this server behind. You can use the SHOW_RANGES command to find out what port range IDs are defined. remove the specified Machine_id from the port range that it is currently placed behind, you should omit this parameter.

Errors

The following error messages may be returned by this command. Message

Machine_ID is not a valid
logical machine ID. Use 'swadm SHOW_SERVERS' to see the correct list. The specified <Port Range ID> parameter is invalid.

Description You have used a Machine_ID that does not exist. Re-run the command using the correct server ID. You have used a Port_range_ID value that does not exist. Re-run the command using the correct Port_range_ID value.

TIBCO iProcess Engine Administrators Guide

Back to Library

The server ID of the machine that you want to add to or remove from a port range.

322

| Chapter 9

Administering Firewall Port Ranges

Message
Unable to add the specified iPE machines to the port range configuration. Check sw_error/sw_warn for more details.

Description swadm cannot update the iProcess Engine database. Examine the SWDIR\logs\sw_error and sw_warn files for more information about the cause of the error.

See Also

ADD_RANGE, DEL_RANGE, MOD_RANGE, SHOW_PORTS, SHOW_RANGES

TIBCO iProcess Engine Administrators Guide

Back to Library

SHOW_PORTS 323

SHOW_PORTS
swadm command Syntax Description
swadm SHOW_PORTS [-m

Machine_id] [-p Process_name]

This command displays information about which ports are currently being used by processes on this iProcess Engine node. This information is read from the port_range_active table. Option -m Machine_id Description The server ID of the machine that you want to show details for.

Options

If this parameter is omitted the local machine is used. -p Process_name The logical process name (in full) that you want to show details for. You can use the SHOW_PROCESSES command to find out the different logical process names. If this parameter is omitted all iProcess Engine processes that currently have port/RPC numbers allocated are shown.
Output

The command displays the current port number and RPC number allocations for the specified parameters. For example:

---------------------------------------------------------------------------Machine ID Process Name Process Instance Port Number RPC Number Process ID ---------------------------------------------------------------------------1 RPCBG 1 1147 1073745660 3836 1 RPC_POOL 1 1196 1073746828 5004 1 RPC_TCP_LI 1 1121 391875 3784 1 WIS 1 1145 1073745652 3828 1 WIS 2 1138 1073745636 3812 1 WQS 1 1131 1073744748 2924

TIBCO iProcess Engine Administrators Guide

Back to Library

You can use the SHOW_SERVERS command to find out the server IDs of servers in this iProcess Engine node.

324

| Chapter 9

Administering Firewall Port Ranges

Errors

The following error messages may be returned by this command. Message

Unable to access the port_range table.

Description swadm cannot read the information from the iProcess Engine database. Examine the SWDIR\logs\sw_error and sw_warn files for more information about the cause of the error.

See Also

ADD_RANGE, DEL_RANGE, MOD_RANGE, SET_RANGE, SHOW_RANGES

TIBCO iProcess Engine Administrators Guide

Back to Library

SHOW_RANGES 325

SHOW_RANGES
swadm command Syntax Description
swadm SHOW_RANGES

This command shows the port ranges that are currently defined on this iProcess Engine, and the servers that are currently running behind each of them. This information is read from the port_range_conf and port_range_nodes tables. The command displays the following information about the port ranges (values shown are examples):

Output

where: Range ID is the ID of this port range Range Mode, Range Size, Port Start and RPC Start are the configuration values for this port range. See the ADD_RANGE command for a full description of these values. Server IDs is a comma-delimited list of server IDs of the servers that are currently running behind this port range. You can use the SHOW_SERVERS command to find out the details of each server ID.

See Also

ADD_RANGE, DEL_RANGE, MOD_RANGE, SET_RANGE, SHOW_PORTS

TIBCO iProcess Engine Administrators Guide

Back to Library

----------------------------------------------------------------------Port Range ID Range Mode Range Size Port Start RPC Start Server ID's ----------------------------------------------------------------------1 0 20 10000 400000 2 2 50 11000 410000 3 1 20 15000 400000

326

| Chapter 9

Administering Firewall Port Ranges

ADD_AQ_PORT_RANGE
swadm command Syntax Description
swadm ADD_AQ_PORT_RANGE {<machine_id>|ALL|0} <start_port> <count>

Applies to TIBCO iProcess Engine for Oracle only. This command adds a new port range in the aq_port_range_conf table.

Options

Option <machine_id>

Description The ID of machine to which the port range is added. If this field is input as "ALL" or "0", the port range will be added to all machines. The port at which the port range starts. The range size for the port range.

<start_port> <count>
Output See Also

This command outputs a <range_id> which identifies this port range. MOD_AQ_PORT_RANGE, DEL_AQ_PORT_RANGE

TIBCO iProcess Engine Administrators Guide

Back to Library

MOD_AQ_PORT_RANGE 327

MOD_AQ_PORT_RANGE
swadm command Syntax Description
swadm MOD_AQ_PORT_RANGE <machine_id> <range_id> <start_port> <count>

Applies to TIBCO iProcess Engine for Oracle only. This command modifies a port range in the aq_port_range_conf table.

Options

Option <machine_id> <range_id> <start_port> <count>

See Also

Description The ID of the machine to which the port range identified by the <range_id> argument applies. The range identifier of the port range you wish to modify. The port at which the modified port range now starts. The new range size for the modified port range.

ADD_AQ_PORT_RANGE, DEL_AQ_PORT_RANGE

TIBCO iProcess Engine Administrators Guide

Back to Library

328

| Chapter 9

Administering Firewall Port Ranges

DEL_AQ_PORT_RANGE
swadm command Syntax Description
swadm DEL_AQ_PORT_RANGE <range_id>

Applies to TIBCO iProcess Engine for Oracle only. This command deletes a port range from the aq_port_range_conf table.

Options

Option <range_id>
See Also

Description The range_id of the port range you wish to delete.

TIBCO iProcess Engine Administrators Guide

Back to Library

ADD_AQ_PORT_RANGE, MOD_AQ_PORT_RANGE

| 329
Chapter 10

Administering Activity Monitoring and Work Queue Delta Publication

This chapter explains how to configure the iProcess Engine to publish iProcess Engine activity information and Work Queue Deltas to external applications.

Overview, page 330 Enabling Activity Monitoring, page 331 Filtering Message Event Request (MER) Messages, page 332 Configuring the iProcess Activity Publication (IAP) Configuration Files, page 333 Updating the IAP Security Principle and Credentials, page 336 Using SWDIR\util\swadm to Administer Work Queue Delta Publication, page 338

TIBCO iProcess Engine Administrators Guide

Back to Library

Topics

330

| Chapter 10

Administering Activity Monitoring and Work Queue Delta Publication

Overview
The TIBCO iProcess Engine can be enabled to publish both iProcess Engine activity information and iProcess Engine Work Queue Deltas to external applications, using JMS queues. An activity is any instruction in the iProcess Engine that creates an audit trail entry, for example, Case started or Event Issued. You can configure any combination of step and/or activity to be monitored. This enables an external application to monitor important business events during the processing of cases. A BG process can identify if a step is being processed and if activity monitoring has been configured for it. The BG process then sends details of the configured activities in XML format to the IAPJMS process. Work Queue Delta publication enables an external application (iProcess Server Objects (Java) or iProcess Server Objects (.NET)) to monitor a queue and to retrieve only those work items in a given work queue that have changed since the subscription started. The WIS process sends messages reporting Work Queue changes to the IAPJMS process. For both activity monitoring and Work Queue Delta publication, the IAPJMS process sends the XML message to a specified JMS topic, from which an external application (for example, iProcess Objects, iProcess Analytics or an external application that you have written yourself) can receive the JMS messages. Note that this Work Queue Delta publication via JMS functionality is independent of the ability to obtain Work Queue Delta items via the iProcess Server Objects interface, as described in the TIBCO iProcess Server Objects (Java) Programmers Guide.

TIBCO iProcess Engine Administrators Guide

Back to Library

Enabling Activity Monitoring 331

Enabling Activity Monitoring

Activity monitoring and Work Queue Delta publication can be configured when the iProcess Engine is installed. If this has not been done, you can subsequently enable them manually. To do this, you need to complete the following steps: 1. Make sure that the SWLIB_PATH process attribute points to the directory containing the Java libraries that you want the IAPJMS process to use. See page 247. By default, SWLIB_PATH points to the Java libraries distributed with the iProcess Engine. You do not need to change this value unless you have a specific requirement for the IAPJMS process to use a different version of these libraries. 2. Enable activity monitoring on your iProcess Engine by configuring the IAPJMS_PUBLISH process attribute. See page 239. 3. Specify the JMS message delivery method by configuring the IAPJMS_SYNCHRONOUS and WQDJMS_TOPICNAME process attributes. See page 241 and page 250. 4. For activity monitoring, configure the port number that is used for message communications between the BG process and IAPJMS process by configuring the IAPJMS_PORTNO process attribute. See page 238. 5. For Work Queue Delta publication, configure the port number that is used for message communications between the WIS process and IAPJMS process by configuring the WQDJMS_PORTNO process attribute. See page 249. 6. Configure the JNDI name for the JMS topic and whether it should be static or dynamic by configuring the IAPJMS_TOPICNAME, IAPJMS_SIMPLETOPIC and WQDJMS_TOPICNAME process attributes. See page 243, page 245 and page 250. If you are using WebLogic as your JMS provider, you must ensure that the WebLogic JNDI name and topic name are the same as the topic name specified in the IAPJMS_TOPICNAME and the WQDJMS_TOPICNAME attributes. (See WebLogic documentation for more information.) 7. Specify whether you wish the IAPJMS process to generate messages in a basic or extended format. See IAPSCHEMA on page 75. 8. Configure the JMS message error handling by configuring the IAPJMS_ROLLBACK process attribute. See page 240.

TIBCO iProcess Engine Administrators Guide

Back to Library

332

| Chapter 10

Administering Activity Monitoring and Work Queue Delta Publication

9. Configure the JVM Attributes that should be specified when the Java Virtual Machine is started by configuring the JVMPROPS process attribute. See page 246. 10. Depending on your requirements, you can filter MER messages and Work Queue Delta messages using the message properties. See page 332. 11. Configure the IAP JMS configuration files - see page 333 12. Update the IAP security principle and credentials - see page 336

Filtering Message Event Request (MER) Messages

Every MER message sent to the iProcess database to update the activity monitoring configuration information consists of XML requesting the events to monitor. The MER XML format is defined by the SWMonitorList.xsd schema. The table below describes the properties of the MER message:. Property IAPMessageType IAPProcedureName IAPNodeName IAPComputerName Description The message type is MER (Monitor Event Request) The iProcess Engine procedure name The name of the iProcess Engine. The name of the machine where the iProcess Engine is installed.

You can filter the MER messages using these properties. Refer to the information supplied with your J2EE Application Server for more information on filtering messages.

TIBCO iProcess Engine Administrators Guide

Back to Library

Configuring the iProcess Activity Publication (IAP) Configuration Files 333

Configuring the iProcess Activity Publication (IAP) Configuration Files

If you want to enable IAP, there are two configuration files that you can configure. If necessary consult the administrator for your JMS provider software. The configuration files are found in SWDIR\etc: iapjms.properties - contains all the configuration information for the IAPJMS process. iapjms_classpath.properties - contains a list of the required .jar files for each of the supported application servers.

The iapjms.properties file contains all the configuration information for the IAPJMS process. The iapjms.properties file enables you to configure the following settings: Property IAPJMSConnect.InitialContextFactory IAPJMSConnect.InitialURL IAPJMSConnect.SecurityPrinciple Description Defines the J2EE initial context factory to be used for all J2EE connections within the application. Defines the initial context URL, if required. Defines the username if security is set in the InitialContextFactory. See Updating the IAP Security Principle and Credentials for more information. Defines the password if security is set in the InitialContextFactory. See Updating the IAP Security Principle and Credentials for more information. Defines the encryption method used for the IAPJMSConnect.SecurityCredentials parameter. Valid values are: PLAIN - Plain text format (default) IPE - iPE proprietary encryption (this mechanism is used by the SWDIR/bin/swconfig utility when writing the password)

IAPJMSConnect.SecurityCredentials

IAPJMSConnect.SecurityEncryption

See Updating the IAP Security Principle and Credentials for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

Configuring the IAP JMS Properties File

334

| Chapter 10
Property

Administering Activity Monitoring and Work Queue Delta Publication

Description Defines where the JMS topic details are configured. If a topic cannot be looked up then the topic is dynamically created by the IAPJMS process, if possible. Defines the maximum time to live for the JMS messages in millisceonds. If the property is set to 0 the messages never time out. For more information, see the documentation supplied with your J2EE Application Server. Defines the priority of the JMS message in the system. For more information, see the documentation supplied with your J2EE Application Server. Defines the number of socket listener threads that are created when the IAPJMS process starts up. Note: This property is not present in the iapjms.properties file by default. It should only be set on instructions from TIBCO Support.

IAPJMSConnect.TopicConnectionFactory

IAPJMSConnect.TimeToLive

IAPJMSConnect.Priority

WQDJMSConnect.ListenerThreads

WQDJMSConnect.ConnectionPoolSize

Each work queue is required to publish its messages on the same JMS connection to ensure that messages appear in the correct order. Therefore the IAPJMS process keeps a pool of JMS connection caches and ensures that all messages from each unique work queue are sent using the same connection. The connection pool is created when the IAPJMS process starts up. This property therefore defines the connection pool size, which is the maximum number of connections available for JMS publication. Each connection will always be used for all items for a single work queue. Note: This property is not present in the iapjms.properties file by default. It should only be set on instructions from TIBCO Support.

TIBCO iProcess Engine Administrators Guide

Back to Library

Configuring the iProcess Activity Publication (IAP) Configuration Files 335

Configuring the IAPJMS Classpath File

The iapjms_classpath.properties file contains: a list of the IAPJMS internal libraries, as shown below:

The internal libraries are required by the IAPJMS process and should not be modified. the required .jar files for each of the supported application servers. Shown below is an extract of the iapjms.classpath file that describes the .jar files for Websphere.

################################################################### #WebSphere 5.1 ################################################################### #classpath.basedir.WAS=c:/program files/WebSphere/AppServer/lib #classpath.WAS.1=bootstrap.jar,iwsorb.jar,j2ee.jar,wsexception.jar #classpath.WAS.2=ffdc.jar,namingClient.jar,ras.jar,utils.jar,idl.jar #classpath.WAS.3=messagingClient.jar,ecutils.jar,naming.jar #classpath.WAS.MQ=com.ibm.mq.jar,com.ibm.mqjms.jar #classpath.WAS.ext=ibmext.jar,ibmorb.jar

You must configure this file for the application server you are using. You must uncomment the lines of the file that apply to the application server you are using. For example, if you are using Websphere, you should uncomment the paths to the .jar files as shown below:
################################################################### #WebSphere 5.1 ################################################################### classpath.basedir.WAS=c:/program files/WebSphere/AppServer/lib classpath.WAS.1=bootstrap.jar,iwsorb.jar,j2ee.jar,wsexception.jar classpath.WAS.2=ffdc.jar,namingClient.jar,ras.jar,utils.jar,idl.jar classpath.WAS.3=messagingClient.jar,ecutils.jar,naming.jar classpath.WAS.MQ=com.ibm.mq.jar,com.ibm.mqjms.jar classpath.WAS.ext=ibmext.jar,ibmorb.jar

TIBCO iProcess Engine Administrators Guide

Back to Library

###################################################################### # Internal libraries ###################################################################### # # # The following entries are required by the IAPJMS process and should NOT be modified # classpath.internal.log4j=thirdparty/log4j-1.2.8.jar classpath.internal.common=common_swprocess_library.jar,common_bootstrap_library.jar ,common_utils_library.jar classpath.internal.socket=socketproxy_socketproxy_library.jar classpath.internal.iapjms=iapjms_iapjms_library.jar

336

| Chapter 10

Administering Activity Monitoring and Work Queue Delta Publication

Updating the IAP Security Principle and Credentials

If you enabled IAP, default values for the JNDI/JMS user name and password are contained in the SWDIR\etc\iapjms.properties file (in the properties SecurityPrinciple and SecurityCredentials respectively). For security reasons, you can change the user name/password using the SWDIR\util\swconfig utility as described below. When you use the SWDIR\util\swconfig utility to modify the iapjms.properties file, a backup file (iapjms.properties.bak) is created, preserving the previous settings.

If you want to update the username and password without encrypting the password, you can directly edit the iapjms.properties file to add the new user name and password; otherwise use the procedure described below. 1. From the SWDIR\util directory, enter the following command:
swconfig -i

2. The swconfig utility displays the current user name and prompts you to enter a new one. 3. The swconfig utility echoes the current password and prompts you to enter a new one. 4. The password is encrypted and the properties IAPJMSConnect.SecurityPrinciple and IAPJMSConnect.SecurityCredentials are updated accordingly.

Deleting the User Name and Password

If you do not want to use security, you can delete the current user name and password as follows: 1. Enter the following command:
swconfig -i -x

2. The properties IAPJMSConnect.SecurityPrinciple and IAPJMSConnect.SecurityCredentials are deleted from the file iapjms.properties file.

TIBCO iProcess Engine Administrators Guide

Back to Library

Resetting the User Name and Password

Updating the IAP Security Principle and Credentials 337

Testing the Password

1. Enter the following command:
swconfig -i -t

2. The swconfig utility prompts you to enter the user name and password. The password held in IAPJMSConnect.SecurityCredentials is decrypted and compared against the password you supplied. 3. The swconfig utility indicates whether the password is valid.

TIBCO iProcess Engine Administrators Guide

Back to Library

338

| Chapter 10

Administering Activity Monitoring and Work Queue Delta Publication

Using SWDIR\util\swadm to Administer Work Queue Delta Publication

You can use the SWDIR\util\swadm utility to administer (view and delete) subscriptions to work queues. Note that: To use this utility, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user. If you are using a node cluster architecture, you can run this utility from any server within the cluster (as long as that server has a connection to the TIBCO iProcess Engine database instance).

Area Publication

Task List Subscriptions Clear Subscriptions

swadm Command SHOW_ALL_SUBSCRIPTION S CLEAR_SUBSCRIPTION

TIBCO iProcess Engine Administrators Guide

Back to Library

The following table summarizes the commands you can use to administer work queue subscriptions.

List Subscriptions 339

List Subscriptions
To display a list of all publications of Work Queue Deltas currently enabled, use the following command:
swadm SHOW_ALL_SUBSCRIPTIONS

The command lists the following information for each publication: WIS No is the identifying number of the WIS process. Work Queue is the unique identifier for the queue subscribed to. WQDID is the Work Queue Delta ID. JMS Topic is the topic that is used for Work Queue Delta messages. By default it is the topic specified by the WQDJMS_TOPICNAME process attribute but a different topic can be specified by the subscribing application.

Example

This example shows the output from the swadm SHOW_ALL_SUBSCRIPTIONS command.

WIS No 1 1 1

Work Queue user002@swnod10 2 user002@swnod10 2 user002@swnod10 2

WQDID 16D3B33A-D305-11DC-8FE2-0017A49 9ABAD 2DB0E050-D305-11DC-8029-0017A49 9ABAD E2AC427A-D304-11DC-AB61-0017A49 9ABAD

JMS Topic WQD TOPIC WQD.TOPIC.USER002 WQD TOPIC

TIBCO iProcess Engine Administrators Guide

Back to Library

340

| Chapter 10

Administering Activity Monitoring and Work Queue Delta Publication

Clear Subscriptions
To clear a work queue delta subscription, use the following command:
swadm clear_subscription

<queue_name> <WQD_ID>

where: queue_name is the descriptive alphanumeric name for the queue. WQD_ID is the Work Queue Delta ID.

TIBCO iProcess Engine Administrators Guide

Back to Library

| 341
Chapter 11

Administering the Work Queue Server and Work Item Server Processes

This chapter describes how you can configure the Work Queue Server (WQS) and Work Item Server (WIS) processes for optimum performance.

Overview, page 342 The WQS Process, page 343 The WIS Process, page 349 Troubleshooting Work Queues, page 359

TIBCO iProcess Engine Administrators Guide

Back to Library

Topics

342

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

Overview
The iProcess work queues, which contain all the iProcess users work items, are managed by the following processes: Work Queue Server (WQS), which handles the listing of queues. This process is run by SWDIR\etc\wqsrpc. There is only a single wqsrpc process running at any time. See The WQS Process on page 343 for more information. Work Item Server (WIS), which handles the listing of work items in the queues. This process is run by SWDIR\etc\wisrpc. The number of wisrpc processes running is controlled by the Process Sentinels (process_config table). See The WIS Process on page 349 for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

The WQS process handles what is displayed in the left hand pane of the Work Queue Manager (the queue list) and the WIS process handles the contents of the right hand pane (the work items list).

The WQS Process 343

The WQS Process

The Work Queue Server (WQS) process handles the listing of work queues. The WQS process allocates one or more queues to each WIS process and responds to client RPC requests to access these queues. The WQS process is multi-threaded, allowing it to perform multiple tasks simultaneously. Different threads are used to: process RPC requests from client applications. update work queues following a MOVESYSINFO event. persist the contents of the WQS/WIS shared memory to the database.

the different aspects of the WQS process behavior that you can configure. the process attributes that you can use to do this. a reference for more information on how to configure each aspect of the WQS process behavior.

TIBCO iProcess Engine Administrators Guide

Back to Library

The following diagram shows:

344

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

WQS Process

RPC processing thread(s) RPC_SVR_CONTROL WQS_NUM_SEARCH_SLOTS See page 353

Client application(s)

Queue update thread

BG process

Queue assignment WQS_WIS_USER_COUNT See page 345

WIS processes

Shared memory persistence thread WQS_PERSIST_SHMEM See page 348

WQS/WIS shared memory See page 351

user/group attribute and membership tables

wqs_index table

TIBCO iProcess Engine Administrators Guide

Back to Library

The WQS Process 345

Configuring WQS RPC Request Processing

To process RPC requests, both the WQS and WIS processes access a pool of worker threads that is provided by a multi-threaded RPC server shared library (SWRPCMTS). You can use the RPC_SVR_CONTROL process attribute to define the number of threads that are available in the SWRPCMTS library to process RPC requests. You can adjust the value of this process attribute to optimize the WQS and WIS process response times when processing RPC requests against available CPU capacity. Increasing the number of threads will improve the throughput of client RPC requests, but at the cost of increased CPU usage. The RPC processing threads perform their work independently of and concurrently with the queue update thread. In pre-10.4 versions of the iProcess Engine, where the WQS process was single-threaded, the WQS process had to switch between processing RPC requests and updating work queues.

Configuring the Assignment of Queues to WIS Processes

When the iProcess Engine starts up, the WQS process is responsible for assigning all the work queues to WIS processes. By default, queues are assigned to WIS processes dynamically, using either the round-robin or on-demand method (as determined by the WQS_ROUND_ROBIN parameter in the SWDIR\etc\staffcfg file - see page 47): Round-robin.This method assigns a work queue to each WIS process alphabetically, cycling round until all work queues are assigned. For example, if a system has 5 WIS processes and 20 work queues A to O then: queues A, F, K are allocated to WIS process 1, queues B, G, L are allocated to WIS process 2, queues C, H, M are allocated to WIS process 3, etc. The round-robin method takes no account of queue size. It is best used when the messages are fairly evenly distributed between the majority of queues and user access is also evenly spread. On-demand. This method assigns work queues to WIS processes based on cost. All work queues have a weighting (determined by the WQS_QUEUE_WEIGHTING parameter) that determines the cost of the work queue to the WIS process. Queues are assigned to the WIS process with the lowest overall cost. The more work queues that are allocated to a WIS process, the higher the cost of the WIS process so the less new work queues are allocated to it. The cost calculation is as follows:

TIBCO iProcess Engine Administrators Guide

Back to Library

346

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

cost = wicount + (WQS_QUEUE_WEIGHTING * qcount) where: wicount is the number of work items the WIS process is currently processing. qcount is the number of work queues the WIS process is currently processing. The number of items in a work queue is taken from data that has been persisted to the wqs_index database table. If, for example, a new queue has been added to the iProcess Engine after it has been started, it means the allocation of the work queues may not reflect the actual count of work items in the work queue. To overcome this, restart the iProcess Engine. This results in the work queues being re-allocated according to the latest work item count. To control how work queues are allocated to WIS processes, you can adjust the WQS_QUEUE_WEIGHTING parameter. This parameter changes the cost of a work queue to a WIS process. For example, the larger the value, the more that the number of work queues rather than the number of work items in the work queues determines whether a work queue is allocated to a WIS process. Therefore, if you have lots of work queues with an even amount of work items in each, you may want to increase the value of the WQS_QUEUE_WEIGHTING parameter. If you only have a few work queues that contain large amounts of work items, you may want to lower the value. The effect of on-demand assignment is that work queues are distributed across WIS processes based on their cost so a more even distribution of work queues is achieved. However, there are two additional methods you can use to customize the assignment process to better reflect your system requirements, and so optimize performance. The following sections describe these methods. Using Different WIS Processes to Handle User and Group Queues User queues and group queues frequently have different characteristics, in terms of the amount of load they carry. For example, if group queues are far more active than user queues on your system, you may want to give them higher priority for WIS process allocation. You can do this by specifying the WQS_WIS_USER_COUNT process attribute for the WQS process. This attribute defines the number of WIS processes that should be dedicated to handling user queues and group queues respectively (either as a fixed number or as a percentage of the available processes). See WQS_WIS_USER_COUNT on page 209 for more information.
TIBCO iProcess Engine Administrators Guide

Back to Library

The WQS Process 347

Assigning a Queue Explicitly to a WIS Process If you have certain queues that are very large or very busy, you may find it useful to dedicate specific WIS processes to handling only those queues (leaving the remaining queues to be dynamically assigned to the remaining WIS processes). To dedicate a specific WIS process to handling a specific queue: 1. Start the Process Administrator, and then start the User Manager. (See Using the TIBCO iProcess Administrator in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information.) 2. To make it possible to allocate queues to specific WIS processes, define a new attribute called SW_WISINST. This should have a Type of Numeric, with a Decimal value of 0.

3. To assign a queue to a specific WIS process, assign the WIS instance number that you want the queue to use as the value of the SW_WISINST attribute for that queue. (You can use the SWDIR\util\swadm show_processes command to list the available WIS instances - see page 105.) See Setting User Values for an Attribute in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information. 4. Save your changes, exit from User Manager and perform a MoveSysInfo to register your changes on the iProcess Engine. See Moving System Information in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information. 5. If the queue is already in use (and therefore already allocated to a WIS process), you will need to stop and restart the iProcess Engine before the change takes effect. Once a WIS process has been dedicated to handling a specific queue or queues, it will handle only those queues. It is no longer available for dynamic queue allocation. There is one exception to this: if all the available WIS processes are dedicated to handling specific queues, and a new queue is added, the queues are no longer treated as dedicated. This means that: the new queue will be dynamically assigned to the appropriate WIS process, according to the current dynamic allocation rules. All dedicated WIS processes are considered to be available to handle the queue. See Using Different WIS Processes to Handle User and Group Queues on page 346. the dedicated WIS processes continue to handle their assigned queues (but they may also have to handle the newly assigned queue as well).
TIBCO iProcess Engine Administrators Guide

Back to Library

See Adding a New Attribute in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information.

348

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

An Example of How to Use These Assignment Methods By using the methods described above, you can configure your system to operate more efficiently under load. For example, consider a system that has 6 WIS processes (WIS 1-6), 8 group queues (GQ1-8) and 500 users (UQ1-500). Queue characteristics are: GQ1 has 100K items and is a holding queue (sometimes searched). GQ2 has 50K items and is the most active queue. GQ3-8 are all fairly busy with up 10K items in each. User queues are not used extensively.

The system is now configured as follows: GQ1 is assigned to WIS 1. GQ2 is assigned to WIS 2. WQS_WIS_USER_COUNT is set to 2

This means that: The two biggest queues, GQ1 and GQ2, are each handled by their own dedicated WIS process, WIS 1 and WIS 2. The remaining 6 group queues, GQ3 to GQ8, are handled by 2 of the 4 remaining WIS processes. The queues are dynamically assigned to WIS processes. The remaining 2 WIS processes handle the 500 user queues. The queues are dynamically assigned to WIS processes.

Configuring When the WQS/WIS Shared Memory is Written to the Database

The WQS/WIS shared memory cache holds summary information about work queues, such as which WIS process is handling a queue, how many work items it contains, how many new items, items with deadlines and so on. This information is constantly updated by the WQS and WIS processes. The shared memory persistence thread wakes up every WQS_PERSIST_SHMEM seconds and writes the contents of the WQS/WIS shared memory to the wqs_index database table. When the WIS process starts up, it needs to know how many work items are in each queue that it is handling, so that it can determine whether or not to cache the queue immediately (see page 355). The WIS process can therefore read this information from the total_items column in the wqs_index database table.

TIBCO iProcess Engine Administrators Guide

Back to Library

The WIS Process 349

The WIS Process

The Work Item Server (WIS) process handles the listing of work items in user and group queues. Each WIS process is allocated one or more queues to handle by the WQS process and responds to client RPC requests to process work items held in these queues. You can use the SWDIR\util\swadm add_process and delete_process commands to change the number of WIS processes on your system according to your requirements. See Using SWDIR\util\swadm to Administer Server Processes on page 104 for more information about how to use these commands. The WIS process is multi-threaded, allowing it to perform multiple tasks simultaneously. Different threads are used to: process RPC requests from client applications. filter work queues - for example, only show work items started by a particular user. update each queue being handled for example, checking for expired deadlines, priority escalations, or for new queues to be handled. cache the information that the WIS process maintains about each work queue that it is handling, allowing the WIS processes to respond quickly to RPC requests from client applications. dynamically update CDQP definitions for work items.

The following diagram shows: the different threads that are used by the WIS process. the process attributes that you can use to control each type of thread. a reference for more information on how to configure this aspect of the WIS process behavior.

TIBCO iProcess Engine Administrators Guide

Back to Library

350

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

WIS Process(es)

RPC processing thread(s) RPC_SVR_CONTROL See page 353

Client application(s)

Queue filtering thread(s) WIS_FILTER_THREAD_BOUNDARIES WIS_FILTER_THREAD_POOL_SIZE See page 353

Queue update thread WIS_UPDATE_LENGTH WIS_UPDATE_PERIOD See page 354

WQS process

Queue caching thread(s) WIS_CACHE_POOL_SIZE WIS_CACHE_THRESHOLD WIS_CACHE_WAIT_TIME See page 355

WQS/WIS shared memory WQS_PERSIST_SHMEM See page 355

CDQP update thread WIS_CDQP_DATA_RECACHE_BATCH See page 357 wqs_index table

staffo table

TIBCO iProcess Engine Administrators Guide

Back to Library

The WIS Process 351

Monitoring the WIS Processes

You can use the SWDIR\util\plist -w command to monitor the operation of the WIS processes. TIBCO recommend that you do this regularly, particularly in the following circumstances: On initial configuration of your system. The default values can be used but when cases, users or groups are added, you will need to monitor and perhaps configure the system. After a number of new queues have been added. After a significant increase in the number of cases in the system. If there are only a small number of queues, for example, less than 10, monitor the system after you add more users or group queues so you can monitor the load balancing of the WIS processes.

The format of the SWDIR\util\plist -w command is:

plist -w[V] [WIS]

where V can be used to display additional information (the LastCacheTime and CDQPVer columns) WIS is the number of a specific WIS process, and can be used to display details only for that WIS process. If this parameter is omitted, the command displays details for all the WIS processes.

Use plist -w to view detailed information about the WIS processes such as the number of items in the queue, whether the queue is disabled, and the number of new items in each WIS process. For example (using plist -wV):
WIS QueueName Flags #Items #Newp #Dead #Urgent LastCacheTime(ms) CDQPVer ----------------------------------------------------------------------------------1 sblanch -----NM 3000 3000 0 0 766 -1 1 steveb ------0 0 0 0 11 -1 1 swadmin -----NM 2 2 0 0 29 -1 1 swgrp0000 --G---0 0 0 0 12 -1 1 swgrp0001 --G---0 0 0 0 11 -1 1 swgrp0002 --G---0 0 0 0 11 -1 1 swgrp0003 --G---0 0 0 0 -1 -1

TIBCO iProcess Engine Administrators Guide

Back to Library

352

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

The command displays the following information. Column WIS QueueName Flags Description The number of this WIS process instance. The name of the work queue allocated to this WIS instance. Any combination of the following, in order. A "-" in place of the indicated letter means that the corresponding flag is not set: #Items #NewP #Dead #Urgent LastCacheTime D = The queue is disabled (this would normally be when the system has just been started and the queues have not yet been allocated to a WIS. U = There are urgent items in this queue.

T = This is a test queue. D = There are items in this queue with deadlines set. N = There is new mail in this queue. M = There is mail in this queue (i.e. it is not empty).

The total number of work items in this work queue. The total number of new (unread) work items in this work queue. The total number of work items in this work queue that have deadlines. The total number of urgent work items in this work queue. Displayed only if the -V option is used. The number of milliseconds that the WIS process took to cache this work queue. Note that: The time shown is the time taken when the queue was last cached (which could be either when the WIS process was started or when the queue was first accessed). The number of items in the queue at that time may have been different to the number of items currently in the queue as shown in the #Items column. A value of -1 indicates that the queue has not been cached yet.

CDQPVer

Displayed only if the -V option is used. The current CDQP definition version for this work queue. (This should match the version number of the cdqp row in the version database table.)

TIBCO iProcess Engine Administrators Guide

Back to Library

G = This is a group queue.

The WIS Process 353

Configuring WIS RPC Request Processing

To process RPC requests, both the WIS and WQS processes access a pool of worker threads that is provided by a multi-threaded RPC server shared library (SWRPCMTS). You can use the RPC_SVR_CONTROL process attribute to define the number of threads that are available in the SWRPCMTS library to process RPC requests. You can adjust the value of this process attribute to optimize the WQS and WIS process response times when processing RPC requests against available CPU capacity. Increasing the number of threads will improve the throughput of client RPC requests, but at the cost of increased CPU usage. The RPC processing threads perform their work independently of and concurrently with the queue update thread. In pre-10.4 versions of the iProcess Engine, where the WIS process was single-threaded, the WIS process had to switch between processing RPC requests and updating work queues.

Configuring How Work Queues are Filtered

When filter criteria are applied to a work queue - for example, only show work items started by a particular user - the WIS process has to filter the work queue to find the correct items to display. By default, the WIS process uses the thread that is processing an RPC request to perform any work queue filtering required by that RPC request. This is perfectly adequate if the queues are small and the filter criteria are simple. However, the time taken to filter a queue can increase significantly as the number of work items in the queue grows and/or the complexity of the filter criteria increases. This can result in a perceptible delay for the user viewing the work queue. For example, filtering a queue that contains over 100000 work items using filter criteria that includes CDQPs can take over 6 seconds. (Obviously, CPU availability on the machine is also a factor in determining how long the filtering operation takes.) To cope with this situation, the WIS process contains a pool of queue filtering threads that can be used to filter work queues more quickly. The following process attributes allow you to configure how and when these threads are used: WIS_FILTER_THREAD_BOUNDARIES allows you to define when a work queue should be split into multiple "blocks" of work for filtering purposes. You can define up to 4 threshold values for the number of work items in a queue. As each threshold is passed, an additional block of filtering work is created, which will be handled by the first available queue filtering thread.

TIBCO iProcess Engine Administrators Guide

Back to Library

354

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

WIS_FILTER_THREAD_POOL_SIZE allows you to define the number of queue filtering threads in the pool. These threads are used to process all additional filtering blocks generated by the WIS_FILTER_THREAD_BOUNDARIES thresholds. Increasing the number of threads in this pool allows more blocks of filtering work to be processed in parallel, but at the cost of increasing the CPU usage of the WIS process.

For example, consider the following scenario: A work queue contains 180000 work items. WIS_FILTER_THREAD_BOUNDARIES has been set to create additional filtering blocks when a queue contains 100000 and 150000 work items. The WIS process receives 5 RPC requests to filter the queue.

The 5 RPC requests therefore generate 10 blocks of additional filtering work to be processed by the queue filtering threads. If WIS_FILTER_THREAD_POOL_SIZE is set to: 10 or more, each block is immediately filtered by one of the queue filtering threads. less than 10, some blocks will have to be queued until a queue filtering thread is available to process them.

When altering the WIS_FILTER_THREAD_BOUNDARIES, WIS_FILTER_THREAD_POOL_SIZE or RPC_SVR_CONTROL process attributes, you should bear in mind that the more RPC processing threads there are and the larger the number of work items in a queue, the more threads in the queue filtering thread pool will be used by a single RPC request to filter a queue.

Configuring Queue Updates

The queue update thread performs two functions: It goes through all the queues handled by the WIS process and checks for expired deadlines, priority escalations, redirection work, new or purged work items and so on. It calls the WQS process for a new queue to handle when required (i.e. when the WQS process has processed a MOVESYSINFO and sent out an SE_WQSQUEUE_ADDED event to the WIS process).

TIBCO iProcess Engine Administrators Guide

Back to Library

Each RPC request on the queue generates 2 additional filtering blocks (each of 60000 work items). The first filtering block is still handled by the RPC processing thread that is handling the RPC request.

The WIS Process 355

The queue update thread performs updates for WIS_UPDATE_LENGTH seconds or until all queues have been processed, at which point it will go to sleep for WIS_UPDATE_PERIOD seconds. If the thread hasn't gone through all the queues within the WIS_UPDATE_LENGTH time then it will start from the point it finished at on its previous update. The queue update thread performs its work independently of and concurrently with the RPC processing threads. In pre-10.4 versions of the iProcess Engine, where the WIS process was single-threaded, the WIS process had to switch between processing RPC requests and updating work queues.

Configuring When WIS Processes Cache Their Queues Back to Library

The WQS/WIS processes maintain an in-memory cache of the information that each WIS process contains about each work queue that it is handling. Caching this information allows the WIS processes to respond quickly to RPC requests from client applications. However, the amount of time that a WIS process takes to start up is heavily influenced by the number of queues that it has to cache, the number of work items in the queue, the number of CDQPs defined in the queue, and the general load on the machine. You can monitor how long a WIS process is taking to start up using the SWDIR\util\plist -wV command (see page 351). The LastCacheTime column shows the number of milliseconds that the WIS process took to cache each queue when it was last cached. You can tailor this behavior to suit your particular requirements by configuring work queues to be cached either: when they are first handled by a WIS process. This will be either when the iProcess Engine starts up, or for queues that are added when the system is running, after a MoveSysInfo request. or when they are first accessed by a client application.

You control which queues are cached when they are first handled by a WIS process by using a combination of the WISCACHE queue attribute and the WIS_CACHE_THRESHOLD process attribute. When the WIS process first handles a queue, it checks the value of the queues WISCACHE attribute: If WISCACHE is set to YES, the WIS process caches the queue (irrespective of how many work items the queue contains).

TIBCO iProcess Engine Administrators Guide

356

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

If WISCACHE has not been created, or has not been set, the WIS process only caches the queue if the queue contains a number of work items that equal or exceed the value of the WIS_CACHE_THRESHOLD process attribute. When the WIS process starts up, it reads the number of work items in each work queue from the total_items column in the wqs_index database table. This table is populated from the contents of the WQS/WIS shared memory, which is written to the database every WQS_PERSIST_SHMEM seconds. Any queue that is not cached now will be cached when it is first accessed by a client application.

Note that:

When an RPC client application makes an RPC call to a work queue that has not already been cached, the WIS process immediately begins caching it. If the value of the WIS_CACHE_WAIT_TIME process attribute is reached and the work queue has still not been cached, the WIS process returns an ER_CACHING error to the client application. If the RPC client application is a TIBCO iProcess Workspace (Windows) session, the user will see the following message in the right-hand pane of the Work Queue Manager, instead of the expected list of work items: The Work Item Server (WIS) is fetching the work items for this queue. Please wait...

The WISMBD process also makes RPC calls to WIS processes to pass instructions from the BG processes. If the WISMBD process receives an ER_CACHING error from the WIS process it retries the connection a number of times. If the attempt still fails, it requeues the message and writes a message (with ID 1984) to the SWDIR\logs\sw_warn file. See the TIBCO iProcess Engine: System Messages Guide for more information about this message.

Configuring more work queues to be cached when they are first accessed obviously improves the startup time for the WIS processes, but the potential cost is that users may have to wait to access their queues while they are being cached.

TIBCO iProcess Engine Administrators Guide

Back to Library

Queues are cached by a pool of threads in the WIS process. You can configure the number of threads in this pool by using the WIS_CACHE_POOL_SIZE

The WIS Process 357

Setting the WISCACHE Attribute for a Queue The WISCACHE queue attribute does not exist by default. If you wish to use it, you must first create it and then assign a value for it to any queues that you want to use it. To do this: 1. Start the Process Administrator, and then start the User Manager. (See Using the TIBCO iProcess Administrator in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information.) 2. Define a new attribute called WISCACHE. This should have a Type of Text, with a Length of 4. See Adding a New Attribute in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information.

All other queues (for which WISCACHE is not set) will be cached either when the WIS process first handles it or when they are first accessed by a client application, depending on the value of the WIS_CACHE_THRESHOLD process attribute. See Setting User Values for an Attribute in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information. 4. Save your changes, exit from User Manager and perform a MoveSysInfo to register your changes on the iProcess Engine. See Moving System Information in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information.

Configuring CDQP Updates

CDQPs allow values from case data to be used by client applications to sort, display and filter work items lists, and to find specific work items. When the WIS process starts up it caches all the CDQP definitions that are used by the queues it is handling, and uses the cached values when displaying CDQPs in its work queues. The WIS process obtains the field values of fields that are defined as CDQPs from the pack_data database table.

TIBCO iProcess Engine Administrators Guide

Back to Library

3. Assign a value of YES to WISCACHE for each queue that you want to be cached when the WIS process first handles it (irrespective of how many work items the queue contains).

358

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

You can change existing CDQP definitions or create new ones by using the SWDIR\bin\swutil QINFO command. By default, you then have to restart the iProcess Engine to allow the WIS process to pick up the changed definitions and update its work queues with them. However, you can dynamically pick up changes to CDQP definitions without having to restart the iProcess Engine, by using the PUBLISH parameter with the QINFO command. This publishes an event that signals that updated CDQP definitions are available. When the WIS process detects this event its CDQP update thread wakes up and updates the CDQP definitions for all work items in its queues. Work items are updated in batches, the size of which is determined by the value of the WIS_CDQP_DATA_RECACHE_BATCH process attribute.

TIBCO iProcess Engine Administrators Guide

Back to Library

See "Case Data Queue Parameters" in the TIBCO iProcess swutil and swbatch: Reference Guide for more information about CDQPs and the QINFO command.

Troubleshooting Work Queues 359

Troubleshooting Work Queues

This section provides troubleshooting information for when users have problems accessing work queues. When experiencing problems with the WIS processes, there are three common error messages that appear in the Work Queue Manager: Failed to Open Work Item List for Queue or Work Queue Servers Not Responding when moving between queues in Work Queue Manager, and

when attempting to start a case. In these examples, the client is unable to contact the WIS or WQS process to find out what queues or work items exist. The problem is that users are unable to access their work items in the queues because the work queues are grayed out in Work Queue Manager. To resolve the problem, try one of the following: Use plist -w to check the status of each WIS process. Check to make sure that the WQS and WIS processes are running: On Windows, use the Processes tab of the Task Manager. On UNIX, run the ps -fe command. The processes are named wisrpc and wqsrpc. Use the Process Sentinels command line utility (SWDIR\util\swsvrmgr) to report the status of the processes. Refer to View Process Status on page 112. Check the SWDIR\logs\sw_warn and sw_error files for any error messages to see if any problems have been logged. If you cannot resolve your work queue problem, contact TIBCO Support.

TIBCO iProcess Engine Administrators Guide

Back to Library

That Facility is Not Available

360

| Chapter 11

Administering the Work Queue Server and Work Item Server Processes

TIBCO iProcess Engine Administrators Guide

Back to Library

| 361
Chapter 12

Administering Case Data Normalization

This chapter describes case data normalization and how to administer it on the iProcess Engine.

Topics Back to Library

Overview, page 362 Enabling Case Data Normalization, page 363

TIBCO iProcess Engine Administrators Guide

362

| Chapter 12

Administering Case Data Normalization

Overview
Case data normalization makes case data searching more efficient and therefore faster by populating the column field_value_N in the case_data table with data from the field_value column. Some previous versions of the iProcess Engine did not support case data normalization, so when you install/upgrade the iProcess Engine, you are prompted to enable this feature. If you are using TIBCO iProcess Objects to perform case searches, TIBCO recommends that you enable case data normalization. If you do not, although you will be able to view and start procedures, you will not be able to see the cases until you normalize the data.

the global process attribute NORMALISE_CASE_DATA (which enables case data normalization system-wide). the normalise_data column on the proc_index table (which indicates whether case data normalization is enabled for a specific procedure). This is controlled by the Case Data Normalization flag on the Status tab of the Properties dialog (see "Setting and Viewing Status Information" in the TIBCO iProcess Modeler - Procedure Management Guide) or by the Case Data Normalization Utility (see Using the Case Data Normalization Utility on page 363).

TIBCO iProcess Engine Administrators Guide

Back to Library

Case data normalization is controlled by the following:

Enabling Case Data Normalization 363

Enabling Case Data Normalization

To enable/disable case data normalization by either: Responding to the prompt during an installation or upgrade: If you enable this feature, the process attribute NORMALISE_CASE_DATA is set to 1 and all existing case data is normalized. Future cases of all procedures are also normalized. If disable the feature, the process attribute NORMALISE_CASE_DATA is set to 0 and existing and future case data is not normalized. Setting the process attribute NORMALISE_CASE_DATA using the SWDIR\util\swadm utility (see page 156).

When you have enabled case data normalization, you can normalize case data by either: Using the Case Data Normalization Utility as described in the following section. This utility changes the setting of the normalise_data column on the proc_index table. Using this utility you can normalize case data either: system wide, or on a per-procedure basis. Selecting the "Normalise Case Data" check box in the Status tab of the Properties dialog to enable the feature for a specific procedure. This check box is only enabled if NORMALISE_CASE_DATA is set to 1 and the procedure has no cases. For more information, see "Setting and Viewing Status Information" in the TIBCO iProcess Modeler - Procedure Management Guide.

Using the Case Data Normalization Utility

The Case Data Normalization Utility allows you to normalize existing case data; either system-wide or on a per-procedure basis. For example, you may have disabled case data during an upgrade because of the large amount of case data involved. After the upgrade you can use the Case Data Normalization Utility to convert the case data during off-peak hours. You can also disable or enable case data normalization on a per-procedure basis with the "Normalise Case Data" check box on the Status tab of the Procedure Properties dialog.

TIBCO iProcess Engine Administrators Guide

Back to Library

364

| Chapter 12

Administering Case Data Normalization

Before using the Case Data Normalization Utility, ensure that the global process attribute NORMALISE_CASE_DATA is set to 1, using the SWDIR\util\swadm utility if necessary (see page 134). This enables case data normalization and allows you to use the Case Data Normalization Utility. The Case Data Normalization Utility is located in the following directory:
SWDIR\util

The command you enter to use the utility has the following format: swnormcd [/U] [/T nnn] /A | procedure_list | /F control_file where: /U indicates that you want to disable case data normalization. Note that disabling case data normalization does not delete the data held in the field_value_N column in the case_data table. New cases of procedures will not use case data normalization and if you are using TIBCO iProcess Objects, new cases will not appear in case data searches. /T nnn specifies the number (nnn) of concurrent threads for case data normalization. The default is 10. Use this parameter to improve performance when normalizing large amounts of data. /A indicates that existing case data should be normalized for all procedures. The normalise_data column on the proc_index table is set to 1 and new cases of procedures are normalized. Normalizing large amounts of case data can take a significant amount of time.

procedure_list is either the name of a procedure, or a list of procedures separated by white space. /F control_file specifies the name of a file that contains procedure names separated by white space.

Examples This command disables case data normalization for the hiring procedure. Any new cases of this procedure will not use case data normalization and will not appear in searches using TIBCO iProcess Objects.
swnormcd /U hiring

TIBCO iProcess Engine Administrators Guide

Back to Library

Enabling Case Data Normalization 365

This command enables case data normalization for all procedures and normalizes existing case data.
swnormcd /A

This command enables case data normalization for the procedures listed in the file proclist.txt and converts any existing case data.
swnormcd /F proclist.txt

TIBCO iProcess Engine Administrators Guide

Back to Library

366

| Chapter 12

Administering Case Data Normalization

TIBCO iProcess Engine Administrators Guide

Back to Library

| 367
Chapter 13

Managing EAI Step Server Plug-ins

This chapter explains how to use the SWDIR\util\sweaireg command line utility to manage the EAI step server plug-ins.

Topics Back to Library

Overview, page 368 Unregister (Remove) an EAI Plug-In, page 372 Modify an Existing EAI Plug-In Entry, page 373 List Existing EAI Plug-In Registry Entries, page 374 Reload an EAI Plug-in, page 376 Get Release Version Stored in EAI Plug-In, page 377 Possible Errors When Using sweaireg, page 378

TIBCO iProcess Engine Administrators Guide

368

| Chapter 13

Managing EAI Step Server Plug-ins

Overview
To function correctly, each EAI step type in the TIBCO iProcess Modeler requires an associated EAI server plug-in to be installed and registered on every server in the TIBCO iProcess Engine node cluster that runs background processes. The following plug-ins are automatically installed when you install the iProcess Engine: TIBCO iProcess COM Server Plug-in (on Windows only; during installation you choose whether or not to register the Plug-in.) TIBCO iProcess Script Server Plug-in

TIBCO iProcess EMail Server Plug-in TIBCO iProcess Plug-in SDK

For installation of these plug-ins, see the iProcess Engine installation guide for your platform/database. For other EAI plug-ins, refer to the specific EAI server plug-in installation guide for installation information. Refer to Using Enterprise Application Integration (EAI) Steps in the TIBCO iProcess Modeler - Integration Techniques Guide for information about how to use EAI steps in your procedures. You can, however, design procedures using a EAI client plug-in for which you have not installed the corresponding EAI server plug-in. This is useful if you want to prepare for porting a procedure to a different platform in the future. If you use an EAI client plug-in without having the relevant EAI server plug-in installed, the EAI step that you create is not processed at run time and an error message is displayed. The error informs you that the step is incompatible with the connected database, and so will not be processed. Although the installation, upgrading, and registration of most EAI plug-ins is handled automatically by the iProcess Engine installation, you can use this utility to: register or re-register an EAI server plug-in - see page 370 unregister an EAI server plug-in - see page 372 modify parts of an existing EAI server plug-ins registry entry - see page 373 list EAI server plug-in registry entries - see page 374 manually request iProcess Engines to reload EAI server plug-ins - see page 376

TIBCO iProcess Engine Administrators Guide

Back to Library

TIBCO iProcess Database Server Plug-in

Overview 369

get the release version of an EAI server plug-in - see page 377.

Refer to page 378 for information about solving possible errors you might encounter when using SWDIR\util\sweaireg. To run SWDIR\util\sweaireg, you must be logged in as the IPEADMIN user or (on UNIX) as the IPEBACKGROUND or root user.

TIBCO iProcess Engine Administrators Guide

Back to Library

370

| Chapter 13

Managing EAI Step Server Plug-ins

Register/Re-register (upgrade) an EAI Plug-In

The REG command installs or upgrades an EAI server plug-in. This command is automatically used by the EAI server plug-ins installation script. Therefore, you only need to use this command if you need to install a plug-in for a given operating system in a shared location. You would then use the REG command to register the plug-in on all your servers. This command automatically detects if this is the first registration of the plug-in or an upgrade for a given EAI step type. This command does not install the plug-in file. Follow the installation procedure described in the specific EAI plug-in documentation.

Syntax

sweaireg REG [-y]

eai_type_name [-m machine_name] -l library [-i init_params]

where: eai_type_name is the short name of the EAI step type handled by the server plug-in. This can be a text string up to 20 characters. machine_name is the optional name of the server in the iProcess Engine node cluster on which the plug-in is to be registered. If this value is omitted, the default is the server on which the command is being run. This can be a text string up to 256 characters. library is the path and file name for the plug-in. This is a text string of up to 256 characters. init_params is an optional value that can be used for any plug-in specific initialization parameters. Refer to the documentation for each plug-in to see what values can be used. If this is omitted and you do a re-registration, the existing parameters will be preserved. This can be a text string up to 1024 characters. -y can be used to automatically answer yes to all the sweaireg command prompts so the command is run immediately without displaying the prompts.

TIBCO iProcess Engine Administrators Guide

Back to Library

Before using this command, you must ensure that the run-time loading requirements are met because the library is loaded when this command is used. For example, if the library uses other system shared libraries, they must be defined in the servers shared library path.

Register/Re-register (upgrade) an EAI Plug-In 371

For a first registration, the values are written to the EAI run-time plug-in registry (the eai_run_plugins table). For a re-registration, the following message is displayed: Re-register eai_step_name run time plug-in version current_release_version with version install_set_release_version? (y/n) If you enter Y, the EAI plug-in registry is updated. If you enter N, no changes will be made. After you have registered the plug-in, you must set the EAI_NEEDS_MSDTC process attribute if the plug-in needs to use the Microsoft Distributed Transaction Coordinator (MSDTC). If you dont do so, EAI steps using the plug-in may not function correctly or in a fully transactional manner. For more information about process attributes and how to set them, see Administering Process Attributes on page 133.
Example

To register the EAI server plug-in for eaidb on the server called hercules, enter the following:
sweaireg REG eaidb -m hercules -l SWDIR\lib\eaidb -y

Before exiting, the following status is displayed:

EAI Run-Time Plug-in Registration Successful: EAI Type: EAIDB Machine: Hercules Version: 1.0 Library:$SWDIR\lib\eaidb Init Params:

TIBCO iProcess Engine Administrators Guide

Back to Library

372

| Chapter 13

Managing EAI Step Server Plug-ins

Unregister (Remove) an EAI Plug-In

Use the UNREG command to remove an EAI step type entry from the plug-in registry. This results in the EAI step type being unregistered from the server so the server will not be able to process any EAI steps that use this server plug-in.
Syntax
sweaireg UNREG

eai_type_name [-m machine_name] [-y]

where: eai_type_name is the short name of the EAI step type handled by the plug-in. This can be a text string up to 20 characters. machine_name is the optional name of the server in the TIBCO iProcess Engine node cluster on which the plug-in is registered. If this value is omitted, the default is the server on which the command is being run. This can be a text string up to 256 characters. -y can be used to automatically answer yes to all the sweaireg command prompts so the command is run immediately without displaying the prompts.

After running the command, the following prompt is displayed:

Unregister EAI Run-Time Plug-In EAI Type EAI Type Name Machine machine name ID:xx Version Release Version Library: library path and name Init Params: Initialisation parameters OK to unregister? (y/n)

If you choose Y, the plug-ins registry entry is removed. The following message is displayed:
EAI Run-Time Plug-In Registration successfully removed

Example

To unregister the eaidb plug-in from the server called hercules (the computer on which you are running this command), enter the following:
sweaireg UNREG eaidb

When prompted, enter Y to proceed with un-registering the server plug-in.

TIBCO iProcess Engine Administrators Guide

Back to Library

Modify an Existing EAI Plug-In Entry 373

Modify an Existing EAI Plug-In Entry

Use this command to modify the server plug-in path or initialization parameters in the EAI plug-ins registry entry.
Syntax
sweaireg MOD [-i

eai_type_name [-m machine_name] [-l library] init_params][-y]

where: eai_type_name is the short name of the EAI step type handled by the plug-in. This can be a text string up to 20 characters. machine_name is the optional name of the server in the iProcess Engine node cluster on which the plug-in is registered. If this value is omitted, the default is the server on which the command is being run. This can be a text string up to 256 characters. library is the path and file name for the server plug-in. This is a text string up to 256 characters. init_params is an optional value that can be used for any plug-in specific initialization parameters. Refer to the documentation for your specific plug-in to see what values can be used. If this is omitted and you do a reregistration, the existing parameters will be preserved. This can be a text string up to 1024 characters. -y can be used to automatically answer yes to all the sweaireg command prompts so the command is run immediately without displaying the prompts.

Example

If you move the plug-in files to a different directory (from SWDIR\lib to SWDIR\lib\version1), you can update the path to point to the new location by entering:
sweaireg MOD eaidb -l SWDIR\libpath\version1\eaidb

This will make the change for the computer on which you are running this command. You need to do this for any other servers using this server plug-in.

TIBCO iProcess Engine Administrators Guide

Back to Library

374

| Chapter 13

Managing EAI Step Server Plug-ins

List Existing EAI Plug-In Registry Entries

Use this command to list all of the EAI plug-in registry entries.
Syntax
sweaireg LIST [eai_type_name] [-m machine

name] [-x]

where: eai_type_name is the short name of the EAI step type handled by the plug-in. This can be a text string up to 20 characters. machine_name is the optional name of the server in the iProcess Engine node cluster on which the plug-in is to be registered. This can be a text string up to 256 characters.

The entries listed are determined by the EAI type name and machine name: Parameters Used Neither eai_type_name or machine_name are specified If both are specified If only eai_type_name is specified Result All registry entries are listed The single registry entry for that EAI type on the given computer is listed. The registry entry for the given EAI type is listed for each machine on which it is registered. The registry entries for all EAI types registered on the given machine are listed.

If only machine_name is specified

Example

To list the EAI plug-in registry entries on the server called hercules, enter the following:
sweaireg LIST -m hercules

TIBCO iProcess Engine Administrators Guide

Back to Library

-x is used to output the listing in a format suitable for script processing (a ; separated list of parameters on a single line). This is optional and if omitted the results are provided in a user-friendly format.

List Existing EAI Plug-In Registry Entries 375

The following is a sample output:

EAI Type: eaidb On Machine: Hercules Version: 1.0 Library: $SWDIR\lib\eaidb Init Params:

TIBCO iProcess Engine Administrators Guide

Back to Library

376

| Chapter 13

Managing EAI Step Server Plug-ins

Reload an EAI Plug-in

When an EAI plug-in entry is re-registered or modified, the iProcess Engine automatically reloads the plug-in. However, you might want to manually reload an EAI server plug-in using this command if: the EAI server plug-in is failing the initialization parameters specify a configuration file and the contents of that file has changed
sweaireg RELOAD

Syntax

eai_type_name [-m machine_name]

where:

machine_name is the optional name of the server in the iProcess node cluster on which the plug-in is to be registered. If this value is omitted, the default is the server on which the command is being run. This can be a text string up to 256 characters.

Example

To reload the eaidb plug-in on the server called hercules, enter the following:
sweaireg RELOAD eaidb -m hercules

If the command is successful, the following message is displayed:

Background reload and re-initialisation requested for eaidb plug-in on machine hercules

TIBCO iProcess Engine Administrators Guide

Back to Library

eai_type_name is the short name of the EAI step type handled by the plug-in. This can be a text string up to 20 characters.

Get Release Version Stored in EAI Plug-In 377

Get Release Version Stored in EAI Plug-In

Use the GETRELVERS command to output the release version in the given EAI server plug-in. This is provided so that the plug-in installation script can display the release version of the plug-in before it installs it. This enables version upgrades to be performed. Before using this command, you must ensure that the run-time loading requirements are met because the plug-in library is loaded when this command is used. For example, if the plug-in uses other system shared libraries, they must be defined in the servers shared library path.
Syntax
sweaireg GETRELVERS -l

library

where library is the path and file name for the server plug-in. This is a text string up to 256 characters.
Example

To extract the release version from the EAI Database library called eaidb in the SWDIR\eai directory, you would enter the following command:
sweaireg GETRELVERS -l \eai\eaidb

TIBCO iProcess Engine Administrators Guide

Back to Library

378

| Chapter 13

Managing EAI Step Server Plug-ins

Possible Errors When Using sweaireg

This section details some of the typical errors you might get when using the SWDIR\util\sweaireg utility. FORMAT:sweaireg REG eai_type_name [-m machine_name] -l <library> [-i init_params] You have entered an invalid command line or there are missing parameters or options. Re-enter the command making sure you include all the required parameters and options. Invalid Parameter: parameter_name

Error connecting to the iProcess Engine Your iProcess Engine environment variables are not set up correctly i.e. check SWDIR and any other environments required for the system are set up correctly and that Oracle is running. Error accessing the EAI run-time plug-in registry There is an error accessing or updating the plug-in registry. For example, the database might not be accessible. An error may also be logged to the SWDIR\logs\sw_warn file. Unexpected Error An internal system error has occurred. Contact TIBCO Support for help. Failed to load library: system defined error message Failed to load EAIRun_GetReleaseVers() from library: library_path You need to make sure that the given library path is correct and any related run-time libraries have been installed and set up correctly.

TIBCO iProcess Engine Administrators Guide

Back to Library

The parameter you have entered is incorrect. Re-enter the command line with a valid parameter.

| 379
Appendix A

iProcess Engine Log Files

The iProcess Engine automatically produces the following log files in the SWDIR\logs directory. Log File sw_error Description This file is created if a serious error occurs that needs to be investigated immediately.

sw_warn

This file is created if an error occurs that needs to be dealt with, but is not serious enough to prevent iProcess from being used. TIBCO recommend that you monitor this file regularly. See the TIBCO iProcess Engine System Messages guide for detailed information about the system error and warning messages that can be returned by the iProcess Engine.

iapjms_java.log userinfo.log

This file is created by the IAPJMS process (if enabled). By default any warning or error messages produced by the IAPJMS process are written to this file. An entry is added to this file whenever user information is updated on the system. For example:
staffusr updated by swadmin - Tue Dec 7 17:27:15 2001

roleinfo.log

An entry is added to this file whenever role information is updated on the system. For example:
staffrol updated by swadmin - Tue Dec 7 17:27:36 2001

swjmx_java.log

This file is created by the JMX engine (which is part of the RPC_TCP_LI process). By default any warning or error messages produced by the JMX engine are written to this file. An entry is added to this file whenever the server shuts down. For example:
2001/12/ 7 17:58 wisrpc : normal shutdown

wiswarn.log

TIBCO iProcess Engine Administrators Guide

Back to Library

See the TIBCO iProcess Engine System Messages guide for detailed information about the system error and warning messages that can be returned by the iProcess Engine.

380

| Appendix A
Log File

iProcess Engine Log Files

Description An entry is added to this file whenever the server shuts down. For example:
2001/12/ 7 17:54 wqsrpc: normal shutdown

wqswarn.log

rpcport.log

This text file is only used when port and/or RPC number ranging is enabled (see Administering Firewall Port Ranges on page 313). The file contains entries that show the resource allocation for the ports and RPC numbers used. It records the following events: Startup of the port/RPC resource allocation service Shutdown of the port/RPC resource allocation service Allocation of a port/RPC number

Failure to re-bind a released port Successful re-binding of a previously failed port Errors in the allocation/release of a port/RPC number

TIBCO iProcess Engine Administrators Guide

Back to Library

Release of a port/RPC number

| 381
Appendix B

System Backup Guidelines

This appendix provides guidelines for the safe backup and recovery of iProcess workflow data. A system backup consists of: backing up your SQL/Oracle database. The iProcess database instance contains all the iProcess case data. backing up configuration files on the iProcess Engine and client. This will prevent you having to record what configuration changes you have made.

TIBCO iProcess Engine Administrators Guide

Back to Library

382

| Appendix B

System Backup Guidelines

Backup and Recovery of iProcess Case Data

Because all iProcess case data is stored in the SQL/Oracle database, you need to make sure that your database administrator makes regular backups. If the database gets corrupted or the system goes down, the database administrator can use the database recovery tools to recover the iProcess case data.

TIBCO iProcess Engine Administrators Guide

Back to Library

Backup and Recovery of iProcess Engine Configuration Files 383

Backup and Recovery of iProcess Engine Configuration Files

TIBCO recommend that you also backup the following: any configuration files that you change, for example SWDIR\etc\staffcfg. any use files in SWDIR\nodename.n\use.

TIBCO iProcess Engine Administrators Guide

Back to Library

384

| Appendix B

System Backup Guidelines

TIBCO iProcess Engine Administrators Guide

Back to Library

| 385
Appendix C

iProcess Engine Directory Structure

This appendix describes the physical location of the iProcess Engines programs and data on the computer hosting the server. The directories are described relative to the iProcess System directory SWDIR. If there are multiple iProcess Engine installations on the computer, each must have a unique SWDIR. Each computer in a node cluster will have iProcess Engine directories and files. Directory SWDIR\bin SWDIR\cms Description Contains system executables and the swutil utility program. Contains failed mail items for remote nodes. NOTE: This directory is not currently used by the iProcess Engine. SWDIR\cms.rx CMS receive folder. NOTE: This directory is not currently used by the iProcess Engine. SWDIR\cms.tx CMS transmit folder. NOTE: This directory is not currently used by the iProcess Engine. $SWDIR/eaidist SWDIR\etc (UNIX only) Contains TIBCO iProcess Engine Server Plug-ins. Contains iProcess executables, message files and configuration files. It also contains the language.lng sub-directory, which contains language dependent message, and configuration files, where language is the language for this installation. There is one directory per installed language. SWDIR\examples Contains the EAI step procedure examples. This directory only exists if you have installed the examples for the TIBCO iProcess Engine Server Plug-ins.

TIBCO iProcess Engine Administrators Guide

Back to Library

386

| Appendix C
Directory

iProcess Engine Directory Structure

Description Contains .jar files required by the IAPJMS process. Contains the Java JRE distributed with the iProcess Engine. (Windows only) Contains shared libraries such as fil.so and TIBCO iProcess Engine Server Plug-in software. (UNIX only) Contains shared libraries such as fil.so and TIBCO iProcess Engine Server Plug-in software. Contains system log files. (Windows only) Contains the mscluster tool used to add iProcess Engine components to secondary machines in a Windows cluster environment. Contains one file per user currently logged in. Contains a username directory for each user defined on this installation. username is the iProcess work queues directory for the user (or group) username. (Windows only) Contains RPC executables. Contains XML schema definitions. Contains the following iProcess Engine Software Development Kit (SDK) sub-directories: deploysdk - for internal use only. eaisdk - the TIBCO iProcess Plug-in SDK. See the TIBCO iProcess Plug-in SDK User's Guide for more information about this SDK. salsdk - the Staffware Application Layer SDK. See the saldsk\docs directory for more information about this SDK. uvapisdk - the TIBCO iProcess User Validation API. See the TIBCO iProcess User Validation API User's Guide for more information about this SDK.

SWDIR\jar SWDIR\java SWDIR\lib $SWDIR/libs SWDIR\logs SWDIR\mscluster

SWDIR\pro\sww.uid SWDIR\queues

SWDIR\rpc SWDIR\schema SWDIR\sdks

$SWDIR/seo

(UNIX only) Contains iProcess Objects Server configuration files.

TIBCO iProcess Engine Administrators Guide

Back to Library

iProcess Engine Directory Structure 387

Directory SWDIR\nodename.n\use SWDIR\sysinfo SWDIR\tomcat SWDIR\tsys SWDIR\uninstll SWDIR\util

Description Contains Use files defined on this node. NOTE: This directory is not currently used by the iProcess Engine. Contains the Apache Tomcat application server distributed with the iProcess Engine. Temporary editing area. (Windows only) Uninstall directory. Contains utility programs and .xfr procedure files.

TIBCO iProcess Engine Administrators Guide

Back to Library

388

| Appendix C

iProcess Engine Directory Structure

TIBCO iProcess Engine Administrators Guide

Back to Library

| 389
Appendix D

Understanding Audit Trails

An audit trail is a predefined iProcess report that provides a detailed log of all transactions for an individual case of a procedure. There are two types of audit trail message: System-defined. The table below describes the system-defined messages. User-defined. See SWDIR\etc\language.lng\auditusr.mes on page 33 for more information about using this file to define user-defined audit trail messages.

Audit trail messages can be used in two ways: You can view a detailed audit trail for any iProcess case to see how a case is progressing or has progressed using the Case Administration tool. See "Administering Cases" in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information. You can configure the iProcess Engine to publish audit trail messages to an external application. This enables an external application to monitor important business events during the processing of cases. See "Configuring Activity Monitoring" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information and Administering Activity Monitoring and Work Queue Delta Publication on page 329 for more information.

The following table describes the system-defined messages that can be displayed in your audit trails and what they mean: Message ID 000 Message Case started by UserName Description The case of a procedure has been started where UserName is the name of the iProcess user who has started the case. See "Starting Cases" in the TIBCO iProcess Workspace (Windows): Users Guide for more information. The StepDescription work item has been processed to the UserName user. See "Opening and Processing a Work Item" in the TIBCO iProcess Workspace (Windows): Users Guide for more information.

001

StepDescription processed to UserName

TIBCO iProcess Engine Administrators Guide

Back to Library

390

| Appendix D
Message ID 002

Understanding Audit Trails

Message StepDescription released by UserName

Description The StepDescription work item has been released by the UserName user. See "Opening and Processing a Work Item" in the TIBCO iProcess Workspace (Windows): Users Guide for more information. The deadline set for the StepDescription work item has expired for the UserName user. If the deadline has expired, then the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information. An iProcess user has forwarded the StepDescription work item from their work queue to another iProcess users work queue. The UserName is the name of the iProcess user who has received the work item in their work queue. See "Enabling Steps to be Forwarded" in the TIBCO iProcess Modeler - Basic Design Guide for more information.

003

Deadline for StepDescription expired for UserName

004

006

Error - StepDescription not found

The StepDescription work item cannot be found. You may see this message if, for example, the case has been purged and so the work item no longer exists. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine: System Messages Guide for more information.

007

Case terminated abnormally

The case has terminated abnormally. You may see this message if there has been a system error that has caused the case to terminate abnormally. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine: System Messages Guide for more information.

008

Case terminated prematurely by UserName

The case of a procedure has been terminated prematurely by the UserName user. This means that not all the steps in the case have been completed because the case was terminated prematurely. See "Closing Cases" in the TIBCO iProcess Workspace (Windows): Manager's Guide for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

StepDescription forwarded to UserName

Understanding Audit Trails 391

Message ID 009 011 012 013

Message Case terminated normally StepDescription released from queue by UserName

Description The case has completed processing all its steps and, therefore, it has terminated normally. This message is obsolete. If this message appears in an audit trail, contact TIBCO Support for further assistance.

There is no message defined for this number. StepDescription withdrawn from UserName The StepDescription work item has been withdrawn from the UserName queue because the deadline expired or as the result of a withdraw action. If the step has been withdrawn because a deadline has expired, the deadline actions will be processed. See "Withdrawing Steps from the Procedure" in the TIBCO iProcess Modeler - Basic Design Guide for more information. The StepDescription work item has been resent to the UserName user. See "Resending work items" in the TIBCO iProcess swutil and swbatch: Reference Guide for more information. The StepDescription event step has been issued by the UserName user. See "Using Events" in the TIBCO iProcess Modeler - Integrating Techniques guide for more information. A case of a sub-procedure has been started from the StepDescription step. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler - Advanced Design Guide for more information. A case of a sub-procedure that was started from the StepDescription step has terminated normally. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler - Advanced Design Guide for more information.

014

StepDescription resent to UserName

015

StepDescription event issued by UserName

016

Sub-Case started from StepDescription

017

Sub-case started from StepDescription completed

TIBCO iProcess Engine Administrators Guide

Back to Library

392

| Appendix D
Message ID 018

Understanding Audit Trails

Message Sub-case started from StepDescription terminated abnormally

Description A case of a sub-procedure has terminated abnormally where StepDescription is the description of the step. You may see this message if a system error has caused the sub-case to terminate abnormally. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine: System Messages Guide for information. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler - Advanced Design Guide for more information.

020

Sub-case started from StepDescription closed

The StepDescription step that called the sub-case has been withdrawn because the deadline has expired. This causes the sub-case started from this step to be closed. This means that the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information. The StepDescription work item has been redirected to another users work queue. UserName is the name of the iProcess user who has received the work item in their work queue. See "Redirecting Work Items" in the TIBCO iProcess Workspace (Windows): Users Guide" for more information. The case has been suspended by the UserName user. See "Suspending the Flow of a Case" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information. The case has been resumed by the UserName user. See "Suspending the Flow of a Case" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information.

021

StepDescription redirected to UserName

022

Case Suspended by UserName

023

Case Resumed by UserName

TIBCO iProcess Engine Administrators Guide

Back to Library

019

Deadline for sub-case started from StepDescription expired

The deadline set for the StepDescription step that is calling the sub-case has expired. This causes the sub-case started from this step to be closed. This means that the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information.

Understanding Audit Trails 393

Message ID 024

Message StepDescription Case Jump by UserName

Description The UserName user has caused the case to jump to this StepDescription step. See "Using GOTOSTEP to Simplify Procedure Routing" in the TIBCO iProcess Modeler - Basic Design Guide for more information. A case of a SubProcedureDescription sub-procedure has been started by a StepName array element step. See "Using Array Fields" in the TIBCO iProcess Modeler Advanced Design Guide for more information. The external application has informed the iProcess Engine of all the processes that need to be completed before the graft step can complete, where: StepName is the name of the graft step Status:StepName is the current status of the graft step and the graft step name.

025

SubProcedureDescription Sub-Case started (using array element StepName) Task count StepName received for Status:StepName

026

See "Graft Step Task Count" in the TIBCO iProcess Modeler Integration Techniques Guide for more information. 027 Task count decremented for Status:StepName One of the processes grafted to this StepName step has completed. Status is the current status of the graft step. See "Graft Step Task Count" in the TIBCO iProcess Modeler Integration Techniques Guide for more information. 028 Sub-Case grafted to StepDescription External process ExternalProcessName grafted to StepDescription. StepDescription initiated The sub-case has been grafted to the StepDescription graft step. See "Using Graft Steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information. The external process has been grafted to the StepDescription graft step. ExternalProcessName is the name of the external process. See "Using Graft Steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information. The StepDescription graft step has been initiated by the external system. See "Using Graft Steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information.

029

030

TIBCO iProcess Engine Administrators Guide

Back to Library

394

| Appendix D
Message ID 031

Understanding Audit Trails

Message External process ExternalProcessName released StepDescription released, all tasks complete

Description The external process has completed. ExternalProcessName is the name of the external process. See "Using Graft Steps" in the TIBCO iProcess Modeler Integration Techniques Guide for more information. The StepDescription graft step has been released because all the tasks grafted to the graft step are complete. See "Using Graft Steps" in the TIBCO iProcess Modeler Integration Techniques Guide for more information. The StepDescription dynamic sub-procedure step has been released. This is because all the sub-cases started from the step are complete. See Defining a Dynamic Call to Multiple Sub-Procedures in the TIBCO iProcess Modeler - Advanced Design Guide for more information.

032

033

StepDescription released, all sub-cases complete

034

Case migrated from Procedure StepName to StepDescription by UserName

The case from the procedure has migrated to a new procedure with a new version number, where: StepName is the name of the step. StepDescription is the name of the form which is displayed when you open this work item. UserName is the name of the iProcess user who has received the work item in their work queue.

See "Using Version Control" in the TIBCO iProcess Modeler - Procedure Management Guide for more information about version control. See "Release a Procedure Version" in the TIBCO iProcess swutil and swbatch: Reference Guide for more information about migrating cases to new procedure versions. 035 Sub-cases, grafted to StepDescription, closed The sub-cases grafted to the StepDescription graft step have been closed. This is because the graft step has been withdrawn because a deadline expired. This means that the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler Basic Design Guide for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

Understanding Audit Trails 395

Message ID 036

Message Deadline for StepDescription expired

Description The deadline set for the StepDescription graft step has expired. If the deadline has expired, then the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information. The deadline set on the StepDescription dynamic sub-procedure step has expired so the dynamic sub-procedure step has been withdrawn. This has caused the sub-cases started from the dynamic sub-procedure step to close. This means that the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information. The StepDescription step has been withdrawn because a deadline has expired. However, the outstanding items have not been deleted. If the deadline has expired, then the deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler Basic Design Guide for more information. The StepDescription step has no addressees defined for it so it has been automatically released. See "Defining a Step" in the TIBCO iProcess Modeler - Getting Started Guide for more information. The StepDescription step has no sub-procedures defined for it so it has been automatically released. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler Advanced Design Guide for more information.

037

Sub-cases, started from StepDescription, closed

038

StepDescription withdrawn, outstanding items not deleted

039

No addressees defined for step StepDescription automatically released No sub-procedures defined for step StepDescription automatically released

040

041-049 050

There are no messages defined for these numbers. StepDescription EAI call-out initiated (UserName) The StepDescription step has initiated an EAI call-out to an external system on behalf of a UserName user. The iProcess Suite cannot continue processing the case until the EAI call-out has completed. See "Using EAI steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

396

| Appendix D
Message ID 051

Understanding Audit Trails

Message StepDescription EAI call-out completed (UserName)

Description The EAI call-out initiated by the StepDescription step has completed. UserName is the name of the iProcess user on whose behalf the call-out was made. See "Using EAI steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information. The deadline for the StepDescription EAI step has expired. The deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information. The StepDescription EAI step has been withdrawn because the deadline has expired. The deadline actions will be processed. See "Using Deadlines in Procedures" in the TIBCO iProcess Modeler - Basic Design Guide for more information. The procedure has reached a StepDescription transaction control step. This step is configured to commit the current data at the current point in the business process. See "Using Transaction Control steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information. The procedure has started a new transaction from the StepDescription transaction control step. See "Using Transaction Control steps" in the TIBCO iProcess Modeler Integration Techniques Guide for more information. The StepDescription step has retried the new transaction. See "Using Transaction Control steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information. The case has been purged. For example, the iProcess Administrator may purge cases if they are dead or if a new version of a procedure is produced and cases for the existing version should no longer be processed.

052

Deadline for EAI Step StepDescription expired

053

054

Commit Point StepDescription reached

055

New Transaction started from StepDescription

056

New Transaction start retried from StepDescription Case purged

057

TIBCO iProcess Engine Administrators Guide

Back to Library

EAI Step StepDescription withdrawn

Understanding Audit Trails 397

Message ID 058

Message Reason Case data modified by UserName

Description Case data has been modified by user UserName. Reason gives a description of the reason for the change, as specified in the SW_MODIFY_CASEDATA statement. See the TIBCO iProcess Engine Database Administrators Guide for your database for details. The StepDescription work item has been opened by the user UserName. See AUDIT_OPENKEEP on page 181 for more information. The StepDescription work item has been kept by the user UserName. See AUDIT_OPENKEEP on page 181 for more information.

059

stepdescription opened by username stepdescription kept by username

060

061-079 080

There are no messages defined for these numbers. StepDescription EAI call-out failed (UserName) The EAI call-out initiated from the StepDescription EAI step on behalf of the UserName. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine System Error Messages Guide for more information. See "Using EAI steps" in the TIBCO iProcess Modeler Integration Techniques Guide for more information.

081

Workflow may have an infinite loop (at StepDescription) reached max actions per transaction (UserName)

You can limit the number of steps sent or withdrawn during the processing of a single workflow transaction (i.e. the number of EAI steps that can be processed in one transaction without any other step types in between). You receive this message if this limit is reached. If this limit is reached, the workflow transaction is aborted and an appropriate message is logged to the SWDIR\logs\sw_warn log file. See the TIBCO iProcess Engine System Error Messages Guide for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

398

| Appendix D
Message ID 082

Understanding Audit Trails

Message Error, workflow transaction aborted because of a system failure - check sw_warn/sw_error logs

Description The workflow transaction has been aborted because of an internal system failure. Appropriate messages should be logged to the SWDIR\logs\sw_warn and sw_error log files. See the TIBCO iProcess Engine System Error Messages Guide for more information. Some EAI plug-ins need to be registered before you can use them. You may receive this message if your EAI plug-in has not been registered or if it has not been installed correctly, where:

083

StepDescription is the description of the EAI step.

See "Using EAI steps" in the TIBCO iProcess Modeler Integration Techniques Guide for information. 084 Invalid sub-procedure UserName specified for StepDescription - check sw_warn/sw_error logs The UserName specified for the StepDescription sub-procedure step (on whose behalf the sub-procedure is being called) is invalid. You need to fix the step so that it uses the correct name. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine System Error Messages Guide for more information. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler - Advanced Design Guide for more information.

TIBCO iProcess Engine Administrators Guide

Back to Library

The run-time plug-in for EAI Type UserName (used by step StepDescription is not registered on all servers or failed to load/initialize correctly.

UserName is the name of the iProcess user on whose behalf the EAI step is running.

Understanding Audit Trails 399

Message ID 085

Message StepDescription and sub-procedure UserName are not based on the same parameter template check sw_warn/sw_error logs

Description The StepDescription step is trying to call a sub-procedure whose parameter template is not the same as the main procedure. UserName is the name of the iProcess user on whose behalf the sub-procedure is being called. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine System Error Messages Guide for more information. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler - Advanced Design Guide for more information.

086

StepDescription and sub-procedure UserName are not based on the same version of parameter template - check sw_warn/sw_error logs

The StepDescription step is trying to call a sub-procedure whose parameter template is not the same version as the main procedure. UserName is the name of the iProcess user on whose behalf the sub-procedure is being called. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine System Error Messages Guide for more information. See "Defining and Using Sub-procedures" in the TIBCO iProcess Modeler - Advanced Design Guide for more information.

087

Transaction Aborted at StepDescription

The procedure has found an error and has reached a StepDescription transaction control step that has caused the transaction to abort. Check the SWDIR\logs\sw_warn or sw_error log files to see if any error messages were logged. See the TIBCO iProcess Engine System Error Messages Guide for more information. See "Using Transaction Control steps" in the TIBCO iProcess Modeler - Integration Techniques Guide for more information.

088-127

There are no messages defined for these numbers.

TIBCO iProcess Engine Administrators Guide

Back to Library

400

| Appendix D
Message ID 128

Understanding Audit Trails

Message stepdescription delivered to Exchange recipient username stepdescription release received from Exchange recipient username stepdescription withdrawn from Exchange recipient username BusinessWorks Activity Audit description processed by username

Description This message is obsolete.

129

This message is obsolete.

130

This message is obsolete.

131

The action description has been carried out by the user UserName within BusinessWorks. This message is generated by, and the description text is provided by, the BusinessWorks iProcess Audit activity. It is used to audit BusinessWorks activities in the iProcess Engine. See the TIBCO iProcess BusinessWorks Connector Users Guide for more information about the iProcess Audit activity.

132-255

There are no messages defined for these numbers.

TIBCO iProcess Engine Administrators Guide

Back to Library

| 401
Appendix E

iProcess Server Manager Interfaces

This appendix describes the programming interfaces provided by the Process Sentinels for integration with TIBCO Hawk. Using these interfaces, you can create your own TIBCO Hawk console application for use with the iProcess Engine. For more information, see the TIBCO Hawk documentation set.

TIBCO iProcess Engine Administrators Guide

Back to Library

402

| Appendix E

iProcess Server Manager Interfaces

getNodeDetails()
Method Purpose

This method returns the Globally Unique Identifier (GUID) associated with a iProcess Engine node. Synchronous, IMPACT_INFO. None.

Type Arguments Returns

Name NodeGUID DatabaseInfo

Type String String

Description

Description of the database host, type and schema to which this micro agent belongs.

TIBCO iProcess Engine Administrators Guide

Back to Library

Globally Unique Identifier of the node to which this process belongs.

getProcessDetails() 403

getProcessDetails()
Method Purpose

This method returns the details of a iProcess Engine process, including the logical machine ID, process name and instance (as configured in the process_config database table. Synchronous, IMPACT_INFO. None.

Type Arguments Returns

Name MachineID ProcessName ProcessInstance

Type Integer String Integer

Description Logical machine ID of the server on which the process is running. Logical process name of the process. Logical process instance of the process.

TIBCO iProcess Engine Administrators Guide

Back to Library

404

| Appendix E

iProcess Server Manager Interfaces

getProcessSummary()
Method Purpose

This method returns a summary of the current processes for a server (regardless of whether they are configured to run). Synchronous, IMPACT_INFO. None.

Type Arguments Returns

Name ProcessType NumInstances NumRunning ParentType NumChildren ChildrenPaused

Type String Integer Integer String Integer Boolean

Description

Number of configured processes of this type. Number of running processes of this type. Logical process name of the processs parent type. Number of child processes the process type has. Whether the child processes are paused.

Index

ProcessType

TIBCO iProcess Engine Administrators Guide

Back to Library

Logical process name of this process type.

getProcessStatus() 405

getProcessStatus()
Method Purpose

This method returns detailed process information for a server (only for those processes configured to run on the server). Synchronous, IMPACT_INFO. None.

Type Arguments Returns

Name MachineID ProcessName ProcessInstance Enabled Persistent LastKnownStatus StatusComment

Type Integer String Integer Boolean Boolean String String

Description

Logical process name of the process. Logical process instance of the process. Whether the process is enabled for startup. Whether the process is persistent. Last known status of the process. Comment associated with the last known status.

Indexes

MachineID, ProcessName, ProcessInstance

TIBCO iProcess Engine Administrators Guide

Back to Library

Logical machine ID of the server on which the process is running.

406

| Appendix E

iProcess Server Manager Interfaces

doStartProcesses()
Method Purpose

This method starts one or more processes on the specified server. If no parameters are passed, all processes on the current server are started. Use the ProcessType parameter to start processes of a specified type. If you use this parameter you can also specify a specific process instance with the ProcessInstance parameter. Synchronous, IMPACT_INFO.

Type Arguments

Name ProcessType

Type String

Description

ProcessInstance

Integer

Logical process instance of the process to start. Must be used in conjunction with the ProcessType parameter. A value of 0 means that all instances of the indicated process type are started.

Errors

Error Code ERR_PMAMI_PROCTYPE ERR_PMAMI_TYPEDYNAMIC ERR_PMAMI_PROCINST ERR_PMAMI_PARAM ERR_PMAMI_MALLOC

See Also

Error Message ProcessType is not a valid process type. Processes of type ProcessType cannot be started independently. ProcessInstance must be >= 0. ProcessInstance cannot be specified without ProcessType. Insufficient memory to start processes.

getIsTypeDynamic()

TIBCO iProcess Engine Administrators Guide

Back to Library

Logical process name of the type of process to start. The process type must be one that can start independently of the other iProcess Engine processes (see getIsTypeDynamic() on page 411).

doStartTemporaryProcess() 407

doStartTemporaryProcess()
Method Purpose

This method starts one or more temporary processes of the specified type on the current server. These instances will not be restarted if the iProcess Engine is restarted. Both arguments are mandatory. Synchronous, IMPACT_INFO.

Type Arguments

Name ProcessType

Type String

Description

ProcessInstance

Integer

Logical process instance of the temporary process to start.

Errors

Error Code ERR_PMAMI_NOPROCTYPE ERR_PMAMI_PROCTYPE ERR_PMAMI_TYPEDYNAMIC ERR_PMAMI_PROCINST ERR_PMAMI_PARAM ERR_PMAMI_MALLOC

See Also

Error Message You must specify a process type to start. ProcessType is not a valid process type. Processes of type ProcessType cannot be started independently. ProcessInstance must be > 0. ProcessInstance cannot be specified without ProcessType. Insufficient memory to start processes.

getIsTypeDynamic()

TIBCO iProcess Engine Administrators Guide

Back to Library

Logical process name of the type of temporary process to start. The process type must be one that can start independently of the other iProcess Engine processes (see getIsTypeDynamic() on page 411).

408

| Appendix E

iProcess Server Manager Interfaces

doRestartProcess()
Method Purpose

This method restarts a iProcess Engine process that has failed and been placed in a suspended state by its controlling process sentinel. Synchronous, IMPACT_INFO.

Type Arguments

Name ProcessName ProcessInstance

Type String Integer

Description Logical process name of the process to restart. Logical process instance of the process to restart.

Errors

Error Code ERR_PMAMI_NOPROCTYPE ERR_PMAMI_PROCTYPE ERR_PMAMI_PROCINST ERR_PMAMI_NOTSUSPENDED ERR_PMAMI_NOSUCHPROC ERR_PMAMI_MALLOC

Error Message You must specify the process type of the process to restart. ProcessType is not a valid process type. ProcessInstance must be > 0. The process MachineID, ProcessName, ProcessInstance is not suspended. The process MachineID, ProcessName, ProcessInstance does not exist. Insufficient memory to start processes.

TIBCO iProcess Engine Administrators Guide

Back to Library

doStopProcesses() 409

doStopProcesses()
Method Purpose

This method stops one ore more iProcess Engine processes on the current server. If no parameters are passed, all processes on the current server are stopped. Use the ProcessType parameter to stop processes of a specified type. If you use this parameter you can also specify a specific process instance with the ProcessInstance parameter. You can also specify optional arguments to perform a forced shutdown, which stops processes regardless of any active user sessions. Synchronous, IMPACT_INFO.

Type Arguments

Name ProcessType

Type String

Description Logical process name of the type of process to stop. The process type must be one that can be stopped independently of the other iProcess Engine processes (see getIsTypeDynamic() on page 411). Logical process instance of the process to stop. Must be used in conjunction with the ProcessType parameter. A value of 0 means that all instances of the indicated process type are stopped. Whether the shutdown is forced. If 1, users are given 300 seconds before the forced shutdown begins. Number of seconds before the forced shutdown begins. Must be used in conjunction with the ForcedShutdown parameter.

ProcessInstance

Integer

ForcedShutdown

Boolean

ForcedTimeout

Integer

Errors

Error Code ERR_PMAMI_PROCTYPE

Error Message ProcessType is not a valid process type.

TIBCO iProcess Engine Administrators Guide

Back to Library

410

| Appendix E

iProcess Server Manager Interfaces

Error Code ERR_PMAMI_TYPEDYNAMIC ERR_PMAMI_PROCINST ERR_PMAMI_PARAM ERR_PMAMI_MALLOC

See Also

Error Message Processes of type ProcessType cannot be stopped independently. ProcessInstance must be >= 0. ProcessInstance cannot be specified without ProcessType. Insufficient memory to start processes.

getIsTypeDynamic()

TIBCO iProcess Engine Administrators Guide

Back to Library

getIsTypeDynamic() 411

getIsTypeDynamic()
Method Purpose

This method queries the Process Sentinels to determine if a specific process type can be started or stopped independently of the other iProcess Engine processes. Synchronous, IMPACT_INFO.

Type Arguments

Name ProcessType

Type String

Description Logical process name of the type of process to check.

Returns

Name IsDynamic

Type Boolean

Description Whether the process type can be started or stopped independently of the other iProcess Engine processes. TRUE means it can; FALSE means it cannot.

Errors

Error Code ERR_PMAMI_NOPROCTYPE ERR_PMAMI_PROCTYPE

Error Message You must specify the process type of the process to check. ProcessType is not a valid process type.

TIBCO iProcess Engine Administrators Guide

Back to Library

412

| Appendix E

iProcess Server Manager Interfaces

getLogFileLines()
Method Purpose

This method returns a portion of the contents of the specified log file in SWDIR/logs. You control which portion of the log file is displayed by the arguments you pass. Synchronous, IMPACT_INFO.

Type Arguments

Name LogFile StartPos

Type String Integer

Description

Line from which the Process Sentinels should start returning data. This parameter can take one of the following values: 0 - starts returning data from the start of the file n (where n is a line number greater than zero) - returns data starting with the specified line number -1 - starts returning data from the end of the file

NumLines Integer

Number of lines from the end of the log file that should be returned. Defaults to 10.

Returns

Name ErrorMessage

Type String

Description A line from the specified log file.

TIBCO iProcess Engine Administrators Guide

Back to Library

Name of the log file in SWDIR/logs that you want to open.

getAllQueues() 413

getAllQueues()
Method Purpose

This method can be used to return identifying information on all the message queues defined in iProcess. Synchronous, IMPACT_INFO. None.

Type Arguments Returns

Name QueueID QueueName QueueType QueueDesc For Oracle only: NormalMessageNumb er DeadMessageNumber For SQL and DB2 only: MessageNumber

Type Integer String String String

Description

Message queue name. Message queue type. Message queue description.

Integer Integer

The number of normal messages in this queue. The number of dead messages in this queue.

Integer

The number of messages in this queue.

TIBCO iProcess Engine Administrators Guide

Back to Library

Message queue ID.

414

| Appendix E

iProcess Server Manager Interfaces

getMessageHeader()
Method Purpose

This method can be used to get the message summary information for the messages in a given queue. Synchronous, IMPACT_INFO.

Type Arguments

Name QueueID

Type Integer

Description The ID of the message queue from which you want message summary information.

For Oracle only: ShowExceptionMessag e Boolean Set this parameter as true if you want to show exception message items. Otherwise set it as false.

Returns

Name MessageID

Type String

Description The message ID of a message in the queue. This and the other items listed are returned for each message in the queue. The instruction type of the message (for example KEEP, RELEASE, NEWCASE). The addressee of the message. The name of the procedure which generated the message. The name of the step within the procedure which generated the message. The case number of the case being processed. The request ID for the message. A ReqID is needed for each work item.

Instruction Addressee Procedure StepName CaseNumber ReqID

String String String String String String

TIBCO iProcess Engine Administrators Guide

Back to Library

getMessageHeader() 415

Name Failedby

Type String

Description This parameter is only applicable to messages in the dead queue. It indicates the process from which the dead message was created, such as WIS or BG.

For SQL Server Only:

For DB2 only: Failedby String This parameter is only applicable to messages in the dead queue. It is the database table where the message was located before it became dead.

Errors

Error Code ERR_PMAMI_PARAM

Error Message If you enter an invalid QueueID, the interface returns an error similar to the following: Failed to open queue <queue id>:<iProcess error code>

TIBCO iProcess Engine Administrators Guide

Back to Library

416

| Appendix E

iProcess Server Manager Interfaces

getMessageDetail()
Method Purpose Type Arguments

This method can be used to get detailed information for a given message. Synchronous, IMPACT_INFO.

Name QueueID

Type Integer

Description The ID of the message queue from which you want message detail information. The message ID of the message from which you want detail information. Specify All to get detail information on all messages.

MessageID

String

For Oracle only: ShowExceptionMessag e Boolean Set this parameter as true if you want to show exception message items. Otherwise set it as false.

Returns

Name MessageID

Type String

Description The message ID of a message in the queue.This and the other items are returned for each message in the queue. The instruction type of the message (for example KEEP, RELEASE, NEWCASE). The addressee of the message. The name of the procedure which generated the message. The name of the step within the procedure which generated the message.

Instruction Addressee Procedure StepName

String String String String

TIBCO iProcess Engine Administrators Guide

Back to Library

getMessageDetail() 417

Name Case Number ReqID FailCount ParsedMessageData

Type String String Integer String

Description The case number of the case being processed. The request ID for the message. A ReqID is needed for each work item. The fail count. Parsed Message Data. A sequence of field name:field value; pairs. If the raw data cannot be parsed successfully, this argument will be N/A:N/A;.

For SQL Server only: Failedby String This parameter is only applicable to messages in the dead queue. It indicates the process from which the dead message was created, such as WIS or BG.

For DB2 only: Failedby String This parameter is only applicable to messages in the dead queue. It is the database table where the message was located before it became dead.

Errors

Error Code ERR_PMAMI_PARAM

Error Message If you enter an invalid QueueID, the interface returns an error similar to the following: Failed to open queue <queue id>:<iProcess error code>

TIBCO iProcess Engine Administrators Guide

Back to Library

RawMessageData

String

The raw message data - the same data as in the previous field, but unparsed.

418

| Appendix E

iProcess Server Manager Interfaces

deleteMessage()
Method Purpose Type Arguments

This method can be used to delete a given message. Synchronous, IMPACT_INFO.

Name QueueID MessageID For Oracle only: ExceptionQueue

Type Integer String

Description The ID of the message queue from which you want message detail information.

Boolean

Set this parameter as true if you want to delete exception messages. Otherwise set it as false.

Returns

Name AffectedNum

Type Integer

Description The number of messages that have been deleted successfully.

Errors

Error Code ERR_PMAMI_PARAM

Error Message If you enter an invalid QueueID, the interface returns an error similar to the following: Failed to open queue <queue id>:<iProcess error code>

TIBCO iProcess Engine Administrators Guide

Back to Library

The message ID of the message you want to delete. Specify All to delete all messages.

restoreDeadMessage() 419

restoreDeadMessage()
Method Purpose

This method can be used to restore a dead message to the queue from which it came. Synchronous, IMPACT_INFO.

Type Arguments

Name MessageID

Type String

Description The message ID of the message you want to restore. Specify All to restore all dead messages.

For Oracle and DB2 only: QueueID String The ID of the queue to which dead messages will be restored.

For SQL Server Only: ProcessName A logical process name. This parameter specifies the resource process from which the dead messages came. The Destination Queue ID - the ID of the queue to which you wish to restore the message. This queue must be hosted by the process specified by ProcessName.

ToQueueID

Returns

Name AffectedNum

Type Integer

Description The number of dead messages that have been restored successfully.

TIBCO iProcess Engine Administrators Guide

Back to Library

420

| Appendix E

iProcess Server Manager Interfaces

Errors

Error Code ERR_PMAMI_PARAM

Error Message If you enter an invalid QueueID, the interface returns an error similar to the following: Failed to open queue <queue id>:<iProcess error code>

TIBCO iProcess Engine Administrators Guide

Back to Library