Oracle® Fusion Middleware

Upgrading SOA Suite and Business Process Management

12c (12.1.3)

E29543-05

April 2015

This guide provides instructions for upgrading and redeploying your Oracle SOA Suite 11g applications to Oracle SOA Suite 12c.

Oracle Fusion Middleware Upgrading SOA Suite and Business Process Management, 12c (12.1.3)

E29543-05

Copyright © 2014, 2015, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Lisa Jamen

Contributing Author:  Sreetama Ghosh

Contributors: Jay Kasi, Robert Donat, Vamsee Goruganthu, Subramanian Hariharan, Suresh Krishnaswamy, William Norcott, Renga Rengarajan, Michael Rubino, Sitaraman Swaminathan

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

What's New in This Guide

- New and Changed Features for Fusion Middleware 12c

1 Introduction to Oracle SOA Suite and Business Process Management Upgrade

- 1.1 Understanding In-Place versus Out-of-Place Upgrades

- 1.2 Understanding the Starting Points for a SOA 12c (12.1.3) Upgrade

- 1.3 Understanding the Interoperability and Compatibility Restrictions Before You Upgrade

- 1.4 Understanding the Standard Upgrade Topologies

- 1.5 Understanding Domain Upgrade Restrictions

- 1.5.1 Upgrading a Domain that was Created Using Test-to-Production Prior to Release 11g (11.1.1.6) (Not Supported)

- 1.5.2 Upgrading an Unclustered Environment with SOA and BAM Managed Servers (Not Supported)

- 1.6 Understanding SOA Composite Upgrades

- 1.7 Understanding Schema Upgrade Restrictions

- 1.7.1 Upgrading Partitioned Schema Tables (Not Supported)

- 1.8 Understanding the SOA Suite and BPM Upgrade Process Flow

2 Performing the Required Pre-Upgrade Tasks for SOA Suite and BPM

- 2.1 Performing General Pre-Upgrade Tasks

- 2.1.1 Creating, Upgrading, and Testing a Development Copy of Your Production Environment

- 2.1.2 Backing Up Your Existing Oracle Fusion Middleware 11g Environment

- 2.1.3 Backing Up Your Database

- 2.1.4 Purging Unused Data

- 2.1.5 Ensuring You Have Sufficient Free Space

- 2.1.6 Using Enhanced Encryption (AES 256)

- 2.1.7 Maintaining Custom setDomainEnv Settings

- 2.1.8 Upgrading from a 32-Bit to a 64-Bit Operating System

- 2.1.9 Upgrading and Preparing the Fusion Middleware Database

- 2.1.10 Adding Datafiles to the SOAINFRA and IAS_TEMP Tablespaces

- 2.1.11 Upgrading User Messaging Service (UMS)

- 2.1.12 Upgrading a SOA Domain with Oracle Service Bus (OSB)

- 2.1.13 Upgrading a Standalone Oracle HTTP Server

- 2.1.14 Reassociating a File-Based Policy Store Before Upgrade

- 2.1.15 Using an Oracle Internet Directory-based Security Store

- 2.1.16 Upgrading Custom Applications Using Oracle JDeveloper 12c

- 2.1.17 Stopping Servers and Processes

- 2.2 Upgrading Security to 12.1.3

- 2.3 Installing the 12c (12.1.3) Infrastructure Distributions Before Upgrade

- 2.3.1 Installing WebLogic Server and JRF Infrastructure

- 2.3.2 Installing Oracle HTTP Server

- 2.4 Installing SOA Integrated Distributions

- 2.5 Preparing to Upgrade Schemas

- 2.5.1 Using the Schema Version Registry to Identify Existing 11g Schemas

- 2.5.2 Creating the Required Schemas Before You Upgrade

3 Upgrading to SOA Suite and Business Process Management 12c (12.1.3)

- 3.1 Installing Oracle SOA Suite and Business Process Management

- 3.2 Creating the Required 12c (12.1.3) Schemas for Oracle SOA Suite and BPM

- 3.3 Generating Log Files During Schema Upgrade (Recommended)

- 3.4 Upgrading SOA Schemas Using the Upgrade Assistant

- 3.5 Reconfiguring the Domain Using the Reconfiguration Wizard

- 3.6 Upgrading the Domain Component Configurations Using the Upgrade Assistant

- 3.7 Upgrading JDeveloper Projects in Bulk

- 3.8 Upgrading BPM Web Forms

- 3.9 Managing Your Upgraded Oracle Fusion Middleware 12c Software

4 Upgrading a Clustered SOA Environment

- 4.1 Understanding the SOA Cluster Upgrade Topology

- 4.2 Using Secured Task Forms in a Clustered Topology

- 4.3 Upgrading a Clustered Topology

- 4.4 Propagating Domain Configuration on SOAHOST2

- 4.5 Performing Post-Upgrade Tasks for Clusters

- 4.5.1 Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

- 4.5.2 Removing OWSM Targets from SOA and OSB Clusters

- 4.5.3 Updating OWSM Cross-Component Wiring

- 4.5.4 Removing MDS-OWSM Data Sources from SOA and OSB Clusters

- 4.5.5 Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

- 4.5.6 Preventing Duplicate Messages When Using JMS Transport Proxy Service

5 Upgrading SOA with Oracle Business Activity Monitoring (Oracle BAM)

- 5.1 Understanding an Upgrade to Business Activity Monitoring in 12c

- 5.2 Performing the Pre-Upgrade Tasks for Oracle BAM

- 5.2.1 Creating a New Oracle BAM 11g Domain Before You Upgrade

- 5.2.2 Exporting All Oracle BAM 11g Artifacts from the Existing Domain

- 5.2.3 Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

- 5.2.4 Creating a Complete Backup of the Oracle BAM 11g Domain

- 5.3 Upgrading a SOA with Oracle BAM Domain to 12c

- 5.4 Post-Upgrade Configuration Tasks

- 5.5 Extending the SOA Domain with Oracle BAM 12c

- 5.5.1 Migrating 11g Monitor Express to Process Star Schema

- 5.5.2 Generating 11g Compatible Process Star Schema Data Views in 12c (Optional)

6 Upgrading Oracle Service Bus Without Oracle SOA

- 6.1 Understanding the Oracle Service Bus Upgrade to 12c

- 6.2 Upgrading Multiple Components that use UMS in a Single OSB Domain (Not Supported)

- 6.3 Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)

- 6.3.1 Creating Schemas for Oracle Service Bus

- 6.3.2 Deploying Oracle Web Services Manager Policy Manager in Your 11g Environment

- 6.3.3 Exporting Services, Projects and Resources when Upgrading Oracle Service Bus

- 6.3.4 Deleting All Services, Projects and Resources

- 6.4 Migrating Resources from Previous Releases

- 6.5 Installing the Oracle Service Bus

- 6.6 Upgrading an OSB Domain (Without SOA)

- 6.7 Reconfiguring an OSB Domain

- 6.8 Upgrading the WebLogic Component Configurations

- 6.9 Performing Post-Upgrade Tasks for Oracle Service Bus

- 6.9.1 Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

- 6.9.2 Importing Domain Configuration Data

- 6.9.3 Importing Security Configurations

- 6.9.4 Upgrading Your XQuery Resources

- 6.9.5 Managing Oracle Service Bus Console Users in Enterprise Manager

- 6.9.6 Understanding 12c Split-Joins

7 Upgrading SOA with SOA Core Extension 12c from AIAFP 11g

- 7.1 Upgrading to SOA Core Extension 12c (12.1.3)

- 7.2 Performing Post-Upgrade Tasks for SOA Core Extension

- 7.2.1 Removing Obsolete AIA Users and Groups from SOA Core Extension (Optional)

8 Performing Post-Upgrade Tasks

- 8.1 Performing Post-Upgrade Tasks

- 8.1.1 Reapplying Start Script Properties for JVM

- 8.1.2 Reapplying Customizations to setDomainEnv

- 8.1.3 Reapplying Customizations to XEngine Configuration Files

- 8.1.4 Copying Custom XPath Classes

- 8.1.5 Recreating Partition-Specific Roles for Application Roles and Policies

- 8.1.6 Migrating Java Keystore (JKS) to OPSS KeyStore Services (KSS)

- 8.1.7 Starting and Stopping Servers

- 8.1.8 Displaying Composite Instances in Enterprise Manager

- 8.1.9 Upgrading Business Process Management (BPM) Metadata

- 8.1.10 Configuring an Oracle Fusion Middleware 12c Audit Data Store

- 8.1.11 Upgrading ServerSocket with Remote Clients

- 8.1.12 Reconfiguring Threads for SOA 12c

- 8.2 Verifying that the Upgraded Components Work as Expected

- 8.2.1 Verifying the Domain Component Configurations Upgrade

- 8.2.2 Verifying the Database Schema Upgrade Succeeded

- 8.2.3 Understanding the Flow Trace Changes in 12c

9 Administering and Monitoring the Upgrade of SOA Instances

- 9.1 Understanding the Instance Upgrade Process

- 9.2 Understanding Instance Upgrade Background Jobs

- 9.3 Using Purge Scripts Before You Upgrade

- 9.4 Using the Upgrade Administration Scripts

- 9.4.1 Accessing the Upgrade Scripts Menu

- 9.4.2 Running the Administration Scripts

- 9.5 Configuring the Administration Scripts

- 9.5.1 Changing Background Control Job Execution Schedule (Option 5)

- 9.5.2 Enabling and Disabling Background Control Job (Option 6)

- 9.5.3 Setting Control Job Parameters (Option 7)

- 9.5.4 Resetting Errored 11g instances (Option 9)

- 9.6 Stopping Upgrade Sessions and Jobs

- 9.7 Restarting an Incomplete Upgrade

- 9.8 Monitoring Upgrade Status with SQL Queries

- 9.9 Monitoring Upgrade Status with Fusion Middleware Control

- 9.9.1 Verifying Data Migration is Complete

- 9.9.2 Managing an Incomplete (Stopped) Upgrade

- 9.9.3 Viewing Instances that Faulted During the Upgrade

- 9.9.4 Viewing Instances Created Prior to Composite Redeployment

- 9.10 Resolving Instance Upgrade Errors

A Troubleshooting the Upgrade

- A.1 Reviewing the Release Notes

- A.2 Resolving Server Start Errors

- A.3 Recovering From a Failed Upgrade

- A.4 Recovering from a Failed BAM Upgrade

- A.4.1 Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration

- A.4.2 Error Handling for UNIX Operating Systems

- A.4.3 Error Handling for Windows Operating Systems

- A.5 Rewiring Components After OWSM Cluster Upgrade

- A.6 Encryption Issues During Upgrade

- A.7 Troubleshooting Oracle Service Bus

- A.7.1 HTTP 404 Error After OSB Upgrade with OHS as Cluster Frontend Host

- A.7.2 HTTP 404 Error When Accessing OSB Console

- A.8 Upgrading Unsupported Domains with the Upgrade Assistant

- A.9 Business Rules Audit Trail Not Showing After Instance Upgrade

- A.10 Resolving a Coherence Cache Exception

- A.11 WSDL Generated Missing Elements for Custom Exception

- A.12 Connecting to the ServerSocket through Remote Clients

Preface

This guide provides instructions for upgrading and redeploying your Oracle SOA Suite 11g applications to Oracle SOA Suite and Business Process Management 12c.

Audience

This document is intended for administrators who are familiar with Oracle Fusion Middleware installation, upgrade, and administration tasks.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

The following documents provide important pre-upgrade information and should be used in conjunction with the information documented in this guide:

- Planning an Upgrade of Oracle Fusion Middleware

- Understanding Oracle Fusion Middleware

- Upgrading with the Upgrade Assistant

- Upgrading Oracle WebLogic Server

- Upgrading to the Oracle Fusion Middleware Infrastructure

- Upgrading a Standalone Oracle HTTP Server

- Administering Oracle User Messaging Service

- Oracle Fusion Middleware Upgrade Guide for Oracle Enterprise Repository

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

What's New in This Guide

The following topics introduce the new and changed features of the Oracle Fusion Middleware upgrade tools and processes.

It also provides information about this book and provides pointers to additional information.

New and Changed Features for Fusion Middleware 12c

Before you begin the upgrade to SOA 12c, review the new features and changes available in Oracle Fusion Middleware 12c. In particular, refer to the following sections in Understanding Oracle Fusion Middleware:

- New and Changed Features for 12c (12.1.3)

- New and Deprecated Terminology for 12c (12.1.3)

- What is the WebLogic Management Framework?

- Oracle Fusion Middleware 12c (12.1.3.0.0) SOA Suite and Business Process Management is the first SOA and BPM 12c release and depends on the Oracle Fusion Middleware Infrastructure 12c (12.1.3) distribution.
NOTE: Oracle SOA Suite and BPM 12c (12.1.3) has a dependency on the Oracle Fusion Middleware Infrastructure 12c (12.1.3). You must install the Oracle Fusion Middleware Infrastructure 12c (12.1.3) before upgrading to Oracle Fusion Middleware 12c (12.1.3.0.0) SOA Suite and Business Process Management.

For more information, see Installing and Configuring the Oracle Fusion Middleware Infrastructure.

- In 12c, Oracle Fusion Middleware uses a new Reconfiguration Wizard, which upgrades your existing 11g domains to 12c.
For more information, see "Reconfiguring a Domain" in Upgrading Oracle WebLogic Server.

1 Introduction to Oracle SOA Suite and Business Process Management Upgrade

The procedures in this guide explain how to upgrade an existing production-version SOA Suite 11g domain, and the Oracle Fusion Middleware component configurations in that domain, to SOA Suite and Business Process Management 12c (12.1.3).

Note:
An upgrade to Oracle SOA Suite and Business Process Management 12c (12.1.3) requires the installation of Fusion Middleware Infrastructure 12c (12.1.3).
Before you begin the SOA upgrade, see Installing and Configuring the Oracle Fusion Middleware Infrastructure and Upgrading to the Oracle Fusion Middleware Infrastructure.

This chapter includes the following sections:

- Understanding In-Place versus Out-of-Place Upgrades

- Understanding the Starting Points for a SOA 12c (12.1.3) Upgrade

- Understanding the Interoperability and Compatibility Restrictions Before You Upgrade

- Understanding the Standard Upgrade Topologies

- Understanding Domain Upgrade Restrictions

- Understanding SOA Composite Upgrades

- Understanding Schema Upgrade Restrictions

- Understanding the SOA Suite and BPM Upgrade Process Flow

Caution:
Some of the 11g components in your SOA domain may not be supported for an upgrade to Fusion Middleware 12c (12.1.3). It is imperative that you review the Understanding Interoperability and Compatibility guide before you begin any upgrade.
For more information, see Section 1.3, "Understanding the Interoperability and Compatibility Restrictions Before You Upgrade".

1.1 Understanding In-Place versus Out-of-Place Upgrades

When upgrading your SOA Suite 11g environment to SOA Suite and Business Process Management 12c (12.1.3), you should understand how your pre-upgrade environment will be affected by the upgrade. For example, schemas and domain directory upgrades are performed "in place" which updates the existing 11g files during the upgrade. The 12c (12.1.3) Oracle Home binaries are upgraded "out of place" as the binaries are installed in a new directory.

The upgrade to 12c (12.1.3) includes the midtier and the schemas. You cannot perform a midtier-only or schema-only upgrade.

The list below describes how the upgrade is performed for the following Infrastructure and SOA Suite components:

- Oracle WebLogic Server, JRF and SOA Oracle Home Binaries - Upgraded Out of Place
You will install the Oracle Infrastructure 12c (12.1.3) (which includes WebLogic Server and JRF) and SOA Suite and Business Process Management 12c (12.1.3) distribution binaries in a new Oracle home. The upgrade of binaries is considered "out of place" as the 11g binaries are not overwritten.

- Schemas - Upgraded In Place
The 11g schemas are upgraded to 12c "in place" which means that the Upgrade Assistant updates and overwrites the schemas during the upgrade process. The servers must be down during this process.

- Instances - Migrated during the schema upgrade
The upgrade of active and closed instances from 11g to 12c happens automatically as part of the schema upgrade. You can manage the upgrade using administration scripts.

- Domain Directory Reconfiguration - Upgraded In Place
The existing SOA domain is upgraded "in place". During the upgrade you will identify the location of the 11g SOA domain and the 11g domain will be reconfigured to point to the new SOA 12c (12.1.3) home directory.

- Domain Component Configuration - Upgraded In Place
After the reconfiguration of the 11g SOA domain, the Upgrade Assistant is used again to upgrade any remaining domain component configurations that require an upgrade in the new SOA 12c (12.1.3) home directory.

Note:
Oracle recommends that you perform your domain upgrades in place. However, if an out-of-place domain upgrade is required, see "Performing an Out-of-Place Domain Directory Upgrade".

1.2 Understanding the Starting Points for a SOA 12c (12.1.3) Upgrade

The Oracle SOA Suite and Business Process Management 12c (12.1.3.0.0) release is the first release of SOA and BPM in 12c. You can upgrade to SOA 12c (12.1.3) from the following production 11g starting points:

- SOA 11g (11.1.1.7)

- SOA 11g (11.1.1.6)

- SOA 11g (11.1.1.5) or earlier - Not Supported
If you are running SOA 11g (11.1.1.5) or earlier, you must first upgrade to SOA 11g (11.1.1.6 or 11.1.1.7) before you can upgrade. For more information, see Oracle® Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter Portal, and ADF in the Oracle Fusion Middleware 11g (11.1.1.7) upgrade documentation library.

- Oracle Application Integration Architecture Foundation Pack 11g
If you are currently running Oracle Application Integration Architecture Foundation Pack (AIAFP) 11g Release 1 (11.1.1.7), you must patch to RUP 2 (17553612) and one off patch (18464591) or later before you attempt to upgrade.

If you are running Oracle Application Integration Architecture Foundation Pack 11g (11.1.1.6), you must apply RUP5 (17423167).

1.3 Understanding the Interoperability and Compatibility Restrictions Before You Upgrade

Before you begin the upgrade process from SOA Suite and BPM 11g to 12c, you must read and understand how all of the components within your 11g domain will be impacted by the upgrade. Understanding Interoperability and Compatibility provides a detailed matrix of which components can and cannot be upgraded together. In general, you cannot upgrade a domain that contains components that are not yet available in Oracle Fusion Middleware 12c (12.1.3). There are other restrictions on the components that can be upgraded to 12c (12.1.3) and you need to be sure that you have reviewed this information carefully before you proceed with the upgrade.

The following list describes some of the restrictions when upgrading SOA Suite to 12c (12.1.3). This is NOT a complete list.

- If your 11g domain includes WebCenter:
If SOA is used to expose human workflow tasks as portlets, then SOA has a dependency on Oracle WebCenter libraries and the domain cannot be upgraded. Oracle WebCenter Portal cannot be upgraded to 12c (12.1.3.) It will be available in a future Fusion Middleware release.

- If your 11g domain includes Oracle Service Registry (OSR) or Oracle Enterprise Repository (OER):
You cannot upgrade a domain that includes OSR or OER to 12c (12.1.3).

Note:
Carefully review all of the upgrade restrictions in Understanding Interoperability and Compatibility before you upgrade.

1.4 Understanding the Standard Upgrade Topologies

This upgrade documentation provides detailed instructions for upgrading two typical SOA Suite configurations. These topologies are referred to as the Oracle Fusion Middleware 12c standard upgrade topologies. Specifically, for the purposes of this guide, a standard installation topology consists of a WebLogic Server domain that contains an Administration Server and a cluster containing two Managed Servers or a standalone domain.

A standalone domain is a container for system components, such as Oracle HTTP Server. It has a directory structure similar to an Oracle WebLogic Server domain, but it does not contain an Administration Server or Managed Servers. It can contain one or more instances of system components of the same type, such as Oracle HTTP Server, or a mix of system component types. For more information on the standalone topology, see "What Is a Standalone Domain?" in Understanding Oracle Fusion Middleware.

Your actual topology may vary, but the topologies described in this guide provide an example that can be used as a guide to upgrade similar SOA Suite component topologies. For more information on the standard topologies and building an enterprise deployment, see Planning an Installation of Oracle Fusion Middleware.

For more information on setting up the 12c SOA Suite topologies, see:

- Installing and Configuring Oracle SOA Suite Foundation and Business Process Management

- Enterprise Deployment Guide for Oracle SOA Suite

1.5 Understanding Domain Upgrade Restrictions

Some domains cannot be upgraded to 12c (12.1.3) because of known limitations and configuration changes from previous Fusion Middleware releases. Review the following to ensure your domains are not impacted by these restrictions. Domains that are impacted by these restrictions cannot be upgraded.

- Section 1.5.1, "Upgrading a Domain that was Created Using Test-to-Production Prior to Release 11g (11.1.1.6) (Not Supported)"

- Section 1.5.2, "Upgrading an Unclustered Environment with SOA and BAM Managed Servers (Not Supported)"

1.5.1 Upgrading a Domain that was Created Using Test-to-Production Prior to Release 11g (11.1.1.6) (Not Supported)

If you created a domain using test-to-production scripts prior to Fusion Middleware Release 11g (11.1.1.6), then you will not be able to upgrade this domain to 12c (12.1.3). When you run the Upgrade Assistant to upgrade schemas in the domain, the Upgrade Assistant will run a check to see if the domain can be upgraded. Domains created prior to release 11.1.1.6 using the test-to-production procedure should not be upgraded.

If you have a domain that was created prior to 11.1.1.6.0 using test-to-production and you need to upgrade the domain to 12c (12.1.3), contact Oracle Support for information on how to perform this upgrade. Do NOT attempt to use the Upgrade Assistant to upgrade the schemas within this domain. They will have to be restored from backup as the upgrade will fail.

1.5.2 Upgrading an Unclustered Environment with SOA and BAM Managed Servers (Not Supported)

This section describes important changes to UMS configuration in 12c (12.1.3).

In Oracle Fusion Middleware 11g, UMS configuration was configured per server. It did not matter if the server was clustered or unclustered, every UMS server acted independently. This meant that every server had to be individually configured, and it did not share any configuration with other UMS servers. You could, however, configure two UMS servers identically for a high availability system. For more information about configuring a server for high availability, see the High Availability Guide.

In 12.1.3, however, the UMS configuration is domain or cluster wide. Configuration is NOT per server. For example: all UMS servers in a cluster share the same configuration. If clusters are not used, all UMS servers in the domain share the same configuration.

Note that you can upgrade an 11g clustered system with one (or many) SOA servers in cluster A, and one (or many) BAM servers in cluster B. However, upgrading clustered SOA servers and a unclustered BAM server, is not recommended. You should not mix unclustered UMS servers and clustered UMS servers in the same domain.

For more information on upgrading a domain with BAM, see Chapter 5, "Upgrading SOA with Oracle Business Activity Monitoring (Oracle BAM)".

For more information on upgrading User Messaging Service, see "Upgrading User Messaging Service from 11g to 12c" in Administering Oracle User Messaging Service.

For more information on creating clusters, see "Clusters" in Creating WebLogic Domains Using the Configuration Wizard.

1.6 Understanding SOA Composite Upgrades

When upgrading SOA composites to Oracle 12c (12.1.3), you will see the following changes to the artifacts in your upgraded environment. Note that this is not a complete list of the post-upgrade changes, but identifies some of the important changes.

Note:
SOA 11g composites will continue to work after upgrading to 12c (12.1.3). You will not have to make any modifications after the upgrade. This section describes the changes you will see in your upgraded environment.

- Application Level Changes

- A new application-level pom.xml file is created. This file can be used for Maven integration.

- The <application>.jws file will be updated with new a version.
For example:

<value n="oracle.ide.model.Project" v="11.1.1.1.0;12.1.3.0.0"/>

- Project Level Changes

- A new (empty) folder structure is created for new 12c artifacts. The 11g composite artifacts continue to exist in the 11g folder structure post migration and new artifacts will be created in the same 11g(or 12c) structure.
For example, if new artifacts are added post upgrade, then the created files will be in the new 12c directory structure:

/SOA
WSDLs
Schema
Transformations
Events

- A new project-level pom.xml file is created. This file can be used for Maven integration.

- The <project>.jws file will be updated with new a version.
For example:

