Model attributes

General

Profile

Name of the profile defined on the BTM tab.

x

Name

Name of the transaction pathway. The name must be unique. No character limit.

x

Description

Explanation or summary for this transaction pathway.

Host

Select the name of the host from the list. Any pathway-level statistics (service level agreements, transaction status) are published under this name. In most cases, this is the name of the first activity in the transaction pathway. It is not possible to define new Hosts here - you can only select hosts which are added to the Available Hosts on the Profile tab.

If you promote your profile and this host is not translated to a host known to this service set, it is left blank and must be configured for a valid model.

Icon

Select an icon to represent this transaction pathway in the Logical tree. Click [Add Icon] to add external PNG format icons.

Aliasing (See Aliasing)

Use Aliases

Select if the transaction ID changes from one activity to another or deferred filtering is needed for an activity.

Also consider whether you need to select Alias on the Activity Properties > Transaction Payload Data tab.

a

Create fragment transaction delay

The default time to delay is 300 seconds (five minutes).

The amount of time to wait for a pending alias ID to be associated with other fragments before publishing the fragment under its own transaction ID. When it is published it becomes available to views and any trend or history reports.

As the transaction passes through, some fragments are published to the TMTM Topic Service quicker than others. The TMTM Topic Service attempts to connect all of the fragments together as quickly as possible, but under some circumstances (for example, network outage between the TMTM Extensible Agent and TMTM Topic Service or a large batch) some alias identifiers is not be associated with the transaction ID in a timely manner. If this occurs, the fragment receives its own transaction ID and becomes a unique transaction in the transaction table.

Different technologies (WebSphere MQ, WebSphere Message Broker, APIs) use different mechanisms for associating the alias identifiers to each other, and ultimately to a single transaction ID.

Therefore, the Create Fragment Delay option tells the TMTM Topic Service to hold the fragments in its memory. After the delay, the fragment is published to the table and the fragment gets its own (and new) transaction ID. If history is enabled, then these new transactions are also added to the database (just like any other transaction).

If you set this value too small, you might not allow the TMTM Topic Service enough time to connect the fragments and therefore create many new transactions. This affects the transaction table if Transaction Table Live Updates is selected, but also the TMTM History Service and database, TMTM Event Service, and any child object summary tables you might have. If you set it too large, then the TMTM Topic Service memory use increases.

x

Use Aliases From History When Necessary

For transactions that take a longer period of time it is possible that previous fragments have been created and preserved in history. This option causes history to be queried with the known aliases of a new fragment that is about to be created to determine whether it can be published using the transaction identifier of the fragment in history causing them to be combined.

x

Summary/SLA/Activity metrics

For transaction pathway-level details refer to Model SLA Metrics and Totals.

Summary Metrics

Check to enable Summary Metrics collected on the entire transaction pathway, activities, paths and touchpoints.

Summary Metrics must be enabled when used as Key Performance Indicators (KPI). See the Key Performance Indicators (KPI) section.

x

Publish Interval

The interval on which Summary, SLA, and Activity Metrics are published.

Summary Metrics History Templates

Allows history collection of the summary metrics allowing use of reports and trend charts.

x

Transaction Display

Remove Transaction Delay

Time to delay before removing a transaction from the live transaction table after completion. The default is 300 seconds.

The longer the delay, the more memory that is used to keep the transaction in the view and application service. The delay is best used for lower volume environments that have a short existence and require a delay for viewing.