Instance ID
The section describes the fields on the Transaction Instance tab of the Activity Properties.
If a technology processes a transaction more than once at a monitoring point (such as a loop, batch transaction, or multiple replies) each time the message is processed it must be identified using a unique instance ID so that each loop iteration or batch segment can be uniquely time-stamped for analysis. Automatically detects whether a loop exists in the transaction pathway, but you must manually configure whether this activity handles batch segments or multiple replies. Can automatically create a unique instance ID, but whenever possible a value from the message should be used for several reasons. First, an identifier that you select can help you understand the transaction better. Second, if the identifier is the same across several activities in a loop, analysis of the transaction is more accurate.
The following table lists the required and optional fields to configure instance IDs for this activity. See also Instance-IDs.
Field name | Description | Rqd |
|---|---|---|
Within a process loop | Automatically selected if the activity has a loop. It cannot be selected or cleared. The only way to change whether it is selected (or not) is to modify the transaction pathway so that the activity has a loop (or clear the loop from the transaction pathway to clear this field). You can configure loop and instance ID details for a specific monitoring point, too. For details, see Overriding an activity's association configuration. | a |
Manipulates batch segments or multiple replies.... | At least one instance ID is required because this activity processes batch segments or multiple replies, or a unit of work is repeated or rolled back. Uses the last update at the time of analysis to report the status of a transaction (unknown, pending, timed out, failed, and so on). Depending on the timing when a unit of work repeats, can occasionally report what appears to be inaccurate information. For example, might report several transactions as successful followed by a failed transaction. Later the transaction that failed is rolled back and repeated with a different instance ID, and this time is successful. It is not that a different instance ID caused it to succeed (or fail). Rather it was the timing of when captured the data. |
|
User-defined instance IDs | Select if you want to define your own instance IDs instead of having assign one for you. In comparison, auto-generated instance IDs are useful for transactions that might get rolled back and repeated. |
|
Message Format | Name of a message format created on the Message Formats tab. Select a message format from the list. The list is populated from the default and custom message formats from the Message Formats tab. The last format listed is Technology Data. When selected the Message Field contains a list of technology data fields available to the activity's technology. If the technology data is not visible, make sure it is enabled. | b |
Message Field | Name of the message field you want to reference. The list of available fields for the message format you chose. The available fields change based on which message format you select. For details about each of the available options, refer to the documentation for message formats (Message format fields) and for WebSphere MQ (MQMD, MQDHL (dead letter header), and MQXQH (transmission queue header)) and WebSphere Message Broker (WMB Exit MQMD and WMB MPN MQMD). | x |
Indices | Identifies which index should be used for the message format data. Refer to your message format and the details about message formats to determine which index or indices you should use. | x |
Delimiter | Character used to separate the individual items in one message format from the next message format. You can have different delimiters between your various message formats, and might be necessary. |
|
- Required if the activity contains a loop.
- Required if user- defined is checked.