<value n="oracle.ide.model.Project" v="11.1.1.1.0;12.1.3.0.0"/>

- The <project>.jpr will be updated with the new applicable technologies.
For example:

<hash n="oracle.ide.model.TechnologyScopeConfiguration">
<list n="technologyScope">
<string v="Maven"/>
<string v="SOA"/>
<string v="WSDL"/>
<string v="WSPolicy"/>
<string v="XML"/>
<string v="XML_SCHEMA"/>
</list>
</hash>

- <project>.jpr will be updated with any new migrator versions.
For example:

<value n="oracle.jbo.dt.jdevx.deployment.JbdProjectMigrator" v="11.1.1.1.0;11.1.2.0.0"/>

- Composite Level Changes

- Composite.xml will be updated with the original version and version attributes.
For example:

<property name="originalProductVersion" type="xs:string" many="false">11.1.1.9.0</property>

<property name="productVersion" type="xs:string" many="false">12.1.3.0.0</property>

- The componentType files are not used in 12c. Corresponding entries will be made in Composite.xml files

1.7 Understanding Schema Upgrade Restrictions

Some schema table configurations cannot be upgraded using the standard upgrade procedures described in this guide. Review the following restrictions before attempting to upgrade your schemas:

1.7.1 Upgrading Partitioned Schema Tables (Not Supported)

If your SOA schema tables are partitioned, and you want to upgrade to 12c (12.1.3), contact Oracle Support for instructions.

Partitioned schema tables cannot be upgraded using the process described in this guide.

1.8 Understanding the SOA Suite and BPM Upgrade Process Flow

This section describes the high-level steps for upgrading the Oracle Fusion Middleware SOA Suite:

Table 1-1 Task Descriptions for Upgrading Oracle SOA Suite

Step

Description

More Information

1

Review the Oracle Fusion Middleware 12c Concepts Guide and the Planning an Upgrade Guide before you begin the upgrade.

These guides provide important information about upgrading to Fusion Middleware12c. You should understand the new 12c terminology changes and new requirements.

See Understanding Oracle Fusion Middleware

See Planning an Upgrade of Oracle Fusion Middleware

See Understanding Interoperability and Compatibility

2

Back up your existing SOA 11g environment. If the upgrade fails for any reason, you will have to restore your environment from backup.

See Backing Up Your Existing Oracle Fusion Middleware 11g Environment

3

Perform all of the standard required pre-upgrade tasks as well as the component-specific pre-upgrade tasks for the components you are upgrading.

See Performing the Required Pre-Upgrade Tasks for SOA Suite and BPM.

NOTE: In addition to the general pre-upgrade tasks, each product may have component-specific upgrade tasks documented in the component-specific chapters.

4

If your policy store is file-based in 11g, you must reassociate to a database-based policy store before you upgrade.

If your policy store is already database-based, skip to the next step.

See Reassociating a File-Based Policy Store Before Upgrade

If you are using an Oracle Internet Directory-based store, see Using an Oracle Internet Directory-based Security Store

NOTE: After you have reassociated your policy store, Oracle recommends that you execute another backup before continuing with the upgrade.

5

Install Fusion Middleware Infrastructure 12c (12.1.3) in a new Oracle home on the same host as the 11g production deployment.

In 12c, Oracle home is used to describe the 11g Middleware home. There is no Middleware home in 12c.

See Installing and Configuring the Oracle Fusion Middleware Infrastructure

NOTE: Install but do not use the Configuration Wizard to configure the domain. You will use the Reconfiguration Wizard during the upgrade.

6

Install SOA Suite and Business Process Management 12c (12.1.3) and any integrated SOA-integrated distributions (Oracle HTTP Server, Oracle Service Bus, etc).

See Installing Oracle SOA Suite and Business Process Management

NOTE: You must install the Fusion Middleware 12c (12.1.3) distributions for each SOA-integrated product you are upgrading. For example, if you are upgrading a SOA 11g environment with Oracle Service Bus, you must acquire the Oracle Service Bus 12c (12.1.3) distribution as well as the Oracle SOA Suite and BPM 12c (12.1.3) distribution. A complete list of distributions is provided in Planning an Installation of Oracle Fusion Middleware.

7

Shut down the 11g Environment (stop all Administration and Managed Servers)

See Stopping Servers and Processes

8

Launch the 12c (12.1.3) Repository Creation Utility (RCU) and create the new required 12c schemas.

See Creating the Required Schemas Before You Upgrade

9

Run the Upgrade Assistant to upgrade the 11g database schemas and to upgrade all active (in flight) instance data to 12c (12.1.3).

See Upgrading SOA Schemas Using the Upgrade Assistant

NOTE: The upgrade of active instance data is started automatically when running the Upgrade Assistant. Once the data is successfully upgraded to the new 12.1.3 environment, you can close the Upgrade Assistant. The closed instances will continue to upgrade through a background process.

For more information, see Administering and Monitoring the Upgrade of SOA Instances.

10

You can manage and administer the ongoing upgrade of closed instances using the administration SQL scripts or Oracle Fusion Middleware Enterprise Manager Control.

See Administering and Monitoring the Upgrade of SOA Instances.

11

If the 11g SOA domain that you are upgrading includes BAM, you must complete all of the pre-upgrade tasks before you run the Reconfiguration Wizard. If you do not complete these steps before you attempt to run the Reconfiguration Wizard will result in a failed upgrade.

See Upgrading SOA with Oracle Business Activity Monitoring (Oracle BAM)

NOTE: Business Activity Monitoring (BAM) has been completely redesigned in 12c, and requires additional steps before reconfiguring the domain and after the upgrade.

10

Run the Reconfiguration Wizard to reconfigure the domain and node manager.

See Reconfiguring the Domain Using the Reconfiguration Wizard

11

Run the Upgrade Assistant (again) to upgrade domain configurations.

See Upgrading the Domain Component Configurations Using the Upgrade Assistant

12

Perform the required post-upgrade tasks.

See Performing Post-Upgrade Tasks

13

Start the Administration and Managed Servers and node manager (if needed).

See Starting and Stopping Servers

14

Make sure that all of the upgraded components are working as expected.

See Verifying the Domain Component Configurations Upgrade

2 Performing the Required Pre-Upgrade Tasks for SOA Suite and BPM

This chapter describes the required pre-upgrade tasks for most upgrades. Product-specific pre-upgrade tasks are described in the other chapters of this book.

- Section 2.1, "Performing General Pre-Upgrade Tasks"

- Section 2.2, "Upgrading Security to 12.1.3"

- Section 2.3, "Installing the 12c (12.1.3) Infrastructure Distributions Before Upgrade"

- Section 2.4, "Installing SOA Integrated Distributions"

- Section 2.5, "Preparing to Upgrade Schemas"

NOTE:
Depending on which Oracle SOA 11g products are being upgraded, you may need to perform additional pre-upgrade tasks.
The tasks in this chapter describe the general pre-upgrade tasks required when upgrading to SOA Suite and BPM 12c (12.1.3). Review the product-specific upgrade chapters for each product that is being upgraded to determine if additional tasks are required for your upgrade.

- Chapter 5, "Upgrading SOA with Oracle Business Activity Monitoring (Oracle BAM)"

- Chapter 6, "Upgrading Oracle Service Bus Without Oracle SOA"

- Chapter 7, "Upgrading SOA with SOA Core Extension 12c from AIAFP 11g"

2.1 Performing General Pre-Upgrade Tasks

This section includes pre-upgrade tasks that apply to any SOA, Business Process Management, or integrated products being upgraded to 12c (12.1.3). Perform only those tasks that apply to your environment.

Caution:
Failure to properly prepare for an upgrade may lead to unrecoverable errors and upgrade failures. Make sure that you have completed ALL applicable pre-upgrade tasks before beginning the upgrade.

The general pre-upgrade tasks include the following:

Pre-Upgrade Task

More Information

CAUTION: Oracle strongly recommends that you perform the upgrade on a cloned copy of your production environment before you upgrade your actual production environment.

Section 2.1.1, "Creating, Upgrading, and Testing a Development Copy of Your Production Environment"

Create a complete backup of your existing environment before you start any pre-upgrade procedures.

Section 2.1.2, "Backing Up Your Existing Oracle Fusion Middleware 11g Environment"

Back up the database that hosts the schema repository before you upgrade.

Section 2.1.3, "Backing Up Your Database"

Run 11g Purge scripts before starting the upgrade to reduce downtime during the upgrade.

Section 2.1.4, "Purging Unused Data"

Make sure that you have sufficient disk space

Section 2.1.5, "Ensuring You Have Sufficient Free Space"

Plan for using enhanced encryption.

Section 2.1.6, "Using Enhanced Encryption (AES 256)"

Backup your setDomainEnv file.

Section 2.1.7, "Maintaining Custom setDomainEnv Settings"

Upgrade to 64-bit operating system.

Section 2.1.8, "Upgrading from a 32-Bit to a 64-Bit Operating System"

Verify that your Oracle database is supported (version 11.2.0.3 or higher).

Section 2.1.9, "Upgrading and Preparing the Fusion Middleware Database"

Verify that your tablespaces are sized appropriately (insufficient sizing will result in a failed upgrade).

Section 2.1.10, "Adding Datafiles to the SOAINFRA and IAS_TEMP Tablespaces"

Complete the required pre-upgrade tasks for User Messaging Service (UMS) if you are upgrading UMS as part of your SOA Suite upgrade.

Section 2.1.11, "Upgrading User Messaging Service (UMS)"

Complete the required pre-upgrade tasks for Oracle Service Bus (OSB) if you are upgrading OSB as part of your SOA Suite upgrade.

Section 2.1.12, "Upgrading a SOA Domain with Oracle Service Bus (OSB)"

Upgrade your standalone Oracle HTTP Server (if necessary).

Section 2.1.13, "Upgrading a Standalone Oracle HTTP Server"

Reassociate any file-based policy stores to database-based stores.

Section 2.1.14, "Reassociating a File-Based Policy Store Before Upgrade"

Understand the schema requirements when using an Oracle Internet Directory-based security store.

Section 2.1.15, "Using an Oracle Internet Directory-based Security Store"

Install Oracle SOA Suite or Oracle Business Process Management Quick Start for Developers if you are upgrading custom applications

Section 2.1.16, "Upgrading Custom Applications Using Oracle JDeveloper 12c"

Stop all 11g FMW servers and processes before you launch the Upgrade Assistant.

Section 2.1.17, "Stopping Servers and Processes"
NOTE: All middle tier servers, such as soa_server1, MUST be stopped before starting the Upgrade Assistant.

2.1.1 Creating, Upgrading, and Testing a Development Copy of Your Production Environment

Oracle strongly recommends that you create a copy of your actual production environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.

For more information on creating a test environment to use to roll out an upgrade, see "Moving from a Test to a Production Environment" in Administering Oracle Fusion Middleware.

Upgrades cannot be reversed. In most cases, if an error occurs, you must stop the upgrade and restore the entire environment from backup and begin the upgrade process from the beginning. Identifying potential upgrade issues in a development environment can eliminate unnecessary downtime.

Performing pre-upgrade testing on a cloned environment provides important data that can be applied to your overall production upgrade plan. Planning an Upgrade of Oracle Fusion Middleware provides detailed information on forming and executing a complete pre-upgrade plan.

Additional benefits of running an upgrade in a cloned production environment include the following:

- Uncover and correct any upgrade issues.

- Practice completing an end-to-end upgrade.

- Understand the upgrade performance and how purge scripts can help.

- Understand the time required to complete the upgrade.

- Understand the database resource usage (such as temporary tablespace; PGA, etc).

2.1.2 Backing Up Your Existing Oracle Fusion Middleware 11g Environment

Before you upgrade SOA 11g to SOA 12.1.3, you must back up your existing 11g environment.

If the upgrade fails you may have to restore your environment from the pre-upgrade backups. While planning your backup strategy, make sure that you include the following in your SOA backups:

- Schema version registry table

- All product-specific schemas

- Domain and application directories

- Inventory directory created by the installer

A complete list of backup considerations and procedures is described in "Backup and Recovery Strategies for Upgrade" in the Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware. Make sure that you have reviewed this information and executed a complete backup before starting the upgrade.

2.1.3 Backing Up Your Database

As with any database repository upgrade, standard procedure dictates that you back up your database before you upgrade to a new database version.

Note that you should also consider backing up the database again, after you have successfully upgraded to a new database version. This way, your backup will reflect the newly upgraded state of the database.

For more information on backing up your database, see "Backup Strategies for Database Upgrades" in Planning an Upgrade of Oracle Fusion Middleware.

2.1.4 Purging Unused Data

Purging unused data before an upgrade can optimize the upgrade process by reducing the number of instances, fault alerts, or adapter reports that will be upgraded to the new 12c deployment. Purging your closed instances can greatly improve the duration of the upgrade. Note, however, that if you purge your closed instances, you will not be able to view or report on them using Enterprise Manager 12c.

Caution:
Do not start the Upgrade Assistant while the purge scripts are running. Wait until the purge is complete before starting the upgrade process. The upgrade will fail if the purge scripts are running while using the Upgrade Assistant to upgrade your schemas. For more information on using purge scripts with the Upgrade Assistant, see Section 9.3, "Using Purge Scripts Before You Upgrade".

For more information on using Auto Purge or purge scripts, see "Managing Database Growth" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

Note:
If a large amount of data needs to be purged, consider partitioning tables or employing other data optimization strategies. Using the scripts to remove large amounts of data may impact performance.
For more information, see "Developing a Purging and Partitioning Methodology" and "Developing a Database Growth Management Strategy" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

2.1.5 Ensuring You Have Sufficient Free Space

Before you begin the upgrade it is recommended that you secure sufficient free space to complete the upgrade.

F or a typical upgrade, the following is recommended:

- At least 25% free table space

- At least 800MB free temp space

2.1.6 Using Enhanced Encryption (AES 256)

The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs allow developers to easily integrate security mechanisms into their application code.

Some of the security algorithms used in Fusion Middleware 12.1.3 require additional policy files for the JDK. If you plan to use enhanced encryption (such as AES 256), Oracle recommends that you apply these policy files to the JDK before you upgrade. For more information, see the following:

Java Cryptography Architecture Oracle Providers Documentation

If you do not apply these policy files to the JDK before you begin the upgrade, the upgrade can fail and you will have to restore the entire pre-upgrade environment and start the upgrade from the beginning.

2.1.7 Maintaining Custom setDomainEnv Settings

Changes made to the setDomainEnv script - or any other startup script - before an upgrade will be overwritten by new, regenerated scripts during the domain reconfiguration process. Consider creating a separate file to store your domain customizations before you upgrade as described in "Maintaining Your Custom setDomainEnv Settings (Optional)".

Note:
If you are unable to create the setUserOverrides script before an upgrade, you will need to reapply your settings as described in "Reapplying Customizations to setDomainEnv".

2.1.8 Upgrading from a 32-Bit to a 64-Bit Operating System

If you are running a 32-bit operating system, then you must upgrade your 32-bit environment to a 64-bit software environment before you upgrade. Make sure to validate the migration to ensure all your Oracle Fusion Middleware 11g software is working properly on the 64-bit machine, and only then perform the upgrade to Oracle Fusion Middleware 12c.

For detailed instructions on how to upgrade your 32-bit system to 64-bit, see "Upgrading from a 32-Bit to a 64-Bit Operating System" in Planning an Upgrade of Oracle Fusion Middleware.

2.1.9 Upgrading and Preparing the Fusion Middleware Database

It is imperative that you understand the Oracle Database requirements for upgrading to Oracle SOA Suite and BPM 12.1.3, and ensure that the database hosting Oracle Fusion Middleware is supported and has sufficient space to perform an upgrade. You must have a supported database configured with the required schemas before you can run Fusion Middleware 12c (12.1.3). Always refer to the latest database certification matrix for the most current information.

Note the following important changes for 12c (12.1.3):

- As of 12c (12.1.3), the only supported database is Oracle. Oracle XE is not supported. For more information see "Upgrading and Preparing Your Oracle Databases for 12c (12.1.3)" in the Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

- This release of Oracle Fusion Middleware only supports schemas in a byte-mode database. The NLS_LENGTH_SEMANTICS initialization parameter, on the database where the schemas reside, must be set to BYTE; setting this parameter to CHAR is not supported.
If NLS_LENGTH_SEMANTICS is set to CHAR, then the Upgrade Assistant will report the following exception:

JDBC SQLException - ErrorCode: 1450SQLState:72000 Message: ORA-01450: maximum key length (6398) exceeded

To check the values of this parameter using SQL*Plus, you can use the show parameters command:

prompt> sqlplus "sys/<password> as sysdba"SQL> show parameters nls_length_semantics

Replace <password> with the actual password for the SYS user.

Alternatively, you can check the values by querying the V$PARAMETER view:

prompt> sqlplus "sys/password as sysdba"SQL> select name,value from v$parameter;

For more information, refer to you database administration documentation.

Note:
In 11g it was possible to run Oracle Service Bus without a database as the SOA schema was not required. In 12c, however, you must have a supported database configured with the required SOA schemas before you can run OSB 12c (12.1.3). For more information, see Section 2.5, "Preparing to Upgrade Schemas".

2.1.10 Adding Datafiles to the SOAINFRA and IAS_TEMP Tablespaces

While important for all tablespaces, it is especially important to make sure that the 11g SOAINFRA tablespace and IAS_TEMP tablespace are sized for a successful upgrade. Oracle recommends that you add more data files to the existing SOA database tablespace to prevent a failed upgrade.

Two sample commands are provided below. Size the files according to your own use case scenarios.

To add datafiles to SOAINFRA tablespace:

Connect to the database as sysdba and run the following command:

alter tablespace <PREFIX>_SOAINFRA add datafile '<DB_HOME>/oradata/orcl/<New_SoaInfra_DBF_FileName>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

To add tempfiles to IAS_TEMP tablespace:

Connect to the database as sysdba and run the following command:

alter tablespace PREFIX_IAS_TEMP add tempfile '<DB_HOME>/oradata/orcl/<New_iastemp_dbf_filename>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

For more information on sizing your tablespaces before upgrade, see "Creating Datafiles and Adding Datafiles to a Tablespace" in the Oracle Database Administrator's Guide.

CAUTION:
Once a database schema upgrade has failed due to a sizing error, you cannot simply add more disk space and retry the upgrade. The schemas have been left in an inconsistent state and may have been marked "INVALID". You cannot recover from this error without restoring the original, pre-upgrade environment from backups.

2.1.11 Upgrading User Messaging Service (UMS)

If you are Upgrading User Messaging Service from 11g to 12c, you may need to perform additional pre-upgrade tasks such as manually copying the configuration files from the managed server to the Admin server.

For more information, see "Upgrading User Messaging Service" in Administering Oracle User Messaging Service.

2.1.12 Upgrading a SOA Domain with Oracle Service Bus (OSB)

If you are upgrading a SOA domain with Oracle Service Bus, you must preform several required pre-upgrade tasks. See Section 6.3, "Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)".

2.1.13 Upgrading a Standalone Oracle HTTP Server

This guide explains how to upgrade Oracle HTTP Server 11g instances that have been configured so they are "associated with" an Oracle WebLogic Server domain. The upgrade is performed as you are upgrading the domain to which the Oracle HTTP Server has been associated.

To upgrade a standalone Oracle HTTP Server instance (one that is not associated with an 11g domain) refer to Upgrading a Standalone Oracle HTTP Server.

2.1.14 Reassociating a File-Based Policy Store Before Upgrade

If you are using a file-based policy store in your existing 11g environment, you must reassociate to database-based policy store before you begin the upgrade process.

Refer to the following tasks for more information:

- Task 1, "Creating 11g OPSS and IAU Schemas"

- Task 2, "Reassociating the 11g Policy Store with the Database-Based Policy Store and OPSS Schema"

Task 1   Creating 11g OPSS and IAU Schemas

Create new 11g Oracle Platform Security Services (OPSS) and Audit Schemas (IAU) schemas in a supported Database using the 11g Repository Creation Utility.

For more information about creating 11g schemas, see "Obtaining and Running Repository Creation Utility" in the Oracle Fusion Middleware Repository Creation Utility User's Guide for 11g Release 1 (11.1.1.7.0).

Task 2   Reassociating the 11g Policy Store with the Database-Based Policy Store and OPSS Schema

If you are using a file-based policy store in your 11g environment, then reassociate the file-based store with the database-based repository and OPSS schema.

For information about reassociating a file-based policy store, see "Reassociating the OPSS Security Store" in the Oracle Fusion Middleware Application Security Guide in the 11g Release 1 (11.1.1.7.0) documentation library.

2.1.15 Using an Oracle Internet Directory-based Security Store

If you are using an Oracle Internet Directory (Oracle Internet Directory)-based security store in 11g, use the 12c Repository Creation Utility to create the new 12c OPSS schema. In the Upgrade Assistant, select the OPSS schema; the Upgrade Assistant upgrades the Oracle Internet Directory-based security store. You do not need to reassociate an Oracle Internet Directory-based security store before upgrade.

Note:
The 12c OPSS database schema is required only so you can reference the 12c schema during the reconfiguration of the domain. Your domain will continue to use the Oracle Internet Directory-based security store after the upgrade.

2.1.16 Upgrading Custom Applications Using Oracle JDeveloper 12c

If you have deployed custom applications to a SOA 11g domain, then the application deployments should function as they did in Oracle Fusion Middleware 11g after the upgrade procedure is complete.

However, if you want to take advantage of new Oracle Application Development Framework (Oracle ADF) 12c (12.1.3) features, download and install the Oracle SOA Suite or Oracle Business Process Management Quick Start for Developers.

The Quick Start for Developers distributions provide Oracle JDeveloper 12c (12.1.3) with the required extensions for developing Oracle SOA Suite and Oracle Business Process Management applications.

For more information, see "Installing Oracle SOA Suite Quick Start for Developers" in Installing SOA Suite and Business Process Management Quick Start for Developers.

2.1.17 Stopping Servers and Processes

Before running Upgrade Assistant, you must shut down ALL Oracle Fusion Middleware Managed Servers, Administration Servers, and system components (such as OHS) that may be using the schemas or configurations you want to update. Failure to do so may result in an incomplete or failed upgrade. Upgrades are performed completely 'offline'.

If you are running Node Manager, you should also stop the Node Manager. You can do this by closing the console window in which Node Manager is running, or by using the stopNodeManager WLST command.

Instructions for stopping an Oracle Fusion Middleware environment are provided in "Stopping an Oracle Fusion Middleware Environment" in Administering Oracle Fusion Middleware.

2.2 Upgrading Security to 12.1.3

Before upgrading the OPSS security store, back it up so that it can be recovered in case the upgrade fails. For details about backing up the security store, see Backing Up and Recovering the OPSS Security Store.

The upgrade procedure varies depending on the type of security store you start from. The security store to be upgraded can be file-, Oracle Internet Directory-, or DB-based. Note the procedures vary according to the type of source audit data store (file- or DB-based).

- Upgrading a DB-Based Security Store

- Upgrading an Oracle Internet Directory-Based Security Store

- Upgrading a Shared Security Store

- Upgrading a File-Based Security Store

2.3 Installing the 12c (12.1.3) Infrastructure Distributions Before Upgrade

Oracle SOA Suite and Business Process Management and the integrated SOA components require the Fusion Middleware Infrastructure and Oracle HTTP Server (if applicable). These distributions must be installed before you install and configure Oracle SOA Suite and BPM 12c (12.1.3).

2.3.1 Installing WebLogic Server and JRF Infrastructure

Before you can upgrade your existing SOA 11g components, you must first install an Oracle WebLogic Server and JRF using the 12c (12.1.3) Infrastructure distribution.

See Installing and Configuring the Oracle Fusion Middleware Infrastructure for detailed instructions.

Caution:
When installing the Infrastructure distributions, do not use the Configuration Wizard to configure the domain. You will use the new Reconfiguration Wizard to configure the 11g domain during the upgrade process.

Note:
You must have the 12c (12.1.3) Infrastructure distribution installed before you can upgrade to SOA 12c (12.1.3). The only application server that Oracle Fusion Middleware 12c (12.1.3) supports is the Oracle WebLogic Server.
If you previously installed and configured the Infrastructure components using the 12c (12.1.2) release, you must first upgrade to Infrastructure 12c (12.1.3).

