Performing Post Upgrade Tasks

6 Performing Post Upgrade Tasks

Summarizes the tasks you might have to perform after upgrading to Oracle SOA Suite 14c (14.1.2.0.0).

Performing Post Upgrade Tasks

The following tasks should be performed after an upgrade:

Changing Domain Mode Post Upgrade

After the upgrade, your domain retains its original pre-upgrade domain security mode settings. If you want to change the domain mode, to enable enhanced security, for example, you must explicitly change the settings using the WebLogic Remote Console or by modifying the DomainMBean.

If your domain is currently set to Production Mode, and you want to enable added security, then after the upgrade use the WebLogic Remote Console to change the domain mode and enable the Secured Production Mode. Change the Domain Mode in Oracle WebLogic Remote Console Online Help.

Caution:

Changes to the domain mode require a full domain restart - a rolling restart is not sufficient. You must stop all managed servers before you attempt to change the domain mode.

When upgrading a domain to 14c (14.1.2.0.0), if there is no explicit secure mode setting, then the Reconfiguration Wizard will explicitly set secure mode to disabled in the upgraded domain. This is to preserve the behavior that was present in the original domain. If there is an explicit secure mode setting, it will be preserved in the upgraded domain. For more information, see Understand How Domain Mode Affects the Default Security Configuration in Securing a Production Environment for Oracle WebLogic Server.

Note:

Secured Production Mode enforces more restrictive and stringent security settings to ensure less vulnerability to threats. To make sure that your domain is secure, after enabling Secured Production Mode, you will have to choose the security configuration options that are appropriate for the environment in which the domain runs, such as obtaining and storing certificates, protecting user accounts, and securing the network on which the domain runs. If these options are not properly configured, you will be blocked from using WebLogic Server.

After you have created your WebLogic domain, several key steps remain to ensure its integrity such as selecting appropriate security configurations. For more information, see Securing the Domain After You Have Created It in Administering Security for Oracle WebLogic Server.

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 existing environment, then you will need to reapply the properties post-upgrade.

Specifically, if you have configured JRockit JVM arguments, 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.

Reapplying Customizations to setDomainEnv.sh

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 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 setDomainEnv file. If there are differences, then make the same changes in the new setDomainEnv file.

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.

Copying Custom XPath Classes

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 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:

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_xxx/classes

to the following 14c directory:

/14c_ORACLE_HOME/soa/modules/oracle.soa.ext_xxx/classes

Recreating Partition-Specific Roles for Application Roles and Policies

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

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

sca_createDefaultPartitionAppRoles partition

Upgrading Business Process Management (BPM) Metadata

The Business Process Management metadata upgrade begins once you log into Business Process Composer 14c (14.1.2.0.0) 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.

Configuring an Oracle Fusion Middleware 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 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

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

Starting Servers and Processes

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 processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Remote Console. See Starting and Stopping Administration and Managed Servers and Node Manager.

As of release 14c (14.1.2.0.0), the WebLogic Server Administration Console has been removed. For comparable functionality, you should use the WebLogic Remote Console. For more information, see Oracle WebLogic Remote Console.

To start your Fusion Middleware environment, follow the steps below:

Note:

Depending on your existing security settings, you may need to perform additional configuration before you can manage a domain with secured production mode enabled. For more information, see Connecting to the Administration Server using WebLogic Remote Console

Step 1: Start the Administration Server

To start the Administration Server, use the startWebLogic script:

(UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh
(Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

Note:

When using secured production mode, you must provide additional parameters to start the Administration Server. See Connecting to the Administration Server using WLST in Administering Security for Oracle WebLogic Server.

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) NEW_DOMAIN_HOME/bin/startNodeManager.sh
(Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

Step 3: Start Any Managed Servers

To start a WebLogic Server Managed Server, use the startManagedWebLogic script:

(UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

Note:

When using secured production mode, you must provide additional parameters to start the Managed Servers. See Starting Managed Servers using a Start Script in Administering Security for Oracle WebLogic Server.

Start SOA servers and processes in this order:

Oracle Web Services Manager (OWSM) Managed Server
Service-Oriented Architecture (SOA) Managed Server
Managed File Trasfer (MFT)
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 4: Start System Components

To start system components, such as Oracle HTTP Server, use the startComponent script:

(UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

You can start system components in any order.

Verifying the Domain Component Configurations Upgrade

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

Remote 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 14c (14.1.2.0.0) Oracle home and not from the existing 12c (12.2.1.4) Oracle home.

Starting Composer After an Upgrade

Composer is not operational post upgrade until the user weblogic logs in. You cannot log in as a demo user until after the weblogic user has started Composer. If you attempt to log in as a demo user, then you will see the following message:

Migration is running in the background.

If you get this error, log out and log back in as weblogic user and wait for the migration to complete.