Business Transaction Management aims to provide the simplest process possible for upgrading from the 12.1.0.2 release.
The upgrade process seeks to minimize downtime while preserving management configurations, object definitions, and existing operational data.
For a detailed description of the process used to back up and upgrade your system, please consult the Business Transaction Management Installation Guide.
This section describes the changes introduced in this upgrade that might affect the ability of Business Transaction Management to monitor your transactions and to secure communications. You should read through these sections to make sure you understand how changes to the product might affect your transaction definitions and the ability of Business Transaction Management to observe and monitor your transactions. After you upgrade, we recommend that you run some traffic and audit your transaction instances to make sure the system is observing and monitoring your transactions as you expect it to. If it is not, you might need to adjust observer communication policies, update transaction definitions, or add manual keying between nodes as appropriate to your situation.
If, after reading through the following subsections, you are still unclear about the implications of upgrading to the 12.1.0.3 release, please open a service request with Oracle Technical Support.
In previous releases, a variety of observers were provided for installing into WebLogic 10.3 servers. Each type of observer contained a set of probes that allowed it to monitor a particular set of component types. The current release provides one single universal observer that contains a superset of all the probes contained in the older observers.
After upgrading to the universal observer, your system will be able to discover and monitor the following probes: ESS, WEB_APP, OSB, SOA, EJB, RMI, JDBC, JMS, JAX-RPC, JAX-WS, and Java probes. All probes are on by default except for the JDBC and Java probes. This might result in more objects being observed and monitored than before the upgrade. This can impact your ability to view and monitor transactions as follows.
If you have a transaction A -> B -> C, and the newly observed operation is B1 (the resulting call chain is A -> B -> B1 -> C), two outcomes are possible, depending on the means of correlation used:
Auto-correlation: Operation C will be shown in gray. If there is a missing message condition defined from B to C, you will be alerted. You will need to redefine the transaction to make C visible and to have the transaction be monitored. In those rare cases where the message from A to B to C does not change, the system will continue to observe and monitor C.
Manual-correlation: Operation C will be visible and correlated to B. The newly observed operation B1 will be visible in the dependency graph, but not in the transaction definition. You will need to redefine the transaction to make B1 visible. In this case, the transaction will be monitored, but B1 will not be included in it.
During the upgrade process, the values in existing observer communication policies are carried forward. This means that if an existing policy has most of its probe fields activated and you upgrade to the WebLogic universal observer and the application server hosts component types that weren't discovered before but are of a type for which there is now an activated probe, then these will be discovered and monitored.
To limit the number of components discovered and monitored to those of interest, before upgrading, you might want to review and adjust the active probes in your observer communication policy. To check your work and determine the changes introduced by the use of the universal observer, you should audit all transactions that contain operations running on WebLogic 10.3 containers.
In addition, note that JDBC is now off by default. This might result in fewer objects being monitored than desired. Be sure to audit transactions that contain JDBC components.
Information about observers is provided in About Observers. Instructions for upgrading observers are provided in the Business Transaction Management Installation Guide.
Depending on the underlying technology, some messages flow directly from a client to a service endpoint; others flow through a host of intermediate endpoints before they reach their actual destination. Such intermediate endpoints might comprise the implementation of a messaging system, a job scheduling system, a distributed system, and so on.
When installing probes for technologies that use intermediate endpoints, Business Transaction Management allows you to specify whether you want to monitor all endpoints or just the endpoints at the edge of such systems; often these are the endpoints that directly represent the business services of interest. In the current release, by default, the monitoring of intermediary endpoints is turned off. This improves monitoring performance and eliminates data that is not essential to monitoring your distributed applications.
If you are upgrading from a system where the monitoring of intermediate endpoints was turned on, Business Transaction Management retains the knowledge of these endpoints after upgrading to the new default setting. You will be able to see these endpoints in the dependency graphs; they will be grayed out in the transaction graphs. You can edit your transaction definitions to remove these endpoints.
As the default setting implies, we recommend turning off the monitoring of intermediate endpoints.
For more information on limiting discovery, see Limiting Discovery.
The current release of Business Transaction Management introduces observer authentication and sets SSL on by default for communication between observer and monitor. These features are described in the Business Transaction Management Installation Guide. In the current release, if you create a new observer communication policy, client authentication and SSL is on by default.
Upgrading your system should not affect expected behavior in most cases. Combining old observers with new communication policies is the one case that will affect communication between observers and monitors as explained below.
An existing observer is communicating with a monitor that was not using SSL. When you upgrade, nothing changes. The new observers will behave like the old observers. To change behavior, edit the observer communication policy to add SSL or observer authentication.
An existing observer is communicating with a monitor over SSL. When you upgrade, this will continue to work the same way. If you wish to add client authentication, you must edit the observer communication policy to do so.
You have an old observer in the field, and you upgrade the central server and monitors. If you then create a new observer communication policy that applies to the old observer, the old observer will fail because it will not be able to authenticate to the monitor, and the monitor will not be able to recognize anything the old observer is sending to it. If a new observer is available and you want to use client authentication, install the new observer. If a new observer is not available, turn off authentication in the observer communication policy.