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

• Performing Post Upgrade Tasks
  
• Verifying the Upgraded Components Work as Expected
  

Performing Post Upgrade Tasks

The following tasks should be performed after an upgrade:

• Updating the SOA Infrastructure Common Properties
  Use Oracle Enterprise Manager Fusion Middleware Control 12c to update the data display options in your upgraded environment.
• Reapplying Start Script Properties for JVM
  
• Reapplying Customizations to setDomainEnv.sh
  
• Reapplying Customizations to XEngine Configuration Files
  
• Copying Custom XPath Classes
  
• Recreating Partition-Specific Roles for Application Roles and Policies
  
• Upgrading Business Process Management (BPM) Metadata
  
• Configuring an Oracle Fusion Middleware 12c Audit Data Store
  
• Upgrading ServerSocket with Remote Clients
  
• Reconfiguring Threads for SOA 12c
  
• Creating a New Default Security Realm After Domain Upgrade
  If you are upgrading domain using partitions from a 12.2.1.0 or later, a new security realm is required. You must create the new realm and then set it as the default. Do not attempt to reuse the existing security realm with the upgraded domain.

Updating the SOA Infrastructure Common Properties

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.

To update the query duration setting after the upgrade:

1. Log in to the Fusion Middleware Control 12c administration console:

   http://machinename.mycompany.com:7001/console

2. Navigate to the SOA Infrastructure Common Properties screen by selecting the SOA managed server (ex: soa_server1) from the navigation panel.

3. Update the Default Query Duration as shown in the image below.

Description of the illustration data-display-options.png

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

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

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

Upgrading Business Process Management (BPM) Metadata

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

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.

Reconfiguring Threads for SOA 12c

Starting in Oracle SOA Suite 12c (12.2.1.3.0), 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.

Creating a New Default Security Realm After Domain Upgrade

If you are upgrading domain using partitions from a 12.2.1.0 or later, a new security realm is required. You must create the new realm and then set it as the default. Do not attempt to reuse the existing security realm with the upgraded domain.

This step is only required if your domain is using WebLogic Server domain multitenant partitions and you are upgrading from Oracle Fusion Middleware 12c (12.2.1.0.0) or later.

Create the new default security realm after a successful domain upgrade.

1. In the left pane of the WebLogic Server Administration Console, expand the Security>Realms node.
   All security realms available for the WebLogic domain are listed in the Realms table.
2. Click Configure a new Realm
   Provide a name for the new realm and apply all necessary attributes and configuration settings. Realm attributes include Check Roles and Security Policies and Future Redeploys.
3. Click Create.
4. Configure the required security providers for the security realm.
   A valid security realm requires an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, and a Role Mapping provider. Otherwise, you will not be able to set the new security realm as the default security realm.
5. Set the new security realm as the default (active) security realm.
   1. In the left pane of the WebLogic Server Administration Console, expand the node representing a domain (for example, Examples).
   2. Click View Domain-wide Security Settings.
   3. Select the General tab.
      The pull-down menu for the Default Realm attribute displays the security realms configured in the WebLogic Server domain. If you create a new security realm but do not configure the minimum required security providers in the security realm, the realm will not be available from the pull-down menu. Refer to step 4.
   4. Select the security realm you want to set as the default security realm.
   5. Click Apply.
   6. Reboot WebLogic Server. If you do not reboot WebLogic Server, the new realm is not set as the default security realm.
   To verify you set the default security realm correctly:
   In the left pane of the WebLogic Server Administration Console, expand the Security>Realms nodes. The Realms table shows all realms configured for the WebLogic Server domain. The default (active) security realm has the Default Realm attribute set to true.
6. Delete the old realm.
   1. In the left pane of the WebLogic Server Administration Console, expand the Security>Realms nodes.
   2. In the table row for the security realm you want to delete, click the trash can icon.
   3. Click Yes in response to the following question:
      Are you sure you want to permanently delete OldRealm from the domain configuration?
      A confirmation message appears when the security realm is deleted.
7. Create the multitenant partitions.

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.
• Verifying the Domain Component Configurations Upgrade
  
• Starting Composer After an Upgrade
  

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 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) NEW_DOMAIN_HOME/bin/startWebLogic.sh

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

• (Windows) NEW_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) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

• (Windows) NEW_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) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

• (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

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) 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 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.3.0) Oracle home and not from the 11g 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.