8 Performing Post Upgrade Tasks

Summarizes the tasks you might have to perform after upgrading to Oracle SOA Suite 12c.

Note:

There are additional component-specific post upgrade tasks for the following:

For Business Activity Monitoring (BAM), see Upgrading from Oracle SOA Suite with Oracle Business Activity Monitoring 11g to 12c

For Oracle Service Bus (OSB), see Performing Post Upgrade Tasks for Oracle Service Bus

For User Messaging Service (UMS), see Upgrading User Messaging Service.

8.1 Performing Post Upgrade Tasks

The following tasks should be performed after an upgrade:

8.1.1 Reapplying Start Script Properties for JVM

If you used a start script to specify required startup properties, or to perform any other work required at start up in your 11g environment, then you will need to reapply the properties post-upgrade.

Specifically, if you have configured JRockit JVM arguments in your 11g environment, then these configurations must be reapplied post-upgrade. Oracle recommends that you use either startup-plan.xml or startscript.xml for configuring JVM startup parameters.

Caution:

Failure to update the start script arguments may prevent you from starting the SOA and OSB servers after the upgrade.

To enable the scripts:

In the nodemanager.properties file, set the StartScriptEnabled property to true. (The default is false.) If your start script is named startWebLogic.sh or startWebLogic.cmd, Node Manager uses one of those scripts as the default.
If you want to specify a custom start script, set the StartScriptName property to the name of your script in the nodemanager.properties file.

Node Manager sets the JAVA_VENDOR, JAVA_HOME, JAVA_OPTIONS, SECURITY_POLICY, CLASSPATH, and ADMIN_URL. It retrieves these values from the ServerMBean, ServerStartMBean, and SSLMBean when you use the Administration Console to start the server, or WLST connected to the Administration Server. When you use WLST connected directly to the Node Manager, you can specify the values; otherwise, they are left empty.

Node Manager combines all of the command line startup options (-D flags) that are specified in the ServerStartMBean Arguments attribute, as well as the SSLArguments into a single environmental variable called JAVA_OPTIONS. SSLArguments are retrieved from the values in the SSLMBean. The SSLMBean is inspected for ignoreHostnameVerification, HostnameVerifier, and ReverseDNSAllowed values, then those values are appended to the -D flags. All of those flags comprise the SSLArguments parameter. All of the values for SSLArguments as well as Arguments in the ServerStartMBean comprise the JAVA_OPTIONS environment variable that is defined for the start script. In addition, the script will append any of its own defined values onto this environment variable.

8.1.2 Reapplying Customizations to setDomainEnv

To complete the upgrade of your SOA Suite and BPM environment to 12.2.1 it might be necessary to re-apply any customizations to startup scripts, such as setDomainEnv.

If servers do not start or start in AdminMode, the cause is most likely that the setDomainEnv.sh changes from 11g were not reapplied to the 12c domain. Compare setDomainEnv from 11g to 12c and then add any custom changes after the upgrade.

For more information, see "Re-apply Customizations to Startup Scripts".

Note:

To prevent losing your customizations in a future upgrade, see Maintaining Custom setDomainEnv Settings in Planning an Upgrade of Oracle Fusion Middleware.

8.1.3 Reapplying Customizations to XEngine Configuration Files

Any pre-upgrade changes made to the XEngine configuration files, such as SeverityConfig.xml, will be overwritten by new, regenerated configuration files during the domain reconfiguration process. Therefore, all customized settings used in the pre-upgrade configuration files will need to be reapplied after the upgrade.

For example, if you added a section for SNIP in the pre-upgrade XEngine configuration file, SeverityConfig.xml, the same section will have to be added to the new, post-upgrade SeverityConfig.xml file.

8.1.4 Copying Custom XPath Classes

After the upgrade you will need to copy any customized XPath classes to the new 12c Oracle Home /classes directory as shown in the example below:

Copy the custom XPath classes from:

<11g Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes

to:

<12c Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes folder

8.1.5 Recreating Partition-Specific Roles for Application Roles and Policies

After the upgrade, you will have to recreate any partition-specific roles used in your 11g environment.

Partition application roles for existing applications are not recreated by the 12c upgrade process. Instead, you must manually create these roles using the following WLST script:

sca_createDefaultPartitionAppRoles partition

8.1.6 Starting and Stopping Servers

After the upgrade of SOA Suite and BPM with integrated components, you should start all of the Administration and Managed servers for your environment and make sure that they are functioning as expected.

You will continue to start the servers from the upgraded 11g domain home, as the domain upgrade was performed in place.

The order in which you START and STOP the servers is important, and failure to start or stop them in the correct order can cause issues with the deployment.

Note:

Procedures for starting and stopping Oracle Fusion Middleware, including the Administration Server, Managed Servers, and components are provided in Starting and Stopping Oracle Fusion Middleware

Start servers in this order:

Webtier (including the Oracle HTTP Server)
Node Managers
Administration Servers
Oracle Web Services Manager (OWSM) Managed Server
Service-Oriented Architecture (SOA) Managed Server
Oracle Service Bus (OSB) Managed Server
Business Activity Monitoring (BAM) Managed Server

Stop servers in this order:

Business Activity Monitoring (BAM) Managed Server
Oracle Service Bus (OSB) Managed Server
Service-Oriented Architecture (SOA) Managed Server
Oracle Web Services Manager (OWSM) Managed Server
Administration Servers
Node Managers
Webtier (including the Oracle HTTP Server)

