Академический Документы
Профессиональный Документы
Культура Документы
com/
Tushar Jain tusjain@yahoo.com, tusjain@gmail.com
Table of Contents
1 Introduction
1.1 Objective
1.2 Tibco BW Concepts
1.2 Methodology
4 Configurations
4.1 Configuring Persistent Connections
4.2 Configuring HTTP/JMS Servers
5 Global Variables
5.1 Grouping & Sub-grouping Rules
5.2 Naming Conventions
6 Logging
6.1 Logging Rules
6.2 Logging Parameters [Details, frequency etc.
The current flavor TIB-BW is provides extensive solution where a process can be configured as a
exposable Service adhering to SOA standard. The current flavor TIB-BW design also supports BPEL
standards of Design.
1.3 Methodology
TIB-BW integration project is developed in phases. Methodology focuses on the aspects of a nature of a
project where a project is in development or in migration phase following a short development cycle,
scalable and extensible, and the ease-ness of use. It is been observed that the sequential execution of
these phases in results in a fast deployment
Decide a Software-Hardware map where the software component(s) and machine(s) to be deployed on
the machine is determined and the features such as load balancing and fail over and backing up
strategies are well defined.
3 Best Practices
The TIBCO BusinessWorks process engine can be configured to be fault-tolerant. One can start up
several engines. In the event of a failure, other engines restart process starters and the corresponding
services. One engine is configured as the master, and it creates and executes services. The second
engine is a secondary engine, and it stands by in case of failure of the master. The engines send
heartbeats to notify each other they are operating normally.
In the event the master process engine fails, the secondary engine detects the stop in the master’s
heartbeat and resumes operation in place of the master. All process starters are restarted on the
secondary, and services are restarted to the state of their last checkpoint.
The expected deployment is for master and secondary engines to reside on separate machines. There
can have multiple secondary engineswith a specified weight for each engine. The weight determines
the type of relationship between the Fault -tolerant engines.
A master and its secondary engines is known as a fault--tolerant group. The group can be configured
with several advanced configuration options, such as the heartbeat interval and the weight of each
group member.
Members of a Fault -tolerant group can be configured as peers or as master and secondary engines. If
all engines are peers, when the machine containing the currently active process engine fails, another
peer process engine resumes processing for the first engine, and continues processing until its
machine fails.
If the engines are configured as master and secondary, the secondary engine resumes processing
when the master fails. The secondary engine continues processing until the master recovers. Once
the master recovers, the secondary engine shuts down and the master takes over processing again.
The Fault-tolerant tab of the Process Engine deployment resource allows to specify the member
weight of each member of a Fault -tolerant group. The member with the highest weight is the master.
One can select "Peer" in the first field on the tab to configure all engines as peers (that is, they all
have the same weight). One can select Primary/Secondary to configure the engines as master and
secondary. One can also select Custom to specify oner own values for the weight of each member of
the group.
When a master process engine fails, its process starters are restarted on the secondary engine. This
may not be possible with all process starters. For example, the HTTP Receiver process starter listens
for HTTP requests on a specified port on the machine where the process engine resides. If a
secondary engine resumes operation for a master engine, the new machine is now listening for HTTP
requests on the specified port. HTTP requests always specify the machine name, so incoming HTTP
requests will not automatically be redirected to the new machine.
Each process starter has different configuration requirements, and not all process starters may
gracefully resume on a different machine. Additional hardware or software required to redirect the
incoming events to the appropriate place in the event of a failure.
The FT Group Settings panel displays only if the TIBCO BusinessWorks process has been added to at least
two (different) machines. If the domain includes components that were deployed as part of a fault-tolerant
group, the display includes the information about the group.
It is possible to start one or more process engines in the group. If more than one engine has started, only one
is displayed as Running and all other engines are displayed as Standing By (or, initially, as Starting Up).
Any change in the status of a component that has been deployed as part of a FT group, the status change
affects all other members of the group.
After deployed the process engines, it is most efficient to select all process engines and start these together.
After the primary and secondary engines have communicated, the master will display as Running and all other
engines as Standby.
If only primary gets started , it will first go to Standby mode as it checks the status of the other engines. It then
changes to Running. Upon shutdown of a process engine, the appropriate secondary engine starts
automatically. The Fault –tolerant mode of running of the process can be configured in the
administrator.
Because Fault -tolerant engines are expected to be on separate machines, it is advisable to use a database
for storage for each process engine. This allows to specify the same JDBC Connection resource for the master
and secondary engines, and therefore all engines can share the information stored for process instance
checkpoints.
If all engines share the checkpoint information, and then the secondary engines can recover process instances
up to their last checkpoint. If engines do not share the checkpoint information, process instances are not
restarted.
One common application of a JMS queue is to distribute queue messages across multiple receivers, there by it
balances the processing of the messages on the queue. To achieve this goal, both the JMS server and TIBCO
BusinessWorks must be properly configured. The JMS server must allow the queue messages to be distributed
across multiple receivers. For example, in TIBCO Enterprise Message Service, the exclusive property on the
queue controls whether messages can be delivered across receivers or not. In TIBCO BusinessWorks, the
process definition containing the JMS Queue Receiver must be deployed across multiple process engines. This
creates multiple queue receivers for the same queue.
When balancing incoming messages across TIBCO BusinessWorks engines, it shouldbe ensured that one
engine does not attempt to accept and confirm a large number of incoming messages before other engines can
receive the messages. In general, most JMS servers balance the load by distributing messages in a round-
robin fashion to all queue receivers. However, there are situations that can cause an uneven distribution of
messages across queue receivers. If the Acknowledge Mode field is set to "Auto" on the Configuration tab of
the JMS Queue Receiver, the process starter confirms messages as it receives them. When process engines
are started at different times, this can lead to one process engine receiving all queue messages and paging
them to disk, depending upon how the engine’s Max Jobs and Activation Limit properties are set when the
engine is deployed.
TIBCO Enterprise Messaging Service, can avoid this problem by setting the acknowledge mode to TIBCO EMS
Explicit and then use the Flow Limit property in the deployment configuration to control the number of process
instances created by the process starter.
If not using TIBCO Enterprise Messaging Service, set the Acknowledge Mode field to "Client". In this mode, a
process engine can only receive as many messages as it has sessions specified in the Max Sessions field.
Once a process engine reaches the maximum number of sessions, another process engine can begin to accept
incoming messages. A process engine cannot receive more messages until the messages have been
acknowledged by using the Confirm activity and can be considered as a draw back. Once the message is
acknowledged, the session is released and the process engine can accept a new message.
• Hotspot Server JVM will give better performance with TIBCO BusinessWorks. Sun also claims better
performance for Hotspot Server JVM.
• Consider using the multi-threaded garbage collector, which is available in Jdk.4.x. Experimenting
with processor sets with multiple engines is a good idea.
3.2.1 Specifying JVM Heap Size
The default Java heap size, which varies according to platform, is a conservative estimate made by
the developers of the particular type of Java being used. To calculate the amount of memory needed
for a TIBCO BusinessWorks Engine, one should determine the largest heap size that can reside in
physical memory. For best engine performance, paging to disk should be avoided.
•Heap size mostly depends on the memory available. Recommended heap size for a small workload
is 256MB, for medium 512MB, and for large workload 1GB or more. Maximum heap size per engine
can be configured and saved using the Tibco Administartor
TIBCO Runtime Agent™ allows to modify the Java heap size, JVM selection, and JVM settings that
the TIBCO BusinessWorks Engine uses when it is started. This memory is committed for engine
activities and job processing.
To set the JVM available memory, use the following parameters:
• The Initial JVM Size parameter sets the minimum amount of memory used
• Maximum JVM Size sets the maximum.
The total amount of JVM memory needed to operate a TIBCO BusinessWorks Engine should be the
memory for each process plus the maximum number of processes that can be in the process pool. If
flow control is enabled, the process pool can contain up to the MaxJobs value.
3.2.2 Setting JVM and Processor Affinity
If machine is equipped with multiple processor machines, TIBCO Software recommends that one
assign processor affinity with different instances of TIBCO BusinessWorks Engines:
• On Windows, use the Task Manager facility to assign affinity.
• On a Solaris platform, create processor set using psrset/psradm/pbind.
• On Linux, use the taskset command to set processor affinity.
3.2.3 JVM Garbage Collection
The recommendation is not to do a make direct explicit garbage collection. JVM internally handles GC
with its inbuilt algorithm. However tuning garbage collection requires good understanding of garbage
collection frequency, message size, and longevity (oneng, tenured, and perm).
3.3 TIBCO Business Works Transport and Palette Guidelines
Choose a appropriate Transport which adheres to interoperability, reliability, and security requirements. Choice
of using XML over HTTP, XML over JMS, SOAP over HTTP, SOAP over JMS, TIBCO Rendezvous messages
and TIBCO Active Enterprise™ messages are a few combinations based on the requirement and infrastructure.
It is observed that SOAP over HTTP is performs better than SOAP over JMS. The SOAP protocol adds
significant overhead whether one use it on HTTP or JMS, since there is an overhead cost of creating and
parsing the SOAP envelope.
The following observations can be made based on various comparisons of HTTP clients, HTTP servers, SOAP
clients, and SOAP servers:
3.3.1 HTTP/S
There are two important tuning considerations related to the HTTP client:
• HTTP/S Client Thread Pool
• Persistent Connection Manager (PCM)
When the client cannot check for stale connections, it is very likely that the server would receive
duplicate messages. If one cannot rely on the client to detect the stale connection, the next option is to
make sure the server provides support for duplicate message detection.
HTTP/SOAP Server
Following important considerations apply to HTTP and SOAP over HTTP server:
• Configure minProcessor & maxProcessor as described in the configuration section.
• HTTP servers can be deployed in various load-balanced situations. However, deploying
multiple HTTP servers that listen on the same machine is not possible, since the HTTP port is
bound to a specific machine. Alternatives are available, such as creating reverse proxy
solution, but they are beyond the scope of this document.
• HTTP traffic that arrives from external sources should be evaluated carefully. Use of
content aware XML accelerators or routers such as Cisco® Application-Oriented Networking
(AON), Sarvega (now in INTEL), or Reactivity helps in determining the content.
3.3.2 SOAP
Simple Object Access Protocol (SOAP) is a lightweight protocol for the exchange of information
between web services. Currently, the supported transports for SOAP are HTTP and JMS. The
performance characteristics of SOAP are closely tied to the performance of the HTTP and JMS
implementation in TIBCO BusinessWorks, and the only way to load balance SOAP over HTTP is to
include a Local Director for directing requests to a set of configured engines.
Major influences of performance for SOAP are similar to the generic influences:
• Message Complexity. The more complex the process the greater impact on the parsing
(packing and unpacking) of the message as it travels through various stages of the SOAP
protocol.
• Secured. The decision to use basic authentication will affect performance. This is
straightforward and the impact is easily measured.
• Load Balanced. The use of a local director to distribute incoming requests.
3.3.3 JMS
Recommendations for using Java Message Service (JMS) are as follows:
• Within TIBCO BusinessWorks 5.1.3 and prior versions, transport such as JMS can be
throttled by limiting the number of sessions. JMS doesn’t deliver more messages until some
of the sessions have been acknowledged.
• Within TIBCO BusinessWorks 5.2, significant improvements have been made to this
mechanism. New for this release is the combination of TIBCO Enterprise Message Service
features Explicit Acknowledge and FlowLimit. In this case, location of ack in process makes
no difference.
FTP activities that share the same host, port, username, and password within the same process
definition can now share the same session. The Quit (post-command) field specifies that the command
should close the session. Keeping the session open for all activities can improve performance
because there is significant overhead creating a session for each activity.
3.3.5 JDBC
JDBC activity most frequently used data access activity that has a significant performance implication.
It is recommended to use certified, high performance JDBC drivers or the recommended drivers
available at BW.
A test can be done in-order to determine the Driver type giving a positive response. The JDBC Query
activity can now fetch batches of records at a time instead of retrieving the entire result set. JDBC
Update activity has been enhanced to allow multiple statements to be executed.
Use Batching instead of Statement when possible (Better Latency)
A general rule of thumb is to initially set the maximum number of database connections to slightly less
than engine thread count. If there are not enough database connections allocated, some jobs may be
blocked waiting to free a connection. One should continue to monitor the number of database
connections using database tools. There are a few tools that one should be familiar with: TIBCO trace
tool, described in this paper, and specific DB tools to monitor the overall number of database sessions.
Static data
These data are typically kept as a local copy; TIBCO BusinessWorks hangs on to it in memory. One
example is global variables implemented internally as the XML structure known as
$_globalVariables. Unused variables can increase the latencies, especially for repeat-until-true
where iterator conditions XPATH formula contains Global Variables instead of constants. Although the
cache has the MFU (Most Frequently Used) to LFU (Least Frequently Used) list of GV for its use.
Dynamic data
• Work on local data, cache carefully, and use optimistic locking.
• TimesTen is an in-memory database that can improve the performance of checkpoints and
wait/notify activities.
• TIBCO® BusinessWorks Smart Mapper is another example which has been used
extensively in cross-referencing (1-1 or 1-n) data. It provides a data caching option which
simply removes any performance overhead of looking up data from the database.
The Java Global Instance shared configuration resource allows one to specify a Java object
that can be shared across all process instances in JVM.
• Shared Java object (example : a shared variable which allowing to implement a wait and
gain nature of inter process communication) should be instantiated at engine startup time and
shared by all activities that access it.
• If an object can be shared across multiple process instances, instantiate shared data only
once to improve performance and reduce overhead.
3.4.2 Checkpoints
The high volume applications which make a significant use of checkpoint have to be continuously
aware of the performance cost of writing data to the checkpoints. These applications frequently need
faster access to checkpoint data, replication of checkpoint data between different systems for failover
reason, and database server-failure protection.
3.4.3 Grouping Activities
Call Process
Every time CP is called, input data including process instance data are bounded to the sub-
process input data structure. In most cases reference is made to original entity; however, whenever
data is mapped a copy of data is created. Keeping this obvious cost in mind, the designer should
always be mindful of use of CP and continuously evaluate cost vs. CP modularization.
TIBCO BusinessWorks provides a testing environment for stepping through oner process models and
determining the sources of errors. Entering the testing environment starts a TIBCO BusinessWorks engine. The
engine starts process instances based on the process definitions stored in oner project. One can select one of
the running process instances to display in the design panel, and the currently executing activity is highlighted
as the process instance runs.
In general, testing should be done during the design and development phase of a project. testing a deployed
project is possible, but might be difficult depending upon the volume of the workload of the system. Also, testing
usually involves setting breakpoints in the process model to stop the running process instances at desired
points. This is not possible in a production environment, so one may want to use a development system for
testing purposes.
Testing a process definition typically involves these steps:
Select the process definition one wish to test in the project panel.
Set breakpoints in the process definition at points where one wish to stop a running process and examine its
state.
If the process begins with a Start activity and the Start activity has a schema defined, one can supply input data
to the process before executing it.
Click the Tester tab on the left of the project panel. The project panel becomes the test panel. From the test
panel one can start process instances or load more process definitions. See Process Instances During testing
for more information about process instances in the test panel.
Examine the data of the process by selecting any of the activities in the process. The current state of the
process data is displayed on the Process Data tab of each activity.
Use the toolbar buttons (Pause testing, Step to Next Activity, and so on) in the test panel to either continue
through the process instance or to stop the current process instance.
Once in testing mode, changes to oner process definitions are not reflected in the running process instances.
Return to design mode before changing process definitions.
3.4.5 Tracing in BW
Tracing activity needed in order to manage and monitor a deployment. View the status of components and
generate tracing information. Start and stop process engines and adapters. Use of Custom Activity, Use of
Logging i.e. system log and application log, configuring a hawk micro agent on the logs. Write a custom micro
agent to monitor specific scenarios. Define Break points at design time and Test. TIBCO Administrator GUI
allows monitoring of the running project at different levels of detail, and can collect tracing information for later
analysis.
This parameter significantly improves memory footprint for processes that manipulate a large amount of data
for a small part of their lifetime. This TIBCO BusinessWorks property allows the engine to release references to
unused process data so that it can be garbage collected by the JVM, thus improving the performance of
processes with large amounts of data.
XML Text* Medium A single text field containing XML, which will be
parsed by the process starter. This is a major
change in TIBCO Active Enterprise™ 5 wire
format. When XML Text format has been
chosen, TIBCO Rendezvous will use the internal
TIBRVMSG_XML type and compress the
message on the wire.
This section will focus on providing a better design practices for an improved performance using
TIBCO BusinessWorks.
3.6 Processing Large Sets of Data
Common uses of a TIBCO BusinessWorks process are to retrieve a large set of data (for example, a JDBC
result set) and then process it through a series of activities. Care should be exercised to limit this data to a
manageable “chunk” before processing.
It is important to note that the default behavior of the JDBC query activity, and other activities such as parse
data or parse XML, is to parse/retrieve the entire result into memory for downstream processing. This has two
effects on performance:
• Memory Large parsed objects can consume considerable memory very quickly, therefore allowing an
unspecified number of records to be retrieved at once can cause memory usage problems.
• Indexing of records If oner data has a large number of repeated records/elements and one plan to
iterate through them, performance will degrade in a non-linear (quadratic) fashion as the number of
records grows. This is due to the increased lookup time as the data “tree” is traversed from the start
The solution to both of these problems is to retrieve the data in smaller sets/chunks and use a group to iterate
through the entire set. The way to do this varies based on the input data source, but a couple of common inputs
are results of Parse Data and JDBC Query activities.
For the parse data activity, one can easily configure it to retrieve a set number of records and process them
before retrieving more. One feature of the parse data activity is that it does not buffer the whole file from the
disk. Therefore, one can use it to process extremely large (1G +) files with a controlled amount of memory
usage.
For the JDBC query activity, it is possible to retrieve the results in chunks by using more selective SQL and
surrounding the JDBC query activity with an iterate group. For example, if the table holds 100K rows and
one retrieve 1K at a time and iterate 100 times, the total processing time will be significantly less than
retrieving all 100K rows at once. Some experimentation can be used to optimize the size of the chunk
depending on the type of data and processing required.
3.6.1 Iterating Through Large Sets of Data Using a Mapper Activity
Mapping technology in TIBCO BusinessWorks (XSLT) has mechanisms for iteration and looping,
which makes it possible to iterate through data within the mapper using the statement xsl:for-each or
xsl:for-each-group instead of using a group around the mapper. This obviously does not apply if
multiple activities must execute within each iteration.
If the mapper is the sole activity, it is much more efficient to use the mapper and utilize xsl:for-
each, instead of placing the mapper in a group and using the “accumulate output” feature of the
group.
Use of Variables
One of the single most important optimizations in the mapping activity and any activity that transforms
data is the use of variables. The mapper activity retrieves data at runtime by evaluating XPath
expressions and traversing the input tree to access the matching data. If the tree is large and the
mappings define many lookups of related or identical data, using variables to store that data can
improve performance significantly.
An example is a large number of records in an input tree that are processed one at a time.
The XPath for one output value in the mapper (contained in an iteration group) might look like the
following:
$JDBC-Query/resultSet/Record[$index]/field1
If this expression is repeated many times for multiple fields, it will be more efficient to create a variable
at the top of the mapper input pane (and generated XSLT) that evaluates the repeated portion of the
XPath ($JDBC-Query/resultSet/Record[$index]) and then use the variable as part of all
subsequent XPath expressions, such as:
$var1/field1
$var1/field2
$var1/field3
The benefits of using variables within the mapper will vary depending on how large the data is, how
complex the expression is, and how many times it is repeated. The mapper GUI makes this easy to
use. Using the mapper GUI, once one create the variable in the input pane, one will see it on the left
side with the appropriate schema representation to allow drag-and-drop mapping.
In TIBCO BusinessWorks 5.2, one can store the current iteration element in a process variable for
faster access during iterations.
4 Configurations
4.1 Configuring Persistent Connections
Persistent connections are created for each HTTP server that Send HTTP Request activities in process
instances communicate with. Each HTTP Client holds a persistent connection until the HTTP server sends the
response message. The connection is then released by the client and returned to the pool.
It is possible specify the maximum number of connections to create in the persistent connection pool, and It is
also possible to specify the maximum number of persistent connections for each HTTP server. Connections for
each HTTP server are created in the pool until the maximum is reached.
When a Send HTTP Request activity requires a connection, the pool is searched for a connection that
corresponds to the HTTP server. If a corresponding unused connection is found, it is used. If no connection is
found to a corresponding HTTP server, a new connection is created if the maximum pool size has not been
reached. If the maximum number of connections for that particular server has been reached, the request must
wait for a connection to be released before using it.
bw.plugin.http.client.usePersistentConnectionManager
This property specifies that a pool of HTTP connections to each HTTP server should be created so
that connections can be reused by Send HTTP Request activities. Not all HTTP servers support
persistent connections. Refer to oner HTTP server documentation for more information about support
for persistent connections.
When this property is set to true, a pool of connections is created for each HTTP server that the HTTP
(SOAP/HTTP) Request-Reply activities connect to. The total number of connections in the pool is
limited by the bw.plugin.http.client.maxTotalConnections property. The number of
connections for each host is limited by the bw.plugin.http.client.maxConnectionsPerHost
property.
The default value of this property is false.
bw.plugin.http.client.maxConnectionsPerHost
bw.plugin.http.client.maxTotalConnections
bw.plugin.http.client.checkForStaleConnections
bw.plugin.http.client.ResponseThreadPool
The HTTP (SOAP/HTTP) client uses a thread pool for sending the HTTP messages. Each HTTP
request is sent out in a separate thread in order to not keep the engine’s thread blocked while waiting
for the response message. These threads are taken from a thread pool. Each HTTP (SOAP/HTTP)
Request-Reply activity has its own thread pool. The thread pool’s size can be configured using this
property.
The default value for this property is 10.
To change these values, add the appropriate property to the bwengine.tra file. When one deploy
oner project using TIBCO Administrator, these properties will automatically become part of the
deployment configuration.
Issues: We strongly recommend that one define a well-defined naming & usage convention for Global Variable
across oner project(s). One must take following issues under consideration before designing “Global Variable”
naming convention.
1. Once global variable is set into the repository it is loaded when business process engine is loaded. Currently
BW doesn’t provide any facility to modify “global variables”, once process engine has been started.
2. Location Independence/Dependence: Special care must be given to certain parameters such as RV
Subjects, RVCM ledger file, and HTTP Port. These parameters may have dependency with migration
environment or machine.
3. Deployment doesn’t allow “Global Variable” substitution yet.
4. Grouping Related GV is easy from Deployment and maintenance aspect of a process.
Process Variables
Though this concept is not available out of box, the utility function introduced with “BWTemplate” provides a
mechanism to specify process specific variables. This service provides a mechanism to read process-specific
properties into memory at initialization time and these properties can then be used through out the process
using x-path functions. Two properties named PTY_LogLevel and PTY_PublishLogLevel are crucial in defining
the way logging is done using the Logging service and these properties are initialized from the property file or
default to global variables if they are not defined within the property file. For more details please see TIBCO
BusinessWorks Common Utility Services(1)
5.1 Grouping & Sub-grouping Rules
Grouping Related GV is easy from Deployment and maintenance aspect of a process.
Choose the repeating element in the Activity Input schema that holds the grouped data. For-Each-Group is a
shortcut to create a For-Each-Group statement with the repeating element as a child element and a Grouping
statement to contain the element you wish to group-by.
Adding the Grouping statement creates the $=current-group() element in the Process Data area. The Grouping
statement creates the list grouped by the desired element, and the current-group() function allows you to
access the items in the Requests repeating element that correspond to the group that is currently being
processed.
In a reverse excersise if a repeating element is coming and the index is known then the element at a particular
index of the repeating element can be determined using the xpath.
Use leading upper case for resources (e.g. ProductNameType) including first letter
The name should not have spaces
First letter must be “Alphabetical” and “Upper Case” Only.
The purpose of this “File System” structure is to provide a uniform referencable external
resource location such as property, log, input/output data, static maps, schemas, unit test,
and message correction file locations.
6 Logging
6.1 Logging Rules
Application Specific success or failure should be logged
System Specific startup shutdown error should be logged
Process Specific log for each instance
Obey the format of logging.
No Extensive logging as it hinders performance
7. Utility Services
These covers the most granular processes and utilised/referenced from main business process.
Example : a common query interface getting used at different business processes within a project
The errors or fault can be categorized into mainly Internal Exceptions, System Exceptions,
Business Exceptions ,Components Exceptions. Each exception is maintained with a code and
description in XML flat file or in Database. The Exception , the process id causing the exception,
time stamp of exception generated can be well traced and monitored. A utility service can be
designed to report the errors(system, application, activity, component related ) or exceptions to an
audit interface which usually mails and stores the details from which an Audit report can be
generated. The fault messages can be audited and the message can be remediated based on the
requirement further.
Hawk and micro agents can well monitor the Process and the Logs generated to report the exception
in form of a mail, alert or it can restart a failed job.