For more information, see "Upgrading from a Previous Infrastructure 12c Release" in Upgrading to the Oracle Fusion Middleware Infrastructure.

2.3.2 Installing Oracle HTTP Server

If your 11g domain includes Oracle HTTP Server instances that are associated with the domain, you must install Oracle HTTP Server 12.1.3 on the following machines:

- On machines where 11g Oracle HTTP Server instances are running

- On the machine where Administration Server is running

For more information about installing Oracle HTTP Server 12.1.3, see "Installing the Oracle HTTP Server Software" in the Oracle Fusion Middleware Installing and Configuring Oracle HTTP Server.

2.4 Installing SOA Integrated Distributions

You must install the 12c (12.1.3) product distributions for each SOA 11g integrated component you will be upgrading.

Refer to the product-specific installation guides for more information:

- Installing and Configuring Oracle SOA Suite Foundation and Business Process Management

- Installing and Configuring Oracle Service Bus

- Administering Oracle User Messaging Service

- Installing and Configuring Managed File Transfer

- Installing and Configuring Oracle Event Processing

- Installing and Configuring B2B and Healthcare

Caution:
When installing the SOA 12c (12.1.3) distributions, do not use the Configuration Wizard to configure the domain. You will use the new Reconfiguration Wizard to configure the 11g domain during the upgrade process.

2.5 Preparing to Upgrade Schemas

You must determine which of the 11g schemas will be upgraded and which schemas you will need to create prior to upgrade. This section describes how to prepare your schemas for an upgrade.

- Section 2.5.1, "Using the Schema Version Registry to Identify Existing 11g Schemas"

- Section 2.5.2, "Creating the Required Schemas Before You Upgrade"

Note:
As part of the schema upgrade, all active and closed instances will be automatically upgraded. You will not lose your active or "in flight" 11g work flow instances during the upgrade.
If you do not want to upgrade instances, you must prevent the instance upgrade before you start the Upgrade Assistant.

For more information, See Chapter 9, "Administering and Monitoring the Upgrade of SOA Instances".

2.5.1 Using the Schema Version Registry to Identify Existing 11g Schemas

If you used the Repository Creation Utility (RCU) to create your 11g schemas, then you can connect to the database as SYSTEM, or as any other database user with DBA privileges, and use the following SQL command to see a list of the Oracle Fusion Middleware 11g schemas that are already installed in your database:

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

The schemas that can be upgraded to 12.1.3 must be at versions 11.1.1.7.x or 11.1.1.6.x. You can use this list to review your domain schemas and to help you determine which schemas to create and which schemas you need to upgrade.

For a complete list of schemas that are available for upgrade to Oracle Fusion Middleware 12c (12.1.3), see "Identifying Schemas that Can be Upgraded with the Upgrade Assistant" in Upgrading with the Upgrade Assistant.

2.5.2 Creating the Required Schemas Before You Upgrade

After installing your 12.1.3.0.0 components, you will need to create the new 12c required schemas in a supported database certified for use with this release of Oracle Fusion Middleware. Table 2-1 describes which schemas should be created based on the upgrade:

Table 2-1 Required Schemas for SOA and SOA integrated products

If you are upgrading...

Create these 12c schemas before you upgrade...

SOA Suite (SOA)

Service Table (_STB)

Audit Services (_IAU)

NOTE: If you created a 12.1.2 version of the _STB schema, you will have to upgrade it to 12.1.3.

Business Process Monitoring (BPM)

Schemas required for SOA Suite

Business Activity Monitoring (BAM)

Schemas required for SOA Suite

And:

WebLogic Services (_WLS)

Oracle Service Bus (OSB)

SOA Infrastructure (_SOAINFRA)

Service Table (_STB)

User Messaging (_UMS)

NOTE: It is possible to install Oracle Service Bus without running Oracle SOA, but you must create the _SOAINFRA, _UMS and _STB schemas.

For more information, see Upgrading an OSB Domain (Without SOA)

Application Integration Architecture Foundation Pack (AIAFP)

Schemas required for SOA Suite

User Messaging Service (UMS)

Schemas required for SOA Suite

See Administering Oracle User Messaging Service

For more information, see the following sections of the Upgrading to the Oracle Fusion Middleware Infrastructure:

- "Determining Which Schemas to Create"

- "Creating the Required Schemas with the Repository Creation Utility”

3 Upgrading to SOA Suite and Business Process Management 12c (12.1.3)

This chapter provides the end-to-end procedure for upgrading a single-node, production SOA Suite with Business Process Management 11g Release 1 (11.1.1.6 or 11.1.1.7) installation to SOA Suite with Business Process Management 12c (12.1.3).

- Installing Oracle SOA Suite and Business Process Management

- Creating the Required 12c (12.1.3) Schemas for Oracle SOA Suite and BPM

- Generating Log Files During Schema Upgrade (Recommended)

- Upgrading SOA Schemas Using the Upgrade Assistant

- Reconfiguring the Domain Using the Reconfiguration Wizard

- Upgrading the Domain Component Configurations Using the Upgrade Assistant

- Upgrading JDeveloper Projects in Bulk

- Upgrading BPM Web Forms

- Managing Your Upgraded Oracle Fusion Middleware 12c Software

CAUTION:
Oracle strongly recommends that you create a copy of your actual production environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.
Identifying potential upgrade issues in a cloned environment can eliminate unnecessary downtime of your production environment.

For more information, see Section 2.1.1, "Creating, Upgrading, and Testing a Development Copy of Your Production Environment".

3.1 Installing Oracle SOA Suite and Business Process Management

Before you can upgrade your existing SOA and Business Process Management (BPM) 11g components, you must first install the SOA Suite and Business Process Management 12c (12.1.3) distribution. Follow the instructions described in Installing and Configuring Oracle SOA Suite Foundation and Business Process Management.

Note:
If your SOA domain has other SOA-integrated components, you must install those distributions as well. See the Oracle Fusion Middleware documentation library for a complete list of installation guides. Be sure to review any of the component-specific chapters in this book to determine if additional pre-upgrade steps for your additional installations.
During the installation process, you will be instructed to configure the newly installed domain. When upgrading, however, do not use the Configuration Wizard to configure the SOA 12.1.3 domain. The Configuration Wizard is used to configure a new domain installation. During an upgrade, however, you will be upgrading your existing domain using the Reconfiguration Wizard described later in this guide.

3.2 Creating the Required 12c (12.1.3) Schemas for Oracle SOA Suite and BPM

As described in Section 2.5.2, "Creating the Required Schemas Before You Upgrade", if you are upgrading from SOA 11g, you must create the required 12c schemas before you begin the upgrade.

Specifically, run the 12c (12.1.3) Repository Creation Utility (RCU) to create the following schemas:

- Audit Services _IAU (IAU_APPEND and IAU_VIEWER)

- Service Table _STB (new in 12c)

- Web _WLF (required when upgrading Business Activity Monitoring (BAM) 11.1.1.6 and 11.1.1.7)

Note:
Oracle Fusion Middleware only supports schemas in a byte-mode database. The nls_length_semantics initialization parameter, on the database where the schemas reside, must be set to BYTE; setting this parameter to CHAR is not supported.
To check the values of this parameter using SQL*Plus, you can use the show parameters command:

prompt> sqlplus "sys/<password> as sysdba"SQL> show parameters nls_length_semantics

Replace <password> with the actual password for the SYS user.

Alternatively, you can check the values by querying the V$PARAMETER view:

prompt> sqlplus "sys/password as sysdba"SQL> select name,value from v$parameter;

For more information, refer to you database administration documentation.

3.3 Generating Log Files During Schema Upgrade (Recommended)

To facilitate troubleshooting the upgrade, Oracle recommends that you generate log files when upgrading _SOAINFRA schema. Logging is disabled by default.

To enable logging:

1. Create the soainfra user directory with the name UPGRADE_DIR

2. Enable debugging logs by calling function set_LogLevel(1) or ALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';

You can also launch the Upgrade Assistant with logging parameters as shown in the UNIX example below:

./ua [-logLevel <log_level>] [-logDir <log_directory>]

For more information on generating and using log files, see "Launching the Upgrade Assistant with Optional Arguments" in Upgrading with the Upgrade Assistant

3.4 Upgrading SOA Schemas Using the Upgrade Assistant

Follow the instructions in this section to upgrade SOA and BPM schemas and instances using the Upgrade Assistant.

Caution:
Do not start the Upgrade Assistant if purge scripts or scheduled database jobs are running.
Wait until the purge or upgrade is complete before starting the upgrade process. The upgrade will fail if the purge scripts or instance upgrade jobs are running while using the Upgrade Assistant to upgrade your schemas.

If you must start the Upgrade Assistant, stop the purge and be sure to disable any scheduled jobs as described in Enabling and Disabling Background Control Job (Option 6).

- Task 1, "Start the Upgrade Assistant"

- Task 2, "Upgrade the Schemas"

- Task 3, "Verify the Schema Upgrade"

- Task 5, "Check for Invalid Database Objects"

Task 1   Start the Upgrade Assistant

Complete the following steps to start the Upgrade Assistant:

1. Change directory to ORACLE_HOME/oracle_common/upgrade/bin (on UNIX operating systems) or ORACLE_HOME\oracle_common\upgrade\bin (on Windows operating systems).

2. Enter the following command to start the Upgrade Assistant.
(UNIX) ./ua

(Windows) ua.bat

Oracle recommends that you run the Upgrade Assistant with logging enabled as shown in the example below.

./ua [-logLevel <log_level>] [-logDir <log_directory>]

Task 2   Upgrade the Schemas

The Upgrade Assistant displays a sequence of screens listed in Table 3-1 when upgrading schemas. Perform the respective action(s) for each of the screens. When Oracle SOA is selected, the _IAU, _MDS, _OPSS, _SOAINFRA, and _UMS schemas will be included in the upgrade.

Table 3-1 Upgrade Assistant Screens: Upgrading Schemas

Screen

Description and Action Required

Welcome

This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks.

Schemas

Select Schemas.

Available Components

This screen provides a list of installed Oracle Fusion Middleware components that have schemas that can be upgraded. When you select a component, the schemas and any dependencies are automatically selected. For example, when Oracle SOA is selected, the _IAU, _MDS, _OPSS, _SOAINFRA, and _UMS schemas will be included in the upgrade.

NOTE: By default, the Oracle Platform Security Services (OPSS) and Audit Services schemas are selected. Most component upgrades requires these schemas. Do not deselect these options unless you are certain your upgrade does not require these schemas.

If you are upgrading AIAFP, see Chapter 7, "Upgrading to SOA Core Extension 12c (12.1.3)".

Domain Directory

This screen appears if you selected Oracle Platform Security Services or Oracle Audit Services on the Available Components screen.

Enter the absolute path to the existing WebLogic domain directory, or click Browse to navigate to and select the 11g domain directory you are upgrading.

Prerequisites

Check that the prerequisites for schema upgrade are met. You must select each prerequisite before you click Next.

CAUTION: Upgrade Assistant will NOT verify that these prerequisites have been met.

Schema Credentials

Use this screen to enter database connection details for each of the schemas you are upgrading.

1. Select a the database type from the Database Type drop-down menu.

2. Enter the database connection details, and click Connect.

3. Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema.
In some cases, such as _ORASDPM, you will need to manually enter the Schema User Name and password.

NOTE: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. Upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as the _UMS schema.

4. Click Next.

Notes:

- The following schemas require elevated login credentials (AS SYSDBA): _OPSS, _IAU, _MDS, and _ODI

- The title of Schema Credentials screen varies, depending upon the schemas you are upgrading. For example, if you are upgrading the _SOAINFRA schema, the screen title appears as "SOAINFRA Schema".

- For information on the fields required to connect to the database, click Help, or refer to "Schema Credentials" in Upgrading with the Upgrade Assistant.

Examine

Review the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade.

Verify that the Source Version displayed for each schema is listing the correct version number for the schema to be upgraded.

Upgrade Summary

Review the summary of the options that you have selected for schema upgrade. Verify that the correct Source and Target versions are listed for each schema you intend to upgrade.

Click Upgrade to upgrade the schemas, or click Back if you wish to change the configurations.

Upgrade Progress

Review the status of the current upgrade process.

NOTE: The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

Click Next when the upgrade is complete.

Upgrade Success

Click Close if the Upgrade was successful.

If the upgrade failed or if you canceled the upgrade before it completed successfully, you should review the log files, restore the backed up environment, and restart the Upgrade Assistant.

Task 3   Verify the Schema Upgrade

Use the following SQL command to verify that the schema version in schema_version_registry has been properly updated.

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

Check that the number in the VERSION column matches the latest version number for that schema. See Table 1-1, "Schemas That Require an Upgrade" in Upgrading with the Upgrade Assistant to verify that the updated version number is correct for your schema(s).

In the query result, the STATUS field will be either UPGRADING or UPGRADED during the schema patching operation, and will become VALID when the operation is completed.

If the status appears as INVALID, the schema update failed. You should examine the logs files to determine the reason for the failure.

Task 4   Verify the Instance Upgrade (if applicable)

If instances were upgraded as part of your schema upgrade, verify that there were no errors with the instances.

- If the Upgrade Assistant reports that there are no additional instances to be upgraded, then simply close the Upgrade Assistant UI and continue with the remaining upgrade procedures (launching the Reconfiguration Wizard for example).

- If the Upgrade Assistant reports that there was an error during the instance upgrade, then correct the error(s) and resubmit the database job to complete the upgrade. You can also use the Report Upgrade Summary administration script (Option 1) to check the UPGRADE ERROR COUNT section of the report. For more information, see Section 9.10, "Resolving Instance Upgrade Errors".

- If there are still closed instances to be upgraded, then you will be notified that the upgrade of the closed instances will continue in the background after you close the Upgrade Assistant. Do not close the Upgrade Assistant until UA reports it is finished and you see the following:

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.

Task 5   Check for Invalid Database Objects

If you are using an Oracle database, you should recompile database objects after running the Upgrade Assistant by connecting to the database as SYS and running the following from SQL*Plus:

SQL>@?/rdbms/admin/utlrp.sql

This will compile the database objects that were upgraded by Upgrade Assistant.

Then issue the following query to ensure there are no longer any invalid database objects:

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

None of the database objects for the upgraded schema should be invalid at this point. If there are any, run the utlrp.sql command again and check again. If the problem persists, you should file a service request.

3.5 Reconfiguring the Domain Using the Reconfiguration Wizard

Follow the instructions in this section to reconfigure the existing 11g domain using the Reconfiguration Wizard. For general information about how the domain is reconfigured, see "Reconfiguring WebLogic Domains" in Upgrading Oracle WebLogic Server.

- Task 1, "Starting the Reconfiguration Wizard"

- Task 2, "Reconfiguring the Domain"

Task 1   Starting the Reconfiguration Wizard

Start the Reconfiguration Wizard in graphical mode by doing the following:

1. Log in to the system on which the domain resides.

2. Open the command shell (on UNIX operating systems) or open a command prompt window (on Windows operating systems).

3. Edition Based Database Users Only: If your schemas are configured with EBR database, a default edition name must be manually supplied before you run the Reconfiguration Wizard.
Run the following SQL command to set the default edition:

ALTER DATABASE DEFAULT EDITION = edition_name;

where edition_name is the name of the child edition name.

4. Go to the following directory:
(UNIX) ORACLE_HOME/oracle_common/common/bin

(Windows) ORACLE_HOME\oracle_common\common\bin

where ORACLE_HOME is your Oracle home directory.

5. Execute the following command:

(UNIX) ./reconfig.sh -log=<log_file> -log_priority=ALL
(Windows) reconfig.cmd -log=<log_file> -log_priority=ALL

Replace log_file with the absolute path of the log file you'd like to create for the domain reconfiguration session. This can be helpful if you need to troubleshoot the reconfiguration process.

The parameter -log_priority=ALL ensures that logs are logged in fine mode.

Notes:
When you run the reconfig.cmd or reconfig.sh command, the following error message might be displayed to indicate that the default cache directory is not valid:

*sys-package-mgr*: can't create package cache dir

You can change the cache directory by setting the environment variable CONFIG_JVM_ARGS. For example:

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

Task 2   Reconfiguring the Domain

The Reconfiguration Wizard displays a sequence of screens listed in Table 3-2. Perform the respective action(s) for each of the screens. Note that you may not see every screen listed below. In addition, you may need to complete additional screens based on your environment setup. For more information, see "Reconfiguring WebLogic Domains" in Upgrading Oracle WebLogic Server.

Table 3-2 Reconfiguration Wizard Screens

Reconfiguration Wizard Screen

Description and Action Required

Select Domain

Enter the absolute path to the existing domain directory, or click Browse to navigate to and select the domain directory.

Reconfiguration Setup Progress

Shows the progress of applying the reconfiguration templates.

Domain Mode and JDK

Domain mode cannot be changed.

Select the JDK to use in the domain or click Browse to navigate to the JDK you want to use.

Note that Oracle Fusion Middleware 12c requires Java SE 7. For more information, see "Verifying Certification and System Requirements" in Planning an Installation of Oracle Fusion Middleware.

Database Configuration Type

Use the RCU Data option to connect to the Server Table (_STB) schema. The Repository Creation Utility will automatically use service table to load the other 12c schema credentials automatically. Always verify the data on the JDBC screens that follow.

NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created by 12c RCU, the default connection data will be retrieved from the _STB schema. If no connection data for a given schema is found in the _STB schema, then the default connection data is used.

For more information, click Help, or refer to "Database Configuration Type" in Upgrading Oracle WebLogic Server.

JDBC Data Sources

This screen is displayed if you created custom data sources for a database-based OPSS security store or Audit Data store in 11g.

Use this screen to configure the JDBC data sources defined in your domain source.

For information about the fields on this page, click Help, or refer to "JDBC Data Sources" in Upgrading Oracle WebLogic Server.

JDBC Data Sources Test

Test the data source connections you configured on the JDBC Data Sources screen.

WARNING: If any data sources fail the test, correct the issue before proceeding to the next step. All data source tests must show a status of PASS.

For information about the fields on this page, click Help, or refer to "JDBC Data Sources Test" in Upgrading Oracle WebLogic Server.

JDBC Component Schema

Specify the data source settings for each of the schemas listed on the screen, by selecting the check box adjacent to each schema name.

Notes:

- You must specify the 11g schema details for those schemas that you upgraded in Section 3.4. For the others, specify the 12.1.3 schema details.

- For information about the fields on this page, click Help, or refer to "JDBC Component Schema" in Upgrading Oracle WebLogic Server.

JDBC Component Schema Test

Test the configurations that you specified for the data sources in the previous screen. Select the check boxes adjacent to the names of the schemas to test, and click Test Selected Connections.

The result of the test is indicated in the Status column. Click Next when the test is successful for all the schemas.

Node Manager

This screen is displayed only if the domain you are reconfiguring is currently using a per-host Node Manager. Use this screen to select the Node Manager configuration to use for the reconfigured domain. The resulting configuration depends on the combination of options you select for Node Manager Type and Node Manager Configuration.

For information on per-domain and per-host Node Manager configurations, see "Default Node Manager Configuration" in Administering Node Manager for Oracle WebLogic Server.

Advanced Configuration

The categories that are listed on this screen depend on the resources defined in the templates you selected for the domain during domain configuration.

For example, when the SOA Suite and BPM template is being applied to the domain, select the Managed Servers, Clusters and Coherence if one or more of the following applies:

- You have more than one managed server in a single domain (soa_server1 and bam_server1, for example)

- You need to modify cluster or coherence data

For information on using the other advanced configuration options, such as Node Manager, Deployments and Services, Domain Front End Host Capture and JMS File Store, see "Advanced Configuration" in the Upgrading Oracle WebLogic Server.

Managed Servers

You must specify the actual host name for the Listen Address for each managed server in your domain.

Do not use the default localhost or All Local Addresses option.

You must specify the actual host name as host name.company.com

Assign Servers to Machines

If you have created servers as part of the upgrade process, then select the server name in the Servers list box and target them to the correct Node Manager Machine.

Otherwise, no action is required on this screen when you are upgrading or reconfiguring the domain.

Assign Servers to Clusters

Cluster Upgrades Only: If you are upgrading clusters, use this screen to assign Managed Servers to clusters.

Note that only Managed Servers are displayed in the Server list box. The Administration Server is not listed because it cannot be assigned to a cluster.

Configuration Summary

Review the configuration summary.

Click Reconfig to reconfigure the domain, or click Back to change the configurations.

Reconfiguration Progress

Review the reconfiguration progress. Click Next when the process is complete.

Reconfiguration Success

Review the final status of the reconfiguration process. Click Finish to exit the Reconfiguration Wizard.

3.6 Upgrading the Domain Component Configurations Using the Upgrade Assistant

Follow the instructions in this section to upgrade any additional domain component configurations using the Upgrade Assistant.

- Task 1, "Starting the Upgrade Assistant"

- Task 2, "Upgrading Component Configurations"

Note:
Do not start the Administration Server before launching the Upgrade Assistant.

Task 1   Starting the Upgrade Assistant

Start the Upgrade Assistant on the host where Administration Server is running, by doing the following:

1. Change directory to ORACLE_HOME/oracle_common/upgrade/bin (on UNIX operating systems) or ORACLE_HOME\oracle_common\upgrade\bin (on Windows operating systems).

2. Enter the following command to start the Upgrade Assistant.
On UNIX operating systems:

./ua

On Windows operating systems:

ua.bat

Task 2   Upgrading Component Configurations

The Upgrade Assistant displays a sequence of screens listed in Table 3-3 when upgrading WebLogic Component Configurations. Perform the respective action(s) for each of the screens.

NOTE: The Reconfiguration Wizard screens you see are based on your environment. You may or may not see all of the screens described below.

Table 3-3 Upgrade Assistant Screens: Upgrading WebLogic Component Configurations

Screen

Description and Action Required

Welcome

This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks.

Click Next to continue.

WebLogic Components

Select WebLogic Component Configurations.

Select the WebLogic Component Configurations option to upgrade component configurations for a managed WebLogic Server domain. You must enter the domain directory for the domain that you are upgrading now.

Click Next.

OWSM Policy Manager

This screen is displayed if your 11g environment has multiple WebLogic Server domains, but the OWSM Policy Manager is only in one WLS domain and the OWSM agents are in other domains.

Provide the credentials for the WebLogic Administration Server domain where the Oracle Web Services Manager (OWSM) Policy Manager is deployed.

For information about the fields on this page, click Help, or refer to "OWSM Policy Manager" in Upgrading with the Upgrade Assistant.

Component List

This screen provides a list of components that will be included in the domain component configuration upgrade.

Prerequisites

Check if the prerequisites for component configurations upgrade are met.

UMS Configuration

This screen is presented if there are remote managed servers hosting UMS 11g configuration files. You must provide the credentials to these servers so that the Upgrade Assistant can access the configuration files.

NOTE: You may be required to manually copy the UMS configuration files if the Upgrade Assistant is unable to locate them. See "Upgrade Assistant: Copying UMS Configuration Files" in Upgrading to the Oracle Fusion Middleware Infrastructure.

Examine

Review the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade.

Upgrade Summary

Review the summary of the options that you have selected for schema upgrade.

Click Upgrade to upgrade the schemas, or click Back if you wish to change the configurations.

Upgrade Progress

Review the status of the upgrade process.

Click Next when the upgrade is complete.

Upgrade Success

Click Close if the Upgrade was successful.

If the upgrade failed or if you canceled the upgrade before it completed successfully, you should review the log files, restore the backed up environment, and restart the Upgrade Assistant.

Note:
Additional configuration tasks may be required.
After the Upgrade Assistant has successfully completes the upgrade of your schemas and component configurations, you may need to perform the post-upgrade tasks in Chapter 8, "Performing Post-Upgrade Tasks" to ensure that your components continue to function as expected.

3.7 Upgrading JDeveloper Projects in Bulk

If you want to upgrade a large number of JDeveloper projects in bulk, without opening them one by one in JDeveloper, you can use the JDeveloper migration tool ojmigrate installed in the 12c Oracle home. You must provide the Workspace file name and files that have workspaces to upgrade.

