Table of Contents
Background
Prior to v4.3, customers used the legacy transaction model to configure Business Transaction (BT) entry points for each application. In v4.3, we introduced the Scope model to make it easier to do this at scale and made it the default way to configure all new applications.
While any application created after v4.3 automatically uses the Scope model, those created prior to v4.3 are still using the legacy model unless you manually changed the config to the Scope model.
What is changing?
As part of our transition from Adobe Flash to HTML, we will be deprecating the legacy transaction config model and UI in the near future. At that time, we will automatically migrate all existing applications (i.e., those created prior to v4.3) to the newer Scope model.
Approximately 60% of our SaaS and on-prem customers’ applications were created prior to v4.3 and will be migrated. If you created an application prior to v4.3, please read the sections below to see how this will impact you.
How do the models differ?
The legacy and Scope models differ in how they support various use cases. The legacy model supported two use cases:
- Configuring all tiers in an application.
- Configuring each tier in an application individually.
As environments are becoming more complex, a third use case has emerged: configuring groups of tiers differently within the same application. For example, you may want to apply a rule to 4 of the 10 tiers in an application.
In the legacy model, this new use case was cumbersome because it required administrators to manually copy the configuration to each individual tier in the group. The Scope model better supports this use case because you can bundle tiers into “scopes” and apply a rule to the scope with fewer steps. For a visual of how this works, click here.
How does this affect me?
When we migrate your application, you can expect the following:
- Application-level rule configurations will apply to the Default Scope (i.e., all the tiers in the application).
- If you have tiers with custom detection rules, we will create tier-specific scopes with those configurations and exclude them from the Default Scope. The scope name will be the same as the tier name.
- Custom auto-detection settings will apply to the auto-discovery rule for the corresponding agent type (e.g., the Java Auto Discovery Rule or the .NET Auto Discovery Rule).
- The Default Scope has an auto-discovery rule for every agent type. Tier-specific scopes only have the auto-discovery rule for the tier's known agent type.
- Custom match rules will not change - they’ll just be migrated to the appropriate scope.
What steps do I need to take?
To satisfy the original two use cases outlined above in the Scopes model:
- Configure all tiers in the application: Apply rules to the Default Scope, which contains every tier in the application.
- Configure each tier individually: Create a custom scope with a single tier in it, then apply rules to that Scope.
Review the documentation below for instructions:
The 7/12/22 revision only corrected formatting issues introduced by
our recent platform update. No content was changed.
