What is the use of Check Point activity ?

To detect duplicate messages, it is important to place the Checkpoint activity before any activities that we do not want to execute more than once.

We must specify a value for the duplicateKey element in the Checkpoint activity input schema.

This value should be some unique key contained in the event data that starts the process.

How it works ?

For example, the TransactionID value is unique for all new orders.

The following describes the procedure for duplicate detection by the process engine:

1. An incoming message is received and a process instance is created.

2. Activities in the process instance are executed until the first Checkpoint activity is reached. The Checkpoint activity has a value specified for the duplicateKey input element.

3. The process engine checks the current list of duplicateKey values for a matching value.

a. If no process instance has stored the given duplicateKey value, the process engine stores the value and completes the Checkpoint activity.

b. If another process instance has already stored the given duplicateKey value, then process engine terminates the process and throws a DuplicateException.

Process Engine Properties for Duplicate Detection

The following process engine properties need to set in bin/bwengine.xml to control duplicate key detection.

• bw.engine.dupKey.enabled —

specifies whether duplicate detection is performed.

true (the default) - indicates the process engine will check for identical duplicateKey values.

false -indicates duplicateKeys when specified are ignored.

• bw.engine.dupKey.timeout.minutes —

 specifies how long (in minutes) to keep stored duplicateKey values.

The default is 30 minutes.

Value -1 indicates the duplicateKey values are deleted when the job completes.

Value 0 indicates to store duplicateKey values indefinitely.

Any positive integer greater than 0 indicates the number of minutes to keep stored duplicateKeys.

• bw.engine.dupKey.pollPeriod.minutes —

specifies the number of minutes to wait before polling for expired duplicateKey values.

AppManage commands Syntax

AppManage location C:\tibco\tra\5.4\bin>

Creating the configuration xml File from a deployed application..

AppManage -export -out C:\AUTODEPLOY\HOToStore.xml -app HOToStore/HOToStore -domain TIBADMIN -user tibco -pw tibco

Creating the configuration xml File from Ear File

AppManage -export -ear C:\AUTODEPLOY\HOToStore.ear -out

C:\AUTODEPLOY\HOToStore.xml

Deploy command using ear and config xml.....

AppManage -deploy -ear C:\temp\HOToStore.ear -deployconfig C:\temp\HOToStore.xml -domain TIBADMIN -user tibco -pw tibco

UnDeploy Command

AppManage -undeploy -app HOToStore/HOToStore -domain TIBADMIN -user tibco -pw tibco

Deploy command for deploying an application that is in the undeployed state

AppManage -deploy -app HOToStore/HOToStore -domain TIBADMIN -user tibco -pw tibco

Delete Command

AppManage -delete -app HOToStore/HOToStore -user tibco -pw tibco -domain TIBADMIN -force

What are the data storage files in EMS ?

The tibemsd server creates three files in "...\tibco\ems\bin\datastore" folder to store shared state.

File Name	Description
meta.db	This file records durable subscribers, fault-tolerant connections, and other metadata.
sync-msgs.db	When a queue or topic definition (in a configuration file) specifies that the destination is failsafe,  then the server stores its messages in this file (using synchronous I/O calls).
async-msgs.db	When a queue or topic definition (in a configuration file) does not specify that the destination is failsafe, then the server stores its messages in this file (using asynchronous I/O calls)

Fault Tolerance Parameters in "tibemsd.conf " file

ft_active
 

ft_active = URL

 
Specifies the URL of the active server. 

If this server can connect to the active server, it will act as a backup server.

If this server cannot connect to the active server, it will become the active server.

ft_heartbeat

 
ft_heartbeat = seconds

 
Specifies the interval (in seconds) the active server is to send a heartbeat signal to the backup server to indicate that it is still operating. Default is 3 seconds.

ft_activation

 
ft_activation = seconds
 

Activation interval (maximum length of time between heartbeat signals) which indicates that active server has failed. Set in seconds: default is 10.

This interval should be set to at least twice the heartbeat interval.
For example: ft_activation = 60
 

Note: The ft_activation parameter is only used by the backup server after a fault-tolerant switchover. 

The active server uses the server_timeout_server_connection to detect a failed server.

ft_reconnect_timeout

 
ft_reconnect_timeout = seconds
 

The amount of time (in seconds) that a backup server waits for clients to reconnect (after it assumes the role of primary server in a failover situation).

If a client does not reconnect within this time period, the server removes its state from the shared state files. 

The ft_reconnect_timeout time starts once the server has fully recovered the shared state, so this value does not account for the time it takes to recover the store files.

The default value of this parameter is 60.

How do you start the EMS server using command ?

Command to start EMS Server is    
 
tibemsd -config tibemsd.conf

Fire this command at location "C:\tibco\ems\5.1\bin>"