For example:

ojmigrate [option]... file...|@file

Where: file is the name of the Workspace to upgrade and @file is the file with workspaces to upgrade (one filename per line)

You can also specify the following options:

- -ade
Connect to currnt ade view

- -dry
Skip calling migrators

- -failFast
Stop migrating after first failure

- -generateDefaults
Let the upgrade tool generate files containing defaults for upgrade options. These generated files will usually be migration.properties file and the .jws file.

3.8 Upgrading BPM Web Forms

Most BPM Web Forms developed with BPM 11g (11.1.1.7.0) are compatible with 12c. There are a small number of cases where manual spacings are specified between elements and these forms may not work correctly in 12c. These forms must be upgraded manually. Without manual intervention, these forms will be in suspended mode. Those forms which do not use these manual layouts will work fine without migration.

To upgrade BPM Web Forms, a user with administrative privileges should navigate to the following URL and enter the administrator credentials when prompted.

http://host name:port/workflow/DefaultToDoTaskFlow/migratewebforms

Loading this page starts the upgrade and shows the upgraded forms. If there are any errors, check the log file and if the error is recoverable, you can try loading the page again. If the error is not recoverable, try to deploy the BPM composite with the failed forms.

Note:
The URL can be launched multiple times, but the upgrade should not be run when there are active users using the web forms.

3.9 Managing Your Upgraded Oracle Fusion Middleware 12c Software

Table 3-4 lists some common administration tasks you will likely want to perform after upgrading to SOA 12.1.3. In addition, the component-specific administration guides may provide additional configuration tasks to perform after an upgrade.

Table 3-4 Basic Administration Tasks

Task

Description

More Information

Performing additional post-upgrade configuration steps for your component.

In addition to the post-upgrade tasks described Chapter 8, "Performing Post-Upgrade Tasks", you may also need to perform additional configuration tasks to ensure your newly upgraded components function as expected.

- Administering Oracle Fusion Middleware

- Administering Oracle SOA Suite and Oracle Business Process Management Suite

- Administering Oracle Service Bus

- Administering Oracle User Messaging Service

Getting familiar with Fusion Middleware administration tools

Get familiar with the various tools available which you can use to manage your environment.

"Overview of Oracle Fusion Middleware Administration Tools" in Administering Oracle Fusion Middleware.

Configuring Secure Sockets Layer (SSL)

Learn how to set up secure communications among between Oracle Fusion Middleware components using SSL.

"Configuring SSL in Oracle Fusion Middleware" in Administering Oracle Fusion Middleware.

Monitoring Oracle Fusion Middleware

Learn how to keep track of the status of Oracle Fusion Middleware components.

"Monitoring Oracle Fusion Middleware" in Administering Oracle Fusion Middleware.

4 Upgrading a Clustered SOA Environment

This chapter describes the process of upgrading to a clustered SOA environment and performing post-upgrade configuration tasks.

- Section 4.1, "Understanding the SOA Cluster Upgrade Topology"

- Section 4.2, "Using Secured Task Forms in a Clustered Topology"

- Section 4.3, "Upgrading a Clustered Topology"

- Section 4.4, "Propagating Domain Configuration on SOAHOST2"

- Section 4.5, "Performing Post-Upgrade Tasks for Clusters"

4.1 Understanding the SOA Cluster Upgrade Topology

Figure 4-1 shows a sample topology of a clustered Oracle SOA Suite deployment with SOA, Oracle Web Services Manager (OWSM), Oracle Service Bus (OSB) and Oracle Business Activity Monitoring (Oracle BAM) in separate clusters across two application hosts, SOAHOST1 and SOAHOST2. The Oracle HTTP Server, Administration Server, Oracle Enterprise Manager Fusion Middleware Control and database are shared with both hosts.

Specifically, this chapter describes the steps required to upgrade a WebLogic domain that contains multiple WebLogic Server clusters that are scaled out to multiple host computers. You can apply the concepts and procedures in this chapter to your own specific Oracle SOA Suite environment.

The steps required to upgrade this sample topology are described in the next section in Table 4-1.

Note:
If you are upgrading Oracle BAM with SOA, see Section 5.3, "Upgrading a SOA with Oracle BAM Domain to 12c".

Figure 4-1 Clustered SOA Topology

4.2 Using Secured Task Forms in a Clustered Topology

If your SOA composite includes a human task form, or if task forms are deployed on non-SOA servers, then you must secure the task form after the upgrade.

The task form is a Java Server Page XML (.jspx) file that you create in the Oracle JDeveloper designer where you created the SOA composite containing the human task. See Administering Oracle SOA Suite and Oracle Business Process Management Suite.

4.3 Upgrading a Clustered Topology

Table 4-1 lists the steps required to upgrade the example clustered, multi-host Oracle SOA Suite topology illustrated in Figure 4-1.

Table 4-1 Oracle SOA Suite and BPM Cluster Upgrade Roadmap

Task Number

Task

For More Information

1

Review the upgrade topology, and identify SOAHOST1 and SOAHOST2 on your setup.

See, Understanding the SOA Cluster Upgrade Topology

2

Shut down the Administration Server, all the Managed Servers, and the Node Managers running on SOAHOST1 or SOAHOST2.

See, Stopping Servers and Processes

3

Back up the existing environment.

See, Backing Up Your Existing Oracle Fusion Middleware 11g Environment

4

Install 12.1.3 Infrastructure (WebLogic Server, OWSM, and JRF), SOA, OSB, and BAM on SOAHOST1 in a new Oracle home directory.

See, Installing the 12c (12.1.3) Infrastructure Distributions Before Upgrade and Installing SOA Integrated Distributions

5

Perform a complete upgrade of your 11g deployment on SOAHOST1. Perform the post-upgrade configurations that apply to your environment.

See, Upgrading to SOA Suite and Business Process Management 12c (12.1.3)

See Also:

If BAM is part of your domain, see Upgrading a SOA with Oracle BAM Domain to 12c

If OSB is part of your domain, see Upgrading Oracle Service Bus Without Oracle SOA

6

Propagate the domain configuration of SOAHOST1 on SOAHOST2.

To do this, you must pack the domain on SOAHOST1, and unpack it on SOAHOST2.

See, Propagating Domain Configuration on SOAHOST2

7

Start the Administration Server and the Managed Servers on SOAHOST1 and SOAHOST2.

See, Starting and Stopping Servers

8

Perform the necessary post-upgrade tasks.

See, Performing Post-Upgrade Tasks

4.4 Propagating Domain Configuration on SOAHOST2

After you have completed your single node upgrade on SOAHOST1, use these steps to propagate the newly upgraded files to another node (SOAHOST2).

- Task 1, "Execute the pack command on the server where the Admin Server and one of the Managed Servers is installed."

- Task 2, "Copy the template file created in the previous step to SOAHOST2."

- Task 3, "Execute the unpack command from the 12c Oracle Home on SOAHOST2."

Task 1   Execute the pack command on the server where the Admin Server and one of the Managed Servers is installed.

