TIBCO iProcess - Best Practices

TIBCO iProcess - Best Practices

book

Article ID: KB0081979

calendar_today

Updated On:

Products Versions
TIBCO iProcess Engine (Oracle) All
TIBCO iProcess Engine (DB2) All
TIBCO iProcess Technology Plug-ins All

Description

We do not have a consolidated list of Best Practices in the Product Documentation. Consult with TIBCO PSG via your TIBCO Account Manager for an exhaustive list of best practices suited for your environment/implementation. This article lists few of the most frequently occurring suggestions made by TIBCO Support. 

Issue/Introduction

Best practices for TIBCO iProcess Suite.

Resolution

Design Time - Even though already in Production, Design Time impacts runtime performance. 

  • Use TCS steps to break long transactions after sub-process completes, etc.
  • Use Delayed Release EAIJAVA call instead of immediate release.
  • Use SW_QRETRYCOUNT to handle EAI Java errors.
  • Do not delete a step in a procedure. Just delete the incoming link. A lot of times cases have a step outstanding and that step itself gets deleted which causes the instructions to fail. 

Runtime environment - 

  • Resource monitoring - Per process / Overall iProcess server / If VM then ESX server as well.
    • CPU
    • Memory
    • Disk I/O
    • Disk space left on device
    • Network latency between servers hosting - iProcess Engine, Database, TIBCO BusinessWorks, TIBCO EMS
    • Time creep between servers
    • Database performance
  • Monitor iProcess MBox queues - swadm count_messages ALL
  • Monitor WIS process (as suggested in - https://docs.tibco.com/pub/ipe-oracle/11.6.0/doc/html/tib_ipe_admin_guide/wiswqs.16.4.htm#1074729)
  • Monitor / Review iProcess logs - sw_error, sw_warn and swentobjsv*logs
  • All monitoring data should be compared with an acceptable performance benchmark data at a defined peak load.
  • Cleanup file system regularly - Archive old logs / temp files
  • Purge cases regularly via dedicated BGs
  • Delete all old procedure versions. Archiving should be performed elsewhere.
  • Regular database maintenance - update stats / re-org tables / rebuild indexes / monitor internal Oracle processes, etc/
  • User administering iProcess should be familiar with at least swadm / swsvrmgr commands (details in iProcess Administrator Guide)
  • Change the EAI Java deadlock timeout to 30 secs.
  • Version 11.5.0 and higher -
    • Utilize the $SWDIR/etc/sqloptim file to fine tune hints for the available sqlids.  
    • Define a default ONFULL and MAXSIZE attribute for all log files to prevent any from reaching the 2GB limit or just making sure they are rotated/saved appropriately if no value is set.
    • Define max sw_warn/sw_error log file sizes with WARN_ERROR_LOG_SIZE to prevent large warn/error log files. 
  • Version 11.4.1 and higher -
    • Monitor the sw_warn file for dequeue times (DB tuning), overall call times (likely due to the need for delayed release), mutex acquisition times (sharing SPO logins).  
    • Use auto-purge deadlines to purge old cases to prevent unneeded cases from piling up in the system (or overall using AUTO_PURGE_DELAY).
    • Use swadm EVLOOPBACK to test events (mostly Oracle related to know to re-start the DB or contact Oracle). 
    • CCOUNT_CACHE_REFRESH now has a value of 0 for everything but RPC_POOL.  For performance, and if this was upgraded, make sure it is not set to a different value for other processes.  
    • If you have a lot of cases, DISABLE_CASE_COUNTS can also be useful (along with disabling case counts in WS(B)).  
  • Version 11.4.0 and higher -
    • Set the SPO_CACHE_PROC attribute to prevent the SPO server from caching all versions of every procedure.