Note:
There are additional component-specific post upgrade tasks for the following:
For Business Activity Monitoring (BAM), see Upgrading Oracle SOA Suite with Oracle Business Activity Monitoring from 11g
For Oracle Service Bus (OSB), see Performing Post Upgrade Tasks for Oracle Service Bus
For User Messaging Service (UMS), see Upgrading User Messaging Service.
The following tasks should be performed after an upgrade:
Use Oracle Enterprise Manager Fusion Middleware Control 12c to update the data display options in your upgraded environment.
If you are upgrading from Oracle Fusion Middleware 11g, and you restricted the display of instances and faults to a specific number of days, you will need to update this setting after the upgrade. In 12c, the default query duration setting is captured in hours and not days.
http://machinename.mycompany.com:7001/console
soa_server1
) from the navigation panel.Update the Default Query Duration as shown in the image below.
Description of the illustration GUID-5E92A7C7-A7C4-4DDB-A388-0C57427CD90A-default.png
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.
If servers do not start, or they start in AdminMode, the cause is most likely that the setDomainEnv.sh
changes from the previous environment were not reapplied to the newly configured 12c domain. During the upgrade process, startup scripts are replaced with the latest version. If you made any modifications to these files, then you will need to edit the new startup scripts with the same information.
To determine if this is the cause, compare the setDomainEnv file from your pre-upgrade backup to the new 12c setDomainEnv file. If there are differences, then make the same changes in the new setDomainEnv file.
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.
If you modified the default XPath classes in your pre-upgrade environment, then after the upgrade you will need to copy the customized XPath classes to the new 12c Oracle home as shown in the example below:
Copy the custom XPath classes from your pre-upgrade backups. Classes are found in the following directory:
/11g_ORACLE_HOME
/soa/modules/oracle.soa.ext_11.1.1/classes
to the following 12c directory:
/12c_ORACLE_HOME
/soa/modules/oracle.soa.ext_11.1.1/classes
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
The Business Process Management metadata upgrade begins once you log into Business Process Composer 12c (12.2.1.2) 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.
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 the main administration tasks and tools you use to manage the audit store, audit policies, and bus-stop files, 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 hostname is configured as localhost. As a workaround, the localhost should be changed to hostname.
Starting in Oracle SOA Suite 12c (12.2.1.2), 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.
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.
The components may be dependent on each other so they must be started in the correct order.
Note:
The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.To start your Fusion Middleware environment, follow the steps below.
Step 1: Start the Administration Server
When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To start the Administration Server, use the startWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 2: Start Node Manager
To start Node Manager, use the startNodeManager
script:
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
Step 3: Start Oracle Identity Management Components
Start any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
Step 4: Start the Managed Servers
To start a WebLogic Server Managed Server, use the startManagedWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Start SOA servers and processes in this order:
Service-Oriented Architecture (SOA) Managed Server
Oracle Service Bus (OSB) Managed Server
Business Activity Monitoring (BAM) Managed Server
Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.Step 5: Start System Components
To start system components, such as Oracle HTTP Server, use the startComponent
script:
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
You can start system components in any order.
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 12c (12.2.1.2) Oracle home and not from the 11g Oracle home.