Configuring event emitters to create new transactions

In IBM Business Monitor V8.5.5, you can use wsadmin commands to control whether Dynamic Event Framework (DEF) events are emitted in a new transaction or an existing transaction.

About this task

You can set up end-to-end monitoring of your business transactions, even if those transactions are composed of discrete processes from different products. You can then view the status of the end-to-end transactions on the generated dashboard.

By default, the Dynamic Event Framework is configured to deliver events into an existing transaction. If you want to deliver events so that they start a new transaction, you can make that happen by using wsadmin commands to change the default behavior.

Each cell has a Dynamic Event Framework configuration. That configuration is shared by the DEF component, which runs in every Java virtual machine in that cell. You can change the default transaction behavior for the DEF configuration to run in a new transaction for a specified event point key. For more information about event point keys, see Event point key and filter.

At run time, when the DEF configuration is reloaded, the transaction configuration is read and cached. After that point, when an event is emitted, its associated event point key is checked against all DefFilter objects that are contained in the DefTransactionRules inside the DefTransactionConfig object. If any event point filter matches the event point key, the existing transaction (if any) is suspended and a new transaction is started. After that, the event is emitted synchronously or asynchronously. If no event point filter matches the event point key, the existing transaction is used.

This procedure uses wsadmin scripting. For information about the wsadmin commands that are used in these scripts, see Commands for the AdminConfig object using wsadmin scripting.

Procedure

Create one DefTransactionConfig object for each event emitting cell that receives events from the event point key. This transaction configuration controls whether emission for an event point key runs in the existing transaction or causes a new transaction to start.
1. Connect to the wsadmin client by entering the following command:
```
wsadmin.bat -lang jython
```
```
wsadmin.sh -lang jython
```
2. Locate the cell identifier.
```
cellid = AdminConfig.list('Cell')
```
3. Create a DefTransactionConfig object.
```
tConfigId = AdminConfig.create('DefTransactionConfig', cellid, '[]')
```
Add DefTransactionRule objects. DefTransactionRule objects are container objects that provide a way to group sets of related event point filters for easier management.
1. Give the rule a name that identifies its use. In this example, the rule is named "newAll" because the rule specifies that all events from all applications will run in new transactions.
```
tRuleOptions = [['ruleId','newAll']]
```
2. Create the rule.
```
tRule = AdminConfig.create('DefTransactionRule',tConfigId,tRuleOptions)
```
Add event point filters. Repeat this step for each new filter that you want to add.
1. Provide the attributes for an event point filter. For each of the seven attributes, provide a specific value, or use an asterisk (*) to accept all values for that attribute. The values in the following example mean that all events from all applications will run in new transactions.
```
tFilterOptions = [['filterId','newAll-filter'],['appName','*'],['version','*'],['componentType','*'],['componentName','*'],['elementType','*'],['elementName','*'],['nature','*']]
```
2. Create the event point filter.
```
tFilter = AdminConfig.create('DefFilter',tRule,tFilterOptions)
```
Save the new DefTransactionConfig object.
```
AdminConfig.save()
```
Reload the configured event listeners to pick up the changes that were made in the previous steps.
1. Get a list of DefManagement names.
```
dmList = AdminControl.queryNames('type=DefManagement,*').splitlines()
```
2. Reload the configured event listeners for each item in DefManagementList. You can use a Jython loop structure in a script or run the commands individually, as in the following example for a three-cluster topology. Add more commands if there are more than three clusters.
```
AdminControl.invoke(dmList[0],'reloadConfiguredEventListeners')
AdminControl.invoke(dmList[1],'reloadConfiguredEventListeners')
AdminControl.invoke(dmList[2],'reloadConfiguredEventListeners') 
```
  In a single cluster environment, DefManagementList contains only one item.
```
AdminControl.invoke(dmList[0],'reloadConfiguredEventListeners')
```
3. Save the configuration settings again.
```
AdminConfig.save()
```

Example

This example puts together the configuration script for the cell that emits events. The DEF event listeners must be refreshed before this new configuration is applied.

cellid = AdminConfig.list('Cell')
tConfigId = AdminConfig.create('DefTransactionConfig', cellid, '[]')
tRuleOptions = [['ruleId','newAll']]
tRule = AdminConfig.create('DefTransactionRule',tConfigId,tRuleOptions)
tFilterOptions = [['filterId','newAll-filter'],['appName','*'],['version','*'],['componentType','*'],['componentName','*'],['elementType','*'],['elementName','*'],['nature','*']]
tFilter = AdminConfig.create('DefFilter',tRule,tFilterOptions)
AdminConfig.save()

Reload the configured event listeners:

dmList = AdminControl.queryNames('type=DefManagement,*').splitlines()
AdminControl.invoke(dmList[0],'reloadConfiguredEventListeners')
AdminControl.invoke(dmList[1],'reloadConfiguredEventListeners')
AdminControl.invoke(dmList[2],'reloadConfiguredEventListeners')
AdminConfig.save()

What to do next

If you find at some time that you must delete a DefTransactionConfig object, use a script such as this one:

remId = AdminConfig.list('DefTransactionConfig')
rem = AdminConfig.remove(remId)
AdminConfig.save()