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
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.
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.
Log in to the Fusion Middleware Control 12c administration console:
- Navigate to the SOA Infrastructure Common Properties screen by selecting the SOA managed server (ex:
soa_server1) from the navigation panel.
Update the Default Query Duration as shown in the image below.
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
startscript.xml for configuring JVM startup parameters.
Failure to update the start script arguments may prevent you from starting the SOA and OSB servers after the upgrade.
To enable the scripts:
nodemanager.propertiesfile, set the
true. (The default is
false.) If your start script is named
startWebLogic.cmd, Node Manager uses one of those scripts as the default.
If you want to specify a custom start script, set the
StartScriptNameproperty to the name of your script in the
Node Manager sets the
ADMIN_URL. It retrieves these values from the
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
Arguments attribute, as well as the
SSLArguments into a single environmental variable called
SSLArguments are retrieved from the values in the
SSLMBean is inspected for
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
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:
to the following 12c directory:
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:
Upgrading Business Process Management (BPM) Metadata
The Business Process Management metadata upgrade begins once you log into Business Process Composer 12c (22.214.171.124.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 (126.96.36.199.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 188.8.131.52 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.
- 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.
- Click Configure a new RealmProvide 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.
- Click Create.
- 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.
- Set the new security realm as the default (active) 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
- In the left pane of the WebLogic Server Administration Console, expand the node representing a domain (for example, Examples).
- Click View Domain-wide Security Settings.
- 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.
- Select the security realm you want to set as the default security realm.
- Click Apply.
- Reboot WebLogic Server. If you do not reboot WebLogic Server, the new realm is not set as the default security realm.
- Delete the old realm.
- In the left pane of the WebLogic Server Administration Console, expand the Security>Realms nodes.
- In the table row for the security realm you want to delete, click the trash can icon.
- 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.
- 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.
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
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
Step 3: Start Oracle Identity Management ComponentsStart any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:
Step 4: Start the Managed Servers
To start a WebLogic Server Managed Server, use the
NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
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
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:
Fusion Middleware Control URL:
After the upgrade, you must run all of your administration tools from the new 12c (184.108.40.206.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.