In our sample topology, you would execute the following on SOAHOST1:

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle Home directory (the installation directory for the 12.1.3 bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

- By default, the domainupgradetemplate is created in the current directory where you ran the pack command. In this example, it would be created in the following directory, but you can specify a full path for the template jar file as part of the -template argument to the pack command:

ORACLE_COMMON_HOME/common/bin/

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

For more information on using the pack command, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

Task 2   Copy the template file created in the previous step to SOAHOST2.

Use the following command to copy domainupgradetemplate.jar file to SOAHOST2:

scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin

Task 3   Execute the unpack command from the 12c Oracle Home on SOAHOST2.

Make sure that the Admin and Managed Servers are still stopped and then execute the following unpack command to create a full domain or a subset of a domain used for a Managed Server domain directory on the remote machine. You may use unpack only with a template compatible with your current installation.

A sample unpack command code snippet is shown below. Use this as an example only. Note that you must specify the "-overwrite_domain=true" flag on unpack.

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle Home directory (the installation directory for the 12.1.3 bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

After the unpack, complete the following:

1. Verify that WL_HOME, SOA_ORACLE_HOME, UMS_ORACLE_HOME in setDomainEnv.sh script from 11g domain are pointing to 12c.
See Reapplying Customizations to setDomainEnv.

2. Start the Node Manager, WebLogic Administration Server, and the Managed Servers on SOAHOST1 and SOAHOST2 in the following order:

1. On SOAHOST1 and SOAHOST2, start the Node Manager.

2. On SOAHOST1, start the WebLogic Administration Server.

3. On SOAHOST1 and SOAHOST2, start the Managed Servers.

For more information, see Starting and Stopping Servers. Carefully review the order in which Managed Servers should be started.

If you cannot start the servers or experience other technical issues, see Appendix A, "Troubleshooting the Upgrade"

Note:
During the upgrade, the Node Manager configuration files (nodermanager.properties, for example) are moved from 11g_DOMAIN_HOME/wlserver_10.3/ location to the 11g_ORACLE_HOME/ domains/DOMAIN_HOME/nodemanager location. Therefore, the node manager in 12c has to be started from the 11g_DOMAIN_HOME domain directory.

4.5 Performing Post-Upgrade Tasks for Clusters

After a successful cluster upgrade, you may need to perform additional post-upgrade configurations tasks. Perform only those tasks that pertain to your clustered environment.

- Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

- Removing OWSM Targets from SOA and OSB Clusters

- Updating OWSM Cross-Component Wiring

- Removing MDS-OWSM Data Sources from SOA and OSB Clusters

- Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

- Preventing Duplicate Messages When Using JMS Transport Proxy Service

4.5.1 Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

To enable Oracle HTTP Server to route to Oracle Service Bus console and Oracle Service Bus service, set the WebLogicCluster parameter to the list of nodes in the cluster.

For more information, see "Configuring Oracle HTTP Server for the Oracle Service Bus" in the Enterprise Deployment Guide for Oracle SOA Suite.

4.5.2 Removing OWSM Targets from SOA and OSB Clusters

If your 12c domain includes an Oracle Web Services Manager (OWSM) in its own cluster and you have extended that domain with a SOA cluster and an OSB cluster, then post upgrade you must manually untarget the wsm-pm from the SOA and OSB clusters.

To remove the owsm-pm target from the SOA and OSB clusters:

1. Log in to the WebLogic Server Administration Console 12c.
Enter the following URL in a browser:

http://host name:port_number/console

The port number is the port number of the Administration Server. By default, the port number is 7001.

The login page is displayed.

2. Select Deployments from Domain Structure.

3. Select wsm-pm under Deployments.

4. In the settings for wsm-pm, select Targets.

5. Select wsm-pm component of type Enterprise Application and select Change Targets.

6. Uncheck SOA cluster and OSB cluster.

7. When prompted, click Yes to apply the changes.

8. REQUIRED: Once the wsm-pm is targeted only to the OWSM cluster, you must rewire the components as described in "Updating OWSM Cross-Component Wiring".

4.5.3 Updating OWSM Cross-Component Wiring

After you have removed OWSM targets from SOA and OSB clusters as described in Removing OWSM Targets from SOA and OSB Clusters, you must rewire the OWSM Policy Manager components as described below:

1. Start the Administration (admin) server and one OWSM server.
For more information, see Starting and Stopping Servers.

2. Log in to the Oracle Enterprise Manager Fusion Middleware Control 12c console and navigate to the Cross Components Wiring > Components option.

3. Select OWSM Policy Manager from the list of available components:

4. From the Service End Points table, select the OWSM Policy Manager t3 connection entry and click Publish. The status will change from Out of Sync to Published.

5. Select OWSM Agent from the Component Type list. Select the t3 connection entry and click Bind.

6. Verify that the Service Type for the service end point is OWSM Policy Manager.

7. Repeat steps 5 and 6 to Bind the remaining component types. In this example, you will select com.oracle.ess and Fusion Middleware Control.

4.5.4 Removing MDS-OWSM Data Sources from SOA and OSB Clusters

Prior to the upgrade, mds-owsm data sources were targeted only to OWSM cluster and Admin Server. Post upgrade, however, the mds-owsm data source is targeted to all clusters, including SOA, OSB and OWSM.

1. Log in to the WebLogic Server Administration Console 12c.
Enter the following URL in a browser:

http://host name:port_number/console

The port number is the port number of the Administration Server. By default, the port number is 7001.

The login page is displayed.

2. Click Lock and Edit and to edit the targets.

3. Select Services and choose Data Sources from Domain Structure.

4. Select the mds-owsm data source and select Targets.

5. Uncheck SOA cluster and OSB cluster to remove the data source.

6. When prompted, click Yes to apply the changes.

4.5.5 Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

After upgrading a SOA Cluster domain to 12.1.3, the upgraded SOA JMS module may be missing the EDNTopic. If the JMS module is missing the EDNTopic, you must manually add the topic or UDD for this topic using the Administration Console or WLST.

See the Administration Console online help for more information on reapplying the EDNTopic.

4.5.6 Preventing Duplicate Messages When Using JMS Transport Proxy Service

In a 12c cluster domain, jmsServers are targeted to migratable targets, which is different from the default behavior in 11g where jmsServers were targeted to an individual server.

When you configure a 12c proxy service based on the JMS transport, set the topic distribution mode to One-Copy-Per-Application or One-Copy-Per-Server. To prevent duplicate messages, do not use Compatibility mode in a clustered environment.

5 Upgrading SOA with Oracle Business Activity Monitoring (Oracle BAM)

This chapter describes the process of upgrading from a supported Oracle SOA Suite 11g environment that includes Business Activity Monitoring (Oracle BAM) to a SOA 12c (12.1.3) environment with the newly redesigned Oracle BAM 12c.

The following procedures are described in this chapter:

- Section 5.1, "Understanding an Upgrade to Business Activity Monitoring in 12c"

- Section 5.2, "Performing the Pre-Upgrade Tasks for Oracle BAM"

- Section 5.3, "Upgrading a SOA with Oracle BAM Domain to 12c"

- Section 5.4, "Post-Upgrade Configuration Tasks"

- Section 5.5, "Extending the SOA Domain with Oracle BAM 12c"

5.1 Understanding an Upgrade to Business Activity Monitoring in 12c

Oracle Business Activity Monitoring (BAM) 12c has been completely redesigned for use with Oracle SOA Suite 12c, so there is no direct upgrade path. The schemas, binaries, and directory structure used in Oracle BAM 12c are different than those used with Oracle BAM 11g. Therefore, upgrading from Oracle BAM 11g to BAM 12c cannot be handled with the standard upgrade procedures. You will need to perform several manual configuration tasks to complete the upgrade.

It is also important to understand that the only Oracle BAM 11g objects that can be used in your BAM 12c domain are data objects (DOs) and enterprise message sources (EMS). You will need to manually export these objects to an XML file and then import them into the BAM 12c domain. The other Oracle BAM 11g artifacts, such as dashboards for example, will have to be manually recreated in Oracle BAM 12c domain.

Oracle recommends that you continue to use your Oracle BAM 11g domain after the upgrade to allow time to create and test all of the necessary artifacts. Therefore, before you begin the SOA with Oracle BAM upgrade process, it is strongly recommended that you reinstall the Oracle BAM 11g domain in a separate location so that the source files remain untouched during the domain reconfiguration. You will configure SOA 12c to point to this new 11g domain after the upgrade as your existing 11g Oracle BAM domain will be altered and will not function with SOA 12c.

Note:
There is no upgrade support for an Oracle BAM-only domain (a domain without SOA). If you have a BAM-only domain, and want to upgrade to Oracle BAM 12c, then you must create a new Oracle BAM 12c domain and import data objects and recreate all the dashboards and alerts.

The following flowchart shows a process overview of upgrading a SOA 11g domain with Oracle BAM to a SOA 12c domain with Oracle BAM 12c.

5.2 Performing the Pre-Upgrade Tasks for Oracle BAM

The tasks in this section should be performed when upgrading a SOA domain with Oracle BAM 11g to 12c (12.1.3).

Note:
If you are using a file-based policy store in your existing 11g environment, you must reassociate to database-based policy store before you begin the upgrade process. This is a standard pre-upgrade requirement and must be performed before you can upgrade BAM. See Reassociating a File-Based Policy Store Before Upgrade.

- Section 5.2.1, "Creating a New Oracle BAM 11g Domain Before You Upgrade"

- Section 5.2.2, "Exporting All Oracle BAM 11g Artifacts from the Existing Domain"

- Section 5.2.3, "Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain"

- Section 5.2.4, "Creating a Complete Backup of the Oracle BAM 11g Domain"

Make sure that you have already completed all of the applicable pre-upgrade tasks described in Performing the Required Pre-Upgrade Tasks for SOA Suite and BPM.

5.2.1 Creating a New Oracle BAM 11g Domain Before You Upgrade

You will continue to use your existing Oracle BAM 11g domain after the upgrade, so you must install BAM 11g in a new domain home before you upgrade. If you do not create a new (separate) BAM 11g domain, you will not have a functioning BAM domain after the upgrade and you will lose many of your artifacts and configurations.

Note:
f you do not create separate domain for Oracle BAM 11g, then you will lose BAM artifacts and BAM-related configurations only (SOA artifacts will not be impacted).
In addition, any composites referring to BAM artifacts (such as adapters) or new instances will be faulted during runtime.

Use the installation instructions in the 11.1.1.7.0 version of the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

To preserve your existing 11g BAM environment, use the 11g ICommand to export ALL of your Oracle BAM 11g artifacts (not just DOs and EMS), and then import them into your new Oracle BAM 11g domain so you have a fully functional Oracle BAM 11g domain after the upgrade.

- Exporting All Oracle BAM 11g Artifacts from the Existing Domain

- Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

After the upgrade, you can continue using the Oracle BAM 11g domain. Alternatively, you can extend the 12c SOA domain with Oracle BAM 12c and export the DOs and EMS artifacts from 11g domain and import them into extended Oracle BAM 12c domain. For more information, see Extending the SOA Domain with Oracle BAM 12c.

5.2.2 Exporting All Oracle BAM 11g Artifacts from the Existing Domain

After you install and configure your new Oracle BAM 11g domain in its new location, you will have to use 11g Oracle BAM ICommand utility to export the data from the existing (old) Oracle BAM 11g domain and then import it into the new Oracle BAM 11g domain before you upgrade.

For more information on using the 11g Oracle BAM ICommand command-line utility to export data files, see the "Export" section of Monitoring Business Activity with Oracle BAM.

5.2.3 Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

After you have created a complete export XML of your Oracle BAM 11g artifacts (not just the DOs and EMS), you must import the XML file into the newly created Oracle BAM 11g domain. This will ensure that you continue to have a fully functioning Oracle BAM domain after the upgrade and domain reconfiguration.

For more information on using the 11g Oracle BAM ICommand command-line utility to export data files, see the "Import" section of Monitoring Business Activity with Oracle BAM.

5.2.4 Creating a Complete Backup of the Oracle BAM 11g Domain

In the event that the upgrade fails, you will need to restore the entire pre-upgrade environment using a backup version. Make sure that you have created a backup version of the entire Oracle BAM 11g environment before you continue with the upgrade process. Note that the backup domain is separate from the new Oracle BAM11g domain you created in Section 5.2.1.

For more information, see "Backup and Recovery Strategies for Upgrade" in the Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

5.3 Upgrading a SOA with Oracle BAM Domain to 12c

This section describes the process of upgrading a SOA 11g domain that includes Oracle BAM to a SOA 12c (12.1.3) domain that will also include Oracle BAM. Do not perform these tasks until you have created a complete backup of the Oracle BAM 11g domain.

- Task 1, "Install the Fusion Middleware Infrastructure 12c (12.1.3) in a new Oracle home directory."

- Task 2, "Install Oracle SOA Suite and Business Process Management 12c (12.1.3) in the 12.1.3 Oracle home."

- Task 3, "Stop Servers and Processes."

- Task 4, "Create new schemas using the 12c (12.1.3) Repository Creation Utility (RCU)."

- Task 5, "Rename the Oracle BAM templates before upgrading the 11g schemas."

- Task 6, "Run the Upgrade Assistant to upgrade the 11g schemas."

- Task 7, "Reconfigure the existing 11g domain using the Reconfiguration Wizard."

- Task 8, "Run the Upgrade Assistant to upgrade component configurations."

Task 1   Install the Fusion Middleware Infrastructure 12c (12.1.3) in a new Oracle home directory.

Create a new Oracle home for Infrastructure 12c (12.1.3) as described in Installing WebLogic Server and JRF Infrastructure.

Task 2   Install Oracle SOA Suite and Business Process Management 12c (12.1.3) in the 12.1.3 Oracle home.

Add the latest SOA component binaries to the 12c (12.1.3) Oracle home as described in Installing Oracle SOA Suite and Business Process Management.

Task 3   Stop Servers and Processes.

Stop all of the 11g servers and processes that are currently running before you begin the upgrade. See Stopping Servers and Processes for information on stopping servers.

Task 4   Create new schemas using the 12c (12.1.3) Repository Creation Utility (RCU).

You may need to create new schemas for SOA and Oracle BAM 12c (12.1.3). For the SOA with Oracle BAM upgrade you will need to create the following schemas (if you have not done so already):

- Service Table (_STB)

- Audit Services (_IAU)

- WebLogic Services (_WLS) - The Oracle WebLogic Services schema is required for Oracle BAM - though Oracle BAM does not have its own separate schema in 11g.

See Creating the Required Schemas Before You Upgrade for more information on creating and preparing schemas for upgrade.

Task 5   Rename the Oracle BAM templates before upgrading the 11g schemas.

Before upgrading the 11g schemas with the Upgrade Assistant, you must change the names of the following Oracle BAM reconfiguration templates upgrade will fail.

Make sure that you have exported your 11g Oracle BAM data before completing this step. If you are unsure, read Section 5.2.2.

The templates can be found in the following 12c directory: $ORACLE_HOME/soa/common/templates/wls

Template Name

Rename To:

oracle.bam.reconfig_template_12.1.3.jar

oracle.bam.reconfig_template_12.1.3.jar.old

oracle.bam.reconfig.template_12.1.3.jar.rename

oracle.bam.reconfig_template_12.1.3.jar

Task 6   Run the Upgrade Assistant to upgrade the 11g schemas.

Follow the standard procedure for upgrading schemas using the Upgrade Assistant. For more information, see Section 3.4, "Upgrading SOA Schemas Using the Upgrade Assistant".

When upgrading SOA Suite and BPM with Oracle BAM 11g schemas, select the following options on the Available Components screen (the schema names are listed for each):

- Oracle Platform Security Services (_OPSS)

- Oracle SOA (_SOAINFRA)

When Oracle Platform Security Services and Oracle SOA are selected, the following dependencies are also selected:

- Oracle Audit Services (_IAU)

- Oracle Metadata Services (_MDS)

- User Messaging Service (_ORASDPM)
NOTE: The 11g _ORASDPM schema has been renamed to _UMS in 12c. However, you must provide the 11g schema name prefix_ORASDPM when prompted in the Upgrade Assistant. The schema will continue to be <prefix>_ORASDPM for upgraded domains since schema names cannot be changed by Upgrade Assistant.

Task 7   Reconfigure the existing 11g domain using the Reconfiguration Wizard.

After you have renamed the Oracle BAM reconfiguration templates, start the Reconfiguration Wizard and follow the steps as described Section 3.5, "Reconfiguring the Domain Using the Reconfiguration Wizard".

The Reconfiguration Wizard will remove the Oracle BAM 11g application, library, BAMDataSource, BAMJMSSserver and BAMJmsSystemResource from the domain.

NOTE: You must manually remove the Oracle BAM server and cluster after the upgrade as described in Remove the Oracle BAM Servers and Clusters from the domain..

Task 8   Run the Upgrade Assistant to upgrade component configurations.

After the domain reconfiguration, run the Upgrade Assistant (again) to upgrade any remaining component configurations.

For more information, see Section 3.6, "Upgrading the Domain Component Configurations Using the Upgrade Assistant".

5.4 Post-Upgrade Configuration Tasks

After a successful upgrade, you must perform the following tasks to run the SOA 12c domain that will eventually include Oracle BAM 12c.

- Task 1, "Start the Admin Server."

- Task 2, "Log in to the WebLogic Server Administration Console 12c."

- Task 3, "Delete the UMS JMS resources running on the Oracle BAM server or Oracle BAM cluster."

- Task 4, "Delete Subdeployment resources targeted to UMS JMS Server targeted to Oracle BAM."

- Task 5, "Remove the Oracle BAM Servers and Clusters from the domain."

- Task 6, "Remove unnecessary Oracle BAM 11g files from the upgraded domain."

- Task 7, "For Cluster Upgrades Only: Stop the Admin and Managed Servers."

- Task 8, "For Cluster Upgrades Only: Run the pack command on the server where the Admin Server and one of the managed servers is installed."

- Task 9, "For Cluster Upgrades Only: Run the unpack command to replicate the domain configuration of SOAHOST1 on SOAHOST2."

- Task 10, "Configure 11g Oracle BAM Adapter to work with SOA 12c domain."

- Task 11, "Start the Managed Server."

- Task 12, "Delete the existing UMS Email driver from the SOA domain."

Note:
Oracle recommends that you first run the 12c SOA environment with Oracle BAM 11g. Once you have verified that the environment is functioning as expected, you can extend the domain with Oracle BAM 12c as described in Section 5.5, "Extending the SOA Domain with Oracle BAM 12c".

Task 1   Start the Admin Server.

To start the Oracle WebLogic Administration Server, use the following script:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

Task 2   Log in to the WebLogic Server Administration Console 12c.

To display the Administration Console:

1. Enter the following URL in a browser:

http://host name:port_number/console

The port number is the port number of the Administration Server. By default, the port number is 7001.

The login page is displayed.

2. Log in using the user name and password supplied during installation or another administrative user that you created.
Oracle WebLogic Server Administration Console is displayed as shown in the following figure:

Alternatively, you can access the Administration Console from Fusion Middleware Control, from the home pages of targets such as the Administration Server or Managed Servers.

Task 3   Delete the UMS JMS resources running on the Oracle BAM server or Oracle BAM cluster.

These steps can be used to remove the UMS JMS resources for standalone or clustered environments. Note the additional steps needed for Oracle BAM cluster.

1. Determine which JMS Server name is targeted to the Oracle BAM server or Oracle BAM cluster. You may have multiple JMS servers, and it is important to note which server is targeted to the Oracle BAM server or cluster before you continue. If you have only one UMS JMS Server, the default name is UMSJMSServer_auto_1. Always validate that the target of the selected UMS JMS Server is the Oracle BAM server or Oracle BAM cluster.
Navigate to the Summary of JMS Servers screen (shown below). From the Domain Structure menu, expand Services, select Messaging and then select JMS Servers. Locate the UMSJMSServer that is targeted to the Oracle BAM server.

In the example below, UMSJMSServer_auto_3 is the server targeted to the Oracle BAM server.

2. Delete the local queues for the UMS JMS Server targeted to Oracle BAM (UMSJMSServer_auto_3 in this example).
Navigate to the Summary of JMS Modules screen (shown below). From the Domain Structure menu, expand Services, select JMS Modules. Locate UMSJMSSystemResource and click to display the local (and distributed) queues in the Settings for UMSJMSSystemResource screen. You can filter the results to show only those queues targeted to your UMS JMS Server.

3. Oracle BAM Cluster Only: Select all Uniform Distributed Queues targeted only to the Oracle BAM server or cluster (UMSJMSServer_auto_3 in this example). (You can filter by type Uniform Distributed Queues). Click Delete.
CAUTION: Do not delete distributed queues that include server targets other than Oracle BAM. If there are other targeted servers, you must first remove (untarget) the Oracle BAM server from the distributed queue as shown in Step 4.

4. Untarget the Oracle BAM server from the distributed queue (if necessary).
To untarget the Oracle BAM server from the distributed queue, click the Targets tab from the Settings for UMSJMSSystemResource screen. Remove the checkmark next to the Oracle BAM server and click Save. Now you can safely delete the distributed queues as described in Step 3.

5. Delete the local queues that are targeted to the UMS JMS Server.
Select all local queues that are targeted to the UMS JMS Server targeted to Oracle BAM (UMSJMSServer_auto_3) from the Settings for UMSJMSSystemResource screen (as shown below):

6. Click Delete.

Task 4   Delete Subdeployment resources targeted to UMS JMS Server targeted to Oracle BAM.

1. Delete the subdeployment resources from the UMS JMS Server.
From the Settings for UMSJMSSystemResource screen (shown above), click the Subdeployments tab.

2. Select the UMS JMS Server targeted to Oracle BAM (in the example below its UMSJMSServer_auto_3).

3. Click Delete.

Task 5   Remove the Oracle BAM Servers and Clusters from the domain.

While the Admin Server is running, use Weblogic Console to complete the following tasks.

Note:
For more information on navigating through the Fusion Middleware Control Console, see "Getting Started with Administering Oracle SOA Suite and Oracle BPM Suite" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

1. Navigate to the Summary of JMS Servers screen (shown below). From the Domain Structure menu, expand Services, select Messaging and then select JMS Servers.

2. Select the UMSJMSServer_auto_x from the list. Make sure the Current Target is the Oracle BAM server.

3. Click Delete.

4. Navigate to the Summary of Persisted Stores screen (shown below).

5. Select UMSJMSFileStore_auto_x from the list. (Make sure the Target is the Oracle BAM server.)

6. Click Delete.

7. Navigate to the Summary of Clusters screen (shown below). From the Domain Structure menu, expand Environment and select Clusters.

8. Select bam_cluster from the list of clusters.

9. Click Delete.

10. Navigate to the Summary of Servers screen (shown below). From the Domain Structure menu, expand Environment and select Servers.

11. Select the Oracle BAM server(s) from the list.

12. Click Delete.

Task 6   Remove unnecessary Oracle BAM 11g files from the upgraded domain.

Use the domainupdater script to remove any unnecessary 11g files from the upgraded domain.

1. Stop the 12c Admin Server:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

2. Run the domainupdater script from the SOA 12c home to remove any unnecessary legacy 11g files from the upgraded domain.

(UNIX) cd ORACLE_HOME/soa/bam/bin
./domainupdater.sh
Enter the 11g domain path: (ex:)/soa11g/user_projects/domains/soa_domain

(Windows) cd ORACLE_HOME\soa\bam\bin
domainupdater.cmd
Enter the 11g domain path: (ex:)\soa11g\user_projects\domains\soa_domain

3. Restart the 12c Admin Server.

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

Task 7   For Cluster Upgrades Only: Stop the Admin and Managed Servers.

If you are upgrading a cluster, you must stop the Admin and Managed Servers before you execute the pack and unpack commands described in the next steps.

To stop the WebLogic Server:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

To stop the SOA server:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
soa_server_name admin_url

See Starting and Stopping Servers for information on stopping servers in the correct order.

Task 8   For Cluster Upgrades Only: Run the pack command on the server where the Admin Server and one of the managed servers is installed.

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

To get the reconfigured domain, including NodeManager, onto the other node in the cluster, one must do a managed pack from the Admin Server machine, and then unpack this on the remote nodes.

For more information on using the pack command, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

NOTE: The pack and unpack command utility must be run from 12c install directory pointing to the upgraded 11g domain.

Execute the pack command on the server where the Admin Server and one of the Managed Servers is installed.

In our example, you would execute the following on SOAHOST1:

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle Home directory (the installation directory for the 12.1.3 bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

- By default, the domainupgradetemplate is created in the current directory where you ran the pack command. In this example, it would be created in the following directory, but you can specify a full path for the template jar file as part of the -template argument to the pack command:

ORACLE_COMMON_HOME/common/bin/

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

For more information on using the pack command, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

Task 9   For Cluster Upgrades Only: Run the unpack command to replicate the domain configuration of SOAHOST1 on SOAHOST2.

Make sure that the Admin and Managed Servers are still stopped and then execute the following unpack command to create a full domain or a subset of a domain used for a Managed Server domain directory on the remote machine. You may use unpack only with a template compatible with your current installation.

A sample unpack command code snippet is shown below. Use this as an example only. Note that you must specify the "-overwrite_domain=true" flag on unpack.

For more information on using the pack command, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle Home directory (the installation directory for the 12.1.3 bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

Task 10   Configure 11g Oracle BAM Adapter to work with SOA 12c domain.

Once the SOA 12c domain has been upgraded, you must configure the SOA 12c domain to use the Oracle BAM 11g domain you created in Section 5.2.1, "Creating a New Oracle BAM 11g Domain Before You Upgrade".

For more information on how to configure this setup, see "Configuring Oracle BAM Adapter" in the 11g version of the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

Task 11   Start the Managed Server.

To start the SOA server:

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
soa_server_name admin_url

See Starting and Stopping Servers for information on stopping servers in the correct order.

Task 12   Delete the existing UMS Email driver from the SOA domain.

Due to incompatibility issues with the mail patterns, you must delete the UMS driver in Oracle Enterprise Manager. Note that you will create a new driver after you have extended the SOA 12c domain with the Oracle BAM 12c templates.

1. While the Admin Server and all the managed servers are running in the SOA domain, navigate to User Messaging Service, select the usermessagingdriver-mail service targeted to the soa_server.
From the User Messaging Email Driver drop-down menu, select Email Driver Properties as shown below.

2. Select the User Messaging Service Email driver name from the Target Navigation pane.

3. Click Delete.

4. Repeat the process for any other cluster present in the domain.

5.5 Extending the SOA Domain with Oracle BAM 12c

When you are ready to use Oracle BAM 12c with your upgraded SOA 12c environment, you must complete the following tasks. Note that some tasks are optional.

- Task 1, "Stop the Admin Server and SOA Managed Server(s)"

- Task 2, "Extend the SOA 12c domain with Oracle BAM 12c domain template."

- Task 3, "Create the new UMS Email driver for the Oracle BAM server."

- Task 4, "Import the Oracle BAM 11g data objects and EMS data to the BAM 12c server."

- Task 5, "Manually recreate the 11g BAM dashboards, alerts, and other artifacts for use in the BAM 12c domain."

- Task 6, "Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)"

- Task 7, "Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional)"
Additional Tasks (Optional):

- Section 5.5.1, "Migrating 11g Monitor Express to Process Star Schema"

- Section 5.5.2, "Generating 11g Compatible Process Star Schema Data Views in 12c (Optional)"

Task 1   Stop the Admin Server and SOA Managed Server(s)

Stop all of the 12c servers and processes that are currently running before you begin extending the domain.

To stop the WebLogic Server:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

To stop the SOA server:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
soa_server_name admin_url

See Starting and Stopping Servers for information on stopping servers in the correct order.

Task 2   Extend the SOA 12c domain with Oracle BAM 12c domain template.

Use the Configuration Wizard to extend the existing SOA domain with Oracle BAM 12c.

1. Launch the Configuration Wizard.

(UNIX) ORACLE_HOME/oracle_common/common/bin
./config.sh

(Windows) ORACLE_HOME\oracle_common\common\bin
config.cmd

2. Select Extend Existing Domain when prompted:

3. Select the following templates on the Templates screen:

- Oracle WSM Policy Manager - 12.1.3

- Oracle Business Activity Monitoring - 12.1.3

4. Complete the remaining Configuration Wizard screens as described in "Configuring the Oracle SOA Suite and Business Activity Monitoring (BAM) Topology" in Installing and Configuring Oracle SOA Suite Foundation and Business Process Management.

Note:
Certain Fusing Middleware components such as SOA, OSB and BAM have a dependency on UMS in 12c. If you configure more than one of these components within a single 12.1.3 domain, then each of these components must run within its own cluster — even if there is only one server that runs that component. See Figure 4-1, "Clustered SOA Topology" in Chapter 4, "Upgrading a Clustered SOA Environment".
When you reach the Advanced Configuration screen of the Configuration Wizard, select Managed Servers, Clusters, and Coherence to create a BAM cluster as described in "Clusters" in Creating WebLogic Domains Using the Configuration Wizard.

Task 3   Create the new UMS Email driver for the Oracle BAM server.

While the Oracle BAM server is running in the cluster, use Fusion Middleware Control Console to complete the following tasks:

1. Navigate to the Email Driver Properties screen.
From the Target Navigation pane, select User Messaging Service and from the User Messaging Email Driver drop-down menu, select Email Driver Properties (as shown below).

2. Click Create to add a new UMS Email driver.

3. Provide a unique name for the new Email driver in the Name field as shown below. Note that UMS needs to be configured on each cluster in a 12c domain. Therefore maintain the default selection for Configuration Level as Cluster as shown in the image.

4. Select Use Default Sender Address and enter EMAIL:emailid@company.com. Note that the EMAIL: prefix is mandatory in this field.

5. Click OK to create the new driver with the given properties.

Task 4   Import the Oracle BAM 11g data objects and EMS data to the BAM 12c server.

Once you have extended the domain to include BAM 12c, you must export the data objects and EMS data from the BAM 11g environment you have been using with SOA 12c. You will then import this data to the SOA with BAM 12c environment.

1. Export the data objects and EMS data from the 11g BAM domain using the 11g ICommand command-line utility. (Note that the EMS definitions were upgraded as part of the standard upgrade process and do not need to be imported.)
The following example shows how to use ICommand 11g to export information about one or more objects in the Oracle BAM server to a XML file:

$11g_ORACLE_HOME/soa/bam/bin/icommand -cmd export -name "/Samples/Call Center" -type dataobject -file C:\CallCenter.xml

NOTE: You may need to modify the ICommand configuration file before you run the script. Specifically, verify that the correct usernames and passwords have been entered. The BAMICommandConfig.xml file is located in WLS_HOME/user_projects/domains/base_domain/config/fmwconfig/servers/bam_server1/applications/oracle-bam_11.1.1/config/.

The following is an example configuration file.

<host>www.example.com</host>
<port>7001</port>
<username>weblogic</username>
<password>welcome1</password>
<dbusername>SOAINFRA</dbusername>
<dbpassword>welcome1</dbpassword>
<dburl>jdbc:oracle:thin:@localhost:1521:orcl</dburl>

For more information on using the 11g BAM ICommand command-line utility to export data files, see the "Export" section of Monitoring Business Activity with Oracle BAM.

2. Import the XML file (created in the previous step) using the 12c BAMCommand command-line utility.
The following example shows how to use 12c BAMCommand to import the information:

$12c_ORACLE_HOME/soa/bam/bin/bamcommand -cmd import -file BPELOrderBookingDataObject.xml -upgrade 1 -username weblogic -port 7001 -host server.yourcompany.com

For more information on using the BAMCommand command-line utility to import data files, see the "Import" section of Monitoring Business Activity with Oracle BAM.

Note:
When you use the import command with the -upgrade parameter to bring Oracle BAM 11g artifacts into Oracle BAM 12c, some information is modified.
For more information, see "Upgrade Considerations" in Monitoring Business Activity with Oracle BAM.

Task 5   Manually recreate the 11g BAM dashboards, alerts, and other artifacts for use in the BAM 12c domain.

The dashboards, alerts, views, etc. you used in your BAM 11g domain must be recreated for the BAM 12c domain.

See the following sections of the BAM user guide, Monitoring Business Activity with Oracle BAM:

- Creating Dashboards

- Creating Alerts

- Creating Parameters

- Creating and Using Business Views

Task 6   Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)

Oracle strongly recommends that you perform the process cubes migration after extending an upgraded BPM 12c domain with BAM 12c. This migration will ensure that all of the necessary 12c data objects are created for BPM entities. This will also ensure the BPM process analytics data has been migrated from the 11g Process cubes (applicable only if cube tables are populated with run-time data).

While exporting and importing each archive, you will be required to provide the server admininstrator (admin) username and password, as well as the SOAINFRA schema username and password.

CAUTION:
The process cubes migration is a required prerequisite before proceeding with the Monitor Express migration described in Task 7.
This step is required even if you did not use Oracle BAM 11g Monitor Express with BPM 11g.

1. Disable the Process Metrics.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which Oracle SOA 12c server is installed.
For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.
The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.
The analytics attributes are listed.

10. If not already set to true, change the value of the DisableProcessMetrics attribute to true.

11. Click Apply.

2. Determine the exportType to be used for the migration. The exportType must be decided before migration because once the active instance migration is complete, and process analytics are enabled, you will not be able to go back and migrate the Completed instance data.
The valid exportType values are:

- INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default): Migrates only Active instance fact data archives

- ALL: Migrates all Active and Completed instance fact data archives

3. (UNIX Only) Run migrateBPMProcessCubes script from the 12c SOA home.
The migrateBPMProcessCubes shell script performs migration in two phases: export and import. The first phase exports the following archives from BPM Process Cubes, and then the second phase imports them to BAM 12c.

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (if running with -exportType = ALL option)

On UNIX Operating Systems:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]

Where:

serverUrl      (mandatory) : BAM 12c Server URL
serverPort     (mandatory) : BAM 12c Server Port
serverUserName (mandatory) : BAM 12c Server  admin user
dbUrl          (mandatory) : SOA DB jdbc URL
dbUserName     (mandatory) : SOAINFRA schema username
exportDir      (mandatory) : A writable Directory where exported archives will be written
exportType     (optional ) : Export Type.  Valid values are
a)INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default):  Migrates only Active instance fact data archives
b)ALL                                             :  Migrates all Active and Completed instance fact data archives
importOnly     (optional ) : If specified, data object definition and data archive export phase is skipped and only import is performed. It is assumed that archives are already present under "exportDir"

Note:
If there were errors during the migration, you may need to manually correct the issues and start the script again. For more information, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

4. (Windows Only) Export data object definitions and data from 11g BPM Process Cubes and then import them to 12c:
The data object definitions migration is performed in two steps. Step one involves exporting the data from 11g process cubes and step 2 imports the data into 12c.

The first phase exports the following archives from BPM Process Cubes, and then the second phase imports them to BAM 12c.The export command shown below will generate the following archive files under the <exportDir> directory:

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (if running with -exportType = ALL option)

Step 1: Export the data objects and definitions using the following code example: (make sure that you provide your actual directory names)

java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar

oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]

Step 2: Import the data object definitions(DefinitionExport.zip) into the BAM server.

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DefinitionExport.zip> -mode update

NOTE: After importing the archive for BAM 12c, review the bamcommand.log.* files under ORACLE_HOME/bam/bin directory to make sure no errors occurred. If error conditions do exist, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

5. (Windows Only) Import dimension data (DimensionExport.zip) into the BAM server. (Note that this command uses -datamode and -migrate parameters.)

Use the following code example to import the dimension data:

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DimensionExport.zip>  -datamode update -migrate 1

NOTE: After importing the archive for BAM 12c, review the bamcommand.log.* files under ORACLE_HOME/bam/bin directory to make sure no errors occurred. If error conditions do exist, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

6. (Windows Only) Import active fact data (ActiveFactDataExport.zip) into the BAM server. (Note that this command uses -datamode and -migrate parameters.)

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

7. (Windows Only - if exportType=ALL) Import completed fact data (CompletedFactDataExport.zip) into the BAM server. (Note that this command uses -datamode and -migrate parameters.)

Use this command only if you used the exportType ALL when you migrated the data objects definitions for the BAM 11g process cubes.

cd %ORACLE_HOME%\bam\bin\

run the following command
bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

NOTE: After importing the archive for BAM 12c, review the bamcommand.log.* files under ORACLE_HOME/bam/bin directory to make sure no errors occurred. If error conditions do exist, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

8. Restart the Oracle BAM server once the migration has completed successfully.

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
bam_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
bam_server_name admin_url

When prompted, enter your user name and password.

9. While the Oracle BAM server is running, enable the process metrics.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which the Oracle BAM server is installed.
For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.
The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.
The analytics attributes are listed.

10. Change the value of the DisableProcessMetrics attribute to false.

11. Click Apply.

Task 7   Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional)

If want to be able to analyze historical data from BAM 11g through the BAM 12c process analytics dashboards, you will need to migrate the 11g Monitor Express data to BAM 12c process star schema using the steps described in Section 5.5.1, "Migrating 11g Monitor Express to Process Star Schema".

Note:
Complete this optional task only if want to be able to analyze historical data from BAM 11g through the BAM 12c process analytics dashboards. To do this, you must migrate the 11g process analytics data from BAM 11g the Monitor Express data objects to the BAM 12c Process star schema data objects as described in Section 5.5.1.

5.5.1 Migrating 11g Monitor Express to Process Star Schema

This section describes the pre-requisites and steps for migrating 11g Monitor Express Data to BAM 12c Process star schema. Note that some tasks in the process apply only to certain components or operating systems. If you are not using the component or operating system, skip to the next task.

- Task 1, "Migrate 11g Process Cubes to BAM 12c Process star schema (BPM Users Only)"

- Task 2, "Migrate BPM data from BAM 11g Monitor express schema."

Task 1   Migrate 11g Process Cubes to BAM 12c Process star schema (BPM Users Only)

Before you can upgrade the 11g Monitor Express data to BAM 12c Process Star schema, you must migrate 11g process cubes to the BAM 12c star schema to ensure that all of the necessary 12c data objects are created for BPM entities. This will also ensure the BPM process analytics data has been migrated from the 11g Process cubes (applicable only if cube tables are populated with run-time data).

Before you continue to the next step, perform the steps in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).

Task 2   Migrate BPM data from BAM 11g Monitor express schema.

Complete this optional task only if want to be able to analyze historical data from BAM 11g through the BAM 12c process analytics dashboards. To do this, you must migrate the11g process analytics data from BAM 11g the Monitor Express data objects to the BAM 12c Process star schema data objects as described in this section.

1. Disable the Process Metrics.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which the Oracle BAM server is installed.
For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.
The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.
The analytics attributes are listed.

10. Change the value of the DisableProcessMetrics attribute to true.

11. Click Apply.

2. Run the BAM/BPM 11g migration utility to migrate the Monitor Express data. (Data objects and data object definitions were migrated in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).)
The following command will generate the data export for BPM data in zipped CSV files:

java -cp
$DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.interface.jar:
$ORACLE_HOME/oracle_common/modules/oracle.jdbc_12.1.0/ojdbc6.jar:
$ORACLE_HOME/bam/modules/oracle.bam.client/bam-client.jar:
$ORACLE_HOME/bam/lib/bam-schema.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.dataobject.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.hwfanalytics.dataobject.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.model.jar    oracle.bpm.metrics.dataobject.migration.application.Migrate11gBAMBPMTo12cDO  PropertyFiles

This command will generate "FactDataExport.zip" file under <PATH> directory.

NOTE: You can specify the composite name in the property file. If a composite name is specified, then data for only those composites will be migrated. If a composite name is not defined in the property file, then all the composite data will be migrated.

#*************************************
#Mandatory Fields
#*************************************
#11g User Name
BAM_11g_USER_NAME= <<11gUserName>>
#12c User Name
BAM_12c_SOURCE_NAME = <<12cUserName>>

#11g URL
BAM_11g_URL=jdbc:oracle:thin:@<<11gBAMSchemaDatabaseIP>>:<<Port>>:<<SID>>
#12c URL
BAM_12c_URL=jdbc:oracle:thin:@<<12cDatabaseIP>>:<<Port>>:<<SID>>

#Path where data to be exported
PATH = <<Path where data need to be exported>>
#*************************************
#Optional Fields
#************************************

COMPOSITE_LIST = <<List of Composite for which data needs to be exported. This is ':' seperated>>
#If above mention configurable is missing then all the composite data will be migrated.
DATAOBJECT_FOLDER_PATH = <<DataObject Path If this field is absent then default path will taken as Samples/Monitor Express/BI_>>
#************************************

3. Import BPM data to BAM 12c.
This step will ensure that the previously exported BPM Monitor Express data is imported to BAM 12c.

cd $DOMAIN_HOME/bam/bin

./bamcommand -host <<host>> -protocol t3 -dbusername <<DbUserName>>  -dburl jdbc:oracle:thin:@<<DBIP>>:<<Port>><<SID>> -username  <<weblogicUserName>> -cmd import  -file <<Path of BPM FactDataExport zip file >> -mode update -migrate 1

4. Once the migration is complete, enable publishing to BAM 12c by setting the DisableProcessMetrics parameter to false.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which the Oracle BAM server is installed.
For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.
The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.
The analytics attributes are listed.

