Business Transaction Management aims to provide the simplest process possible for upgrading from the 11.1 and the 12.1.0.0 release of Business Transaction Management to the 12.1.0.2 release. You need to read the material in this section only if you are upgrading from the 11.1 version.
The upgrade process seeks to minimize downtime while preserving management configurations, object definitions, and existing operational data. It warns you of incompatibilities discovered during upgrade, and it allows you to resolve compatibility issues following the upgrade.
This section examines the issues that you must address in accessing older data and in resolving any compatibility issues that arise from the upgrade.
For a detailed description of the process used to back up and upgrade your system, please consult the Business Transaction Management Installation Guide. The issues discussed in this section become visible after the upgrade, when you restart the Business Transaction Management components: the sphere, the transaction server, and the performance server.
To make sure that no data was lost during the upgrade, you might want to follow the instructions in the next two sections to make sure that historical data is still available. Barring unforseen problems, no historical data should be lost during an upgrade.
To view historic measurements for an object that was monitored before the upgrade, do the following:
Select the object in the main pane, and open the tabs area.
Click the Analysis tab.
Use the time control to look at performance data for the period prior to the upgrade.
To view historic data for service usage that was monitored before the upgrade, do the following:
Select Explorer > SLA Policies and make sure the SLA policy associated with the data sought is listed.
Return to Explorer > Services to Endpoints, and select the object of interest.
Use the Analysis tab or the SLA Compliance tab to view usage data for the time period preceding the upgrade.
Please read the following sections to familiarize yourself with changes that might require you to redefine policies, transactions, and conditions.
The current version of Business Transaction Management no longer allows segmentation to be defined for a service, only for a transaction. To continue monitoring usage SLAs, you must define these for a transaction that includes the service of interest.
Business Transaction Management seeks to upgrade existing transactions. If it encounters features that are not compatible with the current release, it disables these transactions and adds a system alert that describes the problem. If it encounters a condition that is not compatible with the current release, it disables the condition and adds a system alert that describes the problem. To view system alerts, select Alerts in the Last Hour > System Alerts.
After taking corrective action, remember to check the status of the transaction or condition. If it is disabled, you will also need to re-enable it.
Business Transaction Management no longer allows you to define conditions for a service, only for a transaction. If a service condition is encountered during upgrade, Business Transaction Management turns it into a one-service transaction, disables it, and issues a system alert.
To resolve this situation, you should incorporate the service into a larger transaction. You can also choose to leave it as a one-service transaction and re-enable it.
To improve its ability to monitor a large number of services, Business Transaction Management places certain restrictions on condition definitions. These restrictions might cause existing conditions to be evaluated as invalid during the upgrade. Business Transaction Management disables such conditions and issues a system alert for each. Here are the actions you can take to resolve these situations. Note that some conditions might be invalid for more than one reason.
A content-based condition must be based on a property value. If you have a pre-upgrade condition based on message content rather than on a property value, Business Transaction Management might be able to create a property for the content and define the condition based on the value of that property. In this case, you might see properties defined for a service that you have not defined yourself.
A content-based condition can depend on Business Transaction Management checking the content of only one message. If you have a pre-upgrade condition that checks content of more than one message, you must redefine it to check the content of only one message.
A missing message condition must have the start message as the trigger. If you have a pre-upgrade missing message condition that defines another message as the trigger, you must redefine the condition to set the start message as the trigger message.
Upon upgrade, all existing transactions will be set to gather performance measurements even if they were not configured to do this.