Configure Business Transaction Detection

To add a match rule, click Add match rule. To edit an existing match rule, click Edit match rule.

Match Rule Types

The following match rule types are supported:

Business transaction context relates to how business transactions are processed. Business transactions with context are processed in real-time, while business transactions without context are reconstructed from logs. Both categories have some advantages and limitations.

Business Transaction With Context

Business transactions produced by real-time instrumentation create a BT context that persists during the lifetime of a business transaction.

BT context is needed for:

• Standard SQL and ABAP trace, see Configure Snapshot Settings.
• Custom Actions.
• Custom RFC Exit Calls.
• Correlation with downstream agents via HTTP client calls.

Real-time business transactions have the following limitations:

• RFC Exit Calls work only via Custom RFC Exit Calls.
  • One exception is OData instrumentation where RFC correlation between frontend and backend system is supported. See Instrument NetWeaver Gateway.
• Correlation with ST22 and update errors is not supported.

Business Transaction Without Context

Business transactions that are reconstructed from logs do not create a BT context and don't support features that rely on it. Logs used for BT reconstruction contains additional information that enables extra functionality that is not supported:

• RFC calls are reconstructed as exit calls.
  
  • Only one RFC call step from source to target system is reconstructed. If the call continues on the target system to a third system, it is not reconstructed.
• Correlation with ST22 and update errors is supported.
  
• See Monitor SAP Dialog Transactions.

Reconstructed business transactions have the following limitations:

• See list of features that require a BT context.
• Standard SQL and ABAP trace are not supported. Proactive traces are now available for reconstructed business transactions, see Configure Snapshot Settings.
• HTTP exit calls are reconstructed, but the business transaction is not continued in these exit calls.

SQL statements on HANA

When the SAP system uses HANA DB and HANA expensive statements are enabled, Top 5 SQL statements will be available for all business transaction types and snapshots as long as the statements are recorded by the HANA expensive statements mechanism.

Generate Default Match Rules

As of version 21.8.0, a new match rule table button for the generation of default automatic discovery match rules is available. This functionality is intended for faster initial setup on testing environments. It is not recommended to use the generated automatic discovery match rules in production environments.

Copy Match Rules

As of version 23.2.0, a new match rule table button for copying existing match rules is available. This functionality makes the creation of custom match rules more flexible. Simply select one of the table rows, press the Copy match rule button, and the match rule and all of its contents and settings will be copied into a new match rule.

Add Match Rule

Define a custom match rule or an automatic transaction discovery of a specified type. Automatic transaction discovery is a special match rule that automatically matches all inbound traffic of selected type, without the exclusion and the match detail options.

Automatic Discovery in Production Environments

Automatic Transaction Discovery match rules are intended mainly for non-productive environments. For productive systems, it is recommended to define focused sets of custom match rules. See Business Transaction Limits and Organize Business Transactions.

Match Rule Summary

A match rule consists of several settings. Match Rule Type is indicated but cannot be changed at this point. Match rules can be set to include or exclude business transactions. Include rules are always evaluated before the exclude rules regardless of priority.

The following table summarizes other configuration settings:

Configure Match Criteria

Match rule configuration depends on the match rule type:

Generic HTTP Match Rule

To configure a match rule:

1. Match by HTTP request method (GET, POST, PUT, DELETE), or leave it empty to not match by any HTTP request method. This value is not case-sensitive.
2. Select the match option from the following:

• • Equals - not case sensitive, has to be equal to compared value.
    Example - URI - “/sap/order/orderId={2145}” Equals - “/sap/order/orderid={2145}”
  • Starts with - not case sensitive, no wildcards, URI has to start with provided value.
    Example - URI - “/sap/order/orderId={2145}” Starts with - “/sap/order”
  • Ends with - not case sensitive, no wildcards, URI has to end with provided value.
    Example - URI - “/sap/order/orderId={2145}” Ends with - “{2145}”
  • Contains - not case sensitive, no wildcards, has to contain part of the URI.
    Example - URI - “/sap/order/orderId={2145}” Contains - “order”
  • Matches RegEx - case sensitive, URI must match provided regular expression.
    Example - URI - “/sap/order/orderId={2145}” RegEx - “\/sap\/order\/orderId=\{[0-9]*\}”
  • Is in list - not case sensitive, URI has to be in list defined with delimeter “,”
    Example - URI - “/sap/order/orderId={2145}” Is in list - “/sap/order/orderid={2145},/sap/order/orderid={2146},/sap/order/orderid={2147}”
  • Is not empty - matches any URI if its not empty

Also, set the URI pattern. The URI pattern is not case-sensitive and match by URI is mandatory. 

Optional

1. To add match rule detail, click Add match detail. 
   To edit existing match rule detail, click Edit match detail.
   

Match details check the value or existence of an HTTP parameter, header, or cookie. The values are not case-sensitive.

Set a match type and match value when checking a value, parameter, header, or cookie. In the example, the match value contains a value of HTTP parameter and is case-sensitive.
All match rule detail conditions must be met for a match to occur (AND-relation).

As of version 22.11.0, it is possible to check for the existence of an element or element’s value. This feature is supported if the HTTP request body is in the XML, JSON, or SOAPXML format. From the match detail dropdown menu, select the HTTP Body Element option.

• If you selected Existence simply use the name (or XPath string) of the element. The Match rule will match a specific HTTP request if the specified element is found in the HTTP request body.
  
  
• If you selected Value, use the name (or XPath) of the element and the expected value of that element (numerous operators are available - equals/contains/starts with…). The Match rule will match a specific HTTP request if the value of the specified element matches in the HTTP request body.
  
  

In both cases, values are not case-sensitive.

OData Service Match Rule 

1. Match by HTTP request method (GET, POST, PUT, DELETE), or leave it empty to not match by HTTP request method. This value is not case-sensitive.

   

2. OData service conditions are added like match rule details using Add match detail. Click Edit match detail to edit existing OData service conditions. This value is not case-sensitive. Standard F4 help is available for the OData service field.

   

   All OData service conditions must be met for a match to occur (AND-relation).

BSP Application Match Rule

 Match by BSP Application and BSP Event. This value is not case-sensitive. Standard F4 help and multi-selection are available for the BSP Application field. List of BSP applications and events are evaluated like a standard select option (OR-relation).

GUI transaction Match Rule

This match rule type is relevant for SAP dialog transaction monitoring. See Monitor SAP Dialog Transactions.

Match by Transaction Code, Report, Function Code (OK code), Reference Program, and Application Component ID. These values are not case-sensitive. Standard F4 help and multi-selection are available for Transaction Code and Application Component ID fields. All 5 lists are evaluated as a standard select-option (OR-relation).

Values in these fields are compared against corresponding fields of STAD records that are being evaluated (matched) for GUI transaction BT reconstruction.

Background job Match Rule

This match rule detects finished background jobs recorded in STAD logs. The resulting business transactions are registered as background tasks. See Monitor Background Tasks.

Legacy HTTP SDK

Legacy HTTP SDK does not contain functionality that automatically registers SAP background job BTs as background tasks. If you are using a Legacy build of HTTP SDK, please use the controller UI to manually switch the corresponding business transactions to background task type.

Matched by job name (name of the job that appears in SM37) and report that was executed. Standard F4 help is available for Jobname that can select a list of jobs from TBTCO (future/not-yet-defined jobs won’t appear in F4 help).

These values are evaluated against match rules (SM37 screenshots):

Incoming RFC Match Rule

This match rule reconstructs business transactions from RFC server calls. Data are extracted from STAD RFC server statistics.

This rule can be matched by:

• Function module: function module that was executed through RFC on the current system

• Source instance: name of RFC caller instance

• Source IP address: IP address of RFC caller

• RFC user: user that was used for RFC logon on the current system

These values are evaluated against STAD RFC server statistics:

Customer Interaction Center Match Rule

