Tibco BusinessWorks Best Practices

• 
  For-Each should be used instead of group activity wherever possible.
• Labeled transitions and Color Codes for Success and Error Transitions
• For multiple transitions merging into one, all transitions should preferably merge at null activity.
• For Parallel processing, should have an appropriate activity (e.g. null) so that all the parallel paths get executed. This is to ensure that following activities after the null activity will have all the outputs available from parallel paths.
• Use cfg file to override the GV setting for designer mode testing.
• Do not use generic Engine Name
• When an EAR file is created, BW starter processes are packaged in Process Archives (PAR file). Many EAR file has Process Archives using default name "Process Archive"; this must not be done. Process Archive should have proper name. For example FraudDetection, This greatly helps locate BW engine and find out its resource consumption once an EAR is deployed in Production.
• Instead of JMS Queue Requestor use JMS Queue Sender and Wait for JMS Actives. Boz JMS queue requestor open a new primary thread.
• When you want to map a child elements for example Complete Details > Details > Personal Details > Address Details > Permanent Address> Address to the Address then copy the address to process variable and map it. It increases the performance.
• Instead of Java code activity use java Method activity.
• Instead of creating Durable Subscriber create a bridge b\w topic to queue and ask the durable subscriber to listen on that queue. Adding a durable subscriber created anoverhead on ems server.
• Use activity names as small. Avoid using unnecessary activities (i.e null , Mappers , Assign activities,groups,inner groups)
• Divided the functionality in to molecular level for the re-use. Instead of creating in a large process.
• Use Batching instead of Statement when possible (Better Latency) in JDBC Update.
• Use JDBC Query activity to fetch batches of records at a time instead of retrieving the entire result set.
• Rule of thumb is not to use many Global variables(GV) as it stays in memory in form of a
• tree and to retrieve the bind-ed value process has to traverse the tree. If the unwanted GV are there the cost is incurred in traversing.
• Copy-off increases the performance than mapping with for each in Input Tab.
• Instead of passing a large set of data to Call process every time use Job Shared variable. Which increase the performance.

TIBCO BW Engine:(Properties)

The TIBCO BusinessWorks engine runs the business processes in test mode and at runtime.In TIBCO, the BusinessWorks engine is running in a JVM.BW engine runs into its own JVM without any Tomcat or J2EE container.BW engine WEB services and Http relies on Apache libraries, there are a number of properties you can set in the bwengine.tra file TIBCO BusinessWorks engine each include an instance of TIBCO Runtime Agent.

There are two types of activities in BusinessWorks. They can either be blocking or non-blocking activities. This is determined based on how the activity functions with the thread.

Blocking activities are activities that are executed using the engine thread. This type of activity may affect the engine's performance because if this activity is waiting for an event then the engine thread will also be waiting for the activity to resume from its waiting state.

Non-blocking activities are activities that are executed using a private thread. This kind of activity does not affect the engine's performance because when the activity is processing, it switches to its own private thread. When it is done with its process, it will be fetched by the engine thread that is currently running.

The TIBCO Designer application creates an Enterprise Archive (EAR) file to describe a business process and associated resource information; in conjunction with the TIBCO Designer application, certain properties may be included in an XML file called bwengine.xml. Certain aspects of the design elements and all of the aspects of the bwengine.xml file are exposed to the TIBCO Administrator application and may be changed prior to deployment.

EAR files are moved from the TIBCO Designer application to the TIBCO Administrator application. The TIBCO Administrator application is then used to deploy applicable parts of the EAR file to applicable instances of the TIBCO BusinessWorks engine. The TIBCO Administrator application starts the BusinessWorks engine to perform activities in the business process.

EAR consist of one or more par (process archive). Each PAR starts own jvm. So if you are having more than one ear or one par that means all will be executed in different jvm.

Active Matrix BW5.6 introduced a concept called containers. BW container itself is a JVM and when you deploy, you can deploy any number of pars to a container (number of pars depends on the complexity of the process definition, available memory etc.)

The TIBCO Designer application, the TIBCO Administrator application, and the BusinessWorks engine all rely upon software installed by TIBCO Runtime Agent.

The initial configuration of a business process is provided by the TIBCO Designer application in the EAR files that describe the business process. Selected configuration values (those specified by the TIBCO Designer application as externalized) can be modified by the TIBCO Administrator application. The BusinessWorks engine uses whatever configuration values are provided to it when the business process is deployed or when the TIBCO Administrator application indicates a configuration change.

The BW engine uses two flavors of properties:

1. java. property.<propname> -- which is loaded by the wrapper(i.e. bwengine.exe)

2. <propname> -- which is picked by the engine

The wrapper loads its properties from a file specified by --propFile while the engine loads its properties from a file specified by -p.

When running the engine in debug mode (i.e. through Designer), the properties can be put in a file, such as "properties.cfg", and loaded when the engine is launched as -p properties.cfg. When you launch the tester engine, go to the Advanced Test Settings tab and specify the properties file as shown below.

By default, the tester engine in Designer loads the properties file (properties.cfg) to the <TIBCO_HOME>/designer/5.x directory. Some properties of the form 'java.property.*' needs to be specified in the designer.tra file as they are loaded by the wrapper, in which case Designer must be restarted for the properties to take effect. In contrast, any changes made to the engine properties specified with the -p flag should take effect simply by restarting the tester.