10. Change the value of the DisableProcessMetrics attribute to false.

11. Click Apply.

Note:
If there are any errors while importing the archive files, you can roll back all of the imported data in the BAM 12c process star schema data objects by running the rollback SQL file.
From a BAM 12c database SQL prompt, log in as the SOAINFRA schema user, navigate to the <PATH> directory and execute the following command:

sql> @rollbackMonitorExpressMigration.sql

For additional error handling procedures, see Section A.4.1, "Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration".

5.5.2 Generating 11g Compatible Process Star Schema Data Views in 12c (Optional)

Prerequisite: You must complete the steps described in Task 6, "Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)" before generating these views.

If you have an Oracle Fusion Middleware 11g application built on top of 11g process star schema views, and you want to continue to use the application in 12c, then you will need to recreate the views after the upgrade. The Star schema database views in 12c are different from the 11g views and cannot be automatically upgraded.

Specifically, the star schema database views in 12c have different names, are based on top of Oracle BAM data objects (and not on process cube tables), and are created at the composite level (instead of process level as in 11g). An automated utility is provided to assist you in recreating your views - both standard and process-specific - for use in your Oracle 12c environment.

Note:
While this step is optional, Oracle recommends that you use BAM 12c process star schema views as they provide more information that the 11g process stars schema views.

Task 1   Update the classpath to include the interface JAR file.

You must updated the CLASSPATH to include the location of the oracle.bpm.analytics.interface.jar file located in the SOA Home.

For example:

DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar

Task 2   Recreating Standard Views

Use the Standard View 11g Migration Utility to create 12c compatible versions of the following 11g standard views:

BPM_ACTIVITY_DEFINITION_V
BPM_ACTIVITY_INSTANCE_V
BPM_ACTIVITY_PERFORMANCE_V
BPM_PROCESS_DEFINITION_V
BPM_PROCESS_INSTANCE_V
BPM_PROCESS_PERFORMANCE_V
BPM_ROLE_DEFINITION_V
Use the following command to run the utility:

java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.util.StandardView11gMigrationUtil <initialContextFactory> <protocol> <host name> <soa-port> <username>[]

Where:

- initialContextFactory is the JNDI Initial Context Factory such as weblogic.jndi.WLInitialContextFactory

- protocol is the RMI / JNDI protocol configured for the target server. Specify t3, IIOP, HTTP, T3s, IIOPS, or HTTPS.

- host name is the full name of the host such as soa.mycompany.com

- soa-port is the SOA listening port such as 7001

- username is the server login name such as weblogic.

Task 3   Recreating Process-Specific Views

Use the Process Specific View 11g Migration Utility to create 12c compatible versions of the following 11g process-specific views:

BPM_ACTV_INST_<viewIdentifier>_V
BPM_ACTV_PERF_<viewIdentifier>_V
BPM_PRCS_INST_<viewIdentifier>_V
BPM_PRCS_PERF_viewIdentifier>_V
Use the following command to run the utility:

java -cp $ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.utill.ProcessSpecificView11gMigrationUtil <initialContextFactory> <protocol> <host name> <soa-port> <username > [<composite-name>]

Where:

- initialContextFactory is the JNDI Initial Context Factory such as weblogic.jndi.WLInitialContextFactory

- protocol is the RMI / JNDI protocol configured for the target server. Specify t3, IIOP, HTTP, T3s, IIOPS, or HTTPS.

- host name is the full name of the host such as soa.mycompany.com

- soa-port is the SOA listening port such as 7001

- username is the server login name such as weblogic.

- composite-name (optional) is the name of a single composite you want to create views

6 Upgrading Oracle Service Bus Without Oracle SOA

This chapter describes the upgrade-specific tasks for upgrading Oracle Service Bus without Oracle SOA Suite and Business Process Management.

When upgrading Oracle Service Bus 11g (11.1.1.6 or 11.1.1.7) to Release 12c (12.1.3), you must perform the pre- and post-upgrade tasks described in this chapter. Failure to do so may result in a non-functioning post-upgrade environment.

- Section 6.1, "Understanding the Oracle Service Bus Upgrade to 12c"

- Section 6.2, "Upgrading Multiple Components that use UMS in a Single OSB Domain (Not Supported)"

- Section 6.3, "Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)"

- Section 6.4, "Migrating Resources from Previous Releases"

- Section 6.5, "Installing the Oracle Service Bus"

- Section 6.6, "Upgrading an OSB Domain (Without SOA)"

- Section 6.7, "Reconfiguring an OSB Domain"

- Section 6.8, "Upgrading the WebLogic Component Configurations"

- Section 6.9, "Performing Post-Upgrade Tasks for Oracle Service Bus"

6.1 Understanding the Oracle Service Bus Upgrade to 12c

Oracle Service Bus (OSB) can be upgraded to 12c (12.1.3) with or without Oracle SOA Suite and Business Process Management. The upgrade steps in this chapter describe how to upgrade Oracle Service Bus without SOA.

If OSB is part of your SOA 11g domain, and you will be upgrading OSB as part of your SOA Suite upgrade to 12c (12.1.3), follow the standard upgrade process described in Chapter 3, "Upgrading to SOA Suite and Business Process Management 12c (12.1.3)".

If you are upgrading Oracle Service Bus without SOA, use the upgrade procedures documented in this chapter. Note that even though your domain does not include SOA, you will still have to upgrade the _SOAINFRA schema to upgrade OSB data. OSB does not have a separate schema. See Creating Schemas for Oracle Service Bus.

Note:
Be sure to review all of the OSB-specific pre- and post-upgrade steps. All OSB upgrades (with and without SOA) require these additional steps when upgrading to 12c (12.1.3).

Step

Description

More Information

Perform all pre-upgrade tasks.

Perform the standard 12c pre-upgrade tasks as well as any OSB-specific tasks that apply to your deployment.

Section 2.1, "Performing General Pre-Upgrade Tasks"
Section 6.3, "Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)"

Make sure that your Policy Store is database-based

This important pre-upgrade tasks must be completed before you upgrade Oracle Service Bus to 12c.

Section 2.1.14, "Reassociating a File-Based Policy Store Before Upgrade"

Upgrade the WebLogic server and JRF that will host your OSB domain.

You must install the 12c infrastructure and then upgrade the infrastructure domain before upgrading Oracle Service Bus.

Section 2.3, "Installing the 12c (12.1.3) Infrastructure Distributions Before Upgrade"

Install Oracle Service Bus.

Obtain the OSB distribution and install the content to a new Oracle Home.

Section 6.5, "Installing the Oracle Service Bus"

Upgrade Oracle Service Bus.

Follow the steps in this chapter to upgrade your existing Oracle Service Bus domain.

Section 6.6, "Upgrading an OSB Domain (Without SOA)"

Perform all post-upgrade tasks.

Perform the standard 12c post-upgrade tasks as well as any post-upgrade OSB-specific tasks that apply to your deployment.

Section 8.1, "Performing Post-Upgrade Tasks"
Section 6.9, "Performing Post-Upgrade Tasks for Oracle Service Bus"

Section A.7, "Troubleshooting Oracle Service Bus"

6.2 Upgrading Multiple Components that use UMS in a Single OSB Domain (Not Supported)

If your OSB 11g topology is configured with more than one component within a single domain, then you will not be able to upgrade to 12c (12.1.3).

Certain Fusion Middleware components such as Oracle SOA, OSB and Business Activity Monitoring (BAM) have a dependency on User Messaging Service (UMS) in 12c. If you configure more than one of these components within a single 12.1.3 domain, then each of these components must run within its own cluster — even if there is only one server that runs that component.

In order to upgrade these components, you must create a separate cluster for each component during the domain reconfiguration as described in "Clusters" in Creating WebLogic Domains Using the Configuration Wizard.

The supported upgrade topology for these components is described in Section 4.3, "Upgrading a Clustered Topology".

6.3 Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)

If you are upgrading Oracle Service Bus, you must perform the following tasks before you begin the upgrade. Review your own use case scenarios and existing deployment to determine if the following tasks apply to your environment.

1. Creating Schemas for Oracle Service Bus

2. Deploying Oracle Web Services Manager Policy Manager in Your 11g Environment

3. Exporting Services, Projects and Resources when Upgrading Oracle Service Bus

4. Deleting All Services, Projects and Resources

6.3.1 Creating Schemas for Oracle Service Bus

Oracle Service Bus does not have its own schema as all database schema data for Oracle Service Bus is incorporated in the SOAINFRA schema. So, while its possible to run Oracle Service Bus without running Oracle SOA, you must create the _SOAINFRA, _UMS and _STB schemas before you begin the upgrade.

For more information, see "Creating the Required Schemas with the Repository Creation Utility”.

6.3.2 Deploying Oracle Web Services Manager Policy Manager in Your 11g Environment

If Oracle Web Services Manager (OWSM) Policy Manager is not already deployed in your Oracle Service Bus 11g environment, then you must manually deploy it before you upgrade to 12c.

In 11g, both WebLogic security policies and OWSM policies were supported on Oracle Service Bus. As of 11g (11.1.1.7), WebLogic Security policies were deprecated, and are not supported in 12c (12.1.3). Because WebLogic security policies were available in 11g, deployment of the OWSM Policy Manager and use of the OWSM policies was optional. Since only OWSM policies are supported in 12c, OWSM Policy Manager deployment is mandatory.

For information on manually deploying the OWSM Policy Manager in your 11g environment, see "Installing OWSM with WebLogic Server" in Securing Web Services and Managing Policies with Oracle Web Services Manager.

6.3.3 Exporting Services, Projects and Resources when Upgrading Oracle Service Bus

You must export services, projects and resources into a configuration JAR file before you can upgrade to Oracle Service Bus 12.1.3. After the upgrade, you will import the JAR file to the new 12c environment.

Note that you can manually export resources and services from older, supported releases. See Migrating Resources from Previous Releases.

For more information, see "Importing and Exporting Resources and Configurations" in Developing Services with Oracle Service Bus.

6.3.4 Deleting All Services, Projects and Resources

After the export, you must delete all user-created services, projects and resources before the upgrade.

For information on using the Oracle Service Bus Console to delete resources, see ”How to Delete Projects, Folders, and Resources” in Developing Services with Oracle Service Bus.

For information on using JDeveloper to delete resources, see ”How to Delete a Project or Resource" in Developing Services with Oracle Service Bus.

6.4 Migrating Resources from Previous Releases

You can manually export resources and services from the following releases and use them with Oracle Service Bus 12c (12.1.3):

- Oracle Service Bus 11g Releases: 11.1.1.6.0, 1.1.1.5.0, 11.1.1.4.0, 11.1.1.1.3

- Oracle Service Bus 10.3 Releases: 10.3.1 and 10.3.0

- AquaLogic® Service Bus Releases 3.0 and later

For more information, see "Importing and Exporting Resources and Configurations" in Developing Services with Oracle Service Bus.

6.5 Installing the Oracle Service Bus

To install Oracle Service Bus, refer to Installing and Configuring Oracle Service Bus.

You can install and upgrade Oracle Service Bus without Oracle SOA Suite and Business Process Management, but you must still install the Oracle Fusion Middleware Infrastructure 12c (12.1.3) before upgrading Oracle Service Bus. For more information, see Installing and Configuring the Oracle Fusion Middleware Infrastructure.

Note:
If you want to use Oracle Web Services Manager policies with Oracle Service Bus, you must select the Oracle Web Services Manager extension template after selecting one of the Oracle Service Bus domain templates when configuring the Oracle WebLogic domain.

6.6 Upgrading an OSB Domain (Without SOA)

To upgrade Oracle Service Bus, you will follow the basic procedures described in Table 6-1.

Table 6-1 Upgrade Assistant Screens: Upgrading Schemas

Screen

Description and Action Required

Welcome

This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks.

Schemas

Select Schemas.

NOTE: There is no OSB schema. All database schema data for Oracle Service Bus is incorporated in the SOAINFRA schema.

Available Components

This screen provides a list of installed Oracle Fusion Middleware components that have schemas that can be upgraded. When you select a component, the schemas and any dependencies are automatically selected.

When upgrading OSB, select Metadata Services, Audit Services and Oracle Platform Security Services.

Domain Directory

This screen appears if you selected Oracle Platform Security Services or Oracle Audit Services on the Available Components screen.

Enter the absolute path to the existing WebLogic domain directory, or click Browse to navigate to and select the 11g domain directory you are upgrading.

Prerequisites

Check that the prerequisites for schema upgrade are met. You must select each prerequisite before you click Next.

CAUTION: Upgrade Assistant will NOT verify that these prerequisites have been met.

Schema Credentials

Use this screen to enter database connection details for each of the schemas you are upgrading.

Examine

Review the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade.

Verify that the Source Version displayed for each schema is listing the correct version number for the schema to be upgraded.

Upgrade Summary

Review the summary of the options that you have selected for schema upgrade. Verify that the correct Source and Target versions are listed for each schema you intend to upgrade.

Click Upgrade to upgrade the schemas, or click Back if you wish to change the configurations.

Upgrade Progress

Review the status of the current upgrade process.

NOTE: The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

Click Next when the upgrade is complete.

Upgrade Success

Click Close if the Upgrade was successful.

If the upgrade failed or if you canceled the upgrade before it completed successfully, you should review the log files, restore the backed up environment, and restart the Upgrade Assistant.

6.7 Reconfiguring an OSB Domain

After the schema upgrade, you must reconfigure the 11g OSB domain using the Oracle Reconfiguration Wizard. This process is identical to the SOA domain reconfiguration procedures described in Reconfiguring the Domain Using the Reconfiguration Wizard.

6.8 Upgrading the WebLogic Component Configurations

You will run the Upgrade Assistant a second time, after the domain reconfiguration, to upgrade any component configurations in the 11g OSB domain.

This process is described in Upgrading the Domain Component Configurations Using the Upgrade Assistant.

6.9 Performing Post-Upgrade Tasks for Oracle Service Bus

After a successful upgrade, you may need to perform one or more of the following tasks. Review your own use case scenarios and existing deployment to determine if the following tasks apply to your environment.

Note:
If you upgraded a clustered OSB topology, you must complete the post-upgrade tasks described in Section 4.5, "Performing Post-Upgrade Tasks for Clusters".

- Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

- Importing Domain Configuration Data

- Importing Security Configurations

- Upgrading Your XQuery Resources

- Managing Oracle Service Bus Console Users in Enterprise Manager

- Understanding 12c Split-Joins

Note:
If you experience any post-upgrade issues with Oracle Service Bus, refer to Section A.7, "Troubleshooting Oracle Service Bus" for a list of common solutions.

6.9.1 Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

To enable Oracle HTTP Server to route to Oracle Service Bus console and Oracle Service Bus service, set the WebLogicCluster parameter to the list of nodes in the cluster.

For more information, see "Configuring Oracle HTTP Server for the Oracle Service Bus" in the Enterprise Deployment Guide for Oracle SOA Suite.

6.9.2 Importing Domain Configuration Data

After the upgrade you will need to import the domain configuration data that you exported in "Exporting Services, Projects and Resources when Upgrading Oracle Service Bus".

For more information, see "How to Import Resources from a Configuration JAR File in the Console" in Developing Services with Oracle Service Bus and ”Executing a Configuration File” in Administering Oracle Service Bus.

6.9.3 Importing Security Configurations

Use the Oracle WebLogic Administration Console to import the security data that you exported pre-upgrade into the new Oracle Service Bus domain.

For more information, see the "Import data into a security provider" section of the Oracle WebLogic Server Administration Console Online Help.

Note:
You must import the security information for each security provider separately.

6.9.4 Upgrading Your XQuery Resources

Oracle Service Bus supports XQuery 1.0. The older XQuery 2004 is also supported. Any new XQuery resource created in Service Bus uses the XQuery 1.0 version, by default.

If you have upgraded from a pre-12c Service Bus project, all XQuery resources in the project are configured to use the XQuery 2004 version.

For more information on upgrading XQuery Resources, see "How to Upgrade Your XQuery Resources to use XQuery 1.0" in Developing Services with Oracle Service Bus.

6.9.5 Managing Oracle Service Bus Console Users in Enterprise Manager

In Oracle Service Bus 11g, Oracle Service Bus Console user roles were managed only through the WebLogic Console. In 12c, there are Oracle Service Bus Console application roles that must be managed through Oracle Enterprise Manager Console.

To add users/groups to the roles in the Enterprise Manager console:

1. Right click the domain in Enterprise Manager and select Application Roles

2. Select the OSB Console application and click the arrow icon to get the list of roles.

3. Add Users / Groups to the roles as appropriate.

6.9.6 Understanding 12c Split-Joins

The 11g split-join business service will no longer exist in 12c because in 12c there is a direct way to invoke a split-join component from a pipeline or a proxy service. The upgrade process will automatically change all statically configured invoke references to a split-join business service as follows:

- The flow business service is removed. This means the Timeout property configured for the Flow business service is also removed.

- If the business service is located in the same project as the proxy service that invokes it, then the pipeline associated with that proxy service invokes the split-join directly.

- If the business service is located in a different project from the proxy service that invokes it, then a local proxy service is created to invoke the split-join. The local proxy service is invoked by the original proxy service.

7 Upgrading SOA with SOA Core Extension 12c from AIAFP 11g

This chapter describes the upgrade procedures for Application Integration Architecture Foundation Pack (AIAFP) 11g which is now called SOA Core Extension in 12c.

The chapter describes the following tasks:

- Section 7.1, "Upgrading to SOA Core Extension 12c (12.1.3)"

- Section 7.2, "Performing Post-Upgrade Tasks for SOA Core Extension"

Caution:
If you are currently running Oracle Application Integration Architecture Foundation Pack (AIAFP) 11g Release 1 (11.1.1.7), you must patch to RUP 2 (17553612) and one off patch (18464591) or later before you attempt to upgrade.
If you are running Oracle Application Integration Architecture Foundation Pack 11g (11.1.1.6), you must apply RUP5 (17423167).

For more information on supported starting points, see Section 1.2, "Understanding the Starting Points for a SOA 12c (12.1.3) Upgrade".

7.1 Upgrading to SOA Core Extension 12c (12.1.3)

You will follow the procedure described in Upgrading to SOA Suite and Business Process Management 12c (12.1.3) to upgrade SOA with Oracle Application Integration Architecture Foundation Pack 11g to SOA with SOA Core Extension 12c (12.1.3).

Note the following additional options when upgrading AIAFP:

Upgrade Assistant Screen

Description and Action Required

Available Components

When upgrading schemas in Task 2, "Upgrade the Schemas", make sure that you select SOA Core Extension on the Available Components screen as shown below:

11g AIAFP Details

When performing the tasks described in Section 3.6, "Upgrading the Domain Component Configurations Using the Upgrade Assistant", you will have to enter the 11g AIAFP directory location and Instance name in the 11g AIAFP Details screen as shown below:

SCE Cluster Configuration

If AIAFP 11g is installed over a SOA 11g cluster, then you will need to provide the location of the shared directory.

7.2 Performing Post-Upgrade Tasks for SOA Core Extension

The following post-upgrade tasks should be performed after upgrading to SOA Core Extension 12c (12.1.3):

- Removing Obsolete AIA Users and Groups from SOA Core Extension (Optional)

7.2.1 Removing Obsolete AIA Users and Groups from SOA Core Extension (Optional)

As part of the upgrade of AIAFP 11g to the rebranded SOA Core Extension 12c (12.1.3), some of the obselete 11g AIA users and groups has been deprecated.These users and groups may be deleted.

After running the Upgrade Assistant to perform a configuration upgrade to SOA Core Extension 12c (12.1.3), you may run an installed ant script that will remove these obsolete users and groups as described below.

Task 1   Start the Admin Server and SOA managed servers.

To start the Administration Server, go to the DOMAIN_HOME/bin directory.

On UNIX operating systems, run:

./startWebLogic.sh

On Windows operating systems, run:

startWebLogic.cmd

To start the SOA Managed servers, login to Oracle Fusion Middleware Control and follow the steps in Starting the Managed Servers.

Task 2   Set the environment variable using the following command:

Set the SOA Core Extension environment variables using the following command:

On UNIX operating systems:

cd <Domain_Home>/soa/aiafp/bin
./aiaenv.sh

On Windows operating systems:

cd <Domain_Home>/soa/aiafp/bin
aiaenv.bat

Task 3   Execute the following ant script which will delete the obsolete Security configurations:

Note that ant is installed as part of FMW 12.1.3.0.0 at MW_HOME/oracle_common/modules/org.apache.ant_1.9.2 and was added to your PATH in the previous step.

On UNIX operating systems:

ant -f $SOA_HOME/aiafp/Install/config/PostUpgrade.xml

On Windows operating systems:

ant -f  %SOA_HOME%/aiafp/Install/config/PostUpgrade.xml

NOTE:

- Log files are located in the $DOMAIN_HOME/soa/aia/logs directory.

- When you run this script, the user AIAIntegrationAdmin will be deleted

- When you run this script, the groups AIALifecycleUser, AIALifecycleDeveloper, and AIALifecycleInstallDeveloper will be deleted

- Failure mode - if the execution of tasks inside the Deployment Plan fails, the script will exit with Failure on first error and the failures will be logged

8 Performing Post-Upgrade Tasks

This chapter summarizes the tasks you might have to perform after upgrading to SOA 12c.

This chapter includes the following sections:

- Section 8.1, "Performing Post-Upgrade Tasks"

- Section 8.2, "Verifying that the Upgraded Components Work as Expected"

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

8.1 Performing Post-Upgrade Tasks

The following tasks should be performed after an upgrade:

- Section 8.1.1, "Reapplying Start Script Properties for JVM"

- Section 8.1.2, "Reapplying Customizations to setDomainEnv"

- Section 8.1.3, "Reapplying Customizations to XEngine Configuration Files"

- Section 8.1.4, "Copying Custom XPath Classes"

- 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.7, "Starting and Stopping Servers"

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

- Section 8.1.12, "Reconfiguring Threads for SOA 12c"

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

8.1.2 Reapplying Customizations to setDomainEnv

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

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

8.1.4 Copying Custom XPath Classes

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

8.1.5 Recreating Partition-Specific Roles for Application Roles and Policies

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.

8.1.6 Migrating Java Keystore (JKS) to OPSS KeyStore Services (KSS)

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.

8.1.7 Starting and Stopping Servers

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.

Start servers in this order:

1. Webtier (including the Oracle HTTP Server)

2. Node Managers

3. Admin Servers

4. Oracle Web Services Manager (OWSM) Managed Server

5. Service-Oriented Architecture (SOA) Managed Server

6. Oracle Service Bus (OSB) Managed Server

7. Business Activity Monitoring (BAM) Managed Server

Stop servers in this order:

1. Business Activity Monitoring (BAM) Managed Server

2. Oracle Service Bus (OSB) Managed Server

3. Service-Oriented Architecture (SOA) Managed Server

4. Oracle Web Services Manager (OWSM) Managed Server

5. Admin Servers

6. Node Managers

7. Webtier (including the Oracle HTTP Server)

8.1.8 Displaying Composite Instances in Enterprise Manager

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:

1. Stop the Administration Server and any running managed servers as described in Section 8.1.7.

2. Connect to SOAINFRA schema from SQLPLUS and execute the following command:

CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

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

8.1.9 Upgrading Business Process Management (BPM) Metadata

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.

8.1.10 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 using the Audit Data Store, see "Managing the Audit Data Store" in Securing Applications with Oracle Platform Security Services.

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

8.1.12 Reconfiguring Threads for SOA 12c

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.

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

- Verifying the Domain Component Configurations Upgrade

- Verifying the Database Schema Upgrade Succeeded

- Understanding the Flow Trace Changes in 12c

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

8.2.2 Verifying the Database Schema Upgrade Succeeded

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.

8.2.3 Understanding the Flow Trace Changes in 12c

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:

Figure 8-1 New 12c Instance Flow Trace

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

9 Administering and Monitoring the Upgrade of SOA Instances

This chapter describes how open and closed SOA instances are upgraded to 12c (12.1.3) and the options a user has to administer and monitor the upgrade process.

The standard upgrade process for SOA Suite and BPM 12c provides an automated solution that will upgrade your open and closed instances. The upgrade of closed instances can be monitored and configured with the administration scripts described in the following sections of this chapter.

- Section 9.1, "Understanding the Instance Upgrade Process"

- Section 9.2, "Understanding Instance Upgrade Background Jobs"

- Section 9.3, "Using Purge Scripts Before You Upgrade"

- Section 9.4, "Using the Upgrade Administration Scripts"

- Section 9.5, "Configuring the Administration Scripts"

- Section 9.6, "Stopping Upgrade Sessions and Jobs"

- Section 9.7, "Restarting an Incomplete Upgrade"

- Section 9.8, "Monitoring Upgrade Status with SQL Queries"

- Section 9.9, "Monitoring Upgrade Status with Fusion Middleware Control"

- Section 9.10, "Resolving Instance Upgrade Errors"

9.1 Understanding the Instance Upgrade Process

The Upgrade Assistant framework delegates the upgrade of schemas to respective component installations (MDS, ORASDPM, OPSS, SOA, etc.) During the 12c SOA upgrade, the Upgrade Assistant can also upgrade instances.

What is being upgraded?

The SOA installation will also upgrade various components as part of upgrade process, including _MDS schema and the _SOAINFRA schema. The _SOAINFRA schema contains the following schema components:

- Schema definitions - such as tables and indexes

- Metadata - the data required to run the SOA server and SOA composites

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

- Instance Data - the data created by the various composites. Instances can be open or closed.

How are these components upgraded?

During the 12c schema upgrade process, it is important to understand the order in which UA performs the upgrade of these components.

The upgrade occurs in four distinct stages:

1. Upgrade Assistant will upgrade 11g schema definitions.

2. Upgrade Assistant will then upgrade 11g metadata and create background control jobs to upgrade open instances.
NOTE: This process may be time consuming as the jobs will continue to run within UA until the final database job finishes upgrading the open instances. It is important not to close the Upgrade Assistant until the final job is complete.

For example, the time required to upgrade instances depends on the following:

- Size of prefix_SOAINFRA schema (number of open and closed instances)

- System configuration (such as the number of CPI's (cores), memory usage, disk I/O configuration).

- Speed of the system and size of driver tables

3. Once all of the open instances have been upgraded, the background jobs begin upgrading the closed instances. Note that the upgrade of closed instances continues to run in the background even after you close the Upgrade Assistant. However, if the background job is stopped, and there are still closed instances to be upgraded, then you must restart them with the administration scripts.

4. Finally, once the last job finishes upgrading the open instances, the Upgrade Assistant provides the upgrade status and lists the next steps to take in the upgrade process.
You should review the Upgrade Success screen of the Upgrade Assistant to determine your next steps based on the information provided. NOTE: If you are running in -response (silent) mode, this information will be listed in the UA stdout file.

- If the Upgrade Assistant reports that there are no additional instances to be upgraded, then simply close the Upgrade Assistant UI and continue with the remaining upgrade procedures (launching the Reconfiguration Wizard for example).

- If the Upgrade Assistant reports that there was an error during the instance upgrade, then correct the error(s) and resubmit the database job to complete the upgrade. You can also use the Report Upgrade Summary administration script (Option 1) to check the UPGRADE ERROR COUNT section of the report.

- You will be notified that the upgrade of the closed instances will continue in the background after you close the Upgrade Assistant. Do not close the Upgrade Assistant until UA reports it is finished and you see the following:

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all open instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.

Note:
The upgrade of closed instances will continue until all instances have been upgraded or the middle tier is started (such as the SOA managed server, for example.)
If the middle tier is started before all closed instances are upgraded, then the upgrade job will stop. You will have to use the administration scripts to manually restart the upgrade.

9.2 Understanding Instance Upgrade Background Jobs

The background jobs are created by Upgrade Assistant during the _SOAINFRA schema upgrade. These jobs run in the background and automate the upgrade of the open and closed instance data. It is important to understand how these jobs operate within the upgrade process and how you can manage them. The list below describes some important information about these jobs:

- Jobs are created by Upgrade Assistant (UA), but they are managed through administration scripts. You can use the administration scripts to configure how and when these jobs will run, for example.

- Jobs are automatically started after the schema upgrade process.

- Jobs that are initiated through UA are automatically stopped when one of the following occurs:

- The job is complete and all closed instances are migrated to 12c

- A middle tier application is started (a managed server, for example)

- The Stop Jobs script (Option 8) is started

- If closed instances have not yet been upgraded, then the background jobs will continue to run in the background - even after the Upgrade Assistant has been closed.

- If the job is stopped, and there are still instances to be upgraded, you can enable and schedule the jobs to run at another time using the administration scripts.
For more information on configuring the background jobs, see: Enabling and Disabling Background Control Job (Option 6), Stopping Upgrade Sessions and Jobs, and Restarting an Incomplete Upgrade.

9.3 Using Purge Scripts Before You Upgrade

Use the purge scripts before you start the instance upgrade to purge the closed 11g instances that you do not need in the upgraded 12c environment. The 12c purge scripts will include non-migrated closed instances. This means that post upgrade, if you schedule to run 12c Purge scripts, the scripts will purge non-migrated closed instances. Using the purge scripts to remove closed instances can help improve the overall performance of the upgrade.

Note:
When upgrading open instances only, you may see an aborted status flow. A flow will be in an aborted state if the child flow was aborted in 11g.
All composite instance associated with this ECID will remain in terminated state.

For more information on using Auto Purge or purge scripts, see "Managing Database Growth" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

Caution:
Do not schedule purge jobs to run while the Upgrade Assistant background jobs are running. Running the scripts while Upgrade Assistant is running can cause the purge or upgrade to fail.
If you do configure purge scripts to run while UA is running, you will see: "ORA-20099: ERROR The 11g to 12c Upgrade is in progress".

If you run UA while purge scripts are running, you will see: "SQLException: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired".

9.4 Using the Upgrade Administration Scripts

The upgrade administration scripts are included as part of the Upgrade Assistant plugin included with the SOA Suite 12c (12.1.3) installation. These PL/SQL scripts provide additional administrative control over the upgrade of instances. Once upgraded, the instances can be viewed from Oracle Enterprise Manager Console. If more detailed information is needed about the upgrade progress, then use the administration scripts for additional reporting and configuration options.

- Accessing the Upgrade Scripts Menu

- Running the Administration Scripts

- Stopping Upgrade Sessions and Jobs

Note:
The administration upgrade scripts provide detailed information about the upgrade. These scripts provide additional configuration, administration, and monitoring functionality for your instance upgrade. You can configure these scripts to run (or not run) based on your own requirements.
The Fusion Middleware Control Console can also be used to administer and monitor the upgrade process, but you will have more administration options using the administration scripts.

Oracle recommends that you run the Report Upgrade Summary (Option 1) script after using the Upgrade Assistant to monitor Upgrade of closed instances.

For more information about using the Fusion Middleware Control Console to monitor the progress of the upgrade, see Monitoring Upgrade Status with Fusion Middleware Control.

9.4.1 Accessing the Upgrade Scripts Menu

There are several scripts that can be used to configure, administer and monitor your instance upgrade. These scripts can be accessed using the soa_upgrade_menu PL/SQL script.

To access the upgrade scripts menu:

Task 1   Locate the /admin directory of the 12.1.3 SOA home.

For example:

cd  <ORACLE_HOME>/soa/common/sql/soainfra/sql/oracle/121300/upgrade/admin

Task 2   Use SQL* Plus to access the _SOAINFRA schema using the schema owner name and password.

For example:

sqlplus dev_soainfra/<welcome1>

where dev is the schema owner prefix you used when the SOAINFRA schema was created, and welcome1 is the schema password.

Note:
If you attempt to access the administration scripts using a user other than <prefix>_SOAINFRA, you will encounter the following error message:

ERROR at line 24:
ORA-06550: line 24, column 3:
PLS-00201: identifier 'CONTROL_MIGRATION.UPGRADE_STATUS_INFO' must be declared

Task 3   Run the soa_upgrade_menu.sql script to see the upgrade administration options menu.

SQL> @soa_upgrade_menu.sql
==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

Table 9-1 describes the functionality of each script.

9.4.2 Running the Administration Scripts

The Administration Scripts Main Menu displays all of the options you have to monitor and administer the background control jobs and other administration tasks such as troubleshooting.

Caution:
The Advanced Options should only be used to troubleshoot the upgrade or to make changes to the upgrade process based on specific upgrade requirements. In most cases these scripts should only be executed by a designated system administrator or Oracle Support.

To run one of the administration scripts, enter an option number when prompted. Table 9-1 describes the functionality of each script.

Table 9-1 Menu Options for Upgrade Administration Scripts

Option Number

Scripts Name

Use this option to...

Description

1

Report Upgrade Summary

View the overall status of the upgrade.

The report is divided into sub-sections and provides an overview of the overall upgrade and the current run.

The Report Upgrade Summary shows the upgrade summary for METADATA, OPEN ECIDS (open instances) and ALL ECIDS (closed instances). The upgrade status is either COMPLETE or OUTSTANDING (still running).

In addition, it describes the following:

- Last upgrade date for closed 11g instances
The Maximum Upgrade Date for Closed 11g Instances section displays the closure date of the last upgraded flow. The upgrade starts with the most recently closed instances and continues until the oldest completed instance is upgraded. An instance flow that closed on January 1, 2014 would be upgraded before a flow that closed on December 1, 2013. A Maximum Upgrade Date of June 1, 2013 indicates that all closed instances up to June 1, 2013 have been upgraded and any instances that were closed before June 1, 2013 are still in the process of being upgrade.

- Upgrade error count
The UPGRADE ERROR COUNT displays the number of errors that have occurred during the upgrade. You can use the upgrade_error_log file to determine the cause of the errors.

For more information on handling upgrade errors, see Section 9.10, "Resolving Instance Upgrade Errors".

- Instance count since start of upgrade
The Overview Since Start of Upgrade shows the start date and time of the upgrade, the total number of instances to be upgraded and the number of instances remaining.

- Current Run Statistics
Upgrade data from the current upgrade run. Each run is numbered. In the sample report below, the data is from the first run (run:1). A designation of (run:2) would indicate that the upgrade was run for the second time and the statistics displayed are for second run.

- START COUNT: Details how many instances are outstanding as of the start of the RUN. For subsequent upgrade RUNs (run2, run3, etc.) the START COUNT total will detail what was remaining at the completion of the previous run.

- REMAINING COUNT: During the upgrade run a sum of "current instances that have not been processed" is collected every 5 minutes during the RUN. The "current instances that have not been processed" are then subtracted from the START COUNT to produce a REMAINING COUNT. REMAINING COUNT= START COUNT - "current instances that have not yet been processed"

- PROCESSED COUNT:
PROCESSED COUNT= START COUNT - REMAINING COUNT

The report data is shown below:

=============================================
Report Upgrade Summary
(Please wait for report to generate)
=============================================
.
. METADATA : COMPLETE
. OPEN FLOWS : COMPLETE
. ALL FLOWS : COMPLETE
.
. ------------------------------------------
. Date of last upgraded and closed 11g Flows
. ------------------------------------------
. DATE : NOT AVAILABLE OR ALL DATA UPGRADED
.
. NOTE: Closed 11g flows prior to this date
. may not be visible on the EM console
. until they are upgraded.
.
. ---------------------
. UPGRADE ERROR COUNT
. ---------------------
. COUNT : 0

PL/SQL procedure successfully completed.

Enter to continue..
.
---------------------------------------------
Upgrade Start Date and Initial Instance Count
---------------------------------------------
. Upgrade Start Date : 06/MAY/2014:04/50
. Initial Instance Count : 1881
. Outstanding Instances Count : 0
.
------------------------------------
CURRENT RUN STATISTICS (run#: 1)
------------------------------------
. Note: 1/ Statistics maybe from previous run
. until new statistics are generated.
. 2/ Statistics can take 10mins to refresh.
.
. STARTED: 06/MAY/2014:04/50
. ENDED: 06/MAY/2014:04/52
. START COUNT: 1881
. PROCESSED COUNT: 1881
. REMAINING COUNT: 0
.
========= End of Report =====================
Upgrade Counter (Oracle Internal Use): < 300

2

Report upgrade database sessions (Running sessions).

Determine which jobs are still running.

Do NOT use this information to manually stop the jobs.

The option will return running sessions data under 'Module', 'Inst', 'Sid' and 'Serial' columns.

For example:

======================================================
Report Upgrade Database Sessions (Running)
======================================================
.
Module                        Inst  Sid   Serial
---                        --  --   ----
SOAUPGRADECONTROLMAIN         1     122   16535
SOAUPGRADEDATA_0              1     228   14557
SOAUPGRADEDATA_1              1     64    46683
SOAUPGRADEDATA_2              1     180   621
SOAUPGRADEDATA_3              1     130   61577
SOAUPGRADESUBMITJOBS          1     172   66

Monitor job completion through the database scheduler job log.

CAUTION: Do not use this information to stop the sessions. Use the administration script as described in Stopping Upgrade Sessions and Jobs.

3

Report upgrade database background jobs (Completed jobs).

Determine which jobs have completed the upgrade.

The database sessions that perform the instance upgrades are executed as database jobs. Once the jobs are complete, the status can be viewed with this option. The user is not expected to understand what each job does, only to ensure that the status shows success without any errors.

The report displays the control job parameter values, the submitted upgrade job, current status of the job (submitted, waiting, running) and the job thread number (if applicable).

For example:

======================================================
Report Upgrade Database Background Jobs (Completed)
======================================================
.
.  State of last 15 completed Jobs in descending order
.
Log_date                 Job_name                   Status      ERROR
----                 ----                   ---      ----
21-FEB-2014 03:07:36  UPGRADE_SOA_METADATA_JOB      SUCCEEDED   0

4

Report background control job parameters.

View the current background control job parameters.

This option will report the parameters that are passed to the control job which coordinates the instance upgrade.

======================================================
Report Backgrond Control Job Parameters
------------------------------------------------------
BATCH_SIZE            : 10000
MAX_COUNT             : 100000
JOB_MAX_RUNTIME       : 240
DOP                   : 4
METADATA_JOB_COMPLETE : TRUE
OPEN_ECIDS_COMPLETE   : FALSE
DATA_JOB_COMPLETE     : FALSE
CTL_MAX_RUNTIME       : 1
FIRST_TIME            : FALSE
FIRST_CTL_MAX_RUNTIME : 0
FIRST_JOB_MAX_RUNTIME : 0
SQL_TRACE             : FALSE
METRICS               : TRUE
ASYNC                 : TRUE
-----------------------
ENABLE                : FALSE
REPEAT INTERVAL       : freq=daily; byhour=3; byminute=0; bysecond=0

5

Change background control job execution schedule.

Change the repeat interval time and duration of the background control job.

By default, the background control job interval will start at 3AM (local time) and run for 4 hours (240 minutes) every day until all of the closed instances have been upgraded (set in terms freq=daily; byhour=3; byminute=0; bysecond=0). If you want this job to run at a different time, use this option to change the repeat interval.

Change Background Control Job Execution Schedule - Repeat Interval
==================================================================
The repeat interval determines when the control procedure is
executed by the database scheduler.
Examples of repeat intervals can be found in the Oracle Database
Administors Guide.
Enter REPEAT INTERVAL:

For more information, see Changing Background Control Job Execution Schedule (Option 5)

NOTE: To change the duration of the run (default is 240 minutes), modify the JOB_MAX_RUNTIME using the Change Background Control Job Parameters (Option 7).

6

Enable/Disable background control job.

Enable or disable the background job.

By default, the Enable/Disable background control job is disabled (ENABLE: FALSE). Enter Y (Yes) to change the current setting. Note that disabling the control job will prevent the background control job from running at the specified repeat interval.

The setting will appear in the Summary Report as ENABLE: TRUE or FALSE.

Enter N (No) to retain the current setting.

ENABLE/DISABLE CONTROL JOB SCHEDULE
===================================
Disabling the Control Schedule will stop the Control job
from executing at the specified Repeat Interval.
Change ENABLE Y/N:

For more information, see Enabling and Disabling Background Control Job (Option 6)

Advanced Options

7

Change background control job parameters.

Change the BATCH_SIZE, MAX_COUNT, JOB_MAX _RUNTIME or DOP (degree of parallel (options 1-4).

Do not change the Advanced Options (options 5-14) unless instructed to do so by Oracle Support to troubleshoot an upgrade.

For most upgrades, the default values for the background control job parameters are sufficient. However, if you need to make changes, review the parameter descriptions in Setting Control Job Parameters (Option 7).

1:  Set BATCH_SIZE
2:  Set MAX_COUNT
3:  Set JOB_MAX_RUNTIME
4:  Set DOP
.
Advanced Options:
.  (Options below for Oracle Internal Use)
.  (Please contact Oracle Support)
.
5:  Set METADATA_JOB_COMPLETE
6:  Set DATA_JOB_COMPLETE
7:  Set OPEN_ECIDS_COMPLETE
8:  Set CTL_MAX_RUNTIME
9:  Set FIRST_TIME
10: Set FIRST_CTL_MAX_RUNTIME
11: Set FIRST_JOB_MAX_RUNTIME
12: Set SQL_TRACE
13: Set METRICS
14: Set ASYNC
.
15: MAIN MENU
.
Enter option :

8

Stop upgrade database background sessions and jobs.

Stop the current background database sessions or jobs.

Use this option to gracefully stop the current background jobs or sessions as described in Stopping Upgrade Sessions and Jobs

Stop Upgrade Database Background Sessions/Jobs
==============================================
All upgrade sessions and jobs should stop but this may require 5 minutes to take affect.

There will be a one minute wait before this procedure returns.
Are you sure Y/N: Y
Enter for MENU

9

Reset errored 11g instances.

Once an upgrade is run, check the upgrade_error_log and correct any reported errors. Then, use this option to resubmit those instances to process again in the next upgrade job.

This option will enable the instances with errors to be processed again in the next upgrade job. Use this option only after you have corrected the errors reported in the upgrade_error_log.

Reset errored 11g instances
=======================
The 11g instances which have encountered an error will have their
flow_id set to -1. This reset updates the flow_id back to null
so they can be processed in the next exection of the background job.
.
The rows in the upgrade_error_log table will have their type column
set to zero. The rows in this table are not removed so that history
is not lost.
.
NOTE: Ensure to schedule and enable the background job.

Are you sure Y/N:

10

Report Current job run log (Oracle Internal Use).

Generate a report for Oracle Support that shows the parameters used in the current run.

The output of this report can be sent to Oracle Support when troubleshooting an upgrade.

You can also use this report to verify that any changes made to the Control Job Parameters are correct.

Example:
======================================================
Report Current RUN log (Oracle Internal Use)
======================================================
.
Module    Type Comment
---    --- -----
CONTROL  PARM batch_size            => 10000
CONTROL  PARM max_count             => 100000
CONTROL  PARM use_ctl_max_runtime   => 0
CONTROL  PARM use_job_max_runtime   => 0
CONTROL  PARM DOP                   => 4
CONTROL  PARM metadata_job_complete => FALSE
CONTROL  PARM data_job_complete     => FALSE
CONTROL  PARM open_ecids_complete   => FALSE
CONTROL  PARM first_time            => TRUE
CONTROL  PARM sql_trace             => FALSE
CONTROL  PARM metrics               => TRUE
CONTROL  PARM async                 => TRUE
CONTROL  PARM ctl_stoptime_d        => NULL
CONTROL  PARM job_stoptime_d        => NULL
CONTROL  INFO UPGRADE jobs submitted ASYNCRONOUS
METADATA INFO UPGRADE submitting: UPGRADE_SOA_METADATA_JOB
CONTROL  INFO CONTROL procedure waiting for (metadata and/or open ecids)
METADATA INFO UPGRADE UPGRADE_SOA_JOB will wait for UPGRADE_SOA_METADATA_J
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB0
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB1
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB2
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB3
DATA     INFO UPGRADE will wait if UPGRADE_SOA_JOB running

11

Exit

Close the Script Administration Menu.

This option will close the menu.

9.5 Configuring the Administration Scripts

This section describes the steps needed to configure the upgrade administration scripts.

- Changing Background Control Job Execution Schedule (Option 5)

- Enabling and Disabling Background Control Job (Option 6)

- Setting Control Job Parameters (Option 7)

9.5.1 Changing Background Control Job Execution Schedule (Option 5)

Use Option 5 to change the execution schedule of the Background Control Job.

In the example below, the start time of the job was changed from 3AM to 4AM (local time).

Change Background Control Job Execution Schedule - Repeat Interval
==================================================================
The repeat interval determines when the control procedure is executed by the database scheduler.

Examples of repeat intervals can be found in the Oracle Database Administors Guide.

Enter REPEAT INTERVAL: freq=daily; byhour=4;

BEFORE Change  :  freq=daily; byhour=3;byminute=0; bysecond=0
AFTER Change   :  freq=daily; byhour=4

9.5.2 Enabling and Disabling Background Control Job (Option 6)

Use the Enable/Disable Background Control Job script (Option 6) to enable the start of a background control job OR to prevent the start of a scheduled control job. T

Note:
The background control job is disabled by default (ENABLE: FALSE). If you manually enable the job (ENABLE: TRUE), then you must also manually disable it.

ENABLE/DISABLE CONTROL JOB SCHEDULE
===================================
Disabling the Control Schedule will stop the Control job
from executing at the specified Repeat Interval.
Change ENABLE Y/N:

9.5.3 Setting Control Job Parameters (Option 7)

The Set Control Job Parameters script (option 7) can be used to configure the parameters described in Table 9-2.

Table 9-2 Background Control Job Parameters

Parameter

Default

Description

BATCH_SIZE

10000

Determines the number of updates (inserts, updates and deletes) that are sent to the database at one time for execution.

MAX_COUNT

100000

Determines the number of instances (ECIDs) that are fetched to upgrade before another MAX_COUNT worth of instances is fetched.

JOB_MAX_RUNTIME

240 minutes (4 hours)

This is the maximum number of minutes that a background control job will run.

DOP

4

The number of parallel execution servers associated with a single operation is known as the degree of parallelism (DOP). Parallel execution is designed to effectively use multiple CPUs.

CAUTION: Changing the degree of parallel is an advanced option. Refer to your database administration documentation for more information on setting the appropriate degree of parallelism for your deployment.

Advanced Options (for Oracle Internal Use only. Contact Oracle Support)

SQL_TRACE

FALSE

NOTE: Setting SQL_TRACE to TRUE can be used to debug and troubleshoot, but it may require the DBA to grant "alter session" to the soainfra user as shown below:

$ sqlplus / as sysdba
SQL> grant alter session to <soainfra>;

To Change the Job Control Parameters:

Task 1   Launch the SOA Upgrade Menu using the steps in Section 9.4.1. Enter 7 in the Enter option field to run the Change Background Control Job Parameters script.

The SOA Upgrade Menu is shown below:

==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

Task 2   Enter the number of the parameter you want to change in the Enter Option field. For example, to change the BATCH_SIZE, enter 1.

A complete list of control job parameters is listed as shown below:

1:  Set BATCH_SIZE
2:  Set MAX_COUNT
3:  Set JOB_MAX_RUNTIME
4:  Set DOP
.
Advanced Options:
.  (Options below for Oracle Internal Use)
.  (Please contact Oracle Support)
.
5:  Set METADATA_JOB_COMPLETE
6:  Set DATA_JOB_COMPLETE
7:  Set OPEN_ECIDS_COMPLETE
8:  Set CTL_MAX_RUNTIME
9:  Set FIRST_TIME
10: Set FIRST_CTL_MAX_RUNTIME
11: Set FIRST_JOB_MAX_RUNTIME
12: Set SQL_TRACE
13: Set METRICS
14: Set ASYNC
.
15: MAIN MENU
.
Enter option :

Task 3   Change the value of the parameter by entering a new value. Click Enter to commit the change. Repeat this process for each parameter you want to change.

You can verify that the change was accepted by looking at the values in the Before Change and After Change fields.

Task 4   Return to the Main Menu by entering 15 in the Enter Option field.

You will return to the main Administration Script menu.

==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

Task 5   Verify that your changes have been made using the Report Background Control Job Parameters script (Option 4).

======================================================
Report Backgrond Control Job Parameters
------------------------------------------------------
BATCH_SIZE            : 10000
MAX_COUNT             : 100000
JOB_MAX_RUNTIME       : 240
DOP                   : 4
METADATA_JOB_COMPLETE : TRUE
OPEN_ECIDS_COMPLETE   : FALSE
DATA_JOB_COMPLETE     : FALSE
CTL_MAX_RUNTIME       : 1
FIRST_TIME            : FALSE
FIRST_CTL_MAX_RUNTIME : 0
FIRST_JOB_MAX_RUNTIME : 0
SQL_TRACE             : FALSE
METRICS               : TRUE
ASYNC                 : TRUE
-----------------------
ENABLE                : FALSE
REPEAT INTERVAL       : freq=daily; byhour=3; byminute=0; bysecond=0

9.5.4 Resetting Errored 11g instances (Option 9)

If the upgrade encountered errors during the run, resolve the issue(s) and then resubmit the errored instances by resetting the error flow_id from (-1) to null. The instances will be processed in the next scheduled background control job run.

For more information, see Section 9.10, "Resolving Instance Upgrade Errors".

Reset errored 11g instances
=======================
The 11g instances which have encountered an error will have their
flow_id set to -1. This reset updates the flow_id back to null
so they can be processed in the next exection of the background job.
.
The rows in the upgrade_error_log table will have their type column
set to zero. The rows in this table are not removed so that history
is not lost.
.
NOTE: Ensure to schedule and enable the background job.
Are you sure Y/N:

9.6 Stopping Upgrade Sessions and Jobs

You can use the administration scripts to stop a running session or job.

Note:
If you stop a running upgrade job before it has completed, you will not be able to query the remaining data or view it using Enterprise Manager Console.
The background jobs upgrade the newest instances first, so you can see how far the upgrade has progressed by looking at the timestamp of the last upgraded instance in the Upgrade Summary Report (Option 1) under the Maximum Upgrade Date for Closed 11g instances section.

There are two ways to stop the upgrade of read-only instances:

- Once the background database control job has started, use the Stop Upgrade Database Background Sessions and Job script (Option 8) to stop ALL of the upgrade sessions and jobs that are currently running. It can take a few minutes before all of the jobs have stopped.

Stop Upgrade Database Background Sessions/Jobs
==============================================
All upgrade sessions and jobs should stop but this may require 5 minutes to take affect.

There will be a one minute wait before this procedure returns.
Are you sure Y/N: Y
Enter for MENU

Use the Report Upgrade Database Sessions (Option 2) to verify that there are no jobs running.You can restart the upgrade job, if needed, by scheduling a job to run at a user-defined time. This is the preferred method.

- Start a middle tier application, such as the SOA Managed Server.
Once a mid-tier application such as a managed server is started, the upgrade of closed instances is stopped automatically. You can use the administration scripts to schedule the upgrade job to run at another time.

9.7 Restarting an Incomplete Upgrade

If the instance upgrade is stopped, it must be manually restarted using the administrations scripts as described below.

1. Enable the background control job using administration script option 6 - 'Enable/Disable background control job'.
See Section 9.5.2, "Enabling and Disabling Background Control Job (Option 6)".

2. Schedule the background control job execution to run at specific time interval using administration script option 5 - 'Change background control job execution schedule'.
See Section 9.5.1, "Changing Background Control Job Execution Schedule (Option 5)".

3. When the time interval specified in Step 2 is reached, the background control jobs starts. Monitor the upgrade status using the administration script option 1 'Report Upgrade Summary'.
See Option 1 in Table 9-1, "Menu Options for Upgrade Administration Scripts".

4. Once the upgrade is completed, log in to Oracle Enterprise Manager Fusion Middleware Control, expand SOA, click soa-infra (soa_server1) and verify that the Data Migration Completed link is displayed under SOA Runtime Health section.
See Section 9.9.1, "Verifying Data Migration is Complete".

9.8 Monitoring Upgrade Status with SQL Queries

This section provides SQL queries that can be used to monitor and validate upgrade in addition to the Administration Scripts.

To determine if...

Use this query

More Information

A flow instance has encountered an error during upgrade (flowId is set to -1 or -2).

Select count (*) from composite_instance where flow_id=-1;

select count(*) from composite_instance where flow_id = -1;

select count(*) from cube_instance where flow_id = -2

select count(*) from dlv_message where flow_id = -2;

select count(*) from mediator_instance where flow_id = -2;

Once Upgrade Assistant completes upgrading Open instances, Oracle recommends that you check for rows in UPGRADE_ERROR_LOG table within SOAINFRA schema. This table stores errored data that was not upgraded to 12c. The column &rsquor;type' determines the type of error encountered. The different type of error that can be reported in the UPGRDAE_ERROR_LOG table:

- 0 : These errors were reported in the previous upgrade run. Type will be set to 0 while 'Resetting Errored 11g instances (Option 9)' of the Upgrade Administrative Script is executed.

- 1: Error occurred during the upgrade of instances.

- 2: Error occurred during upgrade of EDN error event store or Adapter rejected messages.

- 9: Error occurred during the upgrade of Metadata

- 12: Generic error occurred during the data upgrade process.

It is important to ensure that no errored records exist in these tables.

For more information, see Section 9.5.4, "Resetting Errored 11g instances (Option 9)"

All Open instances are upgraded.

select count (*) from cube_instance where state < 5 and flow_id = -1;

select count (*) from dlv_message where  state in (0,1,4) and  flow_id = -1

select count (*) from mediator_instance where component_state between 4 and 15 and flow_id is null;

Run these queries post-upgrade to verify and they should return zero rows if all Open have been migrated.

All instances have been upgraded as expected (post-upgrade)

select count (*) from composite_instance  where flow_id is null;

select count (*) from cube_instance where flow_id = -1;

select count (*) from dlv_message where flow_id = -1;

select count (*) from mediator_instance where flow_id is null;

SELECT count (*) from REJECTED_MESSAGE WHERE FLOW_ID IS NULL;

SELECT count (*) from EDN_EVENT_ERROR_STORE WHERE FLOW_ID IS NULL;

Run these queries post-upgrade and verify that all queries return zero records.
If any records are generated from these queries, then the Upgrade Assistant did not upgrade those instances. Contact Oracle Support for assistance.

9.9 Monitoring Upgrade Status with Fusion Middleware Control

In addition to the administration scripts, you can also use the Oracle Enterprise Manager Fusion Middleware Control Console to view the general status of the upgrade. The administration scripts will provide you with more administrative control of the upgrade jobs, but you can monitor the following with the Fusion Middleware Control Console:

- Verifying Data Migration is Complete

- Managing an Incomplete (Stopped) Upgrade

- Viewing Instances that Faulted During the Upgrade

- Viewing Instances Created Prior to Composite Redeployment

Note:
If you need to perform advanced administration tasks for the upgrade, such as modifying the schedule or interval time of the upgrade, for example, you must use the administration scripts as described in Using the Upgrade Administration Scripts.

9.9.1 Verifying Data Migration is Complete

In the target navigation pane of Oracle Enterprise Manager Fusion Middleware Control, expand SOA, click soa-infra (soa_server1) and verify that the Data Migration Completed link is displayed under SOA Runtime Health section as shown below:

Figure 9-1 SOA Runtime Health: Data Migration Completed

Click Data Migration Complete and verify that the following message is displayed:

Figure 9-2 Migration Completed

Click OK to close the Migration Completed dialog box. You will see the SOA Runtime Health migration status message (Figure 9-3).

Figure 9-3 SOA Runtime Health: Migration Status Message

Click Close this message. The following confirmation dialog appears:

Figure 9-4 Hide Data Confirmation

Click Yes to hide the data migration completed alert. The Close the message button will disappear from the SOA Runtime Health section.

Click No to retain the alert in the SOA Runtime Health section.

9.9.2 Managing an Incomplete (Stopped) Upgrade

You can use Fusion Middleware Control to manage an incomplete upgrade, which can occur in the following situations:

- None of the open or closed instances are upgraded.

- Some of the open instances have upgraded. For example, if you stop the background control job manually using administration script option 8 (Stop upgrade database background sessions and jobs) during the upgrade of open instances.

- Only open instances have been upgraded.

- Some or none of the closed instances have been upgraded.

Note:
If you start the SOA managed servers before the instance upgrade is complete, Fusion Middleware Control will show the upgrade status as Data Migration Not Complete and you will have to manually restart the upgrade as described in Restarting an Incomplete Upgrade.

If the upgrade is not yet complete, Fusion Middleware Control can provide the maximum creation date for all 11g instances that have not yet been upgraded. This is important because the maximum creation date can also help you determine why some instances might not be visible in the 12c Enterprise Manager Console. For example, if you notice that some older 11g closed instances are not be visible in the Fusion Middleware Control console, you can check the maximum creation date for all non-upgraded instances to help you determine if its because the upgrade has not reached those instances yet.

To verify the status of an incomplete (stopped) upgrade using Middleware Control do the following:

In the target navigation pane of Oracle Enterprise Manager Fusion Middleware Control, expand SOA, click soa-infra (soa_server1). In the SOA Runtime Health section of the screen you will see the current status of the upgrade. For an incomplete upgrade, the status will be Data Migration Not Complete. You can refresh this screen every 5 minutes.

Figure 9-5 SOA Runtime Health: Data Migration Not Complete

Click Data Migration Not Complete and the following message is displayed:

Figure 9-6 SOA Runtime Health: Migration Not Complete Status Message

Data Migration Status:

- Active Instances: Shows the status of upgraded open instances. In the example above, the open instances have already been upgraded (status will be Completed).

- Inactive Instances: Shows the status of upgraded closed instances. In the example above, closed instances older than July 9, 2013 have not yet been upgraded. The upgrade is performed newest to oldest. Any instances that have not yet been upgraded will not appear in any Fusion Middleware Control reports or views. You can refresh the report every 5 minutes.

Note:
For a detailed report of the running upgrade, run the Report Upgrade Summary script (Option 1) as described in Section 9.4.2, "Running the Administration Scripts".

Once all the closed instances are upgraded, the link will change to Data Migration Completed as shown in Figure 9-2).

9.9.3 Viewing Instances that Faulted During the Upgrade

The 11g instances that incur a fault and fail during the upgrade can be seen only at the composite level post-upgrade. These instances will not be displayed at the partition level.

To view these instances, navigate to the Flow Instances tab of the deployed composite as shown in Figure 9-7:

Figure 9-7 Using the composite level to view instances that faulted during upgrade

NOTE: Use Search Options to specify a specific instance creation time or date range.

9.9.4 Viewing Instances Created Prior to Composite Redeployment

If a composite is redeployed with the same pre-upgrade revision, then you must navigate to the partition level (instead of composite level) to view these instances as shown in Figure 9-8.

Instances created after the upgrade, however, can be viewed in the 12c composite level.

Figure 9-8 Using the partition level to see instances created prior to upgrade

9.10 Resolving Instance Upgrade Errors

If the upgrade fails or the UPGRADE ERROR COUNT section of the Report Upgrade Summary report (Option 1) shows that there were errors in the current run, you must resolve the errors before resubmitting the instances to upgrade.

The upgrade_error_log can be used to diagnose the error situation and may provide guidance on how to resolve the issue. For more information on resolving common upgrade errors, see Section A.3, "Recovering From a Failed Upgrade".

Note:
The following message is displayed when there is not enough information to correctly identify the state of the fault: Error Message not available-Generated during instance upgrade.
This message indicates that a temporary fault status was assigned to the error during the upgrade. You can ignore these error messages.

The table below describes each of the errors and possible resolutions:

Error Type

Description

Error Message

Resolution

0

These errors were reported in the previous upgrade run.
Type will be set to 0 after resetting the errored instances as described in Section 9.5.4, "Resetting Errored 11g instances (Option 9)").

Error message giving details about error occurred based on previous error type.

Correct the errors from the previous run and reset using Administrative Script.

1

Error occurred during the upgrade of instances.

The error message will have actual error thrown from the Upgrade script. It will also show a stack trace which will point out the line in the Upgrade PL/SQL script where the error has occurred.

Debugging the root cause can be done by looking at the actual error along with the trace to get the location of the error.
ECID populated in the info column will be helpful in getting the data for failed instance.

2

Error occurred during upgrade of EDN error event store or Adapter rejected messages.

The error message will contain the string upgrade_rejected_message/upgrade_edn_message to determine which component it failed
It will contain the reason for failure along with the id of the message which failed.

Debugging can be done by analyzing the actual reason of the error. To get the details of the adapter/edn message which has failed the id logged as part of ERROR_MSG can be used.

9

Error occurred during the upgrade of metadata.

It will have details of the composite_dn for which the metadata upgrade has failed
It will have the actual error thrown from Upgrade script also with a stack trace which will point out the line in the Upgrade PL/SQL script where the error has occurred.

Debugging can be done by looking at the actual error along with the trace to get the location of the error. Info column will give the whole composite_dn for which the metadata upgrade has failed.

12

Generic error occurred during the data upgrade process and not pertaining to any single instance.

Info will only contain the string migrate_soa
It will have the actual error thrown from Upgrade script also with a stack trace which will point out the line in the Upgrade PL/SQL script where the error has occurred.

This error type will be reported during upgrade run when the data upgrade as a whole fails and not necessarily pertaining to any particular instance.
An example of this type of error may be the TEMP table space issue.

Once the errors have been resolved, use the following steps to restart the upgrade:

1. Fix the error condition(s) displayed in the upgrade_error_log.

2. Remove the error flags from the upgrade_error_log as described in Resetting Errored 11g instances (Option 9). This will allow the errored instances to be resubmitted in a subsequent run.

3. Enable the background control job as described in Enabling and Disabling Background Control Job (Option 6). You will have to trigger another upgrade run.

4. If necessary, change the repeat interval time and duration of the background control job as described in Changing Background Control Job Execution Schedule (Option 5).

5. Monitor the upgrade status using the Report Summary Upgrade script (Option 1). The UPGRADE ERROR COUNT section of the report should show 0 errors. If errors persist, resolve the issue and repeat these steps.

A Troubleshooting the Upgrade

This appendix describes some common procedures for troubleshooting a failed upgrade, domain reconfiguration or server start issues.

- Section A.1, "Reviewing the Release Notes"

- Section A.2, "Resolving Server Start Errors"

- Section A.3, "Recovering From a Failed Upgrade"

- Section A.4, "Recovering from a Failed BAM Upgrade"

- Section A.5, "Rewiring Components After OWSM Cluster Upgrade"

- Section A.6, "Encryption Issues During Upgrade"

- Section A.7, "Troubleshooting Oracle Service Bus"

- Section A.8, "Upgrading Unsupported Domains with the Upgrade Assistant"

- Section A.9, "Business Rules Audit Trail Not Showing After Instance Upgrade"

- Section A.10, "Resolving a Coherence Cache Exception"

- Section A.11, "WSDL Generated Missing Elements for Custom Exception"

- Section A.12, "Connecting to the ServerSocket through Remote Clients"

A.1 Reviewing the Release Notes

Make sure that you review the release notes to determine if any known issues could be impacting your upgrade. You can find the release notes in the Oracle Fusion Middleware 12c (12.1.3) library.

A.2 Resolving Server Start Errors

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 12c domain. Compare the setDomainEnv file from 11g to the new 12c setDomainEnv file and then add any custom changes after the upgrade.

For more information, see "Re-apply Customizations to Startup Scripts".

A.3 Recovering From a Failed Upgrade

Recovering from a failed upgrade depends on when the error(s) occurred. Review the following to determine how to recover:

- If there are errors while running the Upgrade Assistant to upgrade _SOAINFRA schema, you must fix the errors in the schema and rerun batch jobs.
Note that this recovery method only applies when you are running the Upgrade Assistant for the first time and you selected the Schema option.

- If there are errors while running the Reconfiguration Wizard, you must restore from source environment and restart the upgrade from the beginning.

- If there are errors while running the Upgrade Assistant to upgrade WebLogic Component Configurations option, then you can fix the errors and rerun the Upgrade Assistant. The second time you run the Upgrade Assistant there is no need to restore from backup and restart the upgrade process from the beginning. This process is reentrant.

- If there are errors while running the Upgrade Assistant to upgrade schemas, and the error occurs during the upgrade phase, you will have to restore from backup, correct the issues, and then restart the upgrade from the beginning. If the error occurs during the examine phase, however, you can correct the issues and restart the Upgrade Assistant. Errors that occur prior to the upgrade phase are reentrant.

For more information on troubleshooting your upgrade, see "General Troubleshooting Guidelines" in the Upgrading with the Upgrade Assistant.

BAM Upgrades Only:
If you received the CFGFWK-60950 error, rename the BAM templates as described in "Rename the Oracle BAM templates before upgrading the 11g schemas." and launch the Reconfiguration Wizard again.
If you received this error, you will need restore your entire pre-upgrade environment, perform the necessary pre-upgrade tasks and then perform the steps in the section listed above before you can attempt the reconfiguration process again.

A.4 Recovering from a Failed BAM Upgrade

This section applies only when there are BAM servers in the domain. As part of BAM Upgrade, you can export BAM archives from 11g and import them into BAM 12c. If you receive any errors during this process, use this section to try to resolve the issues.

A.4.1 Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration

You may be able to resolve common errors by rolling back the data changes and rerunning the scripts with modified options.

Rollback All Data Changes:

1. Open a SQL session on the SOA database.

2. Log in as the SOAINFRA schema user and run the following script to roll back any data changes:

"<exportDir>/rollBackBPMProcessCubesMigration.sql"

Review the recommendations for your operating system:

- Error Handling for UNIX Operating Systems

- Error Handling for Windows Operating Systems

A.4.2 Error Handling for UNIX Operating Systems

If any unexpected errors occurred during migration, you can try the following steps to correct the issues:

For Errors that Occurred During the Import Phase:

If the error occurred while importing archives to BAM 12c, rerun the shell script "migrateBPMProcessCubes.sh" as described in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only), but add the "-importOnly" option. This can save time by skipping the export step.

For example:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]

For Errors that Occurred During the Export Phase:

If the error occurred while exporting archives from BPM Process cubes, perform the following tasks:

1. Create a backup copy of the export directory defined as (<exportDir>)

2. Delete the contents of the <exportDir>.

3. Rerun the shell script "migrateBPMProcessCubes.sh" as described in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only), but remove the "-importOnly" option.
For example:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL]

Additional Information:

You can also try the following to help resolve any issues:

- After importing each archive to BAM 12c, review the bamcommond.log.* files located in the $ORACLE_HOME/bam/bin directory to make sure no errors occurred.

- Review the migration logs located in the <exportDir>/MigrationLogs.* :

A.4.3 Error Handling for Windows Operating Systems

Roll back all of the data changes as described above, and then try the following:

For Errors that Occurred During the Import Phase:

Reimport the archives as described in the following sections:

- (Windows Only) Import dimension data (DimensionExport.zip) into the BAM server. (Note that this command uses -datamode and -migrate parameters.)

- (Windows Only) Import active fact data (ActiveFactDataExport.zip) into the BAM server. (Note that this command uses -datamode and -migrate parameters.)

- (Windows Only - if exportType=ALL) Import completed fact data (CompletedFactDataExport.zip) into the BAM server. (Note that this command uses -datamode and -migrate parameters.)

For Errors that Occurred During the Export Phase:

If the error occurred while exporting archives from BPM Process cubes, perform the following tasks:

1. Create a backup copy of the export directory defined as (<exportDir>)

2. Delete the contents of the <exportDir>.

3. Rerun the shell script "migrateBPMProcessCubes.sh" as described in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only), but remove the "-importOnly" option.
For example:

java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar

oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]

4. Repeat the remaining migration steps in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).

A.5 Rewiring Components After OWSM Cluster Upgrade

If you modified the wsm-pm targeting for OWSM, and the wsm-pm is now targeted only to the OWSM cluster post-upgrade, then you must rewire the components as described in "Using Cross-Component Wiring for Auto-Discovery of Policy Manager" in Oracle WebLogic ServerSecuring Web Services and Managing Policies with Oracle Web Services Manager.

A.6 Encryption Issues During Upgrade

If you received the following error message during the reconfiguration, you may need to apply additional policy files to the JDK and restart the upgrade from your backup:

JPS-06513: Failed to save keystore. Reason oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to perform cryptographic operation

To prevent this error from reoccurring, apply the policy files before the subsequent upgrade using the information in Section 2.1.6, "Using Enhanced Encryption (AES 256)".

A.7 Troubleshooting Oracle Service Bus

If you experience post-upgrade issues with Oracle Service Bus, review the following and apply any relevant solutions.

- Section A.7.1, "HTTP 404 Error After OSB Upgrade with OHS as Cluster Frontend Host"

- Section A.7.2, "HTTP 404 Error When Accessing OSB Console"

A.7.1 HTTP 404 Error After OSB Upgrade with OHS as Cluster Frontend Host

If you configure Oracle HTTP Server (OHS) as a cluster domain frontend host, then you must add the following code to the OHS configuration file (ohs.confg):

<Location /sbconsole>
SetHandler weblogic-handler
WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>
<Location /servicebus>
SetHandler weblogic-handler
WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>

Where ADMIN.SERVER:PORT is the machine name, server name and port number used for the OHS.

mymachine.us.mycompany.com:7001 as shown in this sample code example:

<Location /sbconsole>
SetHandler weblogic-handler
WebLogicCluster mymachine.us.mycompany.com:7001
</Location>
<Location /servicebus>
SetHandler weblogic-handler
WebLogicCluster mymachine.us.mycompany.com:7001
</Location>

A.7.2 HTTP 404 Error When Accessing OSB Console

Prior to 12c, the OSB console was accessed using the following URL: http://[HOST]:[PORT]/sbconsole

In 12c, the OSB Console URL has changed to: http://[HOST]:[PORT]/servicebus.

After the upgrade, if you enter http://[HOST]:[PORT]/sbconsole, it should redirect to http://[HOST]:[PORT]/servicebus.

If the redirect fails, and you receive a HTTP 404 error, try direclty entering the 12c URL: http://[HOST]:[PORT]/servicebus.

A.8 Upgrading Unsupported Domains with the Upgrade Assistant

If you receive an error from the Upgrade Assistant stating that the specified domain cannot be upgraded, contact Oracle Support for more information. Supported domain configurations are described in Understanding Domain Upgrade Restrictions.

Do not attempt to upgrade or schemas or domain configurations in an unsupported domain.

A.9 Business Rules Audit Trail Not Showing After Instance Upgrade

The audit trail for upgraded 11g instances of the Decision Service Component will not be available post-upgrade. The audit trail for new 12c instances will continue to display.

A.10 Resolving a Coherence Cache Exception

If you see the following WebLogic Cache Provider Coherence exception then it is likely that you are not following an enterprise deployment topology recommendation to specify a specific ListenAddress.

When you see this exception, you must set the ListenAddress for your managed server as shown below:

Exception:

weblogic.cacheprovider.coherence.CoherenceException:
at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510)
at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236)
at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225)
at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)

Resolution:

1. Log in to the WebLogic Server Console.

2. Navigate to Servers.

3. Locate the Managed Servers (SOA or OSB, for example).

4. Modify the Listen Address from localhost to 127.0.0.1 or provide the actual machine name.

A.11 WSDL Generated Missing Elements for Custom Exception

If your EJBs contain custom exceptions, and you export the Web Service Description Language (WSDL) file from your EJB business service, the generated WSDL file will not have the custom exception properties in it. You will need to manually edit the WSDL file to include these custom exception properties after the upgrade.

The issue is limited only to the WSDL generation part of the file. During runtime, the custom exception thrown from the EJB will be mapped to the respective elements in the SOAP fault. The response payload will have the elements populated corresponding to the properties of the custom exception.

A.12 Connecting to the ServerSocket through 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 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" Understanding Technology Adapters.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Pre-General Availability Draft Documentation Notice

If this document is in public or private pre-General Availability status:

This documentation is in pre-General Availability status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Pre-General Availability Draft Documentation Notice

If this document is in private pre-General Availability status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your pre-General Availability trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.