As of release 4.5.1908, a specialized rule for Customer Interaction Center (CIC0) is available for SAP IS-U systems. It's an extension for SAPGUI match rules, which allows splitting the CIC0 transaction into business transactions based on individual IS-U front-office processes.

When monitoring the Customer Interaction Center only using SAPGUI match rules, all business transactions are shows as CIC0. Therefore a further splitting is needed.

This type of match rule is only enabled when running the ABAP agent on an IS-U system.

To match individual front-office processes, fill the selection of the most critical process you need to monitor.

Configure Transaction Splitting

When transaction splitting is active, the naming of transactions matched by the match rule can be extended. Transaction splitting depends on the match rule type.

Generic HTTP Transaction Splitting

• First few URI segment(s)

• Splitting value: Number of segments (N)

• Transaction name: The first (N) of available URI segments separated by '/'. If less than (N) URI segments exist, the entire URI is used

• Last few URI segments(s)

• Splitting value: Number of segments (N)

• Transaction name: The same as the previous method, but instead of first (N) of available segments, the last (N) of available segments are used

• Specific URI segment(s)

• Splitting value: The list of segments separated by ',' (Example '1,5,4,13')

• Transaction name: The URI segments specified in the list of segments separated by '/'. Non-existing URI positions are ignored

• A parameter value

• Splitting value: GET or POST parameter name (case insensitive)

• Transaction name: "<transaction name base>." + value of parameter with specified name (if it exists in the request)

• A header value

• Splitting value: Header name (case insensitive)

• Transaction name: "<transaction name base>." + value of header with the specified name (if it exists in the request)

• A cookie value

• Splitting value: Cookie name (case insensitive)

• Transaction name: "<transaction name base>." + value of the cookie with the specified name (if it exists in the request)

• The request method

• No splitting value can be set

• Transaction name: "<transaction name base>." + request method

If any splitting method returns no value, the default transaction name defined by the match rule name is used instead.

OData Service Transaction Splitting

• OData service description
  • No splitting value can be set
  • Transaction name: Technical OData service name and OData service description text in the English language
• OData service technical name
  • No splitting value can be set
  • Transaction name: Technical OData service name

BSP Application Transaction Splitting

• BSP application name
  • No splitting value can be set
  • Transaction name: Technical BSP application name and the BSP application description text in the English language

If the splitting method returns no value and the match rule name is empty, the fallback name 'BSP' is used. 

GUI Transaction Splitting

• Transaction name (Tcode)

  • No splitting value can be set

  • Transaction name: Technical Tcode name and description text in the English language

• Application component

  • No splitting value can be set

  • Transaction name: Technical Application component name and description text in the English language

• Application sub-component
  

  • No splitting value can be set

  • Transaction name: Technical Application sub-component name and description text in the English language

If a splitting method returns no value, the default transaction name defined by the matching rule is used instead. If the match rule name is empty, GUI Unassigned is used.

Background job Transaction Splitting

• Background job name

  • No splitting value can be set

  • Transaction name: Technical name of background job as it appears in SM37

• Report

  • No splitting value can be set

  • Transaction name: Technical name of the report that was used in the background job

Incoming RFC Transaction Splitting

• Function module

  • No splitting value can be set

  • Transaction name: ‘RFC_<called function module>’

• Source instance

  • No splitting value can be set

  • Transaction name: ‘RFC_<caller instance name>’

• Source IP address

  • No splitting value can be set

  • Transaction name: ‘RFC_<caller IP address>’

Customer Interaction Center Splitting

• Front office process
  
  • No splitting value can be set
  • Transaction name: Front-office process name

Match Rule Settings

As of release 21.11.0, the option to customize settings for each match rule is added. This allows users to specify what is added to business transactions that are matched by the match rule. You can change if exit calls, or call graphs should be relevant for a business transaction, closer specify ABAP/SQL Trace options, or disable End User Monitoring correlation.

Settings can be found under the Rule Settings tab. The following two options are available:

