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.
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.
The legacy and Scope models differ in how they support various use cases. The legacy model supported two use cases:
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.
When we migrate your application, you can expect the following:
To satisfy the original two use cases outlined above in the Scopes model:
Review the documentation below for instructions: