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 releases previous to 12.1.0.3, a variety of observers were provided for installing into WebLogic 10.3 servers. Each type of observer contained a set of probes that gave it the ability to monitor a particular set of component types. For example, the JavaEE observer contained probes for monitoring JavaEE components and the SOA observer contained probes for monitoring SOA components. Starting with release 12.1.0.3, only a single “universal” observer is provided for installing into WebLogic 10.3 servers. This universal observer contains a superset of all the probes contained in the older observers, making it capable of monitoring the superset of component types that were previously monitorable.
After you upgrade to the universal observer, your system will have the ability to discover and monitor new types of components. This enhanced capability might result in the discovery of new objects and could impact your ability to view and monitor transactions as explained below.
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.
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.
The release 12.1.0.4 universal observer for WebLogic 10.3 provides these new probes:
SOA_WORKFLOW – Monitors Oracle SOA Human Workflow components and notifications.
SOA_DIRECT – Monitors direct binding calls between SOA composites and between SOA and Oracle Service Bus.
After upgrading to an observer that contains new probes, the probes are immediately available in all new Observer Communication policies that you create. However, the probes are not automatically added to your existing policies. If you want to use one of the new probes in an existing policy, you must manually add it to the policy. For information on how to add a probe to a policy, see Adding Probes.
Once activated, the new probe types will discover new types of components. If any of these newly discovered components are called within the flow of a transaction that you have defined, then complete monitoring of the transaction will no longer be possible. Monitoring of the transaction will end at the newly discovered component.
In order to monitor the complete transaction, you must edit the transaction in one of this ways:
Return the transaction to its original state by manually keying the disjoined nodes back together.
Enlarge the transaction by adding the newly discovered component as a new node in the transaction and then connecting it to the disjoined nodes.
Upgrading your central servers and monitors adds a new JMS option to the Model Configuration section of the Advanced Settings for all new Observer Communication policies that you create (existing policies are not affected). By default, this new JMS option is set to Model Edge of Flow. At this setting, only JMS topic message listeners are modeled. If you want to model all JMS topics, JMS queues, and their associated message listeners, then you must edit the JMS option and set it to Model All.
For more information, see the Model Configuration entry
Release 12.1.0.4 provides a new and significantly improved JMS probe for WebLogic that replaces the JMS probe found in earlier releases. The new JMS probe is contained in these observers:
Universal Observer for WebLogic 10.3
JavaEE Observer for WebLogic 12.1
After you upgrade the central servers and monitors, they will be compatible with both the new and old JMS probes. You are not required to upgrade your observers, and, if you don't, they will continue to perform as before. You are also permitted to run a mixed system in which some of your observers are upgraded and some are not. However, we highly recommend that you upgrade all of your observers.
Once upgraded, your observers will rediscover the JMS components in your system and model them as new types of JMS services. Queues and topics are modeled as services of type JMS Resource, and message listeners are modeled as services of type Message Listener. Your old JMS services (discovered by the old JMS probe) will continue to be displayed but will not register business traffic flowing through the system. These old services are of type JMS Message Consumer. You should unregister these old JMS services.
Transactions that include any of the old JMS services will cease to function correctly. You should delete these old transactions and redefine them using the newly discovered JMS services.