8 Performing Post-Upgrade Tasks

This chapter summarizes the tasks you might have to perform after upgrading to SOA 12c.

This chapter includes the following sections:

Note:

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

For Business Activity Monitoring (BAM), see Upgrading SOA with Oracle Business Activity Monitoring (Oracle BAM)

For SOA Core Extension (AIAFP), see Performing Post-Upgrade Tasks for SOA Core Extension

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

For User Messaging Service (UMS), see "Upgrading User Messaging Service" in Administering Oracle 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:

  1. 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.

  2. 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 ignorehost nameVerification, host nameVerifier, 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.1.3 it might be necessary to re-apply any customizations to startup scripts, such as setDomainEnv.

If servers do not start, or if they 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 Section 2.1.7, "Maintaining Custom setDomainEnv Settings".

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, partition-specific roles are not automatically recreated for all partitions. The roles are created only for default partition. For all other partitions, you must create these roles using below WLST command:

sca_createDefaultPartitionAppRoles partition

For more information on this new 12c (12.1.3) feature, see "Securing Access to Partitions" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

8.1.6 Migrating Java Keystore (JKS) to OPSS KeyStore Services (KSS)

Oracle Web Services Manager (OWSM) 11g supported multiple types of keystores for message protection, but Java KeyStore (JKS) was the default keystore. As of OWSM Release 12c (12.1.2), however, OWSM is switching to KSS (OPSS KeyStore Service) as the default keystore.

If you were using JKS in 11g, and want to use KSS with 12c, see "Configuring Keystores for Message Protection" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

8.1.7 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" in Administering Oracle Fusion Middleware.

Start servers in this order:

  1. Webtier (including the Oracle HTTP Server)

  2. Node Managers

  3. Admin Servers

  4. Oracle Web Services Manager (OWSM) Managed Server

  5. Service-Oriented Architecture (SOA) Managed Server

  6. Oracle Service Bus (OSB) Managed Server

  7. Business Activity Monitoring (BAM) Managed Server

Stop servers in this order:

  1. Business Activity Monitoring (BAM) Managed Server

  2. Oracle Service Bus (OSB) Managed Server

  3. Service-Oriented Architecture (SOA) Managed Server

  4. Oracle Web Services Manager (OWSM) Managed Server

  5. Admin Servers

  6. Node Managers

  7. Webtier (including the Oracle HTTP Server)

8.1.8 Displaying Composite Instances in Enterprise Manager

If your upgrade includes migrating a large number of instances (closed and open), you may experience performance issues when loading Enterprise Manager flow trace. To prevent performance degradation, create an index as described in the following steps:

  1. Stop the Administration Server and any running managed servers as described in Section 8.1.7.

  2. Connect to SOAINFRA schema from SQLPLUS and execute the following command:

    CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

  3. Restart the Administration Server and managed servers as described in Section 8.1.7.

Note:

For more information on managing instance upgrades, see Chapter 9, "Administering and Monitoring the Upgrade of SOA Instances".

8.1.9 Upgrading Business Process Management (BPM) Metadata

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

For more information on using Business Process Composer, see Business Process Composer User's Guide for Oracle Business Process Management.

8.1.10 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" in Securing Applications with Oracle Platform Security Services.

8.1.11 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 host name is configured as localhost. As a workaround, the localhost should be changed to host name.

For more information, see "Configuring Oracle Socket Adapter" in Understanding Technology Adapters.

8.1.12 Reconfiguring Threads for SOA 12c

Starting with Oracle SOA Suite 12c (12.1.3), 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.1.3 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.

Note:

The following message is displayed when there is not enough information to correctly identify the state of the fault and a temporary fault status has been assigned:

Error Message not available-Generated during instance upgrade.

You can ignore these error messages.

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 follows
Description of "Figure 8-1 New 12c Instance Flow Trace"

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:

Figure 8-2 Upgraded 11g Instance Flow Trace

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