8.1.7 Upgrading Business Process Management (BPM) Metadata

The BPM metadata upgrade begins once you log into Business Process Composer 12c (12.2.1) for the first time (after a successful upgrade).

For more information on using Business Process Composer, see Developing Business Processes with Oracle Business Process Composer.

8.1.8 Configuring an Oracle Fusion Middleware 12c Audit Data Store

As a part of the overall upgrade process, you should have created the IAU schema in the database where your other Oracle Fusion Middleware schemas reside. For more information about using the Audit Data Store, see Managing the Audit Data Store.

8.1.9 Upgrading ServerSocket with Remote Clients

There is a change in behavior in which the ServerSocket is created when you upgrade from Oracle Release 11g to Release 12g. Because of this, remote clients might not able to connect to the ServerSocket when the hostname is configured as localhost. As a workaround, the localhost should be changed to hostname.

8.1.10 Reconfiguring Threads for SOA 12c

Starting in Oracle SOA Suite 12c (12.2.1), Work Managers handle most SOA-related work threads. The thread configurations you specified for SOA 11g will not apply to your upgraded SOA 12c environment. You will have to reconfigure the threads after upgrading to SOA 12c.

For more information on using the new threading model, see "Tuning the SOA Infrastructure" in Tuning Performance.

8.2 Verifying that the Upgraded Components Work as Expected

After a successful upgrade, you should perform the following tasks to make sure that the components are still working as expected and that there are no issues with the new deployment.

8.2.1 Verifying the Domain Component Configurations Upgrade

To verify that the domain component configurations upgrade was successful, log in to the Administration console and the Fusion Middleware Control using the following URLs, and verify the upgraded version numbers for each component:

Administration Console URL: http://administration_server_host:administration_server_port/console

Fusion Middleware Control URL: http://administration_server_host:administration_server_port/em

Note:

After the upgrade, you must run all of your administration tools from the new 12.2.1 Oracle home and not from the 11g Oracle home.

8.2.2 Verifying the Database Schema Upgrade Succeeded

In addition to the Upgrade Assistant Upgrade Status screens, you can also manually validate that the database schema upgrade and instance upgrade was successful by using SQL commands.

For more information, see Monitoring Upgrade Status with SQL Queries.

8.2.3 Understanding the Flow Trace Changes in 12c

In 12c SOA, instances are controlled using flowIDs instead of ECIDs. When the Upgrade Assistant upgrades instances from 11g SOA to 12c SOA, there are few differences between the 11g upgraded flow instances and the newly created 12c instances. These differences will not impact the functionality of the flow trace, but it is important to note the differences.

The flow trace XML examples below show the following differences:

The attributes ActionType and ActionName are new in 12c and are not available in 11g upgraded instances.
Date and lastUpdatedDate are the same for 11g Upgraded instances.
ElapsedTime for Entry Instance Id is 0 for 11g Upgraded instances.

Flow trace XML for 11g to 12c upgraded instances:

================================
 <audit_trail
ecid="9dd01e5816e19dbc:-33f3b618:140c1ee8b0f:-8000-000000000000317e"
flowId="96102"  flowCorrelationId="null"  activeInstances="0"
date="2013-09-02 00:09:52.133 PDT"  lastUpdatedDate="2013-09-02 00:09:52.156
PDT"  elapsedTime="23">
    <entry instanceId="10093" parentInstanceId="-110092" date="2013-09-02
00:09:52.156 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT"
elapsedTime="0" timestamp="1378105792156" state="18" subType="bpel"
type="component">
       ...
    </entry>
</audit_trail>

Flow trace XML in newly created 12c instances:

====================================
 <audit_trail ecid="dfcc3828-d7de-4af8-b94e-474ff830c961-0000069a"  flowId="6"
 flowCorrelationId="0000K7z3tBPFCCGpIwt1if1IRXgh00000M"  activeInstances="0"
date="2013-10-28 05:35:12.738 PDT"  lastUpdatedDate="2013-10-28 05:35:12.825
PDT"  elapsedTime="87">
       <entry instanceId="13" parentInstanceId="12" date="2013-10-28
05:35:12.749 PDT" lastUpdatedDate="2013-10-28 05:35:12.786 PDT"
elapsedTime="37" timestamp="1382963712749" state="18" actionType="operation"
actionName="process" subType="bpel" type="component">
     ...
    </entry>
</audit_trail>

In addition, the Recovery status of the new instances created in 12c for a caught fault in BPEL shows the fault as recovered as shown in Figure 8-1:

Figure 8-1 New 12c Instance Flow Trace

Description of "Figure 8-1 New 12c Instance Flow Trace"

However, the Recovery status of an upgraded 11g instance for a caught fault in BPEL shows the fault as Nonrecoverable as shown in Figure 8-2:

Note:

The information passed from the 11g faults is not enough to correctly identify the state of a fault. To handle this, all the actual faults retrieved from 11g are initially identified as nonrecoverable. Dummy faults are then created to set the proper state (BPEL_invoke_recovery, Bpel_activity_recovery).

Therefore, if you see a warning or notice that the 11g faults are nonrecoverable, you can ignore the warning.

Figure 8-2 Upgraded 11g Instance Flow Trace

Description of "Figure 8-2 Upgraded 11g Instance Flow Trace"