• Global Settings - Default setting. Match rule specific settings are deactivated, and the resulting business transactions will use global settings as per Snapshot Settings. Exit calls and correlation will be turned on.
• Custom Settings - After selecting custom settings, users can set what information will be added to business transactions matched by this match rule.

Exit Calls

These options are used to set how exit calls are handled by business transactions spawned by the match rule. The options are relevant for all match rule types.

• Inactive - No exit call will be added to the resulting business transaction.

• Limited - No real exit calls will be generated. The business transaction instance will calculate runtimes of remote calls and combine them with remote call details into data collectors. Only the first 10 remote calls are reconstructed into data collectors (Exit Call 1 - Exit Call 10). This mode is not available for GUI transactions.

• Exit Call Only - Only exit calls are added to the resulting business transaction, but the exit calls will not be correlated with any downstream system/backend.

• Full - Default business transaction behavior. Exit calls will be added to the resulting business transaction and will be correlated with downstream tiers if possible.

ABAP Trace

These options are only available on SAP systems with version 740 or later. The settings are used to override the global ABAP trace settings. See Configure Snapshot Settings. The options are relevant for all match rule types.

• Off - ABAP trace will not be collected.

• Top 5 ABAP Statements - Top 5 ABAP statements will be added as data collectors into the resulting business transaction snapshots.

• Call Graph - ABAP trace will be added to the resulting business transaction snapshots in a form of a call graph.

• Both - Both top 5 ABAP statements and call graphs will be added to the resulting business transaction snapshot.

SQL Trace

These options are only available on SAP systems with version 740 or later. The settings are used to override the global SQL trace settings. See Configure Snapshot Settings. The options are only relevant for match rule types with BT context.

• Off - SQL trace will not be collected.

• ST05 - Top 5 SQL statements will be added to the resulting business transaction snapshot when ST05 SQL trace is collected. On HANA DB, when the ST05 SQL trace is not available, the top 5 SQL statements will be reconstructed from HANA expensive statements when available.

• HANA (only on HANA DB) - Top 5 SQL statements will be collected only from HANA expensive statements and added to the resulting business transaction snapshot. ST05 SQL trace is not used. HANA expensive statements must be enabled via HANA configuration and a meaningful threshold must be set in t-code DB02.

End User Monitoring Correlation

This option is used to suppress EUM correlation in business transactions spawned by the match rule. This option is only relevant for match rule types with BT context.

• Off - Turns off EUM correlation. User action collected under user monitoring will not be correlated to business transaction matched by this match rule.

• On - Default business transaction behavior.

Error Propagation

This option affects the way errors and exceptions are propagated during business transactions and exit calls.

• Off - Turns off error propagation. Errors and exceptions occurring during business transactions matched by this match rule will not be propagated to controller. Exit calls errors during BT are still propagated.

• Immediately - Errors are propagated immediately when BT is being processed. Turning this option on will distribute HTTP calls but due to synchronous nature of BT reporting, it may cause slight performance overhead.

• End - Default option. Errors are propagated at the end of BT reducing performance overhead.

Limit Transaction Detection for Specific Users

For testing purposes, you can set up an allowlist of users for which the business transaction detection is enabled.

Click the BT user filter in the AppDynamics settings toolbar. The following figure shows the sample list of usernames:

Business Transaction Limits

It is important to consider the business transaction limits for the Controller and App server agents. Business transaction limits prevent boundless growth of the business transaction list. The default limits are 50 business transactions per app server agent (node) and 200 business transactions per application. See Business Transaction Limits.

When the business transaction registration limit is reached or transaction lockdown is enabled, newly detected transactions are not registered as business transactions. However, they are monitored and reported by AppDynamics. The transactions are placed in a virtual business transaction group named All Other Traffic - tier_name. An All Other Traffic group exists for each tier on which the limit is reached. See Organize Business Transactions for more details.

Automatic downstream correlation with incoming traffic

From version 4.4.1812.0 onwards, incoming HTTP requests that contain a valid correlation header are automatically correlated and the business transaction is continued even without any Generic HTTP, OData, or BSP match rules. A match rule was needed to achieve this in previous versions.