When running the engine from the command line, all properties can be placed in one file (e.g. myengine.tra) using the template "bwengine.tra". In the .tra file, you must edit the property tibco.env.APP_ARGS to point to itself. For example, if "myengine.tra" is in C:/temp, then the property would be

tibco.env.APP_ARGS=-p C:/temp/myengine.tra

Engine Properties

Worker Threads

The default number of worker threads is 8. On a multi-CPU machine, the number of threads can be increased. The user should empirically determine the optimal thread value for their deployment as too many threads can cause resource contention. The recommended value is 8 threads per CPU:

Engine.ThreadCount=8

StepCount Property

The StepCount property controls the maximum number of execution steps (unless inside a transaction) for a job before an engine thread switch occurs. The default value of this parameter is 20. Frequent thread switching can cause engine performance degradation. But when a process instance keeps the tread too long, this may cause less concurrency for executing process instances and hence inefficient use of CPU.Therefore, it is difficult to determine the correct value for this property. The default value is sufficient for most situations. But if your process definitions contain a large number of activities (and especially if they contain a large number of activities in iteration loops), you may benefit from setting this property to a higher value.

Engine.StepCount=20

Flow Control

Those are flow control-related properties. Detailed explanation of those properties can be found in the TIBCO Admin Users Guide, Chapter 8 (Setting deployment options), under the section titled "Changing TIBCOBW process configuration properties".

MaxJobs.ProcessFlows/PrRVSubscriber.process=5 (0 by default)

FlowLimit.ProcessFlows/PrRVSubscriber.process=10 (0 by default)

ActivationLimit.ProcessFlows/PrRVSubscriber.process=false ("true" by default)

ActivationLimit.ProcessFlows/Pr\ RVSubscriber.process=false ("true by default)

Memory Saving Mode - BW Garbage Collection (not Java)

Memory saving mode can reduce memory usage by actively running process instances as well as potentially improving the performance of checkpoints. Note that is a BW Process Variable garbage collection and not the Java garbage collection.

EnableMemorySavingMode.*=true (for all process flow)

EnableMemorySavingMode.<processName>=true (for specific process flow)

Both properties above are "false" by default

JobId Block Size

When an engine starts up, it reads a job id block size from the DataManager. Each newly created job is assigned an id from this block. By default, the value of the JobIdBlockSize is 1000:

Engine.JobIdBlockSize=1000

Engine Termination

If you wish to terminate the engine when the "Process initialization failed" error is encountered during engine startup, set the following property to "true":

Engine.ShutdownOnStartupError=true

The default of the property above is "false".

FT-Related Properties

Engine.FT.UseFT=true

Engine.FT.Weight=100

Engine.FT.HeartbeatInterval=3000

Engine.FT.ActivationDelay=6000

Engine.FT.ActivationInterval=10000

Engine.FT.GroupName=RUDRA.xyz

Engine.FT.Subject=RUDRA.Test.Process (optional, if not used, subject=FT.<GroupName>)

If you wish to perform FT-level debugging, you can listen on the following

subject for FT heartbeats:

tibrvlisten "_RVFT.ACTIVE_HB.<FT subject name>"

FT transport configuration:

To use non-default values for FT transport, set the following properties:

Bus.Default.Service=6532

Bus.Default.Daemon=tcp:6532

Bus.Default.Network=;

In some situations where a database is used as the data manager for process engines, a unique constraint violation is thrown. If such an error is encountered, set the property below to "false".

Engine.StandAlone

By default, the property above has a value of "true".

Hawk

Enabling/Disabling Hawk

Hawk.Enabled=true

true - enables both TIBCO Hawk and Engine Command activity usage.

false - disables both TIBCO Hawk and Engine Command activity usage.

local - only enables Engine Command activity (TIBCO Hawk will be disabled).

Hawk Transport

Hawk.Service=7474 (default udp port is 7474)

Hawk.Daemon=tcp:7474 (default tcp port is 7474)

Hawk.Network=; (default network value is ;)

Hawk Display Name

Hawk.AMI.DisplayName=Test.bwengine #default name is com.tibco.pe.<engineName>

Performance Statistics

Set the following property to collect statistics for various activities in a process flow at runtime:

Instrumentation.*=true

Instrumentation.<processName>=true (for a specific process flow)

[Note: be advised that setting the instrumentation property can cause performance degradation and memory overhead.]

When you enable instrumentation, it allows you to execute the following Hawk methods:

Collection of activity statistics using GetActivity micro-agent method

Calls to OnProcessActivity and OnProcessStatusChanged micro-agent methods

The instrumentation property can be set at runtime by calling the TIBCO Hawk setInstrumentProperties method. The property value specified in a call to setInsrumentProperties will take effect immediately.

Other (Non-activity) Specific Properties

Memory

java.extended.properties -Xms768m -Xmx768m -verbose:gc

Global Variable Substitution

tibco.clientVar.<global var>=test

tibco.clientVar.mySubject=test.xyz

Repository Connection - Remote/Local

tibco.repourl=C\:/tibco/tra/domain/amxdom/datafiles/RVCMQtester_root

tibco.deployment=RVCMQtester

tibco.domain=Test

tibco.username=admin