This chapter explains how to perform an in-place upgrade of Business Transaction Management from any version of release 11 or 12 to release 12.1.0.7. Performing an in-place upgrade means that you upgrade components by simply replacing them with new components, without editing configuration settings.
A complete upgrade of Business Transaction Management consists of upgrading these components:
all three central servers—these are, the Main server (btmMain.ear), the Performance server (btmPerformanceServer.ear), and the Transaction server (btmTransactionServer.ear)
all monitors (btmMonitor.ear)
all observers
If any of these components are older than release 11, do not attempt to perform an upgrade using the instructions in this chapter. Instead, enter a service request at My Oracle Support (http://support.oracle.com) for assistance in upgrading your installation.
The order in which you upgrade the components of your Business Transaction Management system is important and depends on the release version of your installed components and on whether your observers are supported by the release 12.1.0.7 monitors. So, before proceeding further, complete these steps:
Take note of the release numbers of your central servers, monitors, and observers:
To determine the release of your installed observer, open the observer's NanoAgent.log file and search for the line that displays the release number, for example:
INFO: Release 11.1.0.4: build 25237 of b21 (11.1.0.4/147754) on 2011-05-13
For information about locating the NanoAgent.log file, see Chapter 14, "Logging Observer Errors and Debugging Information."
You can find the release number of your central servers and monitors in the README.txt file located in the nanoagent directory of the distribution ZIP file.
Determine whether your observers are supported by the release 12.1.0.7 monitors:
If your observers are release 12.1.0.2 or newer, they are supported.
If your observers are release 11.x, they are not supported.
If your observers are release 12.x, but older than 12.1.0.2, you must check the Business Transaction Management (BTM) Certification Matrix. You can find this document online at http://support.oracle.com. If your observer is listed in this document, then it is supported by release 12.1.0.7. If it is not listed, it is not supported.
Read the following scenarios to determine how to order the steps of your upgrade procedure, and then refer to Section 2.2, "Upgrading the Central Servers and Monitors" and Section 2.3, "Upgrading Observers" for detailed explanations of the upgrade steps:
If your central servers and monitors are at release 12.1.0.3 or newer and your observers are supported by release 12.1.0.7, then you can perform a rolling upgrade as follows:
Central Servers – Shut down all the central servers together, upgrade them, then restart them.
Monitors – Shut down the monitors, upgrade them, then restart them. You can upgrade monitors one at a time, or all together.
Observers – (Optional) Shut down the observers, upgrade them, then restart them. You can upgrade observers one at a time, or all together.
Central servers and monitors are old but observers are still supported
If your central servers and monitors are older than release 12.1.0.3 but your observers are supported by release 12.1.0.7, order your upgrade steps as follows:
Central Server and Monitors – Shut down all the central servers and monitors together, upgrade them, and then restart them.
Observers – (Optional) Shut down the observers, upgrade them, then restart them. You can upgrade observers one at a time, or all together.
Observers are no longer supported
If your observers are so old that they are not supported by release 12.1.0.7, then you can follow either of the following upgrade paths:
Shut down all the central servers, monitors, and observers together, upgrade them, and then restart them.
First, upgrade your observers to a release that is supported by release 12.1.0.7 but that is not newer than your monitors (observers must never be of a newer release than their associated monitors). Then, upgrade your central servers and monitors to release 12.1.0.7. Finally (and optionally), upgrade your observers to release 12.1.0.7.
After upgrading both the central servers and monitors, you should upgrade your observers, if possible. If your observers are older than release 12, you must upgrade them. If your observers are release 12 and still supported, then upgrading them is optional. Note that if you do not upgrade your observers, you cannot take advantage of new functionality that depends on upgraded observers.
Note:
The upgrading of central servers older than release 12.1.0.3 adds an observer authentication field to new Observer Communication policies that you create. This observer authentication field is enabled by default. If you want to use observer authentication, you must also upgrade your observers. Observers from releases older than 12.1.0.3 do not have the capability to authenticate themselves. If you don't upgrade your observers to at least 12.1.0.3, then you must disable the observer authentication field in any new policies that you create or else the observer will not be able to connect with the monitor.After you finish upgrading your Business Transaction Management system, read the online help topic named Functional Upgrade Issues. This topic provides information about upgrade-related tasks you might want to perform and about changes in behavior you should expect to see in your upgraded system. You can locate this topic by first choosing Help > Help in the Management console. After the online help opens, navigate to Overview of Oracle Business Transaction Management in the Contents pane, and then scroll down to the Functional Upgrade Issues section.
The Functional Upgrade Issues topic addresses issues such as:
Utilizing new probe types
Fixing broken transactions
Identifying and removing artifacts related to deprecated probes
Note:
Before beginning the upgrade procedure, we suggest that you deactivate your RMI probe unless you require monitoring of RMI calls. Most applications utilize RMI by way of higher-level APIs, such as JAX-RPC, JAX-WS, EJB, and JMS. If your application utilizes RMI only by way of these higher-level APIs, you should deactivate the RMI probe. However, if your application calls RMI directly, you should leave it activated.To deactivate your RMI probe, first open your Observer Communication policy. The Active Probes section of the policy provides an Enable Discovery and Monitor Upon Discovery checkbox for each type of probe. Deselect both of these checkboxes for RMI. If you are using multiple Observer Communication policies, you should perform this task for each policy.
After deactivating your RMI probe, you should unregister any RMI components that have been discovered. To unregister an RMI component, select the component (modeled as a service) in the Business Transaction Management Console and choose Modify > Delete Your_Service Registration, where Your_Service is the name of your RMI component. You can alternatively use the unregister CLI command. For more information, refer to the Business Transaction Management online help.
To upgrade your Business Transaction Management installation:
Back up your Business Transaction Management databases and configuration data.
For information on how to perform this task, refer to the online help topic Backing up and Restoring Business Transaction Management. You can locate this topic by first choosing Help > Help in the Management console. After the online help opens, navigate to Administration of Business Transaction Management > Backing up and Restoring Business Transaction Management in the Contents pane.
Note:
The central servers must be running in order for you to access the online help.Back up the persistent storage directories for each of the central servers and monitors.
For information on the locations of the persistent storage directories, refer to the online help topic Persistent Data. You can locate this topic by first choosing Help > Help in the Management console. After the online help opens, navigate to Administration of Business Transaction Management > Persistent Data in the Contents pane.
Ensure that all WebLogic domains in which the Business Transaction Management central servers and monitors are installed include the Java Required Files (JRF) template. (If you are upgrading a 12.1.0.3 installation, then you have already met this requirement.)
If any of these domains doesn't include the JRF template, extend the domain and add the template. You will get the following exception when you attempt to start the server if the JRF template is not included in the domain:
java.lang.ClassNotFoundException: oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
Note:
The JRF template is part of the Oracle Application Development Framework (ADF) runtime, which means that you must install the ADF runtime into your WebLogic installation before you can extend any domain with the JRF template. When installing the ADF runtime, take care to install the release version that matches your version of WebLogic. You can download the ADF runtime at:http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html
Locate the distribution archive that contains the Business Transaction Management central servers and monitor and unzip it into a directory (referred to henceforth as Install_Dir).
The distribution archive is named BTM_Servers_*.zip, where * is the Business Transaction Management version number.
Optional security step for UNIX-like operating systems – If you want to set permissions on the files that make up the distribution to the most restrictive level that still maintains functionality, complete this step:
Locate setPermissions.sh at the top level of Install_Dir.
This script contains commands for setting file permissions of all regular files to Owner – read/delete; all directories to Owner – read/execute/delete; and all scripts to Owner – read/execute/delete.
Note:
These permission levels are extremely restrictive, for example, only the owner can read the files.On a command line, at the top level of Install_Dir, run this command:
source setPermissions.sh
This command runs the commands in the script file and sets permissions for all files and directories in the expanded archive.
Upgrade the central server and monitor EAR files:
If you are upgrading from release 12.1.0.3 or newer, you can either upgrade all of your central server and monitor EAR files together, or upgrade all of your central server EAR files and then upgrade your monitor EAR files one at a time.
If you are upgrading from a release older than 12.1.0.3, you must upgrade all of your central server and monitor EAR files together.
To upgrade the central server and monitor EAR files together:
Shut down all of the central servers and monitors (btmMain.ear, btmPerformanceServer.ear, btmTransactionServer.ear, and btmMonitor.ear).
It is essential that you shut them all down.
For information about shutting down Business Transaction Management components, see Chapter 13, "Starting and Shutting Down Business Transaction Management."
Using your application server's deployment tools, redeploy each of the central servers and monitors using your new EAR files located in Install_Dir\archives.
Restart the central servers and monitors.
When upgrading from a release older than 12.1.0.7, restarting the central servers triggers the in-place upgrade of Business Transaction Management data. During this process, the system might suffer from reduced performance and some of the data might be temporarily unavailable. This process should complete within 30 minutes. If you are simply patching a 12.1.0.7 installation, your system should start up at its normal speed.
For information about starting Business Transaction Management components, see Chapter 13, "Starting and Shutting Down Business Transaction Management."
Notify all Business Transaction Management users to flush their web browser caches.
The Management Console contains a number of Adobe Flash widgets. Web browsers normally cache these widgets and will continue to use the older cached widgets until you either flush the cache or restart your web browser.
To upgrade the central server EAR files followed by the monitor EAR files:
Shut down all of the central servers (btmMain.ear, btmPerformanceServer.ear, and btmTransactionServer.ear).
For information about shutting down Business Transaction Management components, see Chapter 13, "Starting and Shutting Down Business Transaction Management."
Using your application server's deployment tools, redeploy each of the central servers using your new EAR files located in Install_Dir\archives.
Restart the central servers.
When upgrading from a release older than 12.1.0.7, restarting the central servers triggers the in-place upgrade of Business Transaction Management data. During this process, the system might suffer from reduced performance and some of the data might be temporarily unavailable. This process should complete within 30 minutes. If you are simply patching a 12.1.0.7 installation, your system should start up at its normal speed.
For information about starting Business Transaction Management components, see Chapter 13, "Starting and Shutting Down Business Transaction Management."
Notify all Business Transaction Management users to flush their web browser caches.
The Management Console contains a number of Adobe Flash widgets. Web browsers normally cache these widgets and will continue to use the older cached widgets until you either flush the cache or restart your web browser.
Shut down your monitors (btmMonitor.ear), redeploy them using your new EAR file located in Install_Dir\archives, and restart them.
You can perform this step for all monitors at once, or perform it individually for each monitor.
After you are finished with upgrading the central servers and monitors, and the system has settled down, you can optionally upgrade your observers by following the instructions in the next section.
You must upgrade the Business Transaction Management central servers and monitors, as described in the preceding section, before upgrading the observers.
Note:
This installation guide provides instructions for upgrading observers to versions that are included as part of release 12.1.0.7. If you want to upgrade an observer to a version from an earlier release, consult the installation guide from that earlier release. In particular, if you want to upgrade an observer for WebLogic 9.2, WebSphere, JBoss, or ASP.NET, consult the installation guide for release 12.1.0.2.2.The procedure for upgrading observers is specific to the application server and observer type. Refer to the following sections for detailed instructions on upgrading observers:
Note:
For detailed information about a specific observer's compatibility and functionality, refer to the README.txt file located in the observer's nanoagent directory after you expand the observer ZIP file.This section describes how to upgrade an observer installed into a WebLogic 10.3 application server.
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. In the current release, only two observers are provided for installing into WebLogic 10.3 servers—the ”universal” observer and the observer for Oracle Service Bus 10gR3. These observers are packaged in the following ZIP files:
BTMObserver_Wls_10.3_Universal_*.zip – This ZIP file contains the universal observer. Use this ZIP file to upgrade the following observers:
JavaEE observer for WebLogic 10.3
Oracle Fusion Applications observer
Oracle SOA Suite observer
Oracle Service Bus 11gR1 observer
The universal observer is capable of monitoring JavaEE, Oracle SOA Suite, Oracle Service Bus 11gR1, and Oracle Fusion Applications (ADF-UI, ADF-BC and SOA deployments).
BTMObserver_Wls_10.3_Osb11gR1_*.zip – Use this ZIP file to install the observer for Oracle Service Bus 10gR3 into a WebLogic 10.3 server. Note that although the ZIP file name contains the string ”Osb11gR1”, this observer supports Oracle Service Bus 10gR3. This observer is not recommended for Oracle Service Bus 11gR1 (you should instead use BTMObserver_Wls_10.3_Universal_*.zip for that purpose).
If you upgrade from a limited observer (such as a JavaEE observer) to the universal observer, your system will gain the ability to discover and monitor new types of components. Depending upon your system and your monitoring needs you might, or might not, want to monitor new component types. Before upgrading to the universal observer, you should review and adjust, if necessary, the active probes in your Observer Communication policy. For more information on this topic, read the online help topic named Functional Upgrade Issues. You can locate this topic by first choosing Help > Help in the Management console. After the online help opens, navigate to Overview of Oracle Business Transaction Management in the Contents pane and then scroll down to the Functional Upgrade Issues section.
Note:
If you require an updated version of an observer that monitors only JavaEE, Oracle Fusion Applications, Oracle SOA Suite, or Oracle Service Bus, enter a service request at My Oracle Support (http://support.oracle.com) for assistance.Separate procedures are provided for three different upgrade paths. The procedure you use depends on the type and release version of your installed observer and whether your WebLogic server is Node-Manager configured or script-configured. These are the procedures to choose from:
Use this procedure to upgrade the following observers on WebLogic servers:
release 12.1.0.6 universal observer
release 12.1.0.5 universal observer
release 12.1.0.4 universal observer
release 12.1.0.3 universal observer
all release 12.1.0.2.2 observers
release 12.1.0.2.0 observer for JavaEE
the observer for Oracle Service Bus 10gR3
Locate the appropriate observer distribution ZIP file for your environment and monitoring needs.
Shut down the WebLogic application server in which the observer is installed.
Make a backup copy of the WL_HOME\nanoagent directory.
The string WL_HOME refers to your WebLogic server's home directory, which is the weblogic92, wlserver_10.0, or wlserver_10.3 directory located in your WebLogic installation directory.
Delete the WL_HOME\nanoagent directory.
Unpack the observer distribution ZIP file into WL_HOME.
Unpacking the ZIP file creates directories named nanoagent and security_add_ons. The nanoagent directory contains three subdirectories named bin, config, and lib.
Ensure that the user account running WebLogic has at least the following privileges:
read permission on the nanoagent/config and nanoagent/lib directories (on UNIX-like systems traverse permission is also required)
read permission on all JAR files in the lib directory
If you originally installed the observer by editing script files rather than by using the Node Manager, replace your new observer script file with the observer script file located in your backup copy of the nanoagent directory. If you use the Node Manager, you can skip this step.
On Windows systems, the observer script file is located at:
WL_HOME\nanoagent\bin\nanoEnvWeblogic.cmd
On UNIX-like systems, the observer script file is located at:
WL_HOME/nanoagent/bin/nanoEnvWeblogic.sh
Restart your WebLogic server.
Use this procedure to upgrade the following observers to the current release in a WebLogic 10.3 Node Manager-configured environment:
release 12.1.0.2.0 observer for Oracle SOA Suite
release 12.1.0.2.0 observer for Oracle Service Bus 11gR1
release 11 or 12.1.0.1 observer for JavaEE
Locate the distribution ZIP file for the universal observer (BTMObserver_Wls_10.3_Universal_*.zip).
Open the WebLogic Administration Console (the default URL is http://machine_name:7001/console).
Remove WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar from your managed server's classpath (this setting was required by the version of the observer you are upgrading from, but must be removed for the current release):
Using the Domain Structure pane (on the left), navigate to Environment > Servers.
In the Servers table, click your managed server.
Display the Configuration / Server Start tab.
Click Lock & Edit.
Note:
These instructions assume you are operating in a production environment and that your WebLogic server's Automatically Acquire Lock and Activate Changes setting is therefore disabled. However, if this setting is enabled as it might be in a development environment, you do not have to click Lock & Edit in order to make changes and you do not have to activate changes after saving them.Delete the entry from the Class Path field as follows:
For Windows systems, delete this string:
WL_HOME\nanoagent\lib\bootstrap\ap-nano-bootstrap.jar
For UNIX-like systems, delete this string:
WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar
Keep this page open.
With the Configuration / Server Start tab still displayed, edit your WebLogic startup arguments as follows:
Remove JVM arguments from the Arguments field as follows (these settings were required by the previous release of the observer but must be removed for the current release):
For Windows systems, remove these arguments:
-Daspectwerkz.classloader.preprocessor=com.amberpoint.nanoagent.plugins.APAspectPreProcessor -javaagent:
WL_HOME\nanoagent\lib\bootstrap\aspectwerkz-jdk5-2.0.jar
For UNIX-like systems, remove these arguments:
-Daspectwerkz.classloader.preprocessor=com.amberpoint.nanoagent.plugins.APAspectPreProcessor -javaagent:
WL_HOME/nanoagent/lib/bootstrap/aspectwerkz-jdk5-2.0.jar
Configure the observer bootstrap module into your server by adding a JVM argument to the Arguments field as follows.
For Windows systems, add this argument:
-javaagent:WL_HOME\nanoagent\lib\bootstrap\ap-nano-bootstrap.jar
For UNIX-like systems, add this argument:
-javaagent:WL_HOME/nanoagent/lib/bootstrap/ap-nano-bootstrap.jar
Click Save and then click Activate Changes.
You should receive the following status:
”All changes have been activated. No restarts are necessary. Settings updated successfully.”
Shut down the WebLogic managed server in which the observer is installed.
Delete the WL_HOME\nanoagent directory from your WebLogic managed server.
The string WL_HOME refers to the server's home directory, which is the wlserver_10.3 directory located in your server's installation directory. For the remainder of this procedure, replace the string WL_HOME with the actual path to the WebLogic home directory.
Unpack the observer distribution ZIP file into WL_HOME.
Unpacking the ZIP file creates a directory named nanoagent that contains three subdirectories bin, config, and lib.
Ensure that the user account running the WebLogic server has at least the following privileges:
read permission on the nanoagent/config and nanoagent/lib directories (on UNIX-like systems traverse permission is also required)
read permission on all JAR files in the lib directory
If you inserted <filter> and <filter-mapping> elements into the web.xml files of your web applications during your original installation of the observer, you must now remove those elements.
The elements to remove from the web.xml files are these:
<filter> <filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name> <filter-class> com.amberpoint.nanoagent.bootstrap.servlet.FilterHandlerBootstrap </filter-class> </filter> <filter-mapping> <filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Restart your WebLogic server.
Use this procedure to upgrade the following observers to the current release in a WebLogic 10.3 script-configured environment:
release 12.1.0.2.0 observer for Oracle SOA Suite
release 12.1.0.2.0 observer for Oracle Service Bus 11gR1
release 11 or 12.1.0.1 observer for JavaEE
Note:
When you originally installed the observer, you either installed it into all servers defined in the WebLogic installation or into servers of specific domains. The term global install refers to installing the observer into all servers, and the term domain install refers to installing the observer into a specific domain.In the following procedure, you will replace the nanoagent directory and its contents. If you installed the observer as a global install, the nanoagent directory is located inside your WebLogic server's home directory, which is the wlserver_10.3 directory located in your WebLogic installation directory.
If you installed the observer as a domain install, the nanoagent directory is located inside your domain directory. In this case, you need to repeat this procedure for each domain in which you installed the observer.
Locate the distribution ZIP file for the universal observer (BTMObserver_Wls_10.3_Universal_*.zip).
Shut down the WebLogic application server in which the observer is installed.
Make a backup copy of your observer script file.
The observer script file is the nanoEnvWeblogic.cmd or nanoEnvWeblogic.sh file located inside the nanoagent/bin directory.
Delete the nanoagent directory.
Unpack the observer distribution ZIP file into the directory from which you deleted the nanoagent directory.
Unpacking the ZIP file creates a directory named nanoagent that contains three subdirectories bin, config, and lib.
Ensure that the user account running WebLogic has at least the following privileges:
read permission on the nanoagent/config and nanoagent/lib directories (on UNIX-like systems traverse permission is also required)
read permission on all JAR files in the lib directory
Open your new observer script file for editing and open your backup copy so you can copy settings from it.
Ensure that the values of the NANOAGENT_HOME and NANOAGENT_CONFIGURATION_URL variables in your new observer configuration file match the values in your backup copy.
If you inserted <filter> and <filter-mapping> elements into the web.xml files of your web applications during your original installation of the observer, you must now remove those elements.
The elements to remove from the web.xml files are these:
<filter> <filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name> <filter-class> com.amberpoint.nanoagent.bootstrap.servlet.FilterHandlerBootstrap </filter-class> </filter> <filter-mapping> <filter-name>ORACLE_BTM_WEB_APP_OBSERVER</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Restart your WebLogic server.
This section explains how to upgrade an observer for WCF.
Unpack the observer distribution file (BTMObserver_Iis_7.5_DotNet4_*.zip) into a temporary directory (referred to henceforth as observer_temp).
Unpacking the ZIP file creates a nanoagent directory containing two subdirectories—config and lib. The lib directory contains the observer DLL files.
Make a note of the version number of the new DLLs.
To find the version number, open the Windows Properties dialog box for one of the DLL files and click the Version tab.
Use gacutil.exe or a Windows Explorer to copy all of the DLL files from observer_temp\nanoagent\lib to the global application cache (GAC; normally located at C:\WINDOWS\assembly).
Using a text editor, open the application configuration file that contains the observer configuration code that you added when you originally installed the observer.
The file is either the machine.config, or a web.config file.
In the application configuration file, locate the two occurrences of the Version attribute that refer to the version number of the observer DLLs.
The elements containing the Version attributes are inside a </behaviorExtensions> element and should look similar to this:
<add name="APEPInterceptor" type="AmberPoint.NanoAgent.DotNet.Wcf.APEPBehaviorExtnElem, AmberPoint.NanoAgentWCF, Version=64000.64000.25233.19024, Culture=neutral, PublicKeyToken=d8685c0afbb35893"/> <add name="APServiceInterceptor" type="AmberPoint.NanoAgent.DotNet.Wcf.APServiceBehaviorExtnElem, AmberPoint.NanoAgentWCF, Version=64000.64000.25233.19024, Culture=neutral, PublicKeyToken=d8685c0afbb35893"/>
Edit the setting of the Version attribute so that it matches the version number of the new observer DLLs, and then save and close the file.
Note:
If you configured the observer into multiple web.config files on the machine, edit the Version attributes in each file.Optional – Remove the old observer DLLs from the GAC (unless they are being used by another observer on the machine).
The name of each observer DLL begins with the string ”AmberPoint”. To remove a DLL, right-click it and choose Uninstall.
Note:
The observer for ASP.NET uses many of the same DLLs as the observer for WCF. If you have the observer for ASP.NET installed on the machine, you must not remove the version of the DLLs that are being used by it.This section explains how to upgrade an observer for Oracle Enterprise Gateway.
Shut down your Enterprise Gateway server.
Delete all of the observer-related JAR files from OEG_HOME/ext/lib, where OEG_HOME is your Enterprise Gateway server's home directory (the top-level installation directory).
The observer-related JAR files are those prefixed with ”ap-” plus the following files:
orahttp_client_1.0.0.jar orawsdl_1.0.0.jar xstream-1.2.2.jar
Unpack the observer ZIP file (BTMObserver_OEG_11.1.1.6_OEG_*.zip) into a temporary directory, referred to henceforth as observer_temp.
Unpacking the ZIP file creates three directories named config, lib, and scripts.
Copy all of the JAR files located in the lib directory to OEG_HOME/ext/lib.
Open OEG_HOME/system/conf/jvm.xml in a text editor and make the following changes inside the <JVMSettings> element:
Locate the following line (it should be the 1st child of the <JVMSettings> element):
<SystemProperty name="AP_NANO_CONFIG_URL" value="http://Host_Name:Port_Number/btmmonitor/agent/agent/"/>
Add the following lines as the 2nd, 3rd, and 4th children of the <JVMSettings> element:
<SystemProperty name="AP_NANO_HOME" value="$VDISTDIR/NanoAgent"/> <SystemProperty name="AP_NANO_LOG_BASEDIR" value="$VDISTDIR/NanoAgent"/> <SystemProperty name="AP_NANO_CLASSLOADER_BASEDIR" value="$VDISTDIR/ext/lib"/>
Optional – If you want to target this observer by way of an observer configuration label, add the following line as the 5th child of the <JVMSettings> element:
<SystemProperty name="ap.nano.config.label" value="My_Label_String"/>
Replace My_Label_String with the string you want to use as a label for this observer. For more information about targeting observers refer to Section 8.5, "Applying an Observer Communication Policy."
Restart your Enterprise Gateway server.