Role of vcrepo.dat in TIBCO

TIBCO Designer generates a file named vcrepo.dat in the project root directory when we first save the project.

This file is used to store properties like display name, TIBCO Rendezvous encoding, and description.

This file can also be used for identification in place of the project root directory and can be used as the repository locator string (repoUrl).

Below are contents of one sample VCRepo.dat file for project name MyProjectHelloWorld created using TIBCO Designer version 5.7.4-

<?xml version="1.0" encoding="UTF-8"?>

<repository version="2" commitCount="1">

  <instanceInfo>

    <instanceInfoProperty name="displayName" value="MyProjectHelloWorld"/>

    <instanceInfoProperty name="version" value="5.7.4"/>

    <instanceInfoProperty name="rootDir" value="."/>

    <instanceInfoProperty name="instanceType" value="localFile"/>

    <instanceInfoProperty name="fileType" value="VC"/>

    <instanceInfoProperty name="creationTime" value="1357726054540"/>

    <instanceInfoProperty name="encoding" value="ISO8859-1"/>

  </instanceInfo>

</repository>

Role of inspector activity

The purpose of Inspector activity is to write the output of any or all activities and process variables to a file and/or stdout.

This is specifically useful when debugging process definitions and you want to see the entire set of schema instead of mapping specific elements to the Write File activity.

What does Success if no matching condition transition mean

What does ' Success if no matching condition' transition mean ?

Let’s say between two nodes N1 and N2, there are 3 success transitions with condition and there is no success transition without condition.

If none of the conditions match then a 'Success if no matching condition' transition can be used. Also if there is a success transition and also success transitions with condition and if the condition matches then both the success transition (no condition) as well as the transition(s) with matching conditions are followed. So you can use 'Success if no matching condition' to prevent duplicate paths of execution.

See below case, Exception will be generated in this case.

Wait-notify resources working

What is use of ait notify resources in TIBCO ?

 

Basically wait and notify should share a common notification configuration which is just a schema definition for data that will be passed from notifier to waiter.

 

Notification configuration with KEY:

 

Specific instances of waiter & notifyer are correlated via a key.

 

For example:

If one process is in wait state for key 'Key123', it waits till another process issues a notification with the same key value.

 

Waiting Process:

 

Notifying Process:

 

Purpose of Lock shared configuration resource in TIBCO

What is the purpose of Lock shared configuration resource in TIBCO BW?

 

A Lock is specified for a 'Critical Section' group when the scope is 'Multiple'.

If synchronization is for process instances belonging to the same process definition inside one engine, just specify the scope as 'Single'.

It can be used to ensure synchronization across process instances belonging to multiple process definitions or for process instances across engines.

One can check multi engine flag for lock in this case and the BW engine needs to be configured with database persistence while deployment.

Use of grouping activities in TIBCO

What is use of grouping activity in TIBCO ?

Grouping activities are used for:

1. To Generate a set of activities having a common error transition.
2. Replicate group of activities based on a condition.
   1. - Iterate over a list.
   2. - Iterate until condition true.
   3. - Iterate on Error until condition true.
3. Group activities into a transaction.
4. To create a critical section area that synchronizes process instances.
5. A 'Pick First Group' permits you to wait for the occurrence of multiple events and proceed along a path following the first event to occur.

Below details from TIBCO helps to understand the usage of Pick First Group -

                     

Pick first groups allow process execution to wait for one or more events.

The first event that completes determines which transition to take to continue processing.

For example, as part of an order-entry system, when an order is placed, a check is made to see if the order can be filled from stocked inventory or from returned merchandise. Whichever system returns the information first is used to fill the order. If neither system returns the information about available inventory, the order times out and cancels.

 

 

Difference between Max jobs and Flow Limit and Thread Count

The below diagram from Tibco documentation gives good overview of concepts like Max jobs, Flow Limit, Thread Count, Activation Limit etc.

The process instances created are typically held in memory. However, this may not be the case if the following parameters are set:

Max Jobs:

If the number of process instances in memory have reached the value of Max Jobs, then the process instances created are temporarily held on a disk. These process instances will be moved back into memory when sufficient memory is available.

Flow Limit:

When set, this property limits the number of process instances that can be created. If the number of process instances being created exceeds the value of FlowLimit, the engine suspends the creation of new process instances. However, it continues executing the process instances in memory. The engine resumes creating new process instances when process instances, approximately half the value specified for FlowLimit, have completed.

The number of process instances that can be created in memory is also limited by the memory available on the machine and the memory allocated to the JVM on which the process engine executes.

ThreadCount:

The process instances in memory are executed by the BusinessWorks engine. The number of process instances that can be executed concurrently by the engine is limited by the maximum number of threads, specified by property ThreadCount. Threads execute a finite number of tasks or activities uninterrupted and then yield to the next process instance that is ready.

StepCount:

The engine property StepCount determines the number of tasks that are executed by a thread uninterruptedly. However, the exceptions to StepCount occur when the job is blocked or in a transaction. When a job is in a transaction, the thread will not be released even if the StepCount is exceeded. However, if a process instance is waiting or is in a blocked state, it can be paged out and the freed memory used to process another process instance.

Activation Limit:

Activation Limit can be set if a process instance that is blocked should remain in memory till completion. Setting the ActivationLimit affects the engine performance substantially.

Factors affecting performance of TIBCO BW

Below factors decides the performance of Tibco Activmatrix BW process during runtime, So one has to decide these resources very carefully –

Hardware - CPU, Memory and Disk resources

Java - JVM and JVM configuration

Engine -  Number of engines, number of threads, job creators, flow control, job pool, etc.

Job  - Job, Message size

Process Design - User scripts, sub-processes, inline processes, checkpoints, logging activities

External software - like relational DB, other TIBCO Software product 

In addition to the components above, the performance of the BusinessWorks engine is also affected by external factors such as

• rate of incoming messages,
• network latency,
• performance of external applications with whom BW processes communicate, and
• other OS processes that may be running on the system.

Various Types of Transactions TIBCO supports

TIBCO BusinessWorks offers a variety of types of transactions that can be used in different situations. You can use the type of transaction that suits the needs of your integration project. When you create a transaction group, you must specify the type of transaction.

Latest TIBCO ActiveMatrix BusinessWorks supports the following types of transactions:

•	JDBC Transaction
•	Java Transaction API (JTA) UserTransaction
•	XA Transaction
•	JMS Local Transaction

A transaction group can have only one transaction type. The activities that can participate in the transaction are determined by the transaction type, the configuration of the activity, and the type of the activity. For example, only JDBC activities whose JDBC Connection type is "JDBC" can participate in a JDBC transaction.

Below activities are supported in JTA Transaction

The Java Transaction API (JTA) UserTransaction type allows below activities to participate in transactions.

1. JDBC
2. JMS
3. ActiveEnterprise Adapter (using JMS transports)
4. EJB activities

Below activities are supported in XA Transaction

The XA Transaction type allows below activities to participate in transactions.

1. JDBC activities
2. ActiveEnterprise Adapter activities that use the JMS transport
3. JMS activities

Note:

**For JMS activities and ActiveEnterprise Adapter activities, request/reply operations cannot participate in an XA transaction.

**EJB activities cannot participate in an XA Transaction group.

Resources in the EAR file

An EAR file can contain below resources -

1.    Local project resources

2.    LibraryBuilder resources

3.    AliasLibrary resources files

4.    Files referred in CLASSPATH of the designer

5.    All the files under designer installation directory