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
The following tasks should be performed after an upgrade:
Section 8.1.3, "Reapplying Customizations to XEngine Configuration Files"
Section 8.1.5, "Recreating Partition-Specific Roles for Application Roles and Policies"
Section 8.1.6, "Migrating Java Keystore (JKS) to OPSS KeyStore Services (KSS)"
Section 8.1.8, "Displaying Composite Instances in Enterprise Manager"
Section 8.1.9, "Upgrading Business Process Management (BPM) Metadata"
Section 8.1.10, "Configuring an Oracle Fusion Middleware 12c Audit Data Store"
Section 8.1.11, "Upgrading ServerSocket with Remote Clients"
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 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.
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".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.
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
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.
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.
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.Webtier (including the Oracle HTTP Server)
Node Managers
Admin 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
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
Admin Servers
Node Managers
Webtier (including the Oracle HTTP Server)
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:
Stop the Administration Server and any running managed servers as described in Section 8.1.7.
Connect to SOAINFRA
schema from SQLPLUS and execute the following command:
CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);
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".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.
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.
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.
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.
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.
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.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.
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:
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