Oracle® Fusion Middleware

Administering Oracle SOA Suite and Oracle Business Process Management Suite

12c (12.2.1.2.0)

E68159-05

June 2017

Documentation for system administrators that describes how to administer Oracle Service-Oriented Architecture (SOA) composite applications consisting of binding components and Oracle BPEL process, human task, business rule, Oracle Mediator, and Oracle Business Process Management Notation (BPMN) service components in Oracle Enterprise Manager Fusion Middleware Control. Includes additional information on administering Oracle B2B, Oracle Healthcare, Oracle JCA Adapters, and business events.

Oracle Fusion Middleware Administering Oracle SOA Suite and Oracle Business Process Management Suite, 12c (12.2.1.2.0)

E68159-05

Copyright © 2006, 2017, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Oracle Corporation

Contributor:  Oracle SOA Suite and development, product management, and quality assurance teams

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

- Related Documents

- Conventions

What's New in This Guide

- New and Changed Features for 12c (12.2.1.x)

Part I Introduction to Oracle SOA Suite and Oracle Business Process Management Suite

1 Introduction and Concepts

- 1.1 What Is Oracle Fusion Middleware?

- 1.2 What Is Oracle SOA Suite?

- 1.2.1 Introduction to the SOA Infrastructure Application

- 1.2.2 Introduction to SOA Folders

- 1.2.3 Introduction to SOA Composite Applications

- 1.2.4 Introduction to Business Flow Instances

- 1.2.5 Introduction to Service Components

- 1.2.5.1 Spring Service Component Support

- 1.2.6 Introduction to Binding Components

- 1.2.7 Introduction to Service Engines

- 1.2.8 Introduction to the Service Infrastructure

- 1.2.9 Introduction to the Contents of SOA Composite Applications

- 1.2.10 Introduction to Oracle SOA Suite and Oracle Enterprise Scheduler Integration

- 1.2.10.1 Cross-Component Wiring Between Oracle SOA Suite and Oracle Enterprise Scheduler

- 1.3 What Is Oracle Business Process Management Suite?

- 1.4 Administration of Oracle SOA Suite and Oracle BPM Suite

- 1.4.1 Configuration of Oracle SOA Suite and Oracle BPM Suite

- 1.4.1.1 Introduction to the Order of Precedence for Audit Level Settings

- 1.4.2 Monitoring of Oracle SOA Suite and Oracle BPM Suite

- 1.4.3 Management of Oracle SOA Suite and Oracle BPM Suite

- 1.4.3.1 Introduction to Fault Recovery in the Error Hospital

- 1.4.3.2 Introduction to Policies

- 1.4.3.2.1 Introduction to How Policies are Executed

- 1.4.3.3 Introduction to the Lifecycle State of SOA Composite Applications

- 1.4.3.4 Introduction to SOA Composite Application Automated Testing

- 1.4.4 Performance and Tuning of Oracle SOA Suite and Oracle BPM Suite

- 1.5 Administration for Application Developers

- 1.6 Administration with Oracle Enterprise Manager 12c Cloud Control and the Oracle SOA Management Pack

Part II Getting Started with Administration

2 Getting Started with Administering Oracle SOA Suite and Oracle BPM Suite

- 2.1 Logging In to Oracle Enterprise Manager Fusion Middleware Control

- 2.2 Navigating to Oracle SOA Suite and Oracle BPM Suite Administration Tasks

- 2.2.1 Navigating Through the SOA Infrastructure Home Page and Menu

- 2.2.2 Navigating Through the SOA Composite Application Home Page and Menu

- 2.2.3 Navigating Through the SOA Folder Home Page and Menu

- 2.2.4 Navigating to Deployed Java EE Applications

- 2.2.5 Navigating to the Oracle WebLogic Server Administration Console and Other Pages

- 2.2.6 Navigating to the SOA Infrastructure or SOA Composite Application Home Page from the WebLogic Domain Home Page

- 2.3 Accessing Context Sensitive Online Help

- 2.4 Navigating to the System MBean Browser

- 2.4.1 Accessing the System MBean Browser from the Main Page

- 2.4.2 Accessing the System MBean Browser from the Component Property Pages

- 2.5 Logging Out of Oracle Enterprise Manager Fusion Middleware Control

- 2.6 Setting Accessibility Options

Part III Administering the SOA Infrastructure

3 Configuring the SOA Infrastructure

- 3.1 Configuring SOA Infrastructure Properties

- 3.1.1 To configure SOA Infrastructure properties:

- 3.1.2 Configuring Oracle SOA Suite and Oracle BPM Suite Profiles

- 3.1.3 Configuring the Audit Trail, Payload Validation, and Default Query Duration

- 3.1.4 Configuring UDDI Registry Properties

- 3.1.5 Configuring Callback Server and Server URLs

- 3.1.6 Configuring Analytics and Sensors

- 3.1.7 Configuring Data Sources and Web Service Binding Properties

- 3.1.8 Configuring SOA Infrastructure Advanced Configuration Properties

- 3.2 Stopping and Starting the Managed Server and SOA Infrastructure

- 3.2.1 SOA Composite Application States and SOA Infrastructure Shutdown

- 3.2.2 Restarting the SOA Infrastructure Does Not Activate Endpoints When a Retired Composite is Activated

- 3.2.3 SOA Infrastructure Startup Failure When cwallet.sso Includes the SOA Map

- 3.3 Changing the SOA Infrastructure Server URL Property Port in the System MBean Browser

- 3.4 Configuring Log Files

- 3.4.1 Configuring the Logging File Encoding Property

- 3.4.2 Configuring Logging to Diagnose Performance Issues in Oracle Enterprise Manager Fusion Middleware Control Pages

- 3.5 Changing the Driver Name to Support Custom XA Drivers

- 3.6 Specifying a Nondefault XA Transaction Timeout Value for XA Data Sources

- 3.7 Configuring Database-bound Processing Threads

- 3.7.1 To change the maximum capacity for the SOADataSource property:

- 3.7.2 To configure the SOAMaxThreadsConfig property:

- 3.8 Configuring Local Optimization

- 3.8.1 Condition Checks for Using Local Optimization

- 3.8.2 Overriding or Forcing Local Optimization

- 3.8.3 Local Optimization Logging

- 3.8.4 Local Optimization Calls Use Case

- 3.9 Managing Global Token Variables for Multiple SOA Composite Applications

- 3.9.1 Managing Global Token Variables in the Token Configurations Page

- 3.9.2 How Global Token Variables are Substituted at Runtime

- 3.9.3 Using Predefined Global Token Variables

- 3.10 Preventing Faults from Building Up in SOA

- 3.10.1 Configuring Resiliency at the Global Level

- 3.10.2 Overriding Global Resiliency Settings for a Downstream Endpoint

- 3.10.3 Global Resiliency Properties and Endpoint Resiliency Properties

4 Monitoring the SOA Infrastructure

- 4.1 Monitoring the Overall Status of the SOA Infrastructure or Individual Partition

- 4.1.1 Viewing Key Configuration Settings

- 4.1.2 Viewing the Overall Runtime Health of the SOA Infrastructure

- 4.1.3 Viewing System Backlogs in the SOA Infrastructure

- 4.1.4 Viewing Business Transaction Faults

- 4.1.5 Viewing SOA Composite Applications and Adapters Availability

- 4.1.6 Searching for Instances and Bulk Recovery Jobs

- 4.1.7 Viewing Error Notification Alerts

- 4.2 Discovering the Oracle SOA Suite Routing Topology

- 4.3 Monitoring SOA Infrastructure Performance Summary Metrics

- 4.4 Monitoring Message Delivery Processing Requests

- 4.5 Monitoring Service and Reference Binding Components in the SOA Infrastructure

- 4.6 Using SOA Health Check

- 4.6.1 SOA Health Checks

- 4.6.2 SOA Health Check Categories

- 4.6.3 Invoking SOA Health Checks

- 4.7 Monitoring and Troubleshooting SOA-Wide Issues Using IWS Reports

- 4.7.1 Enabling and Configuring IWS

- 4.7.2 Generating an IWS Report

- 4.7.2.1 About the IWSReport MBean

- 4.7.2.2 WLST Commands to Generate IWS Reports

- 4.7.3 Statistics Included in an IWS Report

5 Tracking Business Flow Instances

- 5.1 Tracking Business Flow Instances at the SOA Infrastructure or Partition Level

- 5.1.1 Specifying and Saving Business Flow Search Criteria

- 5.1.1.1 Executing Predefined Business Flow Instance Searches

- 5.1.1.2 Using the Search Options Toolbar

- 5.1.1.3 Adding and Removing Search Filters

- 5.1.1.4 Configuring and Saving Business Flow Instance Search Filter Criteria

- 5.1.2 Deleting or Terminating Business Flow Instances

- 5.1.3 Viewing the Current State of the Business Flow Instance

- 5.1.4 Recovering from Faults in a Business Flow Instance

- 5.1.5 Viewing Composite Sensor Values in a Business Flow Instance

- 5.1.6 Viewing the Initiating and Participating SOA Composite Applications in a Business Flow Instance

- 5.1.7 Viewing Resequencing Groups in a Business Flow Instance

- 5.1.8 Viewing Business Flows that Extend Across Domains

- 5.1.9 Partition-Level and Composite-Level Search Results for Redeployed Composites with the Same Revision Number

6 Recovering From Faults in the Error Hospital

- 6.1 Managing Faults in the Error Hospital

- 6.1.1 Specifying and Saving Fault Search Criteria

- 6.1.1.1 Executing Predefined Fault Instance and Custom Searches

- 6.1.1.2 Using the Report Filters Toolbar

- 6.1.1.3 Configuring and Saving Fault Search Filter Criteria

- 6.1.2 Viewing Aggregated Fault Statistics to Examine Fault Trends

- 6.1.2.1 To View Aggregated Fault Statistics to Examine Fault Trends:

- 6.1.3 Performing Bulk Fault Recoveries and Terminations in a Single Operation

- 6.1.4 Accessing Faults in the Fault Statistics Table to Perform Single Fault Recovery Operations

- 6.1.5 Understanding Additional Message and Fault Recovery Behavior Scenarios

- 6.1.5.1 Recoverable Messages are Displayed as Unrecoverable in the Error Hospital

- 6.1.5.2 Unrecoverable Binding Component Faults are Displayed as Recoverable

- 6.1.5.3 BPEL Process Messages Awaiting Recovery with no Associated Instance Faults Do Not Appear on the Error Hospital Page

- 6.2 Creating Error Notification Rules

- 6.2.1 To create error notification rules:

- 6.2.2 Error Notification Rules Associated with an Expired Schedule

7 Managing SOA Folders and Work Manager Groups

- 7.1 Managing SOA Folders

- 7.1.1 Creating SOA Folders

- 7.1.2 Deleting Folders

- 7.1.3 Changing the Work Manager Group of a SOA Folder

- 7.1.4 Performing Bulk Lifecycle Management Tasks on Composites in SOA Folders

- 7.2 Managing Work Manager Groups

- 7.2.1 Viewing and Configuring Work Manager Properties

- 7.2.1.1 Viewing and Configuring Work Manager Constraints

- 7.2.2 Viewing Work Manager Pending and Completed Requests

- 7.2.3 Viewing and Creating Work Manager Groups

- 7.3 Securing Access to SOA Folders

- 7.3.1 Viewing SOA Folder Roles

- 7.3.2 Viewing the Permissions Assigned to Each SOA Folder Role

- 7.3.3 Assigning Users to SOA Folder Roles

- 7.3.4 Understanding Additional Permission and Role Behavior Scenarios

- 7.3.4.1 Understanding Permissions on Initiating and Participating Composites in Different SOA Folders

- 7.3.4.2 Viewing Oracle SOA Composer Permission Actions in a SOA Folder

- 7.3.4.3 Understanding the MDS Configuration Page and Oracle SOA Suite Permissions

Part IV Administering SOA Composite Applications and Instances

8 Securing SOA Composite Applications

- 8.1 Introduction to Securing SOA Composite Applications

- 8.2 Configuring Oracle HTTP Server with Oracle BPM Worklist

- 8.3 Setting up SAML Message-Protected Policy Configuration for the SOA Infrastructure

- 8.4 Automatically Authenticating Oracle BPM Worklist and Oracle Business Process Management Users

- 8.4.1 Automatically Authenticating Oracle BPM Worklist Users in SAML SSO Environments

- 8.4.2 Automatically Authenticating Oracle BPM Workspace Users in SAML SSO Environments

- 8.4.3 Automatically Authenticating Oracle Business Process Composer Users in SAML SSO Environments

- 8.4.4 Automatically Authenticating Oracle BPM Worklist Users in Windows Native Authentication Environments

- 8.4.5 Automatically Authenticating Oracle Business Process Composer Users in Windows Native Authentication Environments

- 8.5 Setting the Authentication Provider

- 8.5.1 Listing Oracle Internet Directory as the First Authentication Provider

- 8.5.2 Accessing Web-based Applications with the Default Authentication Provider

- 8.5.3 Enabling Multiple Authentication Providers

- 8.6 Configuring SSL

- 8.6.1 Using SSL Certificates When the SOA/BPM Server Is Configured with an HTTPS Port

- 8.6.2 Recommendation to Configure Either All or No Managed Servers with SSL

- 8.6.3 Switching from Non-SSL to SSL Configurations with Oracle BPM Worklist

- 8.6.4 Configuring SOA Composite Applications for Two-Way SSL Communication

- 8.6.4.1 To enable two-way SSL for a SOA composite application to invoke another application:

- 8.6.5 Invoking References in One-Way SSL Environments in Oracle JDeveloper

- 8.6.6 Configuring Oracle SOA Suite and Oracle HTTP Server for SSL Communication

- 8.6.6.1 Configuring Oracle HTTP Server for SSL Communication

- 8.6.6.2 Configuring Certificates for Oracle Client, Oracle HTTP Server, and Oracle WebLogic Server

- 8.6.7 Configuring SSL Between Business Flow Instances and Oracle WebCache

- 8.6.8 Using a Custom Trust Store for One-Way SSL During Design Time

- 8.6.9 Configuring an Asynchronous Process Deployed to an SSL-Enabled Managed Server to Invoke Another Asynchronous Process Over HTTP

- 8.7 Configuring Security for Human Workflow WSDL Files

9 Monitoring SOA Composite Applications

- 9.1 Monitoring SOA Composite Application Performance Summary Metrics

- 9.2 Viewing the SOA Composite Application Diagram

- 9.3 Monitoring the Service Components and Binding Components of a SOA Composite Application

10 Deploying and Managing SOA Composite Applications

- 10.1 Deploying SOA Composite Applications

- 10.1.1 To Deploy SOA Composite Applications:

- 10.1.2 Understanding Additional Deployment Behavior Scenarios

- 10.1.2.1 PermGen Memory Requirements for Multiple ADF Task Form Deployments

- 10.1.2.2 Deploying SOA Composite Applications with Task Flows

- 10.1.2.3 Deploying SOA Composite Applications with ant Scripts and the WLST Command Line Tool

- 10.2 Updating Instance, Fault, and Rejected Message States to Aborted During Undeployment or Redeployment

- 10.3 Redeploying SOA Composite Applications

- 10.3.1 Redeploying SOA Composite Applications with the Same Revision ID Without Changing the Initial Running Instance to Aborted

- 10.3.1.1 Examples of Redeployment Behavior for Synchronous and Asynchronous BPEL Processes

- 10.4 Undeploying SOA Composite Applications

- 10.5 Managing the State of Deployed SOA Composite Applications

- 10.5.1 Managing the State of All Applications at the SOA Infrastructure Level

- 10.5.2 Managing the State of an Application from the SOA Composite Application Home Page

- 10.5.3 Understanding Additional Lifecycle State Behavior Scenarios

- 10.5.3.1 Starting and Stopping a Managed Oracle WebLogic Server on Which the SOA Infrastructure is Deployed in the Middle of BPEL Processing

- 10.5.3.2 Setting the Business Flow Instance Name

- 10.6 Automating the Testing of SOA Composite Applications

- 10.6.1 Increasing Response Message Size When Executing Test Suites in Bulk

- 10.7 Managing SOA Composite Application Policies

- 10.7.1 Policy Subject of a Local Policy Can Become Invalid After a Server Restart

- 10.7.2 Policy Attachments and Local Optimization in Composite-to-Composite Invocations

- 10.7.3 WS-RM Sessions

- 10.8 Exporting a Deployed SOA Composite Application

- 10.9 Disabling and Enabling the Collection of Analytic, BPEL Sensor, and Composite Sensor Data

- 10.9.1 Disabling Analytics and Sensors for a Specific SOA Composite Application

- 10.9.2 Disabling Analytics and Sensors for All SOA Composite Applications

- 10.9.3 Selectively Disabling Specific Analytic and Sensor Settings for All SOA Composite Applications

- 10.10 Linking to Runtime Applications

11 Managing SOA Composite Application Business Flow Instances

- 11.1 Initiating a Test Instance of a Business Flow

- 11.1.1 Specifying RPC/Literal-Style WSDL Files on the Test Web Service Page

- 11.2 Tracking Business Flow Instances at the SOA Composite Application Level

12 Developing a Database Growth Management Strategy

- 12.1 Introduction to Planning for Database Growth

- 12.2 Identifying the Profile or Size of the Database

- 12.2.1 Identifying the Inflow of Data

- 12.2.1.1 Identifying the Number of Instances Produced Daily

- 12.2.1.2 Identifying the Disk Space Used by Each Instance

- 12.2.1.3 Identifying the Composite Space Persisted Daily

- 12.2.1.4 Analyzing Space Distribution of Oracle SOA Suite Segments

- 12.2.2 Developing a Retention Policy

- 12.2.2.1 Determining the Minimum Retained Disk Space

- 12.2.2.2 Determining the Minimum Number of Retained Composites

- 12.2.3 Identifying the Outflow of Data

- 12.2.4 Identifying Long Running Composites and Table Partitioning

- 12.2.4.1 Recommendations for Each Table to Partition

- 12.3 Monitoring Space Usage, Hardware Resources, and Database Performance

- 12.3.1 Monitoring Space Usage

- 12.3.1.1 Determining the Growth Trend of Components

- 12.3.1.2 Determining the Growth Trend of the Oracle SOA Suite Schema

- 12.3.1.3 Determining the Largest Segments

- 12.3.1.4 Determining the Growth Trend of Tables and Indexes

- 12.3.1.5 Estimating Table Size

- 12.3.1.6 Estimating Index Size

- 12.3.1.7 Monitoring Unused Indexes

- 12.3.2 Monitoring the Hardware Resources and Database

- 12.3.2.1 Hardware - OSWatcher Black Box

- 12.3.2.2 Database – AWR / ADDM

- 12.3.2.3 Disk I/O - Oracle Orion

- 12.4 Understanding Growth Management Challenges and Testing Strategies

- 12.4.1 Database Growth Management Challenges

- 12.4.1.1 Excessive Growth of Oracle SOA Suite Tables Due to an Ineffective Growth Management Strategy

- 12.4.1.2 Tuned Parallel Purge Script Cannot Handle the Inflow

- 12.4.1.3 Table Partitions Cannot Be Dropped Due to Long Running Composites

- 12.4.2 Quality Assurance Testing

- 12.4.2.1 Reviewing Metalink Support Note 1384379.1

- 12.4.2.2 Configuring the Production Audit Level Setting

- 12.4.2.3 Creating an Oracle SOA Suite Schema - Test Environment

- 12.4.2.3.1 Measure Inflow and Space Estimations

- 12.4.2.3.2 Base Point Backup of Test Environment

- 12.4.2.4 Executing the Parallel or Single Threaded Script and Reclaiming Space

- 12.4.2.5 Reviewing the Testing Results

- 12.4.2.6 Partitioning the Tables Causing a Bottleneck

- 12.4.2.6.1 Base Point Backup with Partitioned Table

- 12.4.2.7 Repeating Purge Testing and Review and Excluding the Partitioned Table

- 12.4.3 Recommended Growth Management Strategies

- 12.4.3.1 Recommendations for Large Database Profiles

- 12.4.3.2 Recommendations for Small Database Profiles

- 12.5 Understanding Space Management

- 12.5.1 Introduction to the Components of a Data File

- 12.5.1.1 Segment High Water Mark

- 12.5.2 Reclaiming Segment and Data File Space

- 12.5.2.1 Performing an Online Segment Shrink

- 12.5.2.2 Deallocating Unused Space

- 12.5.2.3 Coalescing or Rebuilding indexes

- 12.5.2.4 Dropping Table Partitions

- 12.5.2.4.1 Dropping a Partition

- 12.5.2.5 Configuring Secure File LOBs

- 12.5.2.5.1 Secure File Requirements

- 12.5.2.5.2 Converting Secure Files

- 12.5.2.5.3 Migrating Secure Files

- 12.5.2.6 Additional Database Management Methods

- 12.5.2.6.1 TRUNCATE Statement

- 12.5.3 Resizing Data Files

13 Managing Database Growth

- 13.1 Introduction to Managing Database Growth

- 13.2 Developing a Purging and Partitioning Methodology

- 13.3 Deleting Large Numbers of Flow Instances, Adapter Reports, and Fault Alerts

- 13.3.1 Purge States

- 13.3.2 Deleting Large Numbers of Instances with Oracle Enterprise Manager Fusion Middleware Control

- 13.3.3 Deleting Large Numbers of Instances with SQL*Plus

- 13.3.3.1 Looped Purge Script

- 13.3.3.1.1 delete_instances Procedure

- 13.3.3.2 Looped Purge in Parallel Script with dbms_scheduler

- 13.3.3.2.1 delete_instances Procedure in Parallel

- 13.3.3.3 Running the Purge Scripts

- 13.3.3.4 Resolving Dead Locks After Running the Looped Purge in Parallel Script

- 13.3.3.5 Purging the Instances of a Specific SOA Composite Application

- 13.3.3.6 Resequenced Message Purge States for Oracle Mediator

- 13.3.4 Monitoring the Status of Purging

- 13.3.5 Generating a Database SQL Trace

- 13.4 Partitioning Component Tables

- 13.4.1 Partitioning the Database with the Repository Creation Utility

- 13.4.2 Partitioning the Component Database Tables

- 13.4.2.1 Referential Integrity and Equipartioning

- 13.4.3 Range Interval Partitioning

- 13.4.4 Equipartitioning and Range Interval Partitioning

- 13.4.5 Range Interval Partitioning Example

- 13.4.6 Introduction to Partition Key Selection

- 13.4.7 Configuring Partitions

- 13.4.8 Introduction to the Verification Script

- 13.4.8.1 Component Tables

- 13.4.8.1.1 Partitioning Constraints

- 13.4.8.1.2 Component Tables, Range Partition Keys, and Groups

- 13.4.8.2 Equipartitioning and Interval Partitioning Verification Script Checks

- 13.4.9 Running the Verification Script

- 13.4.10 Moving Active, Long Running Instances to a Different Partition

- 13.4.11 Routines to Assist with Partition Maintenance

- 13.4.12 Partial Partitioning of Components

- 13.5 Removing Records from the Runtime Tables Without Dropping the Tables

14 Diagnosing Problems with SOA Composite Applications

- 14.1 Introduction to the Diagnostic Frameworks

- 14.1.1 Introduction to WLDF

- 14.1.1.1 Introduction to Watches and Notifications

- 14.1.1.2 Introduction to Diagnostic Scenarios and MBeans

- 14.1.2 Introduction to the Diagnostic Framework

- 14.1.2.1 Controlling the Number of Incident Packages

- 14.1.3 Predefined Incident Processing Rules

- 14.2 Executing Oracle SOA Suite Diagnostic Dumps

- 14.2.1 To List the Dumps:

- 14.2.2 Runtime Environment Diagnostic Dumps (soa.env)

- 14.2.2.1 WLST Command Dump Description and Execution

- 14.2.3 Runtime Platform Configuration Diagnostic Dumps (soa.config)

- 14.2.3.1 WLST Command Dump Description and Execution

- 14.2.4 Database Diagnostic Dumps (soa.db)

- 14.2.4.1 WLST Command Dump Description and Execution

- 14.2.5 Deployed Composite Metadata Diagnostic Dumps (soa.composite)

- 14.2.5.1 WLST Command Dump Description and Execution

- 14.2.6 Instance Audit Trail Diagnostic Dumps (soa.composite.trail)

- 14.2.6.1 WLST Command Dump Description and Execution

- 14.2.7 Event Diagnostic Dumps (soa.edn)

- 14.2.7.1 WLST Command Dump Description and Execution

- 14.2.8 Deployed Composite WSDL/Schema Cache Diagnostic Dumps (soa.wsdl)

- 14.2.8.1 WLST Command Dump Description and Execution

- 14.2.9 Dispatcher Static Configuration Diagnostic Dumps (bpel.dispatcher)

- 14.2.9.1 WLST Command Dump Description and Execution

- 14.2.9.2 Obtaining Dispatcher Static Configuration Diagnostic Dumps with the System MBean Browser

- 14.2.10 Average Instance Processing Time Diagnostic Dumps (bpel.apt)

- 14.2.10.1 WLST Command Dump Description and Execution

- 14.2.11 Average Instance Processing Delay Diagnostic Dumps (bpel.apd)

- 14.2.11.1 WLST Command Dump Description and Execution

- 14.2.12 Synchronous Process Statistics Diagnostic Dumps (bpel.sps)

- 14.2.12.1 WLST Command Dump Description and Execution

- 14.2.13 Asynchronous Process Statistics Diagnostic Dumps (bpel.aps)

- 14.2.13.1 WLST Command Dump Description and Execution

- 14.2.14 Request Statistics Diagnostic Dumps (bpel.rs)

- 14.2.14.1 WLST Command Dump Description and Execution

- 14.2.15 Resequencer Group Processing Delay Diagnostic Dumps (mediator.resequencer)

- 14.2.15.1 WLST Command Dump Description and Execution

- 14.2.16 Adapter Diagnostic Dumps (soa.adapter.ra)

- 14.2.16.1 WLST Command Dump Description and Execution

- 14.2.17 Adapter Diagnostic Dumps (soa.adapter.connpool)

- 14.2.17.1 WLST Command Dump Description and Execution

- 14.2.18 Adapter Diagnostic Dumps (soa.adapter.stats)

- 14.2.18.1 WLST Command Dump Description and Execution

- 14.3 Executing Diagnostic Framework Thread Dumps for SOA Composite Applications

- 14.3.1 WLST Command Dump Description and Execution

- 14.4 Supported DMS Metrics

- 14.5 Creating Watches and Notifications

- 14.5.1 Enabling Preconfigured Rules and Watches

- 14.5.2 Manually Creating Oracle SOA Suite Watches and Notifications

- 14.5.3 Creating a Watch to Identify the Elapsed Time of Web Service Binding Calls

- 14.5.4 Creating a Watch to Identify if Processing Delays Exceed a Specified Time Limit

- 14.5.5 Creating Resequencer Watches and Notifications

- 14.6 Manually Triggering and Executing Dumps

- 14.7 Viewing Incident Packages with ADR Tools

- 14.8 Querying Problems and Incidents

Part V Administering BPEL Process Service Components and Engines

15 Configuring BPEL Process Service Components and Engines

- 15.1 Configuring BPEL Process Service Engine Properties

- 15.2 Configuring Automatic Recovery for Oracle BPEL Process Manager

- 15.3 Configuring Master Node Recovery Scheduling

- 15.4 Configuring Automatic Recovery Attempts for Invoke and Callback Messages

- 15.5 Preserving the Order of Callback Messages

- 15.6 Setting the Audit Level at the BPEL Process Service Component Level

16 Monitoring BPEL Process Service Components and Engines

- 16.1 Monitoring the Flow Trace of a Business Flow Instance

- 16.1.1 Recovering from Faults in the Flow Trace

- 16.1.2 Viewing Composite Sensor Values in the Flow Trace

- 16.1.3 Viewing the SOA Composite Application in the Flow Trace

- 16.1.4 Viewing the Audit Trail and Process Flow in the Flow Trace

- 16.1.5 Monitoring Fault, Activity, and Variable Sensors in the Flow Trace

- 16.1.6 Understanding Additional Flow Trace Behavior Scenarios

- 16.1.6.1 Behavior of Activity Sensors in Compensate and CompensateScope Activities in BPEL 2.0

- 16.2 Monitoring the Time Distribution of BPEL Process Activities and Instance and Fault Throughput Metrics

- 16.3 Monitoring BPEL Process Service Engine Request and Thread Performance Statistics

- 16.3.1 Viewing Low Level Request Breakdown Table Details

- 16.4 Monitoring Deployed BPEL Process Service Components in the Service Engine

- 16.5 Viewing Statistics About the Time a Request Spends in the BPEL Process Service Engine

17 Managing BPEL Process Service Components and Engines

- 17.1 Managing BPEL Process Service Component Policies

- 17.2 Performing BPEL Process Service Engine Message Recovery

- 17.3 Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms

- 17.3.1 Introduction to the Oracle Coherence Caching Architecture

- 17.3.2 Running with Default SOA Cluster Nodes and Coherence Cache Grid Nodes

- 17.3.3 Configuring Oracle Coherence Caching

- 17.3.4 Configuring the Storage of the Audit Trail to Oracle Coherence Cache

- 17.3.5 Configuring the Storage of Invocation Messages to Oracle Coherence Cache

- 17.3.6 Starting the BPEL Process Cache Servers

Part VI Administering Oracle Mediator Service Components and Engines

18 Configuring Oracle Mediator Service Components and Engines

- 18.1 Configuring Oracle Mediator Service Engine Properties

- 18.1.1 To Access System MBean Browser Properties:

- 18.2 Configuring Resequenced Messages

19 Monitoring and Managing Oracle Mediator Service Components and Engines

- 19.1 Introduction to the Oracle Mediator Component Dashboard Page

- 19.1.1 Routing Statistics Section

- 19.1.2 Instance Rate Per Min Section

- 19.2 Monitoring and Managing an Oracle Mediator Service Component

- 19.2.1 Monitoring Oracle Mediator Service Component Routing Statistics and Instances

- 19.2.2 Managing Oracle Mediator Policies

- 19.3 Monitoring an Oracle Mediator Service Engine

- 19.3.1 Monitoring Request Breakdown Statistics

- 19.3.2 Monitoring Deployed Oracle Mediator Service Components in the Service Engine

- 19.4 Monitoring Resequencing Groups

20 Managing Cross-References

- 20.1 Deleting Cross-Reference Values

Part VII Administering Decision Service Components and Business Rules Service Engines

21 Monitoring Decision Service Service Components and Engine

- 21.1 Monitoring Business Rules Service Engine Performance Statistics

- 21.2 Monitoring Business Rules Service Engine Deployed Components

- 21.3 Monitoring Business Rule Tracing

- 21.3.1 Tracing Rule Execution at the Development Audit Level

- 21.3.2 Tracing Rule Execution at the Production Audit Level

- 21.4 Monitoring Decision Service Service Component Logs

- 21.4.1 Viewing Decision Service Service Component Logs

- 21.4.2 Setting the Diagnostic Logging Level with a Log Configuration

Part VIII Administering Human Task Service Components and Human Workflow Service Engines

22 Configuring Human Workflow Service Components and Engines

- 22.1 Configuring Human Workflow Notification Properties

- 22.2 Configuring the Notification Service to Send Notifications to a Test Address

- 22.2.1 How to Remove a Test Address

- 22.3 Configuring Human Workflow Task Service Properties

- 22.4 Configuring Oracle HTTP Server for Task Form Attachments

- 22.5 Configuring Oracle Advanced Queuing for Oracle Human Workflow Notifications

- 22.6 Configuring the Pluggable Notification Service

- 22.6.1 Pluggable Notification Service Implementation

- 22.6.2 Pluggable Notification Service Registration

- 22.7 Globally Disabling the Automatic Release Timers for Oracle BPM Worklist Tasks

- 22.8 Configuring the Number of Email Notification Messages

- 22.9 Configuring Multiple Send Addresses

- 22.10 Configuring Notification Retries

- 22.11 Configuring the Identity Service

- 22.11.1 Adding an Authentication Provider

- 22.11.1.1 Updating the User Attribute

- 22.11.1.2 Configuring Multiple Authentication Providers

- 22.11.2 Creating Users and Groups in the Authentication Provider

- 22.11.2.1 Creating Users Using WebLogic Console

- 22.11.2.2 Creating Groups Using WebLogic Console

- 22.11.2.3 Creating Users and Groups Using Oracle Internet Directory

- 22.11.2.3.1 How to Create a Domain

- 22.11.2.3.2 How to Create a User

- 22.11.2.3.3 How to Create a Group

- 22.11.2.3.4 How to Delete an Entry

- 22.11.3 Configuring the Directory Service

- 22.11.4 Customizing the Identity Provider

- 22.12 Seeding Users, Groups, and Application Roles using LDAP Tools

- 22.12.1 Changing the Default Password in the Embedded LDAP Server

- 22.12.2 Seeding Users or Groups through the LDAP Browser

- 22.12.3 Seeding Application Roles using WLST Scripts

- 22.12.4 Managing Application Roles in Oracle Enterprise Manager Fusion Middleware Control

- 22.13 Enabling Case Agnostic Group Names in Human Tasks

- 22.14 Configuring Security Policies for Human Workflow Web Services

- 22.15 Enabling Lookup of Tasks Assigned to Groups not Part of the Configured Provider

23 Monitoring Human Workflow Service Components and Engines

- 23.1 Monitoring Human Workflow Service Engine Active Requests and Operation Performance Statistics

- 23.2 Monitoring Deployed Human Workflows in the Service Engine

24 Managing Human Workflow Service Components and Engines

- 24.1 Managing Human Workflow Service Component Policies

- 24.2 Managing the URI of the Human Workflow Service Component Task Details Application

- 24.3 Managing Outgoing Notifications and Incoming Email Notifications

- 24.4 Moving Human Workflow Data from a Test to a Production Environment

- 24.4.1 Moving Human Workflow Data from Test to Production Environments

- 24.4.2 migration.properties File Syntax

- 24.4.2.1 Migration Property File Examples

- 24.4.2.1.1 Exporting All Attribute Labels

- 24.4.2.1.2 Importing All Attribute Labels

- 24.4.2.1.3 Exporting Specific Attribute Labels

- 24.4.2.1.4 Importing Specific Attribute Labels

- 24.4.2.1.5 Exporting Task Payload Mapped Attribute Mappings for All Task Definition IDs

- 24.4.2.1.6 Importing Task Payload Mapped Attribute Mappings for All Task Definition IDs

- 24.4.2.1.7 Exporting Task Payload Mapped Attribute Mappings for a Specific Task Definition ID

- 24.4.2.1.8 Importing Task Payload Mapped Attribute Mappings for a Specific Task Definition ID

- 24.4.2.1.9 Exporting All Rules for a Specific User

- 24.4.2.1.10 Importing All Rules for a Specific User

- 24.4.2.1.11 Exporting All Rules for a Specific Group

- 24.4.2.1.12 Importing All Rules for a Specific Group

- 24.4.2.1.13 Exporting All User Views

- 24.4.2.1.14 Importing All User Views

- 24.4.2.1.15 Exporting a Specific User View

- 24.4.2.1.16 Importing a Specific User View

- 24.4.2.1.17 Export All Standard Views

- 24.4.2.1.18 Importing All Standard Views

- 24.4.2.1.19 Exporting a Specific Standard View

- 24.4.2.1.20 Importing a Specific Standard View

- 24.4.3 ant Script Data Migration Syntax

Part IX Administering Oracle JCA Adapters

25 Configuring Oracle JCA Adapters

- 25.1 Configuring the Endpoint Properties for an Inbound Adapter

- 25.1.1 Editing a Predefined Property for an Inbound Adapter

- 25.1.1.1 Edit a Predefined Property:

- 25.1.2 Adding Predefined Properties for an Inbound Adapter

- 25.1.3 Creating a New Property for an Inbound Adapter

- 25.1.4 Deleting a Property for an Inbound Adapter

- 25.1.5 Reverting a Property Value for an Inbound Adapter

- 25.2 Configuring the Endpoint Properties for an Outbound Adapter

- 25.2.1 Editing a Predefined Property for an Outbound Adapter

- 25.2.2 Adding a Predefined Property for an Outbound Adapter

- 25.2.3 Creating a New Property for an Outbound Adapter

- 25.2.4 Deleting a Property for an Outbound Adapter

- 25.2.5 Reverting a Property Value for an Outbound Adapter

26 Monitoring Oracle JCA Adapters

- 26.1 Monitoring Instances and Faults for an Inbound Adapter

- 26.2 Monitoring Recent Faults and Rejected Messages for an Inbound Adapter

- 26.3 Monitoring Faults for an Inbound Adapter

- 26.3.1 Searching for Rejected Messages for an Inbound Adapter

- 26.3.2 Deleting Rejected Messages for an Inbound Adapter

- 26.4 Monitoring Properties for an Inbound Adapter

- 26.5 Monitoring Instances and Faults for an Outbound Adapter

- 26.6 Monitoring Faults for an Outbound Adapter

- 26.6.1 Searching for Faults for an Outbound Adapter

- 26.7 Monitoring Properties for an Outbound Adapter

- 26.8 Monitoring Adapter Logs

- 26.9 Adapter Configuration Reports

- 26.9.1 Enabling Display of Adapter Reports

- 26.9.1.1 Monitoring Report

- 26.9.1.2 Configuration Reports

- 26.9.1.3 Snapshot Reports

- 26.9.1.3.1 Snapshot Reporting Persistence and Intervals

- 26.9.2 Configuration Report Categories and Adapter Properties Reported

- 26.10 Scheduling JCA Adapter Endpoint Activation and Deactivation using Oracle Enterprise Scheduler

- 26.10.1 Create the Schedule Metadata

- 26.10.2 Use the Created Schedule Metadata to Schedule the Deactivation and Activation of a SOA Composite JCA Adapter

- 26.10.3 Editing Oracle Enterprise Scheduler Schedule Metadata

- 26.10.4 Removing Schedules from an Adapter Endpoint

- 26.11 Monitoring Adapter Resiliency

- 26.11.1 Adapter Properties for Resiliency

Part X Administering Oracle B2B and Oracle Healthcare

27 Configuring Oracle B2B

- 27.1 Configuring Oracle B2B Server Properties

- 27.2 Configuring Oracle B2B Operations

- 27.3 Configuring Oracle B2B Attributes

- 27.4 Configuring Oracle B2B Logging Mode

28 Monitoring Oracle B2B

- 28.1 Monitoring the Oracle B2B Infrastructure

- 28.2 Accessing Oracle B2B from the B2B Infrastructure Page

- 28.3 Viewing the Message Flow of an Oracle B2B Binding Component

- 28.4 Viewing Services and References

- 28.5 Accessing Oracle B2B Reports from the Oracle B2B Composite Flow Trace Page

29 Monitoring Oracle Healthcare

- 29.1 Introduction to the Audit Trail

- 29.1.1 Oracle SOA Suite for Healthcare Integration Auditing Options

- 29.1.2 Oracle B2B Auditing Options

- 29.1.3 Using Filter Conditions for Auditing

- 29.2 Configuring the Healthcare Integration Audit Trail

- 29.3 Viewing User Audit Logs

Part XI Administering Binding Components

30 Configuring Service and Reference Binding Components

- 30.1 Configuring Service and Reference Binding Component Properties

- 30.1.1 Configuring Properties for Web Services

- 30.1.2 Configuring Properties for REST Adapters

- 30.1.3 Configuring Properties for Oracle JCA Adapters

31 Monitoring Service and Reference Binding Components

- 31.1 Monitoring Binding Component Messages and Faults

32 Managing Service and Reference Binding Components

- 32.1 Managing Binding Component Policies

- 32.1.1 Override Policy Configuration Property Values

- 32.2 Publishing Web Services to the UDDI Registry

- 32.2.1 Publishing a Web Service to the UDDI Registry

- 32.3 Changing the Endpoint Reference and Service Key for Oracle Service Registry Integration

- 32.3.1 Configuring Caching of WSDL URLs

- 32.4 Publishing and Browsing the Oracle Service Registry

- 32.4.1 Publishing a Business Service

- 32.4.2 Creating a Connection to the Registry

- 32.4.3 Configuring a SOA Project to Invoke a Service from the Registry

- 32.4.3.1 Dynamically Resolving the SOAP Endpoint Location

- 32.4.3.2 Dynamically Resolving the WSDL Endpoint Location

- 32.4.3.3 Resolving Endpoints

- 32.4.4 Configuring the Inquiry URL, UDDI Service Key, and Endpoint Address for Runtime

- 32.4.4.1 Changing Endpoint Locations in the Registry Control

- 32.4.4.1.1 To Update WSDL Binding Overview Documentation:

- 32.4.4.2 Publishing WSDLs from Multiple SOA Partitions

- 32.4.5 How to Publish WSDLs to UDDI for Multiple Partitions

Part XII Administering Business Events

33 Managing Business Events

- 33.1 Introduction to the Event Delivery Network and JMS Provider Types

- 33.2 Mapping Business Events to JMS Topic Destinations

- 33.2.1 Creating an Oracle WebLogic Server JMS Topic

- 33.2.2 Optionally Creating JMS Adapter Connection Factories for Oracle WebLogic Server JMS

- 33.2.3 Creating an AQ JMS Topic

- 33.2.4 Exposing an AQ JMS Topic

- 33.2.5 Optionally Creating JMS Adapter Connection Factories for AQ JMS

- 33.2.6 Enabling a Remote Client to Interact with an AQ JMS-Based Topic

- 33.2.7 Mapping Business Events to JMS Topic Destinations on the Business Events Page

- 33.3 Testing the Publishing of Business Events and Viewing the EDL File

- 33.4 Viewing Business Event Subscribers

- 33.5 Resolving Duplicate Messages for Subscribers in Clustered Environments

- 33.6 Changing the JMS Type

- 33.7 Configuring the Inbound Poller Thread Number

- 33.7.1 Updating the Global Inbound Poller Thread Number in the System MBean Browser

- 33.7.2 Updating the Local Inbound Poller Thread Number Value at the Service Component Level

Part XIII Administering Oracle BPMN Process Service Components and Engines

34 Configuring Oracle BPMN Process Service Components and Engines

- 34.1 Configuring BPMN Process Service Engine Properties

- 34.1.1 Configuring the BPMN Service Engine for Process Monitoring

- 34.2 Integrating Oracle BPM with Oracle BAM 12c

- 34.2.1 Physical Data Objects

- 34.2.2 Logical Data Objects

- 34.2.3 Process Star Schema Database Views

- 34.2.4 Task 1: Enable Oracle BPM Data Publish to Oracle BAM 12c

- 34.3 Integrating Oracle BPM with Oracle BAM 11g

- 34.3.1 Task 1: Configure the Oracle BAM Adapter on Oracle BPM Server

- 34.3.2 Task 2: Enable Oracle BPM Data Publish to Oracle BAM 11g Monitor Express

35 Monitoring BPMN Process Service Components and Engines

- 35.1 Viewing the Audit Trail and Process Flow of a BPMN Process Service Component

- 35.2 Monitoring BPMN Process Service Engine Performance Statistics

- 35.3 Monitoring Deployed BPMN Processes in the Service Engine

36 Managing Oracle BPMN Service Components and Engines

- 36.1 Managing BPMN Process Service Component Policies

- 36.2 Performing BPMN Process Service Engine Message Recovery

- 36.3 Migrating Instances Between Different Composite Application Revisions

- 36.3.1 Migration Compatibility

- 36.3.2 Migrating Instances with the ant Script

- 36.3.3 Example of Migrating a Revision Instance for Oracle BPM

- 36.3.3.1 Migrating a Revision Instance

Part XIV Appendixes

A Installing the Demo User Community in the Database

- A.1 Installing the Demo User Community

- A.2 Demo Community Users

- A.3 Demo Community Groups

- A.4 soa-infra Application Roles

- A.5 SOATestDemoApp Application Roles

- A.6 Roles Granted to and Owned by Users

- A.7 WorkflowPermission Class

B Troubleshooting Oracle SOA Suite and Oracle BPM Suite

- B.1 Setting Logging Levels for Troubleshooting

- B.1.1 Log Files and Thread Dumps from All Managed Servers

- B.2 Parallel Purging and Table Partitioning Issues

- B.2.1 Executing the Parallel Purge Script

- B.2.1.1 Specifying the Degree of Parallel Value

- B.2.1.2 Parsing SOA Composite Applications to Delete

- B.2.1.3 Using Parallel Query Slaves

- B.2.1.4 Debugging and Tracing Purging Operations

- B.2.1.4.1 Debugging Purging Operations

- B.2.1.4.2 Tracing Purging Operations

- B.2.2 Oracle SOA Suite Table Partitioning

- B.2.2.1 Referential Integrity and Equipartitioning

- B.2.2.2 SOA Composite Application Range-Hash Partitions

- B.2.2.3 Interval Partitioning

- B.2.2.4 Global Hash Indexes

- B.2.2.5 Partition Pruning

- B.2.2.6 Purging Partitions

- B.2.3 Reducing Audit Levels

- B.2.3.1 Setting the Audit Level for Production Environments

- B.3 Connection and Transaction Timeout Troubleshooting

- B.3.1 Resolving Connection Timeouts

- B.3.2 Resolving Email Notification Timeouts

- B.3.3 Increasing Database Connection Values

- B.3.4 Updating the EJB Transaction Timeout Value in the Deployment Archive After SOA Infrastructure Failure

- B.3.5 Long Running, Synchronous Calls To Remote Web Services Error Out or Asynchronous Transactions Return with an Error after a Long Time

- B.3.6 Increasing the HTTP POST Timeout Value to Resolve Broken Pipe Errors

- B.3.7 Resolving Exception Errors When Processing Large Documents

- B.4 Runtime Diagnostics Troubleshooting

- B.4.1 Unavailability of Work Manager Threads for Incoming Processing

- B.4.2 Oracle SOA Suite Runtime Failure with a "Cannot read WSDL" Error

- B.4.3 Automatic Recovery of BPEL Instances is Not Recovering a Specific Instance

- B.4.4 Some Composites Are Retried Multiple Times on Failure

- B.4.5 Application Transaction Does Not Complete and the Underlying Composite is Stuck in a Running State

- B.4.6 Errors During Analytics Measurement Event Processing

- B.5 Human Workflow Troubleshooting

- B.5.1 Unavailability of Human Workflow Service Engine

- B.5.2 Task Assignment/Routing/Escalation Issues

- B.5.3 Task Action Issues

- B.5.4 Notification Issues

- B.5.5 Task View Issues

- B.5.6 Task Attribute Mapping Issues

- B.5.7 Task Report Issues

- B.5.8 Task History Issues

- B.5.9 Task Form/Action Issues

- B.5.10 Task Comments/Attachment Issues

- B.5.11 Design Time at Runtime Issues

- B.5.12 Human Workflow API (Including SOAP/EJB) Usage Issues

- B.5.13 Oracle JDeveloper Data Control / Form Generation Issues

- B.5.14 Human Workflow Service/ System MBean Browser Issues

- B.5.15 AMX Extension Issues

- B.5.16 Oracle BPM Worklist/Task Region Issues

- B.5.17 Test-to-Production Issues

- B.5.18 Identity Service Issues

- B.6 Business Events and Event Delivery Network Troubleshooting

- B.6.1 Increasing the JMS Adapter Connection Pool Size

- B.6.2 Tuning Recommendations For Publishing Many BPEL Process Events with Oracle WebLogic Server JMS

- B.6.3 Tuning EDN Event Bus and Delivery

- B.6.4 Events Are Consumed by Multiple Revisions of the Same Composites

- B.6.5 Business Event Is Picked Up Twice (Or More) By SOA Server

- B.6.6 Some Messages Are Lost Between EDN and Composites or Composites Across Clusters

- B.7 Performance Troubleshooting

- B.7.1 Resolving Issue Where BPEL Compiler Does Not Terminate or Report Exceptions

- B.7.2 Resolving Message Failure Caused by Too Many Open Files

- B.7.3 Resolving MaxMessageSizeExceededException Errors Caused By Large Payloads

- B.7.4 Extending Tablespaces to Avoid Problems at Runtime

- B.7.5 Resolving Database Growth Issues Caused by a High Volume of Transactions

- B.7.6 Observing Slow Application Performance Such as Longer Time to Serve Pages or Finish Transactions

- B.7.7 Observing Incoming Message Rates Exceeding Outgoing Message Rates

- B.8 Server Troubleshooting

- B.8.1 Best Practices for Starting and Stopping a Managed Server

- B.8.2 Diagnosing SOA Server Startup Problems

- B.8.3 Specifying the Proxy Server

- B.8.4 Flow Diagram Does Not Display The First Time on Some Lower End Hosts

- B.8.5 Accessing Oracle Enterprise Manager Fusion Middleware Control on Dual Stack Hosts that Support IPv4 and IPv6

- B.9 Browser Troubleshooting

- B.9.1 Limitation on Using the Safari Browser to View WSDL File Content

- B.10 Additional Troubleshooting Documentation

Preface

Administering Oracle SOA Suite and Oracle Business Process Management Suite describes how to administer the components of Oracle SOA Suite and Oracle Business Process Management Suite, including

- The SOA Infrastructure and SOA composite applications

- Composite components and service engines such as the BPEL service engine, BPMN Process service engine, Oracle Mediator service engine, human workflow service engine, and business rules service engine

- Oracle B2B, Oracle JCA Adapters, and business events

Audience

This document is intended for administrators managing applications on a SOA platform.

Related Documents

For more information, see the following Oracle resources:

- Developing SOA Applications with Oracle SOA Suite

- User's Guide for Oracle B2B

- Healthcare Integration User's Guide for Oracle SOA Suite

- Monitoring Business Activity with Oracle BAM

- Understanding Technology Adapters

- Designing Business Rules with Oracle Business Process Management

- Rules Language Reference for Oracle Business Process Management

- Developing Business Processes with Oracle Business Process Management Studio

- Managing and Monitoring Processes with Oracle Business Process Management

- Oracle Fusion Middleware Business Process Composer User's Guide for Oracle Business Process Management

- Tuning Performance

- Enterprise Deployment Guide for Oracle SOA Suite

- High Availability Guide

- WLST Command Reference for WebLogic Server

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

This preface introduces the new and changed features of Oracle SOA Suite and other significant changes that are described in this guide, and provides pointers to additional information. This document is the new edition of the formerly titled Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

For a list of known issues (release notes), see http://www.oracle.com/technetwork/middleware/docs/soa-aiafp-knownissuesindex-364630.html.

New and Changed Features for 12c (12.2.1.x)

For Oracle SOA Suite (12.2.1.2.0, 12.2.1.1.0, and 12.2.1), this guide has been updated to include the following new and changed administration features:

Note:

Screens shown in this guide may differ slightly from your implementation. Any differences are cosmetic.

- Support for monitoring and troubleshooting SOA-wide issues using IWS reports. See Monitoring and Troubleshooting SOA-Wide Issues Using IWS Reports

- Support for Resiliency. See Preventing Faults from Building Up in SOA

- Using SOA Health Check commands. See Using SOA Health Check

- 12.2.1.1.0 and Above: Support for Resiliency is enhanced. REST Services are supported. Both Web Services and REST Services can now be suspended at the operation level. More adapters are supported. See Preventing Faults from Building Up in SOA

- 12.2.1.1.0 and Above: SOA partitions have been renamed to SOA folders. The new SOA Folders tab can be accessed from the SOA Infrastructure home page. See Introduction to SOA Folders and Navigating Through the SOA Folder Home Page and Menu for more details.

Part I Introduction to Oracle SOA Suite and Oracle Business Process Management Suite

This part describes Oracle SOA Suite and Oracle Business Process Management Suite.

This part includes the following chapter:

- Introduction and Concepts

1 Introduction and Concepts

Understand Oracle Fusion Middleware, Oracle Service-Oriented Architecture (SOA) Suite, and Oracle Business Process Management (BPM) Suite and the types of Oracle SOA Suite and BPM Suite administration tasks you perform from Oracle Enterprise Manager Fusion Middleware Control. Also get an overview of Oracle Enterprise Manager 12c Cloud Control and the Oracle SOA Management Pack.

- What Is Oracle Fusion Middleware?

- What Is Oracle SOA Suite?

- What Is Oracle Business Process Management Suite?

- Administration of Oracle SOA Suite and Oracle BPM Suite

- Administration for Application Developers

- Administration with Oracle Enterprise Manager 12c Cloud Control and the Oracle SOA Management Pack

For more information about Oracle Enterprise Manager Fusion Middleware Control administrative tasks and Oracle Fusion Middleware concepts, see the following documents:

- Tuning Performance

- Administering Oracle Fusion Middleware

- Oracle Fusion Middleware 2 Day Administration Guide

- Understanding Oracle Fusion Middleware

1.1 What Is Oracle Fusion Middleware?

Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services: from Java EE and developer tools, to integration services, business intelligence, and collaboration.

Oracle Fusion Middleware offers complete support for development, deployment, and management of applications.

1.2 What Is Oracle SOA Suite?

Oracle SOA Suite is a middleware component of Oracle Fusion Middleware. Oracle SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing SOA composite applications.

Oracle SOA Suite enables services to be created, managed, and orchestrated into SOA composite applications. Composites enable you to easily assemble multiple technology components into one SOA composite application. Oracle SOA Suite plugs into heterogeneous IT infrastructures and enables enterprises to incrementally adopt SOA.

You can administer Oracle SOA Suite from Oracle Enterprise Manager Fusion Middleware Control.

- Introduction to the SOA Infrastructure Application

- Introduction to Partitions

- Introduction to SOA Composite Applications

- Introduction to Business Flow Instances

- Introduction to Service Components

- Introduction to Binding Components

- Introduction to Service Engines

- Introduction to the Service Infrastructure

- Introduction to the Contents of SOA Composite Applications

For introductory information about Oracle SOA Suite, see Developing SOA Applications with Oracle SOA Suite and Understanding Oracle SOA Suite.

1.2.1 Introduction to the SOA Infrastructure Application

The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their lifecycle, service engines, and binding components.

You deploy SOA composite applications designed in Oracle JDeveloper to a partition of your choice in the SOA Infrastructure. Partitions are separate sections of your SOA Infrastructure that enable you to logically group the composite applications for ease of management.

In the example shown in Figure 1-1, many SOA composite applications are deployed to the SOA Infrastructure and are visible in Oracle Enterprise Manager Fusion Middleware Control.

From the SOA Infrastructure home page, you can perform administration tasks such as monitoring the overall status of the SOA Infrastructure, monitoring the deployed SOA composite applications in the SOA Infrastructure, updating the state of SOA composite applications, tracking business flow instances, and performing fault recovery in the Error Hospital.

Figure 1-1 SOA Composite Applications Deployed in the SOA Infrastructure

You can click a specific SOA composite application in the Composite table to access its home page. Figure 1-2 shows the home page for a SOA composite application. From the SOA composite application home page, you can perform administration tasks such as viewing the service components and service and reference binding components included in the SOA composite application, viewing a graphical representation of the SOA composite application, updating the state of the SOA composite application, monitoring business flow instances, automating testing of the SOA composite application, and attaching security policies. You can also perform a limited number of configuration tasks at the SOA composite application level, such as specifying the composite audit level, specifying payload validation, and enabling and disabling the collection of analytic and sensor data. These tasks are displayed as buttons at the top of the page.

Figure 1-2 SOA Composite Application Home Page

For more information, see the following sections:

- Introduction to SOA Composite Applications

- Administering the SOA Infrastructure

- Monitoring the Service Components and Binding Components of a SOA Composite Application.

1.2.2 Introduction to SOA Folders

You can deploy SOA composite applications into separate sections of the SOA Infrastructure known as SOA Folders. Deploying to folders enables you to logically group SOA composites and perform bulk lifecycle management tasks on large numbers of composites. At least one folder is required for deploying SOA composite applications. A default folder named default is automatically included with Oracle SOA Suite.

You can perform the following tasks:

- Deploy SOA composite applications into the SOA Folder using Oracle Enterprise Manager Fusion Middleware Control, Oracle JDeveloper, WebLogic Scripting Tool (WLST) commands, or ant commands.

- Access the folder and its deployed composites using the SOA Folders tab on the SOA Infrastructure page.

- Perform the following bulk lifecycle management tasks on the composites in a specific folder:

- Start all composites

- Shut down all composites

- Undeploy all composites

- Retire all composites

- Activate all composites

- List all composites

- Secure user access to folders, which provides the following benefits:

- Administrative access control

- Striping of instance data by folders

- Folder level resource management

Note:

Folders are not associated with a particular state such as started, stopped, activated, or retired. Only the composites within the folder are associated with a particular state. Therefore, you cannot start, stop, activate, or retire a folder.

For more information about folders and folder security, see Managing SOA Folders and Work Manager Groups.

1.2.3 Introduction to SOA Composite Applications

SOA composite applications such as those shown in the Deployed Composites page in Figure 1-1 consist of the following:

- Service components such as Oracle Mediator for routing, BPEL processes for orchestration, BPMN processes for orchestration (if Oracle BPM Suite is also installed), human tasks for workflow approvals, spring for integrating Java interfaces into SOA composite applications, and decision services for working with business rules.

- Binding components (services and references) for connecting SOA composite applications to external services, applications, and technologies.

These components are assembled into a single SOA composite application. Having the components assembled into one unit of deployment (the application) greatly simplifies the management and lifecycle of SOA applications.

Figure 1-3 shows a diagram of a SOA composite application on the Composite Definition page. Service binding components in the left swimlane (labeled as Operations) advertise their capabilities to external consumers. The service exposes a public interface of the SOA composite application that can consist of BPEL process, Oracle Mediator, decision service (business rule), spring, and human task service components. A wire connects the service to a specific component or reference in the composite. Reference binding components in the right swimlane (also labeled as Operations) enable messages to be sent from the SOA composite application to external services. The service binding components, service components, and reference binding components are wired (connected) for communication. The Composite Definition page is similar to the diagram of the SOA composite application in the SOA Composite Editor in Oracle JDeveloper.

Figure 1-3 SOA Composite Application

The service components and binding components included in a SOA composite application are displayed in the Dashboard page of a SOA composite application. Figure 1-4 shows BPEL process and Oracle Mediator service components in the Components section and service and reference binding components in the Services and References section. You can click a specific service component or binding component to access its home page.

Figure 1-4 Service Components and Binding Components of a SOA Composite Application

For more information, see the following documentation:

- Introduction to Service Components

- Introduction to Binding Components

- Administering SOA Composite Applications and Instances

- Viewing the SOA Composite Application Diagram

- Administering Binding Components

- Developing SOA Applications with Oracle SOA Suite

1.2.4 Introduction to Business Flow Instances

In 12c (12.2.1), business flow instances replace the 11g Release 1 (11.1.1) concept of composite instances. When you create an instance of a SOA composite application in 12c (12.2.1), a business flow instance is created. A business flow instance is defined as follows:

- Corresponds to an end-to-end business transaction.

- Consists of a single SOA composite application or multiple SOA composite applications connected together in a business flow. The SOA composite application that initiates the business flow instance is known as the initiating composite. All other SOA composite applications in the business flow instance are known as the participating composites. A business flow can also include Oracle Service Bus components.

- Provides a complete view of the flow, rather than a subsection of the flow.

- Is identified by a single flow ID value. The 11g Release 1 (11.1.1) concept of service components having their own instance values no longer exists.

You track business flow instances from the Flow Instances page at the SOA Infrastructure, individual partition, or individual SOA composite application level in Oracle Enterprise Manager Fusion Middleware Control. For example, Figure 1-5 shows flow IDs displayed for SOA composite applications in the Flow Instances page of the SOA Infrastructure. When you first access this page, business flow instances do not display. You must first click Search to display business flow instances. You can click the flow ID to access the flow trace of the business flow instance. From the Flow Instances page, you can perform additional tasks:

- Monitor the state of business flow instances (completed, recovery required, and so on).

- Delete or terminate business flow instances.

- Recover from faults.

- View composite sensor values.

- View the initiating and participating composites.

- View any resequencing groups.

Instances that you create as unit tests from the Test Runs page of a SOA composite application are distinguished from those created automatically or created manually from the Test Web Service page by a little yellow box. This box is displayed to the left of the flow ID. For some SOA composite applications, conversation IDs are also generated. Conversation IDs provide another method for distinctly identifying a set of generated instances. Conversation IDs are not automatically displayed for all instances. To see a conversation ID generated, perform one of the following tasks:

- Programmatically invoke the service and pass a unique ID through a WS-Addressing header (messageId).

- Create an instance using the Test Web Service page. The only exception to this is when the Enable Stress Test checkbox of the Additional Test Options section of the Test Web Service page is selected. In that case, a conversation ID is not created for the instance.

Figure 1-5 Flow IDs of Business Flow Instances at the SOA Infrastructure Level

For more information, see the following sections:

- Introduction to Service Components

- Tracking Business Flow Instances

- Recovering From Faults in the Error Hospital

- Initiating a Test Instance of a Business Flow.

1.2.5 Introduction to Service Components

SOA composite applications include service components. Service components are the basic building blocks of SOA composite applications. Service components implement a part of the overall business logic of the SOA composite application.

The following service components can be used in a SOA composite application:

- BPEL process: For process orchestration of synchronous and asynchronous processes

- BPMN process (if Oracle BPM Suite is installed): For creating and modeling business processes using Business Process Management Notation and Modeling (BPMN)

- Oracle Mediator: For content transformation and routing events (messages) between service producers and consumers

- Human task: For modeling a human task (for example, manual order approval) that describes the tasks for users or groups to perform as part of an end-to-end business process flow

- Spring: For integrating Java interfaces into SOA composite applications

- Decision service: For making a decision or for processing based on business rules

From the service component home page in Oracle Enterprise Manager Fusion Middleware Control, you can perform administration tasks such as viewing BPEL process activity time distribution details and attaching security policies. Figure 1-6 provides details.

Figure 1-6 Service Component Home Page of a BPEL Process

For more information about administering service components, see the following sections:

- Administering BPEL Process Service Components and Engines

- Administering Oracle Mediator Service Components and Engines

- Administering Decision Service Components and Business Rules Service Engines

- Administering Human Task Service Components and Human Workflow Service Engines

- Administering Oracle BPMN Process Service Components and Engines

1.2.5.1 Spring Service Component Support

Oracle SOA Suite provides support for the spring service component. Note the following details about spring support in Oracle Enterprise Manager Fusion Middleware Control:

- There are no spring service engine management pages.

- A spring composite is displayed in the flow trace, but there is no audit trail for it.

- Spring composite metrics are shown in the composite application home page.

- The spring service component does not support the running and terminated instance states. Because the spring service component is synchronous, by design, there is no support to terminate the synchronous, running spring instance. Therefore, you cannot abort the running instance and cannot have a terminated state for the spring service component.

1.2.6 Introduction to Binding Components

Binding components connect SOA composite applications to external services, applications, and technologies (such as messaging systems or databases). Binding components are organized into two groups:

- Services: Provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. The service bindings define how a SOA composite service can be invoked (for example, through SOAP).

- References: Enable messages to be sent from the SOA composite application to external services (for example, the same functionality that partner links provide for BPEL processes, but at the higher SOA composite application level).

In Oracle Enterprise Manager Fusion Middleware Control, you can perform binding component administration tasks such as viewing the total number of outgoing messages and faults since the last server startup, attaching policies, setting binding component properties, and, for JCA adapters, viewing reports. Figure 1-7 shows the home page of a service binding component (for this example, a JCA database adapter).

Figure 1-7 Binding Components

For more information, see Administering Binding Components

1.2.7 Introduction to Service Engines

The SOA Infrastructure includes a set of service engines (BPEL process, human workflow, decision service, Oracle Mediator, and spring) that execute the business logic of their respective components within the SOA composite application (for example, a BPEL process). If Oracle BPM Suite is installed, the SOA Infrastructure also includes the BPMN process service engine.

Figure 1-8 provides an example in Oracle Enterprise Manager Fusion Middleware Control of the BPEL process service engine. Each BPEL process service component runs in the same BPEL process service engine. You can click the links on the page to see more details about each BPEL process service component and the SOA composite application in which it is included.

Figure 1-8 Service Components Running in a Service Engine

In Oracle Enterprise Manager Fusion Middleware Control, you can perform service engine administration tasks such as monitoring service components and composites, viewing message request and thread statistics, manually recovering (BPEL) failed messages, and configuring properties specific to a service engine. These configuration properties impact all service components that execute in the service engine, no matter the SOA composite application in which the service components are included.

For more information about administering service engines, see the following sections:

- Administering BPEL Process Service Components and Engines

- Administering Oracle Mediator Service Components and Engines

- Administering Decision Service Components and Business Rules Service Engines

- Administering Human Task Service Components and Human Workflow Service Engines

- Administering Oracle BPMN Process Service Components and Engines

Note:

Oracle Enterprise Manager Fusion Middleware Control does not include pages for managing the spring service engine.

1.2.8 Introduction to the Service Infrastructure

The service infrastructure provides the internal message transport infrastructure for connecting components and enabling data flow. The service infrastructure is responsible for routing messages along the wire connections between services, service components, and references.

For more information, see the following sections:

- Monitoring Message Delivery Processing Requests

- Developing SOA Applications with Oracle SOA Suite for details about wiring

1.2.9 Introduction to the Contents of SOA Composite Applications

Your SOA composite application can consist of a variety of service components, binding components, and services that you administer from Oracle Enterprise Manager Fusion Middleware Control:

- BPEL processes

- BPMN processes (if Oracle BPM Suite is installed)

- Human workflows

- Oracle Mediator

- Decision services (Oracle Business Rules)

- Spring

- JCA adapters

- HTTP binding

- REST service

- EJB service

- Direct binding service

- Oracle Application Development Framework (ADF) Business Component service

- Oracle BAM 11g (This adapter can only connect to an Oracle BAM 11g server.)

- Oracle B2B

- Oracle Healthcare

- Business events

- Oracle User Messaging Service

For conceptual information about these service components, binding components, and services, see Understanding Oracle SOA Suite and Developing SOA Applications with Oracle SOA Suite. For information about JCA adapters, see Understanding Technology Adapters.

1.2.10 Introduction to Oracle SOA Suite and Oracle Enterprise Scheduler Integration

Oracle Enterprise Scheduler enables you to define, schedule, and run jobs. A job is a unit of work done on an application's behalf. For example, you define a job that runs a particular PL/SQL function or command-line process.

When Oracle Enterprise Scheduler is deployed with Oracle SOA Suite, you can create jobs to perform tasks. For example, you can create error notification rules at the SOA Infrastructure or individual partition level that cause an alert message to be triggered when specific fault criteria are met.

Oracle Enterprise Scheduler is currently focused on scheduling embedded product jobs. Use Oracle Enterprise Scheduler only for the following tasks:

- Schedule web services (composites, proxy services, and others).

- Schedule adapter activate and deactivate.

- Schedule fault notification and bulk fault recovery.

- Schedule scripts.

- Submit jobs and job sets from Oracle SOA Suite/Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control. You can use Oracle Enterprise Scheduler web service jobs to schedule SOA composite applications:

- Create job definition metadata using Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control and secure the job with Oracle Web Services Manager (OWSM) policies. The job definition must be created in the namespace /oracle/apps/ess custom/soa. The SOA system administrator has Oracle Enterprise Scheduler permissions to create this job. For information about creating job metadata, see "Managing Job Metadata" of Administering Oracle Enterprise Scheduler.

- Submit the job using Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control and define a schedule when submitting the job. For information about submitting jobs, see "Managing Oracle Enterprise Scheduler Requests" of Administering Oracle Enterprise Scheduler.

- Create custom metadata from Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control.

- Manage, view job output, throttle, and control threads in Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control.

- Submit a job from a BPEL process.

- Use Enterprise Scheduler Web service (ESSWebservice) to access a subset of the Oracle Enterprise Scheduler runtime functionality. The ESSWebservice is provided primarily to support SOA integration, for example invoking Oracle Enterprise Scheduler from a BPEL process. However, any client that needs a Web service to interact with Oracle Enterprise Scheduler can use ESSWebservice. ESSWebservice exposes job scheduling and management functionality for request submission and request management.

- Use all Oracle Enterprise Scheduler WLST commands in Oracle SOA Suite environments, as described in WLST Command Reference for SOA Suite.

For other uses, documentation and support may be incomplete and not supported in this release.

For more information about Oracle Enterprise Scheduler, see the following documentation:

- Creating Error Notification Rules

- Administering Oracle Enterprise Scheduler

- Developing Applications for Oracle Enterprise Scheduler

1.2.10.1 Cross-Component Wiring Between Oracle SOA Suite and Oracle Enterprise Scheduler

Oracle SOA Suite jobs (adapter activation/deactivation, fault notification, and bulk fault recovery) and Oracle Enterprise Scheduler are by default mutually wired bidirectionally using cross-component wiring. Oracle SOA Suite is automatically wired to Oracle Enterprise Scheduler, and vice versa. Each wire is implemented in two parts.

- The first part publishes where the URL is written to the service table.

- The second part consumes where the service table is read and the URL is cached in the local configuration.

If the URL changes, the republishing is typically automatic. However, on the consumption side, you must manually reread the service table and recache it in Oracle Enterprise Manager Fusion Middleware Control. You can also manually rewire when port numbers and others change in Oracle Enterprise Manager Fusion Middleware Control.

For more information about performing these tasks, see the "Wiring Components to Work Together" chapter of Administering Oracle Fusion Middleware.

1.3 What Is Oracle Business Process Management Suite?

Oracle BPM Suite provides an integrated environment for developing, administering, and using business applications centered around business processes.

Oracle BPM Suite provides the following:

- Enables you to create process models based on standards with user-friendly applications. It enables collaboration between process developers and process analysts. Oracle BPM supports BPMN 2.0 and BPEL from modeling and implementation to runtime and monitoring.

- Enables process analysts and process owners to customize business processes and Oracle Business Rules.

- Provides a web-based application for creating business processes, editing Oracle Business Rules, and task customization using predefined components.

- Expands business process management to include flexible, unstructured processes. It adds dynamic tasks and supports approval routing using declarative patterns and rules-driven flow determination.

- Unifies different stages of the application development lifecycle by addressing end-to-end requirements for developing process-based applications. Oracle BPM Suite unifies the design, implementation, runtime, and monitoring stages based on a service component architecture (SCA) infrastructure. This allows different personas to participate through all stages of the application lifecycle.

Oracle BPM Suite provides a seamless integration of all stages of the application development lifecycle from design-time and implementation to runtime and application management.

Oracle BPM Suite is layered on Oracle SOA Suite and shares many of the same product components, including:

- Oracle Business Rules

- Human workflow

- Oracle adapter framework for integration

For more information, see the following documentation:

- Administering Oracle BPMN Process Service Components and Engines

- Developing Business Processes with Oracle Business Process Composer

- Developing Business Processes with Oracle Business Process Management Studio

1.4 Administration of Oracle SOA Suite and Oracle BPM Suite

You can perform a variety of Oracle SOA Suite and Oracle BPM Suite administration (configuration, monitoring, and management) tasks from Oracle Enterprise Manager Fusion Middleware Control.

- Configuration of Oracle SOA Suite and Oracle BPM Suite

- Monitoring of Oracle SOA Suite and Oracle BPM Suite

- Management of Oracle SOA Suite and Oracle BPM Suite

- Performance and Tuning of and Oracle BPM Suite

The administrative tasks that you can perform are based on the partition roles to which you are mapped. Each partition role corresponds to a different set of privileges. You can assign the specific partition roles you want a user to possess on a partition. These roles determine the tasks that a user can perform in Oracle Enterprise Manager Fusion Middleware Control. For more information, see Securing Access to Partitions.

1.4.1 Configuration of Oracle SOA Suite and Oracle BPM Suite

You can perform Oracle SOA Suite and Oracle BPM Suite configuration tasks in Oracle Enterprise Manager Fusion Middleware Control. Configuration tasks consist of setting properties such as audit levels and payload validation for your environment. Properties can be set at the following levels:

- SOA Infrastructure (impacting all SOA composite applications)

- Service engines (impacting all service components that execute in the service engine, no matter the SOA composite application in which they are included)

- SOA composite application (impacting all service components that are included in that composite application)

- Oracle B2B bindings

- Service and reference binding components message header properties

In terms of order of precedence, inherited SOA composite application property settings (such as audit level settings and payload validation) take the highest precedence, followed by service engine settings, followed by SOA Infrastructure settings. However, most properties do not have this type of precedence to consider.

For more information about Oracle SOA Suite and Oracle BPM Suite tuning configuration properties, see Tuning Performance.

1.4.1.1 Introduction to the Order of Precedence for Audit Level Settings

Audit tracking enables you to select the level of information to be collected by the message tracking infrastructure. Audit level tracking can be set at the following levels:

- Individual BPEL activity

- BPEL process or BPMN process service component

- SOA composite application

- Service engine

- SOA Infrastructure

If you set audit tracking at multiple levels, it is important to understand which setting takes precedence. Table 1-1 provides some typical examples of audit level settings.

Table 1-1 Examples of Audit Levels and Order of Precedence

BPEL Activity

Component

Composite

Service Engine

SOA Infrastructure

Which Setting Takes Effect?

No property

No property

No property

Inherit

Production

SOA Infrastructure

This is the out-of-the-box setting.

The audit level is set to Production. The SOA Infrastructure settings are inherited by the child (Service Engine, composite, component, activity) levels. No property defaults to Inherit.

No property

No property

No property

Inherit

Off

SOA Infrastructure

The audit level is set to Off.

This is the recommended setting, and leads to performance enhancements. Depending on your audit requirements, you can then individually set the audit levels for composites that require auditing for debugging or compliance.

No property

No property

Production/Development

Inherit

Off

Composite

The audit level is set to Production/Development. The composite setting overrides the setting at the SOA Infrastructure level.

No property

Production/Development

No property

Inherit

Off

Component

The audit level for the component is set to Production/Development, overriding the settings at parent levels.

Production/Development

No property

No property

Inherit

Off

BPEL Activity.

The audit level for the BPEL activity is set to Production/Development, overriding the settings at the parent levels.

Note:

The default audit level value at the BPEL activity, component, composite, and service engine levels is Inherit. If the audit level property is missing, it defaults to Inherit. The default audit level at the SOA Infrastructure level is Production.

To limit database growth, and for optimal performance, Oracle recommends that you turn Off the setting at the SOA Infrastructure level, and set the audit level at the composite level for composites that require debugging or monitoring. Your compliance requirements might also determine the granularity of your audit requirements.

The following sections describe configuring audit levels:

- See Configuring the SOA Infrastructure for more information about configuring audit level settings at the SOA Infrastructure level.

- See Configuring BPEL Process Service Engine Properties for more information about configuring audit level settings at the BPEL service engine level.

- See Managing the State of an Application from the SOA Composite Application Home Page for more information about configuring audit level settings at the composite level.

- See Setting the Audit Level at the BPEL Process Service Component Level for more information about configuring audit level settings at the BPEL component level.

- See “Auditing SOA Composite Applications at the BPEL Activity Level” in Developing SOA Applications with Oracle SOA Suite for more information about configuring audit level settings at the BPEL activity level.

Reducing Audit Levels includes tips on improving performance and reducing database storage for your production environment.

1.4.2 Monitoring of Oracle SOA Suite and Oracle BPM Suite

You can perform Oracle SOA Suite and Oracle BPM Suite monitoring tasks in Oracle Enterprise Manager Fusion Middleware Control, including monitoring the following:

- Business flow instances, faults, and rejected messages in the SOA Infrastructure or individual partition.

- Service engine, service infrastructure, and binding component processing request performance.

- Service and reference binding component message processing totals and average processing times.

- Audit trail and process flow behavior in service components. For BPMN processes, the entire BPMN process flow is displayed, and the path taken by the process instance is highlighted.

- Service engine request and thread states in BPEL processes, BPMN processes, Oracle Mediator, and human workflows.

- Adapter configuration, monitoring, and snapshot reports.

Note:

You can also monitor and diagnose problems in Oracle SOA Suite through use of the WebLogic Diagnostic Framework (WLDF) and Diagnostics Framework. For more information, see Diagnosing Problems with SOA Composite Applications.

1.4.3 Management of Oracle SOA Suite and Oracle BPM Suite

You can perform Oracle SOA Suite and Oracle BPM Suite management tasks in Oracle Enterprise Manager Fusion Middleware Control, including managing the following:

- Creating and deleting partitions. Once you create partitions, you can deploy a composite to the appropriate partition. This action enables you to logically group SOA composite applications into partitions.

- Creating and managing work manager groups. Each partition is associated with a work manager group that consists of work managers. A work manager is an Oracle WebLogic Server entity that represents a logical thread pool. You can define priorities for the work to be processed by work managers.

- Securing user access to partitions. This limits users to administering only the composites within the partition to which they are granted access.

- Managing the composite state (activating, retiring, starting, stopping, and setting the default composite version).

- Deleting and terminating business flow instances.

- Deploying, undeploying, and redeploying SOA composite applications.

- Exporting a deployed SOA composite application to a JAR file.

- Initiating SOA composite application test instances from the Test Web Service page.

- Recovering from faults at the SOA Infrastructure level or individual partition level.

- Recovering rejected messages in BPEL processes.

- Creating error notification rules at the SOA Infrastructure or individual partition level that cause an alert message to be triggered when specific fault criteria are met.

- Scheduling the activation and deactivation of JCA adapter services.

- Performing automated testing of SOA composite applications.

- Attaching policies to SOA composite applications, service components, and binding components.

- Managing incoming and outgoing notification messages in human workflow.

- Subscribing to business events and testing of event publications.

- Disabling and enabling the collection of analytic, BPEL sensor, and composite sensor data.

- Storing instance and callback message data in Oracle Coherence distributed cache on Oracle Exalogic platforms.

The following sections provide a more specific overview of several management tasks:

- Introduction to Fault Recovery in the Error Hospital

- Introduction to Policies

- Introduction to the Lifecycle State of SOA Composite Applications

- Introduction to SOA Composite Application Automated Testing

Note:

- Backup and recovery of Oracle SOA Suite is described in Administering Oracle Fusion Middleware.

- GridLink data sources and multidata sources protect the SOA Infrastructure against database failures. You typically configure GridLink and multidata sources during system setup (defining multipools directly at installation time). When an Oracle Real Application Clusters (Oracle RAC) database instance fails, the connections are reestablished with available database instances. For more information about Gridlink and Oracle SOA Suite, see High Availability Guide.

1.4.3.1 Introduction to Fault Recovery in the Error Hospital

In 12c (12.2.1), fault recovery is centralized at the SOA Infrastructure level (for all partitions) and individual partition level. This differs from 11g Release 1 (11.1.1) in which fault recovery actions were displayed at multiple levels (SOA Infrastructure, SOA composite application, service engine, and service component).

You perform fault recovery from the Flow Instances and Error Hospital pages in Oracle Enterprise Manager Fusion Middleware Control.

The following types of fault recovery are supported.

- Recovery from individual faults, where you have access to the most granular recovery options specific to each type of fault

- Recovery from multiple (bulk) faults, where you select multiple faults for recovery

For BPEL process faults, you can define a fault recovery policy in the Fault Policy Editor in Oracle JDeveloper. The Fault Policy Editor creates the required fault policy and fault policy binding files that are packaged with the SOA composite application that you deploy to the SOA Infrastructure and administer in Oracle Enterprise Manager Fusion Middleware Control.

Oracle Mediator and human workflow faults do not have the same behavior; they can create recoverable faults without any fault policy. For errors in human task service components or human workflow service engines, you perform fault recovery on faults identified as recoverable from Oracle BPM Worklist.

The following types of faults can be displayed in Oracle Enterprise Manager Fusion Middleware Control:

- Business: Application-specific faults that are generated when there is a problem with the information being processed (for example, a social security number is not found in the database).

- System: Network errors or other types of errors such as a database server or a web service being unreachable.

- Oracle Web Service Manager (OWSM): Errors on policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

Faults can also be classified as either of the following:

- Recoverable or nonrecoverable:
Only certain types of faults are identified as recoverable. Table 1-2 provides examples of several recoverable and nonrecoverable faults.

- Rejected Messages:
A fault is classified as a rejected message based on where it occurs. If a fault occurs before entering a SOA composite, without generating a business flow instance, it is classified as a rejected message. A system or a policy fault can be identified as a rejected message.

Table 1-2 Recoverable and Nonrecoverable Faults

Recoverable Faults

Nonrecoverable Faults

- Business faults and some specific system faults

- Oracle Mediator input file path and output directory mismatch

- An Oracle BPM Worklist user is not authorized to perform relevant (expected) actions

- Rejected messages

- Most system faults

- Non-existent references

- Service invocation failures

- Policy faults

For more information about performing fault recovery, see Deleting or Terminating Business Flow Instances, Recovering from Faults in a Business Flow Instance, and Recovering From Faults in the Error Hospital.

For information about the Fault Policy Editor, see "How to Design a Fault Policy for Automated Fault Recovery with the Fault Policy Wizard" of Administering Oracle SOA Suite and Oracle Business Process Management Suite.

1.4.3.2 Introduction to Policies

You can attach and detach policies at the following levels in Oracle Enterprise Manager Fusion Middleware Control:

- SOA composite applications

- Service components

- Service and reference binding components

Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services. The following types of policies are supported:

- Security: Implements WS-Security 1.0 and 1.1 standards. They enforce authentication and authorization of users, identity propagation, and message protection (message integrity and message confidentiality).

- Reliable Messaging: Supports the WS-ReliableMessaging protocol, guaranteeing the end-to-end delivery of messages.

- Message Transmission Optimization Mechanism (MTOM): Ensures that attachments are in MTOM format, a format for efficiently sending binary data to and from web services.

- WS-Addressing: Verifies that SOAP messages include WS-Addressing headers in conformance with the WS-Addressing specification. Transport-level data is included in the XML message rather than relying on the network-level transport to convey this information.

- Management: Logs request, response, and fault messages to a message log. Management policies can include custom policies.

- SOAP over JMS: Enables web services and clients to communicate using JMS destinations instead of HTTP connections.

- Configuration: Enables web service features, such as Fast Infoset, schema validation, persistence, and so on.

- Atomic Transactions: Supports web service WS-AtomicTransaction (WS-AT) transaction interoperability between Oracle WebLogic Server and other vendor's transaction processing systems.

Policies are part of an enterprise policy framework that allows policies to be centrally created and managed.

For more information, see the following documentation:

- Managing SOA Composite Application Policies

- Managing BPEL Process Service Component Policies

- Managing Policies

- Managing Human Workflow Service Component Policies

- Managing Binding Component Policies

- Managing BPMN Process Service Component Policies

- Securing Web Services and Managing Policies with Oracle Web Services Manager and Understanding Oracle Web Services Manager for definitions of available policies and details about which policies to use for your environment

1.4.3.2.1 Introduction to How Policies are Executed

Policies are executed before a message reaches the component with the attached policy. This causes the error to be displayed in the component preceding the component with the attached policy. For example:

- A policy attached to an Oracle Mediator service component is executed on the wire before the message is passed to Oracle Mediator. This causes the fault to be displayed in the service binding component instead of Oracle Mediator.

- A policy attached to a human task service component is executed in the preceding BPEL process service component before the message is passed to the human task service component. This causes the fault to be displayed in the BPEL process service component instead of the human task service component.

- A policy attached to a human task service component is executed inside the BPMN process in the human steps associated with the human service component before the message is passed to the human task service component. This causes the fault to be displayed in the BPMN process service component instead of the human task service component.

To see the exact location of the policy error, view the audit trail.

1.4.3.3 Introduction to the Lifecycle State of SOA Composite Applications

You can administer the lifecycle state of deployed SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control. An application is automatically activated when you deploy it to the SOA Infrastructure. During deployment, you can specify a specific revision number for the application. A revision is a specific deployed version of the application. You can deploy multiple revisions of an application, enabling all to run at the same time.

This is a key benefit of revisions. For example, you may have an older revision of an application running with one customer that is still valid. You then begin a partnership with a different customer that requires a slight modification to the design of the application. At some point, you plan to migrate the old customer to the newer revision of the application, but for now that is not necessary. Revisions enable you to run both applications.

The revision value is added to the application name in Oracle Enterprise Manager Fusion Middleware Control. For example, in Figure 1-1, revision 1.0 is the version for many deployed SOA composite applications. If a new request comes in for a specific composite application revision, that composite application revision is invoked. If a new request comes in without specifying a revision, the default revision is invoked. A small green dot distinguishes the default revision from other revisions.

You can perform the following lifecycle administration tasks on a SOA composite application from Oracle Enterprise Manager Fusion Middleware Control:

- Create an instance.

- Stop and restart application revisions. An application revision is typically started instantly after deployment.

- Retire and activate application revisions. Application revisions are instantly activated upon deployment.

- Set an application as the default version.

- Deploy, undeploy, and redeploy application revisions.

- Delete specific instances of an application revision.

For more information about administering the lifecycle states of a SOA composite application, see the following sections:

- Initiating a Test Instance of a Business Flow

- Managing the State of Deployed SOA Composite Applications.

1.4.3.4 Introduction to SOA Composite Application Automated Testing

You can create, deploy, and run test cases that automate the testing of SOA composite applications. Test cases enable you to simulate the interaction between a SOA composite application and its references before deployment in a production environment. Test suites consist of a logical collection of one or more test cases. Each test case contains a set of commands to perform as the test instance is executed. The execution of a test suite is known as a test run. Each test corresponds to a business flow instance. You can also create BPEL process service component test cases in the SOA composite application test case. Instances generated by the execution of these tests are distinguished as test instances by a little yellow box next to their flow ID on the Flow Instances page of the SOA Infrastructure.

The test suite framework provides the following features:

- Uses emulations to simulate the behavior of components with which your SOA composite application interacts during execution. Instead of invoking a specific component, you can specify a response from the component.

- Uses assertions to validate data during process execution.

For information about the following:

- Creating and running test cases, see Automating the Testing of SOA Composite Applications

- Designing test cases for SOA composite applications, see Developing SOA Applications with Oracle SOA Suite

1.4.4 Performance and Tuning of Oracle SOA Suite and Oracle BPM Suite

How you set configuration properties can impact Oracle SOA Suite performance. For example, you can set properties in the BPEL process service engine for allocating the number of threads for processing system, invoke, and engine dispatcher messages. Tuning information is described in the following documents.

For the following information, see Tuning Performance:

- Use case tuning recommendations

- Key tuning properties per component, including the following information:

- Default values

- Symptoms, if not properly tuned

- Impact of changing properties from their default values

- Recommendations if symptoms appear

- Profile-based tuning recommendations (selecting a profile by answering questions during installation and tuning properties based on the profile selected).

For additional information about tuning Oracle SOA Suite components, see the following documentation:

- Configuring SOA Infrastructure Properties

- Configuring BPEL Process Service Components and Engines

- Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms

- Configuring Service Engine Properties

- Configuring Human Workflow Service Components and Engines

- Configuring Oracle B2B

- Configuring the Healthcare Integration Audit Trail

- Configuring Service and Reference Binding Components

- Configuring BPMN Process Service Engine Properties

- Understanding Technology Adapters

- Chapter "Managing Large Documents and Large Numbers of Instances" of Developing SOA Applications with Oracle SOA Suite

- Administering Oracle Service Bus

1.5 Administration for Application Developers

If you are an application developer, you can manage and test SOA composites using a combination of Oracle JDeveloper and Oracle Enterprise Manager Fusion Middleware Control.

See Developing SOA Applications with Oracle SOA Suite to develop SOA composite applications with Oracle JDeveloper, and refer to the following sections to deploy, monitor, and initiate a test instance of the SOA composite application with Oracle Enterprise Manager Fusion Middleware Control:

- Monitoring SOA Composite Applications

- Deploying and Managing SOA Composite Applications

- Initiating a Test Instance of a Business Flow.

To create and design business processes with Oracle BPM Suite, see Developing Business Processes with Oracle Business Process Management Studio.

1.6 Administration with Oracle Enterprise Manager 12c Cloud Control and the Oracle SOA Management Pack

Oracle Enterprise Manager 12c Cloud Control enables you to monitor runtime and historical data for multiple Oracle Fusion Middleware farms and Oracle WebLogic Server domains.

Oracle Enterprise Manager 12c Cloud Control supports the discovery, monitoring, and central management of the entire family of Oracle Fusion Middleware components, including Oracle SOA Suite through the Oracle SOA Management Pack.

Oracle Enterprise Manager 12c Cloud Control is a separately licensed and installed component that is not part of the Oracle Fusion Middleware installation.

For more information, visit the following URL:

http://www.oracle.com/us/products/enterprise-manager/index.html

Part II Getting Started with Administration

This part describes how to navigate to Oracle SOA Suite and Oracle BPM Suite administration tasks in Oracle Enterprise Manager Fusion Middleware Control.

This part includes the following chapter:

- Getting Started with Administering and Oracle BPM Suite

2 Getting Started with Administering Oracle SOA Suite and Oracle BPM Suite

Learn how to log in to and navigate the menus of Oracle Enterprise Manager Fusion Middleware Control to perform Oracle SOA Suite and Oracle BPM Suite configuration, monitoring, and management tasks. Also learn how to access the System MBean Browser and Oracle WebLogic Server Administration Console from Oracle Enterprise Manager Fusion Middleware Control.

- Logging In to Oracle Enterprise Manager Fusion Middleware Control

- Navigating to Oracle SOA Suite and Oracle BPM Suite Administration Tasks

- Accessing Context Sensitive Online Help

- Navigating to the System MBean Browser

- Logging Out of Oracle Enterprise Manager Fusion Middleware Control

- Setting Accessibility Options

For more information about service engines, service components, binding components, and the SOA Infrastructure, see Introduction and Concepts .

2.1 Logging In to Oracle Enterprise Manager Fusion Middleware Control

Get an overview of log in information ofOracle Enterprise Manager Fusion Middleware Control.

To log in to Oracle Enterprise Manager Fusion Middleware Control:

1. Use a browser to access the following URL:

http://host_name:port/em

where:

- host_name is the name of the host on which Oracle Enterprise Manager Fusion Middleware Control is installed.

- port is a number that is dynamically set during installation. This port is typically 7001, but is the HTTP port associated with Oracle HTTP Server. For environments in which the SSL port was enabled during configuration, the default port is 7002.

2. Enter weblogic/password and click Login.

where:

- weblogic is the default administrator user name for Oracle Enterprise Manager Fusion Middleware Control (you can change this during installation or create your own user name).

- password is the password you entered during Oracle SOA Suite installation.

The Accessibility Preference dialog appears the first time you log in. If you want, you can select to not display this dialog again.

3. Select an appropriate action and click Continue.

The WebLogic Domain home page is displayed. From there, you can navigate to Oracle SOA Suite and Oracle BPM Suite in several different ways, as described in the following sections.

For more information about installation, see Installing and Configuring Oracle SOA Suite and Business Process Management and Installing SOA Suite and Business Process Management Suite Quick Start for Developers.

2.2 Navigating to Oracle SOA Suite and Oracle BPM Suite Administration Tasks

Understand methods for navigating to Oracle SOA Suite and Oracle BPM Suite administration tasks in Oracle Enterprise Manager Fusion Middleware Control.

- Navigating Through the SOA Infrastructure Home Page and Menu

- Navigating Through the SOA Composite Application Home Page and Menu

- Navigating Through the SOA Folder Home Page and Menu

- Navigating to Deployed Java EE Applications

- Navigating to the Oracle WebLogic Server Administration Console and Other Pages

- Navigating to the SOA Infrastructure or SOA Composite Application Home Page from the WebLogic Domain Home Page

Note:

The WebLogic Domain menu is always displayed at the top of the navigator. As you expand the SOA folder in the navigator and click the links displayed beneath it, the SOA Infrastructure menu becomes available at the top of the page.

2.2.1 Navigating Through the SOA Infrastructure Home Page and Menu

You can navigate to Oracle SOA Suite and Oracle BPM Suite administration tasks through the SOA Infrastructure home page and menu. The SOA Infrastructure provides you with access to all deployed SOA composite applications, service engines, service components, business events, and other elements.

To navigate through the SOA Infrastructure home page and menu:

1. Click the Target Navigation icon near the top left of the screen.

The Target Navigation panel appears.

2. Expand SOA > soa-infra (server_name).

Note:
You can further expand soa-infra (server_name) to see the list of partitions and the list of SOA composite applications in those partitions. For more information about partitions, see Introduction to Partitions.

3. Click soa-infra (server_name).
This displays the Dashboard page of the SOA Infrastructure. This page displays details about the following:

- Important configuration settings

- Runtime health status

- System backlogs

- Business transaction faults

- Composite and adapter endpoint availability

- Error notification rule alerts

This page also provides search functionality to find business flow instances and bulk recovery job status. The bulk recovery job search is applicable when Oracle Enterprise Scheduler is deployed with Oracle SOA Suite.

4. Note that the SOA Infrastructure menu appears below the soa-infra name at the top of the page.

Note:

Depending upon your current location, the context of this menu changes to provide you with the administrative options most relevant to your current location. For example, when you are in the following locations:

- Within the pages of a SOA composite application, the SOA Composite menu is displayed.

- On the home page of a specific partition, the SOA Partition menu is displayed.

- Within the pages of a specific partition or SOA composite application, the SOA Infrastructure menu is still available. However, it moves to the top left corner of the page.

5. Select the SOA Infrastructure menu.

These administrative options enable you to perform the following tasks:

Option

Description

Home

This option enables you to directly navigate to the selected tab of the SOA Infrastructure:

- Dashboard: This option enables you to monitor important configuration settings, runtime health status, system backlogs, business transaction faults, composite and adapter endpoint availability, and error notification rule alerts. You can also search for business flow instances and bulk recovery job search capabilities.
For more information, see Monitoring the Overall Status of the SOA Infrastructure or Individual Partition.

- Deployed Composites: This option enables you to manage the state of all SOA composite applications in the SOA Infrastructure.
For more information, see Managing the State of All Applications at the SOA Infrastructure Level.

- Flow Instances: This option enables you to view the list of business flow instances in the SOA Infrastructure. Business flows can consist of multiple SOA composite applications connected together in a flow.
For more information, see Tracking Business Flow Instances .

- Error Hospital: This option enables you to manage faults occurring within Oracle SOA Suite and view aggregated statistics associated with system-wide faults data.
For more information, see Recovering From Faults in the Error Hospital.

Monitoring

This option displays the following details:

- A summary of performance statistics in the SOA infrastructure.

- Request processing details that show the breakup of time spent in handshaking requests between the binding components, service infrastructure, and service engines.

For more information, see Monitoring Message Delivery Processing Requests.

Logs

This option enables you to view and configure the logging levels for runtime loggers.

For more information, see Configuring Log Files and Setting Logging Levels for Troubleshooting.

SOA Deployment

This option enables you to deploy, undeploy, or redeploy SOA composite applications.

For more information, see Deploying and Managing SOA Composite Applications .

Manage Partitions

This option enables you to logically group your SOA Infrastructure into separate sections known as partitions in which you deploy your SOA composite applications. This helps you to logically group composites so that you can perform bulk lifecycle management tasks on large numbers of SOA composite applications.

For more information, see Introduction to Partitions and Managing Partitions and Work Manager Groups.

Work Manager Groups

This option enables you to manage the work manager groups. A work manager group consists of work managers used by Oracle SOA Suite for each partition. A work manager is an Oracle WebLogic Server entity that represents a logical thread pool. It is similar to a queue in which work items line up for processing.

For more information, see Managing Work Manager Groups.

Resequencing Groups

This option enables you to access the Mediator Resequencing Groups page for finding all resequencing groups processed within a specified time period. Resequencing places unsynchronized Oracle Mediator messages back in the correct order.

For more information, see Monitoring Resequencing Groups.

Service Engines

This option provides access to monitoring and management tasks for the BPEL process, Oracle BPMN, Oracle Mediator, human workflow, and business rules service engines.

Bindings

This option displays details about recently active document types and trading partners, and inbound and outbound endpoints for Oracle B2B.

For more information, see Monitoring the Oracle B2B Infrastructure.

Services and References

This option displays message processing metrics for service and reference binding components in all SOA composite applications.

For more information, see Monitoring Service and Reference Binding Components in the SOA Infrastructure.

Business Events

This option displays available business events and current event subscribers.

For more information, see Managing Business Events.

Error Notification Rules

This option enables you to manage error notification rules. Rules are configuration definitions created for generating alerts during runtime. Alerts are triggered when a rule condition is met (for example, you define an alert to trigger if more than 10 faults occur within a 48 hour period).

For more information, see Creating Error Notification Rules.

Note: This option is displayed if Oracle Enterprise Scheduler is deployed with Oracle Enterprise Manager Fusion Middleware Control.

Define Schedules

This option enables you to define a schedule for submitting jobs. You select the defined schedule when you create an error notification rule. Schedules specify how often to trigger the scheduler (for example, invoke the scheduler every two minutes).

Note: This option is displayed if Oracle Enterprise Scheduler is deployed with Oracle Enterprise Manager Fusion Middleware Control.

For more information, see Administering Oracle Enterprise Scheduler.

SOA Administration

This option provides access to the following configuration tasks for the SOA Infrastructure and each service engine:

- Common Properties: For setting properties that impact the entire SOA Infrastructure, such as viewing and updating the configuration profile, setting the SOA Infrastructure audit level, enabling the payload validation of incoming messages, updating the default query duration, specifying the callback server and server URLs, enabling and disabling analytics and sensors, setting the Universal Description, Discovery and Integration (UDDI) registry properties, viewing the data source JNDI locations, setting the nonfatal connection retry count, and setting web service binding properties.
For more information, see Configuring SOA Infrastructure Properties.

- BPEL Properties: For setting the audit trail size, maximum document size for a variable, payload validation for incoming and outgoing messages, audit trail level, and BPEL monitor and sensor disabling status.
For more information, see Configuring BPEL Process Service Engine Properties.

- BPMN Properties: For setting the audit trail size, maximum document size for a variable, payload validation for incoming and outgoing messages, audit trail level, and BPMN monitor and sensor disabling status. This option is only available when Oracle BPM Suite is installed.
For more information, see Configuring BPMN Process Service Engine Properties .

- Mediator Properties: For setting the audit level, metrics level, maximum number of parallel rows retrieved, parallel locker thread sleep, container ID refresh time, container ID lease timeout, and resequencer locker sleep, maximum groups locked, and worker threads.
For more information, see Configuring Service Engine Properties.

- Workflow Properties: Displays the following tabs:
Mailer tab: For setting the workflow service notification mode and actionable email address value. For more information, see Configuring Human Workflow Notification Properties.

Task tab: For setting the actionable email account, setting the workflow service session timeout, adding the workflow custom class path URL, setting the dynamic and task escalation functions and parameters, setting the worklist application URL, setting the task assignee, setting the portal realm mapping, and adding the task auto release configuration priority. For more information, see Configuring Human Workflow Task Service Properties.

- B2B Server Properties: For enabling Dynamic Monitoring Service (DMS) metrics. For more information, see Configuring Oracle B2B Server Properties.

- Cross References: For selecting cross-reference values. For more information, see Deleting Cross-Reference Values.

- Token Configurations: For defining and managing global token variables. When you move a SOA composite application from one environment to another, some values require substitution in each configuration plan. To avoid substituting values in each plan, you can define global token variables for specific URIs in SOA composite applications.
For more information, see Managing Global Token Variables for Multiple SOA Composite Applications.

- Auto Purge: For scheduling and executing purge jobs that automatically remove older flow instances, adapter reports, and fault alerts data from the database.
For more information, see Deleting Large Numbers of Instances with .

Note: This option is not available for selection if you are using the Java database included with the Oracle SOA Suite Quick Start installation option. For more information about this option, see Installing SOA Suite and Business Process Management Suite Quick Start for Developers.

Security

This option displays the following selections:

- Application Policies: For creating application policies that an application relies upon for controlling access to resources.

- Application Roles: For creating application roles for applications.
For more information about application roles, see Securing Applications with Oracle Platform Security Services.

This option is available for all deployed Java EE applications, including the SOA Infrastructure (soa-infra) application. These options do not configure security policies for SOA composites.

For more information about attaching policies to composite applications, see Managing SOA Composite Application Policies.

Administration

This option displays the following selections:

- MDS Connections: For managing metadata service (MDS) connections.

- TopLink Sessions: For managing cache for the Oracle TopLink persistence framework.

- System MBean Browser: For advanced configuration of properties across applications and components.
For more information, see Navigating to the System MBean Browser and Administering Oracle Fusion Middleware for instructions on using the System Mean Browser.

In addition to configuring the System MBean Browser from Oracle Enterprise Manager Fusion Middleware Control, you also can invoke SOA configuration MBean operations with the WebLogic Scripting Tool (WLST). For information, see WLST Command Reference for SOA Suite.

Note: The System MBean Browser includes an MBean for Oracle BPMN, even if Oracle BPM Suite is not installed. If Oracle BPM Suite is not installed, this MBean cannot be used, and should be ignored. The presence of this MBean does not impact the runtime behavior of other Oracle SOA Suite components.

Target Information

This option displays general details about the SOA Infrastructure, such as the Oracle Enterprise Manager Fusion Middleware Control version, Oracle home, and Oracle instance.

6. Select a specific SOA composite application from the soa-infra list shown in Step GUID-54373B3E-0CF0-4E24-979D-FEBF947B4F96.htm#GUID-2809A0C6-7565-47F8-93E5-FD59033E8BE8__BEIFFGBB.
The SOA Infrastructure menu is now displayed above the navigator, providing you with access to the same high-level administrative options, even when you are within the pages of a SOA composite application. This menu changes positions when you select a composite application.

7. Right-click soa-infra in the navigator. The menu that is displayed provides you with access to the same administrative options that appear in the SOA Infrastructure menu.

2.2.2 Navigating Through the SOA Composite Application Home Page and Menu

You can navigate directly to Oracle SOA Suite and Oracle BPM Suite administration tasks for a specific SOA composite application.

To navigate through the SOA composite application home page and menu:

1. Expand SOA > soa-infra in the navigator.

2. Expand the partitions.

This displays all SOA composite applications running in the partitions of the SOA Infrastructure.

3. Select a specific SOA composite application.

This displays the home page for the selected SOA composite application. This page enables you to perform composite management tasks (retire, activate, shut down, start up, test, and so on) and view the service components and service and reference binding components included in the SOA composite application.

4. Below the name of the SOA composite application, select the SOA Composite menu.

These administrative options enable you to perform the following tasks.

Option

Description

Home

This option enables you to directly navigate to the selected tab of the SOA composite application:

- Dashboard: This option enables you to manage the state of an individual SOA composite application (retire, shut down, activate, start up, test, and so on) from the application's home page.
For more information, see Managing the State of an Application from the SOA Composite Application Home Page.

- Composite Definition: This option enables you to view a graphical display of the SOA composite applications designed in Oracle JDeveloper 12c. This view is similar to the display of the SOA composite application in Oracle JDeveloper. SOA composite applications designed in Oracle JDeveloper 11g are not displayed. To resolve this issue, reopen the SOA composite application in Oracle JDeveloper 12c and redeploy it.

- Flow Instances: This option enables you to view the list of business flow instances in this SOA composite application. Business flows can consist of multiple SOA composite applications connected together in a flow.

- Unit Tests: This option enables you to run test cases that simulate the interaction between the current SOA composite application and its web service partners before deployment to a production environment. This option generates test instances of the composite.
For more information, see Introduction to SOA Composite Application Automated Testing and Automating the Testing of SOA Composite Applications.

- Policies: This option enables you to view and attach or detach policies to or from the SOA composite application.
For more information, see Introduction to Policies and Managing SOA Composite Application Policies.

Monitoring

This option displays the performance summary statistics for the selected SOA composite application.

SOA Deployment

This option enables you to undeploy or redeploy this SOA composite application, or deploy another SOA composite application.

For more information, see Deploying SOA Composite Applications.

Export

This option enables you to export a deployed SOA composite application to a JAR file.

For more information, see Exporting a Deployed SOA Composite Application.

Test Service

This option enables you to manually initiate an instance of this deployed SOA composite application through the Test Web Service page.

For more information, see Initiating a Test Instance of a Business Flow.

SOA Infrastructure

This option takes you to the Dashboard page of the SOA Infrastructure.

For more information, see Monitoring the Overall Status of the SOA Infrastructure or Individual Partition.

SOA Infrastructure Common Properties

This option enables you to view and set the configuration profile, set the SOA Infrastructure audit level, enable the payload validation of incoming messages, update the default query duration, specify the callback server and server URLs, disable analytics and sensors, set the Universal Description, Discovery and Integration (UDDI) registry properties, view the data source JNDI locations, set the nonfatal connection retry count, and set web service binding properties.

For more information, see Configuring SOA Infrastructure Properties

Service/ Reference Properties

This option enables you to configure WSDL file properties for the service and reference binding components included in the SOA composite application.

For more information, see Configuring Service and Reference Binding Component Properties

Target Information

This option displays general details about this SOA composite application, such as Oracle Enterprise Manager Fusion Middleware Control version, Oracle home, Oracle instance, and partition in which the composite is deployed.

5. Right-click the name of a SOA composite application in the navigator. A menu is displayed that provides you with access to the same administrative options that appear in the SOA Composite menu.

2.2.3 Navigating Through the SOA Folder Home Page and Menu

You can navigate to administrative tasks for a specific folder in the SOA Infrastructure.

To navigate through the SOA Folder home page and menu:

1. Click SOA > soa-infra in the Target Navigation pane.

The SOA Infrastructure page appears.

2. Click the SOA Folders tab.

The SOA Folders page appears. Use the SOA Folders page to see all the folders in your SOA Infrastructure and the count of composites in each folder. You can also see the number of active and retired composites for each folder. You can navigate to the Dashboard tab or Deployed Composites tab of any folder.

3. Click a folder name to navigate to the home page (Dashboard) for the folder.

The Dashboard page enables you to monitor important configuration settings, composite and adapter endpoint availability, business transaction faults, business flow instances and bulk recovery job search capabilities, and error notification rule alerts for the folder.

4. At the top of the page, select the SOA_Folder _Name menu.

These administrative options enable you to perform the following tasks:

Option

Description

Composites Control

This option displays the following bulk lifecycle management tasks:

- Start Up All: Invokes a dialog for starting all composites in this folder.

- Shut Down All: Invokes a dialog for shutting down all composites in this folder.

- Activate All: Invokes a dialog for activating all composites in this folder.

- Retire All: Invokes a dialog for retiring all composites in this folder.

For information about these composite states, see Managing the State of All Applications at the SOA Infrastructure Level.

SOA Deployment

This option displays the following management tasks.

- Deploy To This SOA Folder: Invokes the Deploy SOA Composite wizard for selecting a composite to deploy in this partition.

- Undeploy All From This Folder: Invokes a dialog for undeploying all composites in this folder.

- Redeploy: Invokes the Redeploy SOA Composite wizard to select composites to redeploy in this folder.

For more information, see Deploying and Managing SOA Composite Applications .

Delete This SOA Folder

This option invokes a dialog to delete this folder. All composites in the folder are automatically undeployed before the folder is deleted.

Resequencing Groups

This option enables you to access the Mediator Resequencing Groups page for finding all resequencing groups processed within a specified time period. Resequencing places unsynchronized Oracle Mediator messages back into the correct order.

For more information, see Monitoring Resequencing Groups.

BPEL Recovery

A shortcut to the BPEL Recovery page where you can recover or abort messages marked as recoverable.

BPMN Recovery

A shortcut to the BPMN Recovery page where you can recover or abort messages marked as recoverable.

5. Select the Deployed Composites tab to navigate to the deployed composites page for the folder.
The Deployed Composites page enables you to manage the state of all SOA composite applications in the folder.

6. Select the Flow Instances tab to look at message flows for composites deployed in the folder.

The Flow Instances page enables you to view the list of business flow instances in the folder. Business flows can consist of multiple SOA composite applications connected together in a flow.

For more information, see Tracking Business Flow Instances .

7. Select the Error Hospital tab to look at aggregated faults for the folder.

The Error Hospital page enables you to manage faults occurring in the folder and view aggregated statistics associated with folder-wide faults data.

For more information, see Recovering From Faults in the Error Hospital.

For information about folders, see Introduction to SOA Folders and Managing SOA Folders and Work Manager Groups.

2.2.4 Navigating to Deployed Java EE Applications

You can navigate to deployed Java EE applications related to Oracle SOA Suite and (if installed) Oracle BPM Suite components. These applications are Java EE applications that represent the SOA system components, such as the technology adapters, Oracle B2B, Oracle BPM Worklist, and so on. You can deploy a web service and see it listed here. You can also click individual applications (for example, the deployed web service), and manage and test that you can deploy WAR and EAR files from here. If you have deployed your own Java EE applications, they are also displayed here.

To navigate to deployed Java EE applications:

1. Expand Application Deployments in the navigator.

2. Expand Internal Applications.

3. Expand Resource Adapters.

A list of deployed Java EE applications related to Oracle SOA Suite and Oracle BPM Suite components appears.

4. Click a specific application to display details about application performance.

While Oracle Enterprise Manager Fusion Middleware Control displays the URLs for all deployed modules, you cannot directly invoke them from this page.

2.2.5 Navigating to the Oracle WebLogic Server Administration Console and Other Pages

Most pages in Oracle Enterprise Manager Fusion Middleware Control include a Related Links menu in the upper right-hand corner. Depending upon your current location, the context of the menu changes to provide links to relevant pages. For example, when you are on the BPEL process service engine page, the Related Links menu provides links to the SOA Infrastructure home page, the BPEL process configuration properties page, the Oracle WebLogic Server Administration Console, and a page for service engine log files. Figure 2-1 provides details. You can also click soa-infra at the top of the BPEL service engine page to go directly to the SOA Infrastructure home page.

Figure 2-1 Related Links Menu for a SOA Composite Application

When you are on the page of a service component of a SOA composite application (for example, a BPEL process or Oracle Mediator), several navigational menus and links are available:

- The Related Links menu provides links to the SOA Infrastructure home page and the applicable service engine home page. Figure 2-2 provides details.

- Breadcrumbs are displayed in the upper left-hand corner as you traverse further into a SOA composite application.

- Within any SOA composite application page (including the service component pages), links to the SOA Infrastructure pages also remain available through the SOA Infrastructure menu that is displayed next to the WebLogic Domain menu above the navigator. For example, this enables you to go from the home page of a specific BPEL service component directly to the BPEL service engine configuration properties page.

- Names at the top of the page can be clicked to navigate to parent pages. For example, clicking the name of a composite at the very top of a service component page enables you to go to the composite that includes that component.

Figure 2-2 Related Links Menu for a Service Component of a SOA Composite Application

The service engines, SOA administration (such as the SOA Infrastructure Common Properties page), and business event pages all provide access to Oracle WebLogic Server Administration Console from the Related Links list. Selecting WebLogic Server Console opens a new browser page and takes you to the login prompt for the Oracle WebLogic Server Administration Console. Your current page in Oracle Enterprise Manager Fusion Middleware Control is not lost. After logging in, the home page is displayed. Figure 2-3 provides details.

Figure 2-3 Oracle WebLogic Server Administration Console

You can perform the following Oracle SOA Suite tasks from Oracle WebLogic Server Administration Console:

- Configure adapter connections for composite references.

- Create and manage data sources used by adapters.

- Create and manage JMS resources used by adapters.

- Manage SOA Infrastructure data sources (for example, modifying connection pool settings).

- Administer security of human workflow users.

- Manage Oracle WebLogic Server transaction (JTA) settings (for example, the transaction timeout value).

- Deploy human task user interfaces.

2.2.6 Navigating to the SOA Infrastructure or SOA Composite Application Home Page from the WebLogic Domain Home Page

You can access the home page of the SOA Infrastructure, a specific SOA partition, or a specific SOA composite application from the WebLogic Domain home page.

To navigate to the SOA Infrastructure or SOA composite application home page:

1. In the Deployments section of the WebLogic Domain home page, click soa-infra or a specific SOA composite application.

The home page for your selection is displayed.

2.3 Accessing Context Sensitive Online Help

Each page in Oracle Enterprise Manager Fusion Middleware Control provides access to context sensitive help from the Help for This Page option of the Help main menu.

To access context sensitive online help:

1. In the upper right corner of a page, select Help for This Page from the weblogic > Help main menu.

Context sensitive help that describes the fields for that page is displayed.

The Help main menu list provides the following selections.

Selection

Description

Contents

Displays a table of contents with links to relevant Oracle Enterprise Manager Fusion Middleware Control guides.

Help for This Page

Displays context sensitive help that describes the selectable fields of the selected page.

How Do I?

Displays links to conceptual and procedural documentation that is relevant to the selected page.

Documentation Library

Displays the main page for the Oracle Fusion Middleware documentation library.

User Forums

Displays the Oracle Fusion Middleware user forum.

Oracle Technology Network

Displays the main Oracle Fusion Middleware page of the Oracle Technology Network.

2.4 Navigating to the System MBean Browser

Some configuration parameters for Oracle SOA Suite are not exposed in any Oracle Enterprise Manager Fusion Middleware Control property page. These parameters can nonetheless be modified using the System MBean Browser.

A managed bean (MBean) is a Java object that represents a Java Management Extensions (JMX) manageable resource in a distributed environment, such as an application, a service, a component, or a device. Oracle Enterprise Manager Fusion Middleware Control provides the System MBean Browser for managing MBeans that perform specific monitoring and configuration tasks.

This section describes the various ways to access the System MBean Browser, and provides references to documentation that describes how to edit specific SOA Infrastructure and service component properties.

For general information about the System MBean Browser, see Section "Getting Started Using the Fusion Middleware Control MBean Browsers" of Administering Oracle Fusion Middleware.

2.4.1 Accessing the System MBean Browser from the Main Page

You can directly access the main System MBean Browser page. The main page provides you with access to all properties in the System MBean Browser. You must then traverse the navigational tree to the section that you want to manage.

To access the System MBean Browser from the main page:

1. In the navigator, right-click soa-infra.

2. Select Administration > System MBean Browser.

The System MBean Browser is displayed.

3. Scroll down to Application Defined MBeans.

4. Expand the Application Defined MBeans to access specific sections. You can also use the Search field at the top if you know the name (for example, BPELConfig).

This section contains properties for many Oracle SOA Suite components.

5. Expand the component that includes the properties you want to configure. For example, expand oracle.as.soainfra.config > Server: server_name > BPELConfig > bpel. You can also access this location by clicking the More BPEL Configuration Properties short cut described in Step 3 of Accessing the System MBean Browser from the Component Property Pages.

This guide provides many examples of navigating the System MBean Browser from the main page to configure properties. Here are several examples:

- For BPEL processes, see Setting the Audit Level at the BPEL Process Service Component Level

- For Oracle Mediator, see Configuring Service Engine Properties

- For human workflow, see Globally Disabling the Automatic Release Timers for Tasks

- For BPMN processes, see Task 2: Enable Oracle BPM Data Publish to Oracle BAM 11g Monitor Express.

2.4.2 Accessing the System MBean Browser from the Component Property Pages

You can also access the System MBean Browser from various menus in the Oracle SOA Suite component property pages. These shortcuts provide you with direct access to specific sections of the MBean tree, including the oracle.as.soainfra.config section of the Application Defined MBeans group. This provides you with quick access to many common properties of the SOA Infrastructure and service components.

To access the System MBean Browser from the component property pages:

1. In the navigator, right-click soa-infra.

2. Select SOA Administration.

3. Select the appropriate component for which to manage System MBean Browser properties, then scroll down the page to access the short cut.

Select...

Scroll Down and Click...

See...

Common Properties (for the SOA Infrastructure)

More SOA Infra Advanced Configuration Properties

Configuring SOA Infrastructure Properties.

BPEL Properties

More BPEL Configuration Properties

Configuring BPEL Process Service Engine Properties.

BPMN Properties

Note: This option is only displayed for selection if Oracle BPM Suite is installed.

More BPMN Configuration Properties

Configuring BPMN Process Service Engine Properties .

Mediator Properties

More Mediator Configuration Properties

Configuring Service Engine Properties.

Workflow Properties > Mailer tab

More Workflow Notification Configuration Properties

Configuring Human Workflow Notification Properties.

Workflow Properties > Task tab

More Workflow Task Service Configuration Properties

Configuring Human Workflow Task Service Properties.

B2B Server Properties

More B2B Configuration Properties

Configuring Oracle B2B Server Properties.

Auto Purge

More Auto Purge Configuration Properties

Deleting Large Numbers of Instances with .

For example, if you select the More BPEL Configuration Properties link, you are automatically placed into the oracle.as.soainfra.config > Server: server_name > BPELConfig > bpel section of the System MBean Browser. Properties that you can configure are displayed on the right side of the page.

2.5 Logging Out of Oracle Enterprise Manager Fusion Middleware Control

Overview of log out information of Oracle Enterprise Manager Fusion Middleware Control

To log out of Oracle Enterprise Manager Fusion Middleware Control:

1. Note the following details about logging out.

- If multiple pages are open (for example, the help dialog, topology viewer, and flow trace), logging out of any page logs you out of the entire application in all open pages.

- If you log out with any unsaved configuration changes, you receive no warning message and your changes are lost.

2. In the upper right-hand corner of any page, click weblogic and select Log Out from the menu.

2.6 Setting Accessibility Options

Oracle Enterprise Manager Fusion Middleware Control provides accessibility options for the pages on which you monitor and manage applications. Oracle Enterprise Manager Fusion Middleware Control supports screen readers and provides standard shortcut keys to support keyboard navigation.

You can also view the console pages in high contrast or with large fonts for better readability. For information and instructions on configuring accessibility in Oracle Enterprise Manager Fusion Middleware Control, see "Using Oracle Fusion Middleware Accessibility Options" in Administering Oracle Fusion Middleware.

Part III Administering the SOA Infrastructure

This part describes how to administer the SOA Infrastructure.

This part includes the following chapters:

- Configuring the SOA Infrastructure

- Monitoring the SOA Infrastructure

- Tracking Business Flow Instances

- Recovering From Faults in the Error Hospital

- Managing Partitions and Work Manager Groups

3 Configuring the SOA Infrastructure

This chapter describes how to configure the properties of the SOA Infrastructure, including Oracle SOA Suite and Oracle BPM Suite profiles, audit levels, payload validation, and default query duration. These property settings can apply to all SOA composite applications running in the SOA Infrastructure. This chapter also describes how to configure local optimization, stop and start the managed server and SOA Infrastructure, and create global token variables.

This chapter includes the following sections:

- Configuring SOA Infrastructure Properties

- Stopping and Starting the Managed Server and SOA Infrastructure

- Changing the SOA Infrastructure Server URL Property Port in the System MBean Browser

- Configuring Log Files

- Changing the Driver Name to Support Custom XA Drivers

- Specifying a Nondefault XA Transaction Timeout Value for XA Data Sources

- Configuring Database-bound Processing Threads

- Configuring Local Optimization

- Managing Global Token Variables for Multiple SOA Composite Applications

- Preventing Faults from Building Up in SOA

For more information about the SOA Infrastructure, see Introduction to the SOA Infrastructure Application.

3.1 Configuring SOA Infrastructure Properties

You can configure the following SOA Infrastructure properties in the SOA Infrastructure Common Properties page:

- Oracle SOA Suite and Oracle BPM Suite profiles

- Audit levels

- Payload validation

- Time period during which to retrieve flow instances and faults data

- Universal Description, Discovery, and Integration (UDDI) registry

- Callback server and server URLs

- Analytics, BPEL sensors, and composite sensors

- Java Naming and Directory Interface (JNDI) data source

- Web service binding properties

The properties set at this level impact all deployed SOA composite applications, except those composites for which you explicitly set different audit level values at the composite application or service engine levels.

Additional advanced properties for the SOA Infrastructure can be configured through the System MBean Browser. You can access these properties from the More SOA Infra Advanced Configuration Properties link on the Common Properties page as described in this section or from the SOA Infrastructure menu by selecting Administration > System MBean Browser > Application Defined MBeans > oracle.as.soainfra.config.

SOA Infrastructure properties are stored in the Oracle Metadata Services (MDS) Repository associated with the SOA Infrastructure. For Oracle SOA Suite, the MDS Repository is configured by default to store its contents in the database.

Note:
For quartz jobs that use Database for persistence, the node to node communication is done through the Database. If one node is down, there is a failover response time configuration stored in Database from where the available node detects the failure and starts processing uncompleted job requests. In SOA, this failover response time is configured for 10 minutes. This implies that there will be a delay of 10 minutes to the escalation and expiration properties if the node goes down just before the expiration time.

3.1.1 To configure SOA Infrastructure properties:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select SOA Administration > Common Properties.

a. Right-click soa-infra.

b. Select SOA Administration > Common Properties.

a. Select SOA Infrastructure Common Properties.

The SOA Infrastructure Common Properties page is displayed.

Note:

- Some property fields are designated with an icon showing green and red arrows. If you change these properties (for example, Server URL), you must restart the SOA Infrastructure.

- If you exit this page without clicking Apply, the changes are not saved.

- If you make changes and want to reset these properties to their previous values, click Revert.

The properties of the SOA Infrastructure Common Properties page are described in the following sections:

- Configuring and Oracle BPM Suite Profiles

- Configuring the Audit Trail_ Payload Validation_ and Default Query Duration

- Configuring UDDI Registry Properties

- Configuring Callback Server and Server URLs

- Configuring Analytics and Sensors

- Configuring Data Sources and Web Service Binding Properties

- Configuring SOA Infrastructure Advanced Configuration Properties

3.1.2 Configuring Oracle SOA Suite and Oracle BPM Suite Profiles

Oracle SOA Suite profiles provide subsets of functionality. You select a profile and restart the SOA server to activate the selected SOA technologies. Only one SOA profile can be active in a domain at a given time. SOA profiles provide the following benefits:

- Reduce the overall memory footprint of the SOA Infrastructure.

- Make Oracle SOA Suite a more modular platform. You load only the functionality you need to use.

- Reduce overall class loading and overall startup time of the server.

A default profile is automatically set during installation. For Oracle SOA Suite installations (not using Oracle BPM Suite), the default profile is SOA Foundation. For Oracle BPM Suite installations, the default profile is BPM Basic. When you upgrade Oracle SOA Suite from Release 11g to Release 12c, the profile is set to SOA Classic. When you upgrade Oracle BPM Suite from Release 11g to Release 12c, the profile is set to BPM Classic.

Profiles are an advanced feature that must be configured with care. Ensure that you understand the following issues:

- Profile changes, if not done properly, put the system in an unstable state. Only a qualified SOA administrator must perform this operation.

- The SOA servers must be restarted after a profile change to reset the various component/application class loaders and ensure that the Oracle WebLogic Server instance does not hold onto resources for components that have been disabled by the profile change.

- Because SOA profiles define subsets of the overall SOA technology, take care when selecting the correct profile for an existing installation base of SOA composite applications. If a smaller profile is selected that does not support a required SOA technology, composite deployment and runtime errors can occur. For example, if you change the profile from SOA Foundation to BPEL Only, and you have a business flow instance that includes a human task, the human task in the composite becomes inoperable.

- Profiles are only supported on Oracle WebLogic Server.

- When you change a profile, the domain is queried to determine the set of installed templates at runtime, and uses this information to determine which profiles are valid, given the current installation.

To change a profile:

1. Click Change Profile.

2. Select the desired profile, and click OK.

Profile Type

Profile Description

Adapter Set Provided

BPM Classic

Contains the Oracle SOA Suite and Oracle BPM Suite functionality enabled in Release 11g (BPEL, BPMN, case management, Oracle Mediator, Oracle B2B, human workflow, and business rules). When you upgrade from Release 11g to 12c, this is the default profile.

The full set of adapters is included (file, FTP, database, JMS, MQSeries, AQ, E-Business Suite, User Messaging Service, socket, LDAP, Coherence, MSMQ, and JDE).

SOA Foundation

Contains SOA Foundation functionality (BPEL, human workflow, Oracle Mediator, and business rules).

The limited set of adapters is included (file, FTP, database, JMS, MQSeries, AQ, E-Business Suite, and User Messaging Service).

SOA Foundation With B2B

Contains SOA Foundation and the Oracle B2B functionality (BPEL, human workflow, Oracle Mediator, business rules, and Oracle B2B).

The full set of adapters.

SOA Foundation With Healthcare

Contains SOA Foundation and the Oracle B2B functionality (BPEL, human workflow, Oracle Mediator, business rules, and Oracle B2B).

The full set of adapters.

BPM Enterprise

Contains standard Oracle SOA Suite and Oracle BPM Suite functionality (BPEL, BPMN, case management, human workflow, Oracle Mediator, and business rules).

The full set of adapters.

Orchestration

Contains BPEL and human workflow functionality.

The limited set of adapters.

BPM Basic

Contains the standard Oracle SOA Suite platform, Oracle B2B, and Oracle BPM technologies (BPEL, BPMN, case management, human workflow, business rules, and Oracle B2B).

The limited set of adapters.

SOA Classic

Contains the Oracle SOA Suite functionality enabled in Release 11g (BPEL, BPMN, case management, Oracle Mediator, Oracle B2B, human workflow, and business rules). When you upgrade from Release 11g to 12c, this is the default profile.

The full set of adapters.

BPEL Only

Contains the BPEL service component. This is the minimal profile that only supports BPEL.

The limited set of adapters.

SOA Foundation Enterprise

Contains the SOA Foundation functionality (BPEL, human workflow, Oracle Mediator, and business rules).

The full set of adapters.

3. Click Apply.

Until you click Apply, you can click Revert to revert the profile change. In addition, no changes are made if you select different profiles (for example, to view their descriptions) and click Cancel in this dialog.

4. Restart Oracle WebLogic Server immediately.

Any server that includes a SOA Infrastructure deployment must be restarted:

- If the SOA Infrastructure is deployed on the administration server, then it must be restarted.

- If the SOA Infrastructure is deployed on a managed server or a cluster of managed servers, then these servers must all be restarted.

You must perform lifecycle management operations like composite undeployment, retire, activate etc. only when all managed servers in the cluster are running and accepting requests. You must not try any of these operations while a few managed servers are starting up and SOA platform is not on all the servers in the cluster.

3.1.3 Configuring the Audit Trail, Payload Validation, and Default Query Duration

You can configure the payload validation, audit trail, and default query duration for the SOA Infrastructure. Descriptions for each property are provided in the following table.

To configure the audit trail, payload validation, and default query duration:

1. Make changes appropriate to your environment.

Element

Description

Audit Level

Select the level of information to be collected by the message tracking infrastructure. This information is collected in the instance data store (database) associated with the SOA Infrastructure. This setting has no impact on what gets written to log files.

- Off: No business flow instance tracking and payload tracking information is collected. Drilling down into a flow shows the components and their status. Using this setting limits database growth, and also helps reduce latency and improve throughput.

- Production: Flow and audit event information is collected and stored in the database. Drilling down into a flow provides the flow trace. The flow trace shows the exact sequence of component interaction, and also shows component statuses. Drilling down into a BPEL instance shows the execution of BPEL activities, and their statuses.
As the flow-trace audit trail may not be required for all composites, you may want to set the audit level to Off at the SOA Infrastructure level, and set the audit level to Production for the required composites

- Development: This option collects payload details in addition to flow and audit events. This setting is not recommended for a production environment, as it will impact performance and result in rapid database growth. This level is useful largely for testing and debugging purposes only.

For more information about reducing the audit level for SOA composite applications and the data written to the Oracle SOA Suite schema, see Reducing Audit Levels.

Payload Validation

Select to enable validation of incoming and outgoing messages. Nonschema-compliant payload data is intercepted and displayed as a fault. By default, this checkbox is not selected.

Default Query Duration

Specify the time period for retrieved instances and fault data, or accept the default value of 24 hours. This property controls the amount of instance and fault data fetched by default by all out-of-the-box queries. This value is also displayed as the default time range value on pages with query/search functionality (for example, the Dashboard page regions that include query functionality, the Flow Instances pages, Error Hospital pages, the Resequencer pages, and so on). You can override this value on the corresponding page, as needed.

Note: It is highly recommended that you set a time period duration because it has a significant impact on the performance of multiple Oracle Enterprise Manager Fusion Middleware Control pages and queries.

2. Click Apply.

3. If you make changes and want to reset these properties to their previous values, click Revert.

3.1.4 Configuring UDDI Registry Properties

You can integrate SOA composite applications running in the SOA Infrastructure with the UDDI registry. The UDDI registry provides a standards-based foundation for locating published services and managing metadata about services (security, transport, or quality of service). You can browse and select published services that meet your needs.

The User and Password properties are applicable if the UDDI registry is secured. These are only used for the secure HTTP configuration of Oracle Service Registry (OSR). The Inquiry URL property is public.

To configure UDDI registry properties:

1. Make changes appropriate to your environment.

Element

Description

Example

Inquiry URL

Enter the URL of the master registry you want to query. The URL must not refer to the slave registry itself. Otherwise, you can lose some data. The inquiry URL obtains full-standard UDDI version 3 structures. This is the same UDDI inquiry URL that you specified in the Create UDDI Registry Connection wizard.

http://master.mycompany.com:8888/registry/uddi/inquiry

User

Enter the registry inquiry user.

admin

Password

Enter the password for the master registry inquiry user.

Enter a password that uses good security practices.

For information about setting the endpoint reference and service key, see Changing the Endpoint Reference and Service Key for Oracle Service Registry Integration.

2. Click Apply.

3. If you make changes and want to reset these properties to their previous values, click Revert.

3.1.5 Configuring Callback Server and Server URLs

The Server URLs section displays the following properties. If not explicitly set here, these values are determined at runtime by querying the Oracle WebLogic Server cluster, the web server, or the local server properties.

To configure callback server and server URLs:

1. Make changes appropriate to your environment.

Element

Description

Callback Server URL

Enter the callback server URL. This setting applies to all SOA composite application service or reference callbacks. This setting typically takes the format of http://host:port and is used to construct the SOAP service URL (for example, http://host:port/endpoint-context-uri for a service callee to asynchronously send back responses to the caller).

Server URL

Enter the server URL. This URL is published as part of the SOAP address of a service in the concrete WSDL file.

Note: SOAP optimization is automatically configured. Therefore, if you upgrade to Release 12c and are using the optimized shortcut approach in existing applications, optimized calls are activated only when the hostname value (as referred to in the WSDL URL in the composite.xml file) matches the Server URL value. Either set both values to the hostname (for example, myhost) or to the full domain name (for example, myhost.domain.com). If these values do not match, a regular SOAP call is performed instead of an optimized local call.

For information about local optimization, see Configuring Local Optimization.

Note:

If you change the Callback Server URL and Server URL values (for example, when moving from a test to a production environment), you must restart Oracle WebLogic Server for the WSDLs to be regenerated.

2. Click Apply.

3. If you make changes and want to reset these properties to their previous values, click Revert.

3.1.6 Configuring Analytics and Sensors

The Analytics and Sensors Configuration section enables you to manage the collection of analytics, BPEL sensors, and composite sensors. By default, all selections are enabled.

Note the following order of precedence when disabling or enabling a selection on the SOA Infrastructure Common Properties page:

- Disabling a selection on the Common Properties page disables the collection of data for that selection for all SOA composite applications. For example, if you disable composite sensors on the Common Properties page, composite sensor details are not collected for any flow instances created after this change.

- Enabling a selection on the Common Properties page enables you to disable that setting at the individual SOA composite application level. For example, if you enable composite sensors on the Common Properties page and disable composite sensors for an individual SOA composite application (for example, named LoanFlow) on its home page under Settings > Enable/Disable Analytics & Sensors, composite sensor details are not collected for any instance of the LoanFlow SOA composite application after this change. However, all other flow instances continue to collect composite sensor details.

To configure analytics and sensors:

1. Make changes appropriate to your environment.

Element

Description

Analytics

Use to manage the collection of analytics in SOA composite applications. When enabled, analytics enable you to perform the following tasks:

- Measure a business indicator at a certain point in the process or in a section of the process.

- Capture BPEL process metrics that are sent to Oracle BAM Server, and then used for analysis and graphic display.

BPEL Sensors

Use to manage the collection of BPEL sensor details in SOA composite applications. When enabled, BPEL sensors collect data for any fault, activity, and variable sensors defined in the composite.

Composite Sensors

Use to manage the collection of composite sensor details in SOA composite applications. When enabled, composite sensors perform the following tasks:

- Monitor incoming and outgoing messages.

- Specify composite sensor details in the search utility of the Flow Instances page of a SOA composite application in Oracle Enterprise Manager Fusion Middleware Control. This action enables you to locate a particular instance.

- Publish JMS data computed from incoming and outgoing messages.

2. Click Apply.

3. If you make changes and want to reset these properties to their previous values, click Revert.

For information about setting analytics and sensors in an individual SOA composite application, see Disabling and Enabling the Collection of Analytic_ BPEL Sensor_ and Composite Sensor Data.

3.1.7 Configuring Data Sources and Web Service Binding Properties

A data source enables you to retrieve a connection to a database server.

To configure data sources and web service binding properties:

1. Expand the Advanced section.

The Data Sources section displays the following properties.

2. Make changes appropriate to your environment.

Element

Description

Example

Server Data Source JNDI

Displays the JNDI location for the server data source. Click Configure to go to the data source configuration page of the Oracle WebLogic Server Administration Console. Global transaction support should be disabled for this data source.

jdbc/SOALocalTxDataSource

Server Transaction Data Source JNDI

Displays the JNDI location for the server transactional data source. Click Configure to go to the data source configuration page of the Oracle WebLogic Server Administration Console. You must configure the data source for global transactions.

jdbc/SOADataSource

Nonfatal Connection Retry Count

Enter the maximum number of times a nonfatal connection error can be retried before failing. These type of errors occur for any connection error with the dehydration store (for example, Oracle Real Application Clusters failover, database shutdown, and so on).

10

The Web Service Binding Properties section displays the following options.

3. Make changes appropriate to your environment.

Element

Description

Example

Oracle SSL Ciphers

Enter the list of supported Oracle ciphers.

A cipher suite is a set of algorithms that provide security for data transmissions. Before data can flow through an SSL connection, both sides of the connection must negotiate common algorithms to use.

SSL_RSA_WITH_RC4_128_MD5

Oracle Wallet Password

Enter the wallet password for the keystore.

Enter a password that uses good security practices.

Use Chunking

Select to enable chunking of data for SOAP over HTTP deliveries.

- -

Chunk Size

Specify a chunk size. The value must be less than or equal to 999. The size is used for SOAP over HTTP deliveries and is specified in bytes.

500

4. Click Apply.

5. If you make changes and want to reset these properties to their previous values, click Revert.

3.1.8 Configuring SOA Infrastructure Advanced Configuration Properties

To change advanced parameters, click More SOA Infra Advanced Configuration Properties. This opens the System MBean Browser. The properties that display include, but are not limited to, the following. Descriptions are provided for each property.

- AuditConfig: The status of BPEL message recovery. This property includes the following key:

- excludeBpelMaxCreationTime key: Enables you to set the time period for excluding messages that require recovery. For more information, see Monitoring the Overall Status of the SOA Infrastructure or Individual Partition.

- CreateWSCallTrackingMBean: Controls the creation of an MBean for tracking the elapsed time of web service calls. If the elapsed time threshold is exceeded, an incident is created. When set to true, you can create a watch. This setting applies to all SOA composite applications in the SOA Infrastructure. For more information, see Creating Watches and Notifications.

- GlobalTxMaxRetry: The maximum number of times an invocation exception can be retried.

- GlobalTxRetryInterval: The number of seconds between retries for an invocation exception.

- HttpServerURL: The HTTP protocol URL published as part of the SOAP address of a process in the WSDL file.

- HttpsServerURL: The HTTPS protocol URL published as part of the SOAP address of a process in the WSDL file.

- KeystoreLocation: The path to the Oracle SOA Suite keystore.

- UddiCacheLifetime: The UDDI endpoint cache life span.

3.2 Stopping and Starting the Managed Server and SOA Infrastructure

You can stop and start the SOA Infrastructure in Oracle Enterprise Manager Fusion Middleware Control for maintenance or for configuration restarts. To do so, stop and start the managed server on which the SOA Infrastructure is installed. This restarts both the managed server and the SOA Infrastructure.

Note:

- Starting with 11g Release 1 (11.1.1.4.0), you can no longer stop and start the SOA Infrastructure from the soa-infra menu in the navigator.

- You can also have a developer configuration that only includes an administration server, and no managed servers.

For more information about server startup issues, see Server Troubleshooting.

To stop and start the managed server and SOA Infrastructure:

1. Access this page through one of the following options:

From the WebLogic Domain Menu...

From the WebLogic Domain Folder in the Navigator...

a. Select Control.

a. Right-click the managed server (for example, soa_server1).

b. Select Control.

2. To shut down the managed server and SOA Infrastructure, select Shut Down.

3. Click OK when prompted to shut down the managed server and SOA Infrastructure.

4. Wait for shutdown to complete.

5. To start the managed server and SOA Infrastructure, select Start Up.

For information on stopping and starting managed servers with Node Manager, see Administering Node Manager for Oracle WebLogic Server.

For information on starting and stopping managed servers with WLST commands, see Administering Oracle Fusion Middleware.

3.2.1 SOA Composite Application States and SOA Infrastructure Shutdown

SOA composite application states are not updated to indicate that they are down after SOA Infrastructure shutdown. If you attempt to access the composite, you receive an error message stating that composite details cannot be retrieved:

soa-infra runtime connection error  An error happened while connecting to
soa-infra runtime at  t3://address:8001/soa-infra.

This message may lead you to believe that another issue exists in the system. However, this is not the case.

These composite states display as up or, in some cases, pending because this metric indicates whether the composite is enabled, and is independent of whether the SOA Infrastructure is started. In addition, the composite is still active and can receive requests on other managed servers in a cluster.

3.2.2 Restarting the SOA Infrastructure Does Not Activate Endpoints When a Retired Composite is Activated

If a SOA composite application with adapter endpoints is in a retired state, the endpoints are not activated if you perform the following actions:

- Restart the SOA Infrastructure

- Activate the SOA composite application

This is because files, records, and so on are not picked up by the endpoint adapters. As a workaround, redeploy the SOA composite application after restarting the SOA Infrastructure.

3.2.3 SOA Infrastructure Startup Failure When cwallet.sso Includes the SOA Map

When cwallet.sso has the SOA map, you receive an error message similar to the following when attempting to start the SOA Infrastructure.

Caused By: java.security.UnrecoverableKeyException: Password verification
failed
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1185)
at oracle.j2ee.ws.saaj.util.SSLUtil.loadKeyStore(SSLUtil.java:73)
at
oracle.j2ee.ws.saaj.util.SSLUtil.getKeyManagerFactory(SSLUtil.java:88)
at oracle.j2ee.ws.saaj.util.SSLUtil.getKeyManagers(SSLUtil.java:97)
at
oracle.j2ee.ws.saaj.util.SSLUtil.createSSLSocketFactory(SSLUtil.java:50)
at
oracle.integration.platform.common.SSLSocketFactoryManagerImpl.getSSLSocketFac
tory(SSLSocketFactoryManagerImpl.java:58)
at oracle.fabric.common.wsdl.WSDLManager.init(WSDLManager.java:356)
at oracle.fabric.common.wsdl.WSDLManager.<init>(WSDLManager.java:101)
at
oracle.fabric.common.metadata.MetadataManagerImpl.getWSDLManager(MetadataManag
erImpl.java:283)
at
oracle.fabric.composite.model.CompositeModel.getWSDLManager(CompositeM

Perform the following steps to resolve this issue.

1. Perform one of the following actions:

- Delete the SOA map in cwallet.sso.

- Remove $DOMAIN_HOME/config/fmwconfig/default-keystore.jks. Oracle Web Services Manager (OWSM) uses this file.

2. Restart the SOA Infrastructure.

3.3 Changing the SOA Infrastructure Server URL Property Port in the System MBean Browser

In addition to the SOA Infrastructure Common Properties page described in Configuring SOA Infrastructure Properties, you can also change the SOA Infrastructure ServerURL property port in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control.

When changing the port, note the following details:

- If the SOA Infrastructure and managed Oracle WebLogic Server port numbers are different, you receive a ConnectException error when trying to connect to Oracle BPM Worklist. Ensure that these port numbers match.

- You cannot change the SOA Infrastructure port from the Oracle WebLogic Server Administration Console. Only the port for the managed Oracle WebLogic Server can be changed from the Oracle WebLogic Server Administration Console.

To change the SOA Infrastructure port:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select SOA Administration > Common Properties.

a. Right-click soa-infra.

b. Select SOA Administration > Common Properties.

a. Select SOA Infrastructure Common Properties.

2. In the Name column, click ServerURL.
The Attribute: ServerURL page appears.

3. In the Value field, change the port.

4. Click Apply.

5. Change the managed Oracle WebLogic Server port in the Oracle WebLogic Server Administration Console to the same value.
In environments in which a load balancer is used in front of an Oracle WebLogic Server cluster, the ServerURL property host and port can be different from the Oracle WebLogic Server host and port. This is typical for enterprise deployment environments in which a load balancer distributes requests across the managed servers in the Oracle WebLogic Server cluster. For more details, see the Enterprise Deployment Guide for Oracle SOA Suite.

3.4 Configuring Log Files

Oracle SOA Suite components generate log files containing messages that record all types of events, including startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.

To configure log files:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Logs > Log Configuration.

a. Right-click soa-infra.

b. Select Logs > Log Configuration.

The Log Configuration page displays the following details:

- A View list for selecting the type of loggers for which to view information:

- Persistent: Loggers that become active when a component is started. Their configuration details are saved in a file and their log levels are persisted across component restarts.

- Active runtime: Loggers that are automatically created during runtime and become active when a particular feature area is exercised (for example, oracle.soa.b2b or oracle.soa.bpel). Their log levels are not persisted across component restarts.

- A table that displays the logger name, the Oracle Diagnostic Logging (ODL) level for setting the amount and type of information to write to a log file, the log file, and the log level state.

2. Specify search criteria (for example, soa), and click the Search icon.
Oracle SOA Suite loggers are displayed.

3. Perform the following log file tasks on this page:

a. In the Logger Name column, expand a logger name. This action enables you to specify more specific logging levels within a component.

b. In the Oracle Diagnostic Logging Level columns, select the level and type of information to write to a log file.

c. In the Log File column, click a specific log file to create and edit log file configurations.
For more information about ODL log files and the level and type of logging information to write to a log file, see Administering Oracle Fusion Middleware.

4. Click the Log Files tab.
This page enables you to create and edit log file configurations, including the log file in which the log messages are logged, the format of the log messages, the rotation policies used, and other parameters based on the log file configuration class.

For information on setting logging levels and Oracle SOA Suite logging files to view, see Setting Logging Levels for Troubleshooting.

3.4.1 Configuring the Logging File Encoding Property

The oracle-soa-handler log handler property of the soa-diagnostic.log file has no encoding property specified in the SOA_Domain/config/fmwconfig/servers/server_soa/logging.xml file. Instead, the soa-diagnostic.log file is written in the operating system's default encoding format. This can cause the following problems:

- Non-ASCII error messages can become unreadable because logging information is written to soa-diagnostic.log in the server's default encoding format.

- On Windows operating systems, writing in the default encoding format can lead to non-ASCII data loss.

To avoid this problem, specify a value of UTF-8 for the oracle-soa-handler log handler property in the logging.xml file.

<?xml version='1.0'?>
<logging_configuration>
<log_handlers>
<log_handler name='wls-domain'
class='oracle.core.ojdl.weblogic.DomainLogHandler' level='WARNING'/>
<log_handler name='oracle-soa-handler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='c:\soa1210.1411\user_
projects\domains\soa/servers/server_soa/logs/soa-diagnostic.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='supplementalAttributes' value='J2EE_APP.name,J2EE_
MODULE.name,WEBSERVICE.name,WEBSERVICE_PORT.name,composite_instance_id,component_
instance_id,composite_name,component_name'/>
<property name='encoding' value='UTF-8'/>
</log_handler>
</log_handlers>
...

Log files are written with ODL. You can view the content of log files from Oracle Enterprise Manager Fusion Middleware Control.

For more information about logging, see Administering Oracle Fusion Middleware.

3.4.2 Configuring Logging to Diagnose Performance Issues in Oracle Enterprise Manager Fusion Middleware Control Pages

Oracle SOA Suite can log performance metrics for API calls. You can trace the performance of costly API calls to the Oracle Enterprise Manager Fusion Middleware Control page that made them. This tracing is useful when an API call does not perform efficiently. The view id is logged with other information to the following file:

FMW_HOME/user_projects/domains/domain_name/servers/weblogic_name/logs/weblogic_name-soa-tracking.trc

For example, you can enable logging at the FINE level for the root logger associated with the weblogic_name-soa-tracking.trc file, reproduce the problem to diagnose, and set the logging level back to SEVERE. The content of the log can be analyzed to pinpoint the underlying operations performed by Oracle SOA Suite.

To configure logging to diagnose performance issues:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Logs > Log Configuration.

a. Right-click soa-infra.

b. Select Logs > Log Configuration.

The Log Configuration page is displayed.

2. In the Logger Name column, expand oracle.soa > oracle.soa.sql.trc.fabric.

3. Set the logging level to FINE.

4. Click Apply.
The Oracle Enterprise Manager Fusion Middleware Control page that generated the API call is logged to the weblogic_name-soa-tracking.trc file. For this example, /ai/soa/composite (SOA composite application home page) is identified as the page.

[2012-08-07T23:21:04.488-07:00] [soa_server1] [TRACE:32] []
[oracle.soa.sql.trc.fabric.toplink_session.tracking_session] [tid:
[ACTIVE].ExecuteThread: '1' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: weblogic] [ecid:
6fec0e67fbf81939:-7d87fd84:138e67064fb:-8000-0000000000000dd6,1:24469]
[SRC_CLASS: oracle.integration.platform.instance.store.ToplinkSessionLogger]
[APP: soa-infra] [SOA.toplink.session_name: tracking_session]
[SOA.logging.category: query] [SOA.call_origin_category: /ai/soa/composite]
[SOA.call_origin: em] [SRC_METHOD: log] execute_query

3.5 Changing the Driver Name to Support Custom XA Drivers

The default SOA Infrastructure data source is always XA-enabled. If your data sources require support for custom drivers, you must change the driver name on Oracle WebLogic Server.

To change the driver name through one of the following methods:

- Edit in Oracle WebLogic Server Administration Console.

1. Log in to Oracle WebLogic Server Administration Console.

2. Under Domain Structure on the left side of the page, select Services > Data Sources > SOADataSource > Connection Pool.

3. For the Driver Class Name, change the value to a custom data source (for example, oracle.jdbc.xa.client.myDataSource).

4. Restart the server.

- Edit the soaDataSource-jdbc.xml file.

1. Open the soaDataSource-jdbc.xml file on Oracle WebLogic Server.

2. Change the SOADataSource driver name from .jdbc.OracleDriver to oracle.jdbc.xa.client.myDataSource.

<?xml version="1.0" encoding="UTF-8"?>
<jdbc-data-source
/. . .
. . .
/  <name>SOADataSource</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:myhost.us.example.com:1537:co0yf470</url>
<driver-name>*oracle.jdbc.xa.client.myDataSource*</driver-name>
<properties>
<property>
<name>user</name>
<value>fusion_soainfra</value>
</property>
</properties>
/  . . .
. . ./
</jdbc-driver-params>
/. . .
. . ./
</jdbc-data-source>

3.6 Specifying a Nondefault XA Transaction Timeout Value for XA Data Sources

The default XA transaction timeout value for XA data sources is 0 seconds. You can change the default value in the Oracle WebLogic Server Administration Console. Follow these steps.

To specify a nondefault XA transaction timeout value for XA data sources:

1. Log in to Oracle WebLogic Server Administration Console.

2. Under Domain Structure on the left side of the page, select Services > Data Sources.

3. In the Name column of the Data Sources table, select EDNDataSource (for event delivery network transactions) or SOADataSource (for all other types of transactions).

4. Under the Configuration tab at the top, click the Transaction subtab.

5. In the XA Transaction Timeout field, enter a value in seconds.

6. Select the Set XA Transaction Timeout checkbox. You must select this checkbox for the new XA transaction timeout value to take effect.

7. Click Save.

3.7 Configuring Database-bound Processing Threads

When client requests come in at a high rate, the requests collect in a queue and wait for the availability of database connections. To handle more concurrent incoming requests, you can change the following properties:

- The SOADataSource property in the Oracle WebLogic Server Administration Console

- The percentages used to calculate the maximum number of threads with the SOAMaxThreadsConfig property in the System MBean Browser

The incomingRequestsPercentage and internalProcessingPercentage elements of SOAMaxThreadsConfig are defined so that combined processing tasks are less likely to overwhelm the number of database connections. The thread limit number used for these maximum threads constraints is calculated based on the maximum capacity value of the SOADataSource property in the Oracle WebLogic Server Administration Console.

If you change the maximum capacity for the SOADataSource property, a background process is initiated to readjust the maximum threads number defined for both the incomingRequestsPercentage and internalProcessingPercentage elements. The automatic adjustment must acquire the Oracle WebLogic Server configuration editing lock before it can proceed with the operation. If you have already acquired the lock, you must release it to allow the automatic adjustment to proceed.

You can adjust the percentage allocated for internal processing versus incoming requests. The default percentage allocation enables the internal processing tasks to take up to 65% of the database connection pool size. Incoming requests take up to 15% of data source pool size, and the remaining 20% account are for adapter and Event Delivery Network processing.

3.7.1 To change the maximum capacity for the SOADataSource property:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure, select Services > Data Sources.

3. At the top of the page, click Connection Pool.

4. In the Name column, select SOADataSource.

5. In the Maximum Capacity field, update the value (for example, to 300 to accommodate loads with 200 threads). The default value is 50.

6. Click Save.

3.7.2 To configure the SOAMaxThreadsConfig property:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select SOA Administration > Common Properties.

a. Right-click soa-infra.

b. Select SOA Administration > Common Properties.

a. Select SOA Infrastructure Common Properties.

2. Click More SOA Infra Advanced Configuration Properties.

3. Expand SOAMaxThreadsConfig.

4. Make changes appropriate to your environment.

For example, make the following changes to accommodate these thread values:

- incomingRequestsPercentage: 20 (to accommodate 10 threads)

- internalBufferPercentage: 50 (to accommodate 25 threads)

- internalProcessingPercentage: 30 (to accommodate 15 threads)

5. Click Apply.

6. If you make changes and want to reset these properties to their previous values, click Revert.

3.8 Configuring Local Optimization

Local optimization is the process of one SOA composite application invoking another SOA composite application through direct Java invocations in an environment in which both composites are on the same SOA server (JVM).

Direct Java invocations are generally more efficient than SOAP over HTTP calls. Therefore, whenever the conditions are met for direct Java invocations, Oracle SOA Suite optimizes the service calls for the co-located composites.

3.8.1 Condition Checks for Using Local Optimization

Oracle SOA Suite performs the following condition checks to determine if local optimization is possible.

- It must be a composite-to-composite invocation. This is the most fundamental criteria that makes direct Java calls possible when both the client and target services are implemented based on the same SOA Infrastructure (that is, the same SOA server).

- The composite implementing the reference (target) service must be active. This condition requires the target composite to be up and running, which in turn ensures that the reference service is available.

Note:

The state of the target composite must be on and active. A stopped or retired state is not eligible for local optimization.

- The client and target composites must be co-located on the same server. This is an obvious requirement for direct Java invocations. It is also a critical step in which Oracle SOA Suite compares the server (on which the client composite is deployed) host configuration with the host and port values specified in the reference (target) service endpoint URI. If the host and port values match, it can be concluded that the client and target composites are located on the same server. However, the comparison is not necessarily straightforward given that working with both standalone and clustered server setups and potential load balancer configurations is necessary. Therefore, here are the step-by-step condition checks that determine the correct server configuration on all platforms:

- Checks the Server URL configuration property value on the SOA Infrastructure Common Properties page, as described in Configuring SOA Infrastructure Properties.

- If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort, if SSL is enabled) configuration property values from the cluster MBeans.

- If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort, if SSL is enabled) configuration property values from the Oracle WebLogic Server MBeans.

- If not specified, uses the DNS-resolved Inet address of localhost.

- Checks if the port value specified in the reference service endpoint URL matches the configured server port value. If no port value is specified in the endpoint URL, Oracle SOA Suite assumes 80 for HTTP and 443 for HTTPS URLs.

- If the port values match, the server URL (that is, http(s)://host:port, where host and port are obtained from the checks mentioned above) is then compared to the server URL in the reference endpoint address. The URLs are resolved to canonical values and the comparison also takes into account the cases in which the endpoint URL host is localhost or 127.0.0.1.

- Oracle SOA Suite concludes that the composites are co-located if the server URL comparison returns a value of true.

- The security policy configurations, if applied on either or both the client and server composites, must allow for local optimization. For information about policy configurations and local optimization, see Policy Attachments and Local Optimization in Composite-to-Composite Invocations.

You can confirm if a call went over local optimization in the Trace section of the Flow Trace page. The (Local Invocation) text for the reference and service of the invoking and invoked composites is displayed, as shown in Figure 3-1.

Figure 3-1 Local Optimization Details in the Trace Section of the Flow Trace Page

For more information about the Flow Trace page, see Monitoring the Flow Trace of a Business Flow Instance.

3.8.2 Overriding or Forcing Local Optimization

Two configuration properties are provided for either overriding or forcing local optimization.

- oracle.webservices.local.optimization
By default, Oracle SOA Suite prefers local optimization. However, you can override this behavior with the oracle.webservices.local.optimization binding property in the composite.xml file. When this property is set to false, local optimization is not performed and cross-composite calls are performed through SOAP and HTTP. Use this property where appropriate. For information about setting this property, see Policy Attachments and Local Optimization in Composite-to-Composite Invocations.

- oracle.soa.local.optimization.force
You can override the oracle.webservices.local.optimization property and force optimization to be performed by setting the oracle.soa.local.optimization.force property to true. Use this property in the following scenarios:

- The server configuration is sufficiently complicated (for example, there are fire wall or proxy settings in an intranet), which may cause the co-location checks described in Condition Checks for Using Local Optimization to not deliver the correct result.

- You clearly understand the semantics of local optimization, the system setup qualifies for local optimization, and local optimization is absolutely preferred.

There can be other scenarios for forcing optimization that are not described in this section.

Note:

If oracle.webservices.local.optimization is set to false and oracle.soa.local.optimization.force is set to false, local optimization is not performed.

The oracle.soa.local.optimization.force property has a default value of false. When this property is set to true, Oracle SOA Suite skips the condition checks described in Condition Checks for Using Local Optimization, except for policy configuration checking, which is necessary to ensure and enforce the integrity of service invocations.

Another important note about this property is that Oracle SOA Suite always honors the setting of this property (if policy checks allow the optimization). However, if local invocation fails due to nonapplication faults or exceptions (that is, runtime errors mostly related to the direct Java invocation), the value of this setting is ignored for subsequent invocations on the configured endpoint and for all the valid endpoint addresses configured on the endpoint.

To enable the oracle.soa.local.optimization.force property:

Add oracle.soa.local.optimization.force as a binding component level property in the reference section of the composite being invoked. For example, if composite comp_comp2 invokes comp_comp1, then define this property in the reference section of the composite.xml file of comp_comp2.

<reference name="Service1"
ui:wsdlLocation="http://localhost:8001/soa-infra/services/default/comp_
comp1!1.0/BPELProcess1.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/comp_comp/comp_
comp1/BPELProcess1#wsdl.interface(BPELProcess1)"
callbackInterface="http://xmlns.oracle.com/comp_
comp/comp_comp1/BPELProcess1#wsdl.interface(BPELProcess1Callback)"/>
<binding.ws port="http://xmlns.oracle.com/comp_comp/comp_
comp1/BPELProcess1#wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)"
location="http://localhost:8001/soa-infra/services/default/comp_
comp1!1.0/bpelprocess1_client_ep?WSDL">
<property name="oracle.webservices.local.optimization">false</property>
<property name="oracle.soa.local.optimization.force">true</property>
</binding.ws>

To force local optimization on the reference service callback:

Add the oracle.soa.local.optimization.force property to the <callback> element in the <service> definition of the corresponding reference service.

For example, if composite1 invokes composite2, add oracle.soa.local.optimization.force property in the <service> definition of compsite2 as follows. This forces the asynchronous callback from composite2 to composite1 to be optimized locally:

<service ui:wsdlLocation="composite2.wsdl">
. . .
<callback>
<binding.ws
port="http://xmlns.oracle.com/example#wsdl.endpoint(FooService/FooPort)">
<property
name="oracle.soa.local.optimization.force">true</property>
</binding.ws>
</callback>
</service>

For information about optimization and WS-AtomicTransaction (WS-AT) transactions, see Section "WS-AT Transactions are Not Supported When Optimization is Enabled" of Developing SOA Applications with Oracle SOA Suite.

3.8.3 Local Optimization Logging

Oracle SOA Suite provides NOTIFICATION:1(INFO) level logging for every critical decision made for local optimization versus SOAP processing. For more details or debugging information, set the oracle.integration.platform.blocks.local and oracle.integration.platform.blocks.soap loggers at the TRACE:1(FINE) level in Oracle Enterprise Manager Fusion Middleware Control.

3.8.4 Local Optimization Calls Use Case

This local optimization calls use case describes the following:

- How local optimization calls work in an environment in which composite A calls a co-located composite B on the same server, and composite B is unreachable (Table 3-1).

- What happens when you create a load balancer address with a port value that is not the port on which the Oracle WebLogic Servers are listening (Table 3-2).

Table 3-1 Local Optimization Calls When a Composite is Unreachable

Scenario

Description

What happens when a local optimization call fails?

A check of composite B is performed before trying a local optimization call.

If the check fails (composite B is unreachable), an exception is thrown in the SOA Infrastructure that is converted to a BPEL fault. The BPEL fault contains information about composite B being unreachable.

Is it possible to retry the co-located call?

After the basic check is performed, a local optimization call is tried. If that call fails, it is reinvoked over SOAP. However, the following conditions must be met for the reinvocation over SOAP to occur:

- The oracle.soa.local.optimization.force WS-binding property must be set to true to force local optimization. This condition is provided for backward compatibility.

- The exception must not be a business exception.

If a retry of the co-located call is possible (for example, the fault policy is set to retry on the composite or endpoint), is the call optimized again or does it attempt to leave the local container and access the load balancer?

If the call fails the first time you attempt to send it locally, the information is cached (that it failed locally).

For subsequent calls, the call is sent over SOAP (the local optimization call is not retried this time).

Table 3-2 Creating a Load Balancer Address with a Port Value That is Not the Port on which the Oracle WebLogic Servers are Listening

Scenario

Description

If you want to create a load balancer address with a port value that is not the port on which the Oracle WebLogic Servers are listening, can you specify the server URL (in the SOA Infrastructure Common Properties page) and the frontend host/port (in the Oracle WebLogic Server HTTP tab) as the address of the load balancer?

Yes. The server URL or frontend host/port are more identifiers of the address for the local optimization rules than the actual addresses to which to send network requests.

Does local optimization not use the port to make a call (for example, composite A calling composite B over port 2011)?

Yes, the port is used only to make comparisons to see if the target is co-located, so as to make a local call.

3.9 Managing Global Token Variables for Multiple SOA Composite Applications

Configuration plans are composite-specific. Therefore, when you move a SOA composite application from one environment to another, some values require substitution in each configuration plan. To avoid substituting values in each plan, you can define global token variables for specific URIs in SOA composite applications in Oracle Enterprise Manager Fusion Middleware Control.

Global token variables provide the following benefits:

- If multiple SOA composite applications invoke different services hosted on a specific server, you can use a single global token variable to reference this server across the composites. This simplifies development because individual configuration plans are not required; only a single set of token values must be updated. For example, instead of updating the host name of the server in ten different configuration plans, you set the name globally with global token variables. The value is retrieved and replaces the value of the global token variable for the host name in the binding.ws element of the composite.xml file of the deployed SOA composite application.

- Usage of global token variables means that Oracle SOA Suite metadata deployed on the runtime server does not include any environment-specific values.

- In a clustered environment, global token variable changes are made on the administration server and propagated to all managed servers.

The following options for managing global token variables are available:

- Manage (create, edit, and delete) global token variables through the Token Configurations page in Oracle Enterprise Manager Fusion Middleware Control.

- Tokens are only supported for the host, port, and protocol at the ws.binding location and any property under the reference tag.

- Use a predefined global token variable named serverURL.

Note:

- Do not create a token name that contains special characters such as dashes (for example, host-name). During invocation, special characters cause the SOA composite application to fail with a Null Pointer Exception error.

- You can only create tokens used in the composite.xml file.

- The use of global token variables in the import element of the composite.xml file is not supported.

3.9.1 Managing Global Token Variables in the Token Configurations Page

You can manage global token variables on the Token Configurations page. This page enables you to do the following:

- Append variables from a local mdm-url-resolver.xml file to variables from the system's mdm-url-resolver.xml file, and then make appropriate edits.

- Manage variables in the system's mdm-url-resolver.xml file.

To manage global token variables on the Token Configurations page:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > Token Configurations.

a. Right-click soa-infra.

b. Select SOA Administration > Token Configurations.

The Token Configurations page is displayed.

2. Select the global token variable configuration action to perform:

To...

Go to Step...

Select to append variables from a local mdm-url-resolver.xml file to variables from the system's mdm-url-resolver.xml file.

3

Manage variables in the system's mdm-url-resolver.xml.

4

3. Perform the following steps to append variables from a local file:

a. Click Bulk Append Tokens.

b. Click Browse to select the mdm-url-resolver.xml file from the local file system. The local file must adhere to the following format to be successfully uploaded. In this example, global token variables are defined for host name, port, and protocol.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata manager to resolve $<variable>
in URLs
</comment>
<entry key="host">mymachine.us.example.com</entry>
<entry key="port">8001</entry>
<entry key="protocol">http</entry>
</properties>

c. Click Append.
The contents of the local file are appended to the contents of the system's mdm-url-resolver.xml file. Global token variables that already exist in the system's mdm-url-resolver.xml file are not overwritten.

d. If you want to edit the variables, click Modify Configuration File, and go to Step 4.

4. Perform the following steps to manage variables in the system's mdm-url-resolver.xml file:

a. Click Modify Configuration File.
If you first selected Bulk Append Tokens and uploaded a file, the global token variables in the local mdm-url-resolver.xml file and the system's mdm-url-resolver.xml file are displayed in a tabular token name and value format. Columns can be sorted either in ascending or descending order. There is no duplication of variables; any variables in the local file that already exist in the system file are not displayed.

If you first selected Modify Configuration File, the global token variables from the system's mdm-url-resolver.xml file are displayed in a tabular token name and value format.

b. Select the global token variable to manage, and perform a specific task.

Note:

After making changes, you must click Save before switching to Bulk Append Tokens mode or navigating away from this page. These actions cause uncommitted changes to be lost.

Element

Description

i. Click to invoke the Add Token dialog for adding a new token name and value. If you attempt to add a token name that already exists, you are prompted with a message asking you to specify a different name. Either enter a different name or close this dialog and click the Edit icon to change the existing name.

ii. Click OK to save your changes in the Add Token dialog.

iii. Click Save to save your changes in the system's mdm-url-resolver.xml file.

i. Click to invoke the Edit Token dialog for editing a selected token name, value, or both.

ii. Click OK to save your changes in the Edit Token dialog.

iii. Click Save to save your changes in the system's mdm-url-resolver.xml file.

i. Click to remove an existing token name and value.

ii. Click OK to confirm.

iii. Click Save to save your changes to the system's mdm-url-resolver.xml file.

i. Click to commit all changes you made to the token configuration. This persists any new, edited, or removed token names and values. This action commits your changes in the system's mdm-url-resolver.xml file.

i. Click to undo all changes you have made since you last clicked Save.

ii. Click Yes when prompted to confirm.

c. Restart the SOA Infrastructure after adding, modifying, or deleting token values. For information, see Stopping and Starting the Managed Server and SOA Infrastructure .
Your updates are propagated across the cluster.

d. For information about how global token variables are substituted at runtime, see section How Global Token Variables are Substituted at Runtime.

3.9.2 How Global Token Variables are Substituted at Runtime

Note:

When you deploy a SOA composite application in Oracle Enterprise Manager Fusion Middleware Control that uses global token variables, a warning message is displayed asking you to verify that all tokens are configured in the system's mdm-url-resolver.xml file. For more information, see Deploying SOA Composite Applications.

The token names and the replacement values that you specified in the Token Configurations page are added to the system's mdm-url-resolver.xml file in the following directory:

$MIDDLEWARE_HOME/user_projects/domains/domain_name/config/fmwconfig/
mdm-url-resolver.xml

For example, assume four global token variable names and values are defined through the Token Configurations page.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata manager to resolve $<variable> in
URLs
</comment>
<entry key="myprotocol">http</entry>
<entry key="myhost">mymachine.us.example.com</entry>
<entry key="myport">8001</entry>
</properties>

When the composite.xml for the deployed SOA composite application is loaded during runtime and the resources indicated by URIs within the file are retrieved, any values of global token variables within the URIs are replaced with the values specified in the Token Configurations page.

For example, the following composite.xml file specifies a URI using these tokens in the binding.ws element:

<?xml version="1.0" encoding="UTF-8"?>
<composite...>
. . .
. . .
<reference name="Service" ui:wsdlLocation="...">
. . .
<binding.ws port="..."
location="${myprotocol}://${myhost}:${myport}/soa-infra/services/default/
mycomposite/bpelprocess1_client_ep?WSDL" soapVersion="1.1">
</binding.ws>
</reference>
. . .
</composite>

When the WSDL definition file is retrieved during runtime, the tokens are replaced by the values in the mdm-url-resolver.xml configuration file to create the following URI:

http://mymachine.us.example.com:8001/soa-infra/services/default/myComposite/
bpelprocess1_client_ep?WSDL

3.9.3 Using Predefined Global Token Variables

You can use a predefined global token variable named serverURL in resource URLs. During runtime, this token is replaced by the setting for the Server URL property of the SOA Infrastructure Common Properties page in Oracle Enterprise Manager Fusion Middleware Control.

To use predefined global token variables:

1. In the Server URL field of the SOA Infrastructure Common Properties page, enter a value (for example, my.host.com:8080). A restart of the server is required when changing this property. Figure 3-2 provides details.

Figure 3-2 Server URL Field of the SOA Infrastructure Common Properties Page

2. Enter the serverURL token in the composite.xml file.

http://${serverURL}/somePath/someReource.xml

This results in the following URI after the token is replaced during deployment:

http://my.host.com:8080/somePath/someResource.xml

For more information about the Server URL property and the SOA Infrastructure Common Properties page, see Configuring SOA Infrastructure Properties.

3.10 Preventing Faults from Building Up in SOA

Resiliency or Circuit Breaker enables you to configure the system to automatically suspend upstream endpoints when a downstream endpoint is down in a SOA composite. This prevents fault buildup in the server and relieves you from having to bulk-recover faulted instances. The upstream endpoints are automatically resumed after the downstream endpoint comes back. For Web Services and REST Services, a new message arriving after the suspension/retry interval brings the service back up.

Note:
This SOA Suite feature is part of Oracle Integration Continuous Availability. Please refer to the Oracle Fusion Middleware Licensing Information for more details on Oracle SOA Suite for Middleware Options.

Enable Resiliency (Circuit Breaker) globally by configuring it at the SOA Infrastructure level. Once enabled, all downstream endpoints are monitored in all composites. If a downstream endpoint experiences errors that exceed the threshold, specified by you in the Resiliency configuration settings, then the upstream endpoints for that downstream endpoint are automatically suspended. So, for example, if a Reference file adapter fails to write to the directory, the upstream web service can be automatically suspended. The system will periodically check if the downstream file adapter is back, and re-enable the web service when the adapter comes back.

The following types of upstream endpoints can be automatically suspended:

- Web Services: Incoming requests are rejected for the duration that the Web service is suspended.
Starting in 12.2.1.1.0, if the Web Service has multiple operations, then only the operation where the message originated from is suspended.

- REST Services: Starting in 12.2.1.1.0, upstream REST services can be automatically suspended. If the REST Service has multiple operations, then only the operation where the message originated from is suspended.

- Adapters: JMS, AQ, DB, File, Apps, SAP, MQ, UMS, and FTP adapters can be automatically suspended in this release.

- EDN Subscribers: The EDN subscriber closest to the downstream endpoint gets suspended. In the 12.2.1 release, all subscribers in a component (BPEL or Mediator) were suspended when the circuit breaker was triggered. In 12.2.1.1.0, only the subscriber where the message originated from is suspended.

Note:
A downstream endpoint can have many upstream endpoints. Only upstream endpoints that are actively funneling in data to the downstream endpoint are suspended.

Viewing and Resuming Suspended Services

Services suspended as a result of Resiliency kicking in appear on the SOA Infrastructure Dashboard page, under the Resiliency — Suspended Services section.

The Resiliency settings take care of automatically resuming any suspended service when the downstream endpoint comes back up.

You can click on the Dashboard suspension message to see the details of the suspended service. The details of the resiliency parameters (x errors in y minutes) that triggered the suspension are displayed. The name of the downstream endpoint and the SOA composite are also displayed. You can click Resume to manually resume the service.

The following example shows an upstream Web Service (Mediator1_ep) being suspended, as the downstream endpoint (FileWrite) has failed 2 times in 1 minute.

The following example shows a suspended EDN subscriber. Both the component name and the subscriber details are shown.

Resiliency related messages are also written to the log. You can search for strings like “CircuitBreaker” in the Log Messages page to filter out Resiliency-related messages.

3.10.1 Configuring Resiliency at the Global Level

Use the Resiliency Configuration page to enable or disable resiliency, and to specify global resiliency settings.

1. Under the SOA Infrastructure menu, select SOA Administration > Resiliency Configuration.
The Resiliency Configuration page appears.Figure 3-3 shows the Resiliency Configuration page.

Figure 3-3 Resiliency Configuration Page

2. Select the Enabled check box to enable resiliency.
When you enable resiliency, downstream endpoints are monitored for errors, and when these errors exceed the specified threshold, upstream endpoints are automatically suspended.

The other resiliency configuration parameters, like Failure Rate and Retry Interval, are now enabled.

3. Specify a Failure Rate: Enter the number of errors and the duration in minutes.
For example, if you specify 10 errors in 5 minutes, then a downstream endpoint failing 10 times in a span of 5 minutes triggers the resiliency feature.

4. Specify a Retry Interval in minutes.

- If you select Disable Auto Retry, then automatic retries are disabled. You would need to resume the upstream endpoint manually.

Any suspended upstream endpoint is temporarily re-enabled after every Retry Interval to check if the downstream endpoint is back up. So, if you specify a Retry Interval of 10 minutes, then a suspended upstream endpoint is re-enabled every 10 minutes to check if the downstream endpoint is back up. If the downstream endpoint is still down, then the upstream endpoint is suspended again.

5. Note:
This step is optional.

Click Add Notification to configure SMS, e-mail, and IM (instant messaging) notifications for the administrator.
You can notify the administrator when an upstream endpoint is suspended, or when an endpoint comes back up.

a. Under Send Notification To, enter the subscriber ID for the administrator.
The subscriber ID can be an email address, phone number, or IM identifier, depending on the chosen communication channel.

b. Under Via, select the communication channel.
You can click Add Notification, identified by the plus sign (+), to add another notification channel.
You can also click Delete Notification, identified by the red X, to remove an existing notification channel.

6. Note:
This step is optional.

Click More Resiliency Configuration Properties to configure additional resiliency properties. See Global Resiliency Properties and Endpoint Resiliency Propertiesfor details on the properties that can be configured.

7. Click Apply on the Resiliency Configuration page to save your changes.

- If you click Revert, then all changes made to this page are reverted.

You have now enabled resiliency at the global level.

3.10.2 Overriding Global Resiliency Settings for a Downstream Endpoint

You can tweak the resiliency settings for a downstream endpoint, and these settings will override the global Resiliency settings for that endpoint.

For example, if you do not wish to monitor a downstream file adapter for write failures, you can disable resiliency for that particular adapter. Use the following steps to configure the resiliency settings for a downstream endpoint in Oracle Enterprise Manager Fusion Middleware Control:

1. From the SOA Composite page for the composite containing the endpoint, click the endpoint name under Services and References.
For example, if you are tweaking resiliency settings for a file adapter, click the name of the file adapter under Services and References.

The dashboard for the endpoint appears.

2. Click Properties to switch to the Properties tab.
A list of properties appears for the component.

3. If you cannot see the Resiliency properties, click the Add button identified by the plus (+) sign.
See Global Resiliency Properties and Endpoint Resiliency Properties for the list of available Resiliency properties.

4. Modify the values for the properties that you wish to change.

Note:

You can also override the resiliency properties for a downstream endpoint in JDeveloper.

3.10.3 Global Resiliency Properties and Endpoint Resiliency Properties

You can modify the ResiliencyConfig MBean attribute in the System MBean Browser to globally set advanced configuration properties for Resiliency. You can also modify the properties for a Reference endpoint to override the global Resiliency settings for the endpoint.

Table 3-3 ResiliencyConfig MBean Attribute Keys and Endpoint Properties

MBean Key

Reference Endpoint Property

Description

circuitBreakerEnabled

circuitbreaker.disabled

Enables or disables Resiliency.

failureRate

circuitbreaker.failure.rate

The threshold count of errors that trigger Resiliency.

failureRateTime

circuitbreaker.failure.rate.time

The time window within which the errors (failureRate) should occur for Resiliency to kick in.

resiliencyNotificationConfigList

The list of email addresses, phone numbers, and IM identifiers to notify when an upstream endpoint is suspended, or when an upstream endpoint is resumed.

resumeInitialDelay

circuitbreaker.resume.initial.delay

The time duration, in ms (milliseconds), to wait between processing successive messages when resuming an endpoint.
This guards against failure buildup in case the downstream endpoint goes down again.

resumeRampupTime

circuitbreaker.resume.rampup.time

The time duration, in minutes, after which the initial delay is reduced to 0. This equates to the time duration after which you are reasonably confident that the downstream endpoint is up, and the system can start pumping messages without delay.
The initial delay is adjusted every 5 minutes.

retryTimeInterval

circuitbreaker.retry.interval property for a Reference endpoint.

Periodic interval, in minutes, at which the downstream endpoint is tested by temporarily re-enabling the upstream endpoint, and letting trickle messages through.

You can set the above properties for composite references in JDeveloper by selecting the reference in the composite and clicking the Add button under the Composite Bindings section.

4 Monitoring the SOA Infrastructure

This chapter describes how to monitor the overall status of the SOA Infrastructure or individual partition, Oracle SOA Suite routing topology, SOA Infrastructure performance summary metrics, message delivery processing requests, and service and reference binding components in the SOA Infrastructure.

This chapter includes the following topics:

- Monitoring the Overall Status of the SOA Infrastructure or Individual Partition

- Discovering the Oracle SOA Suite Routing Topology

- Monitoring SOA Infrastructure Performance Summary Metrics

- Monitoring Message Delivery Processing Requests

- Monitoring Service and Reference Binding Components in the SOA Infrastructure

- Monitoring and Troubleshooting SOA-Wide Issues Using IWS Reports

For more information, see Introduction to the SOA Infrastructure Application.

4.1 Monitoring the Overall Status of the SOA Infrastructure or Individual Partition

You can monitor the overall status of your environment from the Dashboard pages of the SOA Infrastructure or an individual partition. The Dashboard pages enable you to view information such as the following:

- The overall health of the SOA runtime, including any faults with which to be concerned.

- The health of deployed applications and adapter endpoints (for example, any problems when the system was restarted or when applications were deployed or upgraded).

- The health of the business transactions, including any faults with which to be concerned.

- The key events that occurred in the system in the last operating time range (for example, 24 hours).

The information that is displayed on the Dashboard page of the SOA Infrastructure or an individual partition differs in some sections. Table 4-1 describes the sections of the Dashboard pages and how they differ.

Table 4-1 Dashboard Page Sections at SOA Infrastructure and Individual Partition Levels

Section

Displayed on SOA Infrastructure Dashboard Page?

Displayed on Individual Partition Dashboard Page?

Key Configuration

Yes

Yes, and also includes the work manager group of the partition.

SOA Runtime Health

Yes

No

System Backlogs

Yes

No

Business Transaction Faults

Yes, shows all faults for the entire SOA Infrastructure.

Yes, shows faults for the individual partition only.

Composites and Adapters Availability

Yes, shows composite and adapter availability for the entire SOA Infrastructure.

Yes, shows composite and adapter availability for the individual partition only.

Search

Yes, shows all instance and bulk recovery job searches and saved searches for the entire SOA Infrastructure.

Yes, shows instance and bulk recovery job searches and saved searches for the individual partition only.

Fault Alerts

Yes, shows error notification alerts for the entire SOA Infrastructure.

Yes, shows error notification alerts for the individual partition only.

The information that you can view on the Dashboard pages is based on your permissions. For example, if you only have permissions on a specific partition, you cannot access the SOA Infrastructure Dashboard page. However, you can access the Dashboard page for that specific partition.

To monitor the overall status of the SOA Infrastructure or individual partition:

1. Access this page through one of the following options:

a. To access overall status information for the SOA Infrastructure:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

i. Select Home > Dashboard.

i. Expand SOA.

ii. Select soa-infra > server_name.

i. Select SOA Infrastructure.

The SOA Infrastructure Dashboard page displays the following details:

b. To access overall status information for the individual partition:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

i. Select Manage Partitions.

ii. In the SOA Partition column, select a specific partition.

i. Expand SOA.

ii. Expand soa-infra > server_name.

iii. Select the specific partition.

The Dashboard page of the selected partition displays the following details:

You can perform the following overall status monitoring tasks:

- Viewing Key Configuration Settings

- Viewing the Overall Runtime Health of the SOA Infrastructure

- Viewing System Backlogs in the SOA Infrastructure

- Viewing Business Transaction Faults

- Viewing SOA Composite Applications and Adapters Availability

- Searching for Instances and Bulk Recovery Jobs

- Viewing Error Notification Alerts

4.1.1 Viewing Key Configuration Settings

The Key Configuration section enables you to view important system configuration settings for the SOA profile, instance tracking, default query duration, work manager group (for a partition), and automatic purging. The same configuration settings are displayed on the Dashboard pages of the SOA Infrastructure and individual partition. In addition, the work manager group of the partition is displayed on the Dashboard page of the individual partition.

To view key configuration settings:

1. View the following details in the Key Configuration section.

- On the SOA Infrastructure Dashboard page:

- On the individual partition Dashboard page:

2. Perform the following monitoring and management tasks from this section.

Element

Description

Profile

Displays the current configuration profile selected on the SOA Infrastructure Common Properties page (for example, BPM Classic). SOA profiles provide subsets of SOA functionality and reduce the overall memory footprint of the SOA Infrastructure. A default profile is automatically set during installation.

To change this value:

a. To the right of the Profile field, click the icon.

b. Click Change Profile. The SOA Infrastructure Common Properties page is displayed.

c. From the list, select the profile and click OK.

d. Restart the server.

Note: Profile changes, if not done properly, put the system in an unstable state. Only a qualified SOA administrator must immediately restart all Oracle WebLogic Servers on which this SOA Infrastructure is deployed. Otherwise, the system is in an unstable state. For more information about profiles, see Configuring and Oracle BPM Suite Profiles.

Instance Tracking

Displays the audit level setting (Off, Production, or Development). This setting determines the level of information to be collected by the message tracking infrastructure. This information is collected in the instance data store (database) associated with the SOA Infrastructure. For details about these settings, see Configuring the Audit Trail_ Payload Validation_ and Default Query Duration.

To change this value:

a. To the right of the Instance Tracking field, click the icon.

b. Click Change Audit Level. The SOA Infrastructure Common Properties page is displayed.

c. From the Audit Level list, select the appropriate value, and click Apply.

Default Query Duration

Displays the time period during which to retrieve instances and faults data. This property controls the amount of instance and fault data fetched by default by all out-of-the-box queries. This value is also displayed as the default time range value on pages with query/search functionality (for example, the Dashboard page regions that include query functionality, the Flow Instances pages, Error Hospital pages, the Resequencer pages, and so on). You can override this value on the corresponding page, as needed.

Note: It is highly recommended that you set a time period duration because it has a significant impact on the performance of multiple Oracle Enterprise Manager Fusion Middleware Control pages and queries.

Some of the more data intensive pages do not initially preload the data for performance reasons. You must explicitly request to view the data by clicking a search or refresh button. If you have not specified a different time period, the query executes using the default duration setting.

The default value is 24 hours. The value is set in the Default Query Duration section on the SOA Infrastructure Common Properties page.

To change this value:

a. To the right of the Default Query Duration field, click the icon.

b. Click Change Default Query Duration. The SOA Infrastructure Common Properties page is displayed.

c. From the Default Query Duration list, change the time period, and click Apply.

For more information about setting this property, see Configuring the Audit Trail_ Payload Validation_ and Default Query Duration.

Work Manager Group

Displays the work manager group for the partition. This section is displayed only on the Dashboard page of the individual partition.

Work manager groups isolate partition configuration and request processing. A work manager is an Oracle WebLogic Server entity that represents a logical thread pool. It is similar to a queue in which work items line up for processing.

For more information, see Managing Work Manager Groups.

Auto Purge

Displays whether Oracle SOA Suite is enabled to automatically remove older flow instances, adapter reports, and fault alerts data from the database. By default, this option is enabled for Oracle SOA Suite production installations.

To change this value:

a. To the right of the Auto Purge field, click the icon.

b. Click Set Up Auto Purge. The Auto Purge page is displayed.

c. Based on the requirements for your environment, select or deselect the Enable checkbox.

Note: The Auto Purge element is not displayed if you are using the Java database included with the Oracle SOA Suite Quick Start installation option.

For more information about automatically removing data from the database, see Deleting Large Numbers of Instances with .

EDN Paused

This message is only displayed when the delivery of business events has stopped. This occurs in the following scenarios:

- The edn System MBean Browser property is set to true.

- When patches are applied, the EDN is automatically placed into paused mode. If the patch fails, EDN remains in paused mode.

For more information about setting this property, see Tuning EDN Event Bus and Delivery.

4.1.2 Viewing the Overall Runtime Health of the SOA Infrastructure

The SOA Runtime Health section enables you to view the overall health of the SOA Infrastructure in a cluster or a single-node environment and whether the migration of 11g to 12c data has completed. This section is only displayed on the Dashboard page of the SOA Infrastructure.

To view the overall runtime health of the SOA Infrastructure:

1. View the following details in the SOA Runtime Health section.

a. If the SOA Infrastructure for each node is running and all composites are successfully loaded, the following message is displayed.

b. If the data sources are stopped, not targeted to the SOA server, or not working (for example due to a connection timeout), the following message is displayed.

c. If the Oracle Web Services Manager (OWSM) policy manager is not running, the following message is displayed.

2. Perform the following monitoring and management tasks from this section.

Element

Description

Data Migration

Displays the 11g to 12c data upgrade status. The following message links can be displayed.

- Data Migration Not Completed
Click this message link to invoke a message that displays the following details.The migration status of active instances (completed or not completed).The migration status of inactive instances (completed, older than date and not yet migrated, or not completed).

- Data Migration Completed
Click the alert icon next to this message link to invoke a message indicating that all data available before the upgrade is now available and you can run the report migration script to view specific details.

To close this message, click the close icon to the upper right of the message. This invokes a confirmation message in which to select not to display the migration completion message again.

To run the report migration script, see Section "Using the Upgrade Administration Scripts" of Upgrading Oracle SOA Suite and Business Process Management.

For information about migration status, see Section "Monitoring Upgrade Status with Fusion Middleware Control" of Upgrading Oracle SOA Suite and Business Process Management.

soa-infra (server_name)

Displays the overall status of all nodes in a clustered or single-node environment. Click the server name to go to the home page of the managed server. If the SOA Infrastructure for each node is running and all composites are successfully loaded, the following message is displayed.

Initialized Successfully

There are several issues that can impact the overall health of the SOA Infrastructure runtime environment:

- If the data sources are stopped or not working (for example, due to a connection timeout), the following message is displayed:

Data Sources unavailable: number

The following data sources are monitored:

- EDNDataSource

- EDNLocalTxDataSource

- SOADataSource

- opss-data-source

- mds-SOA

Expand the warning message to display the impacted data source type (for example, EDNDataSource). You can click the data source to access the JDBC Data Sources (Monitoring) page.

- The SOA Infrastructure Java Transaction API (JTA) application is running, but not all SOA composite applications are loaded. A warning message indicating that the SOA Infrastructure is down and currently initializing is displayed. The SOA Infrastructure may not be completely initialized to administer incoming requests until all deployed composites are loaded. Therefore, the response metrics that are displayed on some Oracle Enterprise Manager Fusion Middleware Control pages may not reflect their actual status. This is most apparent when the SOA Infrastructure is in a cluster with multiple managed servers and a large number of deployed composites. During the initialization stage, Oracle Enterprise Manager Fusion Middleware Control does not prevent you from executing operations such as composite deployment, composite undeployment, and others, even though these operations may not complete successfully. Do not perform operations such as composite deployment, composite undeployment, and others while this message is displayed. Once initialization completes, the message is no longer displayed. You see this after you refresh the page. You can then perform operations.

- If the OWSM policy manager is not running, the following message is displayed:

Policy Manager validation failed

- Expand the message and click Navigate to WSM Diagnostics.

- In the System MBean Browser, click Operations.

- Click checkPolicyManagerStatus.

- Click Invoke.

4.1.3 Viewing System Backlogs in the SOA Infrastructure

The System Backlogs section enables you to view the number of messages in the queues. You must click the Refresh Backlogs button to retrieve the message queue backlog counts. This section is only displayed on the Dashboard page of the SOA Infrastructure.

To view system backlogs in the SOA Infrastructure:

1. View the following details in the System Backlogs section.

2. Perform the following monitoring and management tasks from this section.

Element

Description

Messages in Queues

Displays the number of messages in the queues for the following message types. The number of messages currently in the queue for these message types is not loaded by default.

- BPEL Invoke

- BPEL Callback

- Mediator Parallel Routing

- EDN WLS JMS

Refresh Backlogs

Click to refresh the display of the number of messages in the queues.

4.1.4 Viewing Business Transaction Faults

The Business Transaction Faults section enables you to set the specified time period during which to retrieve nonrecoverable faults, faults requiring recovery, recovered faults, and automatically retried system faults at the SOA Infrastructure or individual partition level. The default value is 24 hours.

To view business transaction faults:

1. View the following details in the Business Transaction Faults section.

- On the SOA Infrastructure Dashboard page (for all partitions):

- On the individual partition Dashboard page (for all composites in the partition):

2. Perform the following monitoring and management tasks from this section.

Element

Description

Last Time_Period

Specify the time period during which to check for faults.

Refresh icon

Click to refresh the page to display the total number of nonrecoverable faults, faults requiring recovery, recovered faults, automatically retried system faults in each partition of the SOA Infrastructure or individual partition, and the inactive resequencer groups count.

Click a specific graph of a partition to access fault details on the Error Hospital page. When you access the Error Hospital page, the following is displayed:

- At the SOA Infrastructure level, the specific partition name is automatically populated in the Partition Name list of the Composite filter in the Report Filters section.

- At the individual partition level, the specific SOA composite application is automatically populated in the Composites field of the Composite filter in the Report Filters section.

- At the SOA Infrastructure and individual partition levels, the number of inactive (faulted and timed out) resequencer groups is displayed. Click the Inactive Resequencing Group link to access the Mediator Resequencing Groups page.

4.1.5 Viewing SOA Composite Applications and Adapters Availability

The Composites and Adapters Availability section enables you to view the composites that did not start, adapters with connectivity errors, and scheduled downtimes for the composite and adapter endpoints. This section is displayed in both clustered and single-node environments.

To view SOA composite applications and adapters availability:

1. View the following details in the Composites and Adapters Availability section. On the SOA Infrastructure Dashboard page, the availability of all composites and adapters in the SOA Infrastructure are displayed. On the individual partition Dashboard page, the availability of all composites and adapters within only that partition are displayed.

2. If you have composite startup errors, expand the message to display the SOA composite application name and time of the error.

3. If you have EIS connectivity errors, expand the message and place your cursor over the error timestamp to display fault details.

4. Perform the following monitoring and management tasks from this section.

Element

Description

Select the SOA Infrastructure in a clustered or single-node environment for which to obtain the following composite and adapter availability details. For a clustered environment, all managed servers are displayed in the list.

- Composite start-up error status.

- EIS connectivity errors status: Errors are displayed when the connection between the endpoint and EIS is down (for example, for the database adapter when the database is down and for the file adapter when the file does not exist at a specified location or the file is not readable or writable). These errors are applicable for adapter service binding component endpoints, and not for reference binding component endpoints.

- Composite downtime status (up or down): Downtime status typically refers to scheduled downtimes and is more planned than the first two statuses in this list.

When an error occurs, a warning sign and the number of errors are displayed next to the section.

a. Expand the section to display the list of composites or adapter endpoints that have problems.

b. Click the error description for more specific details about the error.

c. Click the name of a composite or adapter to go to its home page.

4.1.6 Searching for Instances and Bulk Recovery Jobs

The Search section enables you to search for recent instances and bulk recovery jobs. The Bulk Recovery Jobs search option is not displayed if Oracle Enterprise Scheduler is not deployed.

For the Trace Instance, Bulk Recovery, and SOA Diagnostic job to work with remote agent, you must use SSH credentials as host credentials.

To search for instances and bulk recovery jobs:

1. View the following details in the Search section.

a. Click Instances to view preseeded and custom instance search filters.

b. Click Bulk Recovery Jobs to view preseeded job search filters.

2. Perform the following monitoring and management tasks from this section.

Element

Description

Instances

Select to search for recent instances. This search returns instances created within the time period specified by the Default Query Duration property in the SOA Infrastructure Common Properties page. The default time period for which to search is 24 hours.

a. Click one of the links in the list of predefined search queries and saved search queries to initiate a search.
With Faults: This search returns recent instances that have faults.

All: This search returns all instances created in the default time period.

Saved Searches: Displays the saved searches available for execution. If you create a saved search on the Flow Instances page or Error Hospital page and specify this partition name, the search is displayed in this list.

Or:

a. Enter values for any of the following elements and click Search Instances.
Composite

Instance Name or ID

Sensor Name

Sensor Value

You are redirected to the Flow Instances page with the search results.

Bulk Recovery Jobs

Select to search for recent bulk recovery jobs. This search displays only if Oracle Enterprise Scheduler is deployed, and returns the jobs created within the time period specified by the Default Query Duration property on the SOA Infrastructure Common Properties page. (More search options are provided in the Oracle Enterprise Scheduler page.)

a. Click one of the links in the list of predefined search queries. You are redirected to the Oracle Enterprise Scheduler page where the search results are displayed.
Error

Pending

All

Or:

a. In the Job Request ID, enter a value to find a specific bulk recovery job by its job ID, and click Check Job Status. This field is displayed if Oracle Enterprise Scheduler is deployed.

You are redirected to the Oracle Enterprise Scheduler job page for viewing the status of the job.

For more information about the job request ID, see Performing Bulk Fault Recoveries and Terminations in a Single Operation.

For more information about using Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control, see Administering Oracle Enterprise Scheduler.

4.1.7 Viewing Error Notification Alerts

The Fault Alerts section enables you to view error notification alerts for the SOA Infrastructure and individual partitions if you have the correct permissions. If there are no errors in the system, then this section is visible with the message No Alerts found in place of a list of fault alerts.

To view error notification alerts:

Alerts are triggered when a rule condition is met (for example, you define an alert to trigger if more than 10 faults occur within a 48 hour period). Error alerts are displayed if the Send Alert to Dashboard option is selected on the Create Error Notification Rules page. You create error notification rules on the Create Error Notification Rules page to be sent when specific fault criteria are met.

1. View the following details in the Fault Alerts section.

- On the SOA Infrastructure Dashboard page:

- On the individual partition Dashboard page (all fields are disabled and the partition name is displayed):

2. Perform the following monitoring and management tasks from this section.

Element

Description

Rules

Select to view error notification alerts for the following:

- All: Click to display all alerts.

- System: Click to display alerts created at the SOA Infrastructure level.

- Partition. Click and select the partition for which to view alerts.

Click the fault number to access error details on the Error Hospital page.

Alert_Name

Displays the following details:

- Name of the alert.
Click the alert name to view the error notification rule that triggers this alert.

- Number of faults associated with the alert.
Click the fault number to go to the Error Hospital page to view details about the faults. The Time part of the Report Filters section on the right side is automatically selected to show you when the fault alert initially occurred and last occurred.

- Time at which the alert was triggered.

Note: If you do not select Send Alert to Dashboard on the Create Error Notification Rule page, alerts are not displayed on the Dashboard page.

For more information, see Creating Error Notification Rules.

4.2 Discovering the Oracle SOA Suite Routing Topology

The Topology Viewer is useful for when you are tasked to administer an existing Oracle SOA Suite environment. The Topology Viewer quickly provides you with a graphical representation of the deployed resources (servers, databases and data sources, SOA composite applications, and so on) and their relationships.

The Topology Viewer shows the routing relationships across components and elements. The Topology Viewer enables you to discover your Oracle Enterprise Manager Fusion Middleware Control environment and identify how requests are routed across components.

For example, you can use the Topology Viewer to understand the following:

- Which databases your SOA servers rely on

- Which data sources are used to connect to these databases

- Which entities such as SOA servers are up and down

- Performance metrics for components, such as the request processing time for the administration server.

To discover the Oracle SOA Suite routing topology:

1. From the WebLogic Domain menu, select Routing Topology.

The Topology Viewer is displayed. The Topology Viewer shows the routing relationships between Oracle Fusion Middleware components (administration server, managed servers, clusters, and databases).

2. Expand the handles on the left sides of the icons to display additional details. For example, if you expand soa-infra, you can view the partitions in the SOA Infrastructure.

3. Expand a partition to display the SOA composite applications deployed to that partitions.

4. From the View By list, select Application. This displays the routing relationships between the applications. The configured Oracle Metadata Services (MDS) repositories are also displayed.

5. Above the Topology Viewer, click the Up arrow to display targets whose status is running.

6. From the Options icon, select Annotations and an option to display details such as the state of various entities, which servers are down, and key performance metrics for the components.

7. Right-click a component (such as soa-infra) to invoke a menu for performing operations. For example, select Home to access the Dashboard page of the application.

8. Click a line between components to view the JDBC routing relationship, such as the host, port, and database being used.

9. Place the cursor over the edge of one of the entities (for example, the AdminServer) to invoke a small icon.

10. Select the icon to display details about server type, host name, and port.

11. Click more for additional details.

For more information about the Topology Viewer, see Section "Viewing the Routing Topology" of Administering Oracle Fusion Middleware.

4.3 Monitoring SOA Infrastructure Performance Summary Metrics

You can view a summary of SOA Infrastructure performance metrics on the Performance Summary page.

The Performance Summary page provides a graphical representation of the following information by default:

- Total number of messages in the SOA Infrastructure since the last server restart.

- Total number of service component messages (BPEL process, Oracle Mediator, human workflow, and business rule (decision service)) since the last server restart.

To monitor SOA Infrastructure performance summary metrics:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Monitoring > Performance Summary

a. Right-click soa-infra.

b. Select Monitoring > Performance Summary.

The Performance Summary page is displayed.

2. At the bottom of the page, view additional message information.

3. Click Show Metric Palette to display a hierarchical tree of all metrics for the SOA Infrastructure. The tree organizes the metrics into various categories of performance data.

4. Expand a folder and select a metric in the Metric Palette to display a performance chart that shows the changes in the metric value over time. The chart refreshes automatically to show updated data.

5. Click Slider to display a slider tool that lets you specify the time frame for the data shown in the charts.

For more information about the Performance Summary page, see the online Help for the Performance Summary page and Section "Viewing the Performance of Oracle Fusion Middleware" of Administering Oracle Fusion Middleware.

For information about monitoring message delivery processing requests, see Monitoring Message Delivery Processing Requests.

For information about monitoring SOA composite application summary metrics, see Monitoring SOA Composite Application Performance Summary Metrics.

For information about monitoring service engine statistics, see the following:

- Monitoring BPEL Process Service Engine Request and Thread Performance Statistics.

- Monitoring Request Breakdown Statistics.

- Monitoring Business Rules Service Engine Performance Statistics.

- Monitoring Human Workflow Service Engine Active Requests and Operation Performance Statistics.

- Monitoring BPMN Process Service Engine Performance Statistics.

4.4 Monitoring Message Delivery Processing Requests

You can monitor SOA Infrastructure message delivery processing requests. These are metrics for the message delivery between the service engines, service infrastructure, and binding components. Once a message is handed over to a service engine, the amount of time it takes to process that message (instance processing time) is not captured in these metrics.

To monitor message delivery processing requests:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Monitoring > Request Processing.

a. Right-click soa-infra.

b. Select Monitoring > Request Processing.

The Request Processing page enables you to monitor the following details:

- The average request processing time for both synchronous and asynchronous messages, active requests, requests processed, and faulted requests in the service engines and service infrastructure.

- The average request processing time, requests processed, and errors occurring in service (inbound) and reference (outbound) binding components.

2. In the Service Engines section, click a specific service engine (for example, BPEL Engine) to access details such as recent instances using this service engine, components using this service engine, and recent fault occurrences.

For more information, see the following sections:

- Introduction to Binding Components.

- Introduction to Service Engines

- Introduction to the Service Infrastructure

4.5 Monitoring Service and Reference Binding Components in the SOA Infrastructure

You can monitor all service and reference binding components used in all SOA composite applications deployed to the SOA Infrastructure. Services provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. References enable messages to be sent from the SOA composite application to external services in the outside world.

To monitor service and reference binding components in the SOA Infrastructure:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Services and References.

a. Right-click soa-infra.

b. Select Services and References.

The Services page displays details about the names and types of the services, the SOA composite applications in which the services are used, the partitions in which the SOA composite applications are deployed, the total number of messages processed, the average processing time, and the number of faults occurring in the services.

2. In the Service column, click a specific service to access its home page.

3. In the Composite column, click a specific SOA composite application to access its home page.

4. In the Partitions column, click a specific partition to access its home page.

5. Click the References tab.
The References page displays details about the names and types of the references, the SOA composite applications in which the references are used, the partitions in which the SOA composite applications are deployed, the total number of messages processed, the average processing time, and the number of faults occurring in the references.

6. In the Reference column, click a specific reference to access its home page.

7. In the Composite column, click a specific SOA composite application to access its home page.

8. In the Partitions column, click a specific partition to access its home page.

For more information about services and references, Introduction to Binding Components

4.6 Using SOA Health Check

The SOA Health Check framework provides a number of health checks and health check categories to monitor the health of your system. Checks include memory checks, data source checks, SOA-related service checks, SOA application-targeting checks, BPEL-related checks, and so on.

Startup checks execute automatically at server startup, and periodic checks can be scheduled to run at periodic intervals. You can also execute individual health checks or health check categories using WLST.

This section includes the following topics:

- SOA Health Checks

- SOA Health Check Categories

- Invoking SOA Health Checks

4.6.1 SOA Health Checks

SOA health checks include memory checks, data source checks, SOA-related service checks, SOA application-targeting checks, BPEL-related checks, and so on.

Table 4-2 summarizes the SOA health checks that are available in this release.

Table 4-2 SOA Health Checks

Health Check Name

Description

BPELAsyncRequestCheck

Checks if the BPEL asynchronous request count is within the configured threshold of 1000.

BPELComponentInstanceCheck

Checks if the number of open BPEL component instances are within the threshold of 1000. Also checks if the number of faulted BPEL component instances are within the threshold of 500.

DatasourceCheck

Checks if the data sources are appropriately targeted for use by the soa-infra application.

For each data source, the check verifies if the targets of the data source cover all targets of the soa-infra application. If any of the soa-infra application targets is missing from any of the data source targets, an error is raised.

DBStatsCheck

Checks if the MDS database statistics are current.

EDNMessageCheck

Checks if the pending messages count in the EDN event queue and OAOO queue are within thresholds. The threshold limit used for the EDN event queue is 2000 and the threshold limit used for the OAOO queue is 5000.

JDBCPoolsCheck

Checks if the SOA, EDN, and MDS data sources are healthy at runtime.

SOAAppCheck

Verifies targeting of SOA applications. SOA applications should at least target all of the soa-infra application targets.

SOALibraryCheck

Verifies the targeting of SOA, and related, libraries. SOA libraries should at least target all of the soa-infra application targets.

ServiceCheck

Verify if SOA-related services are functional. Currently, this check verifies if the OWSM Policy Manager service is functional.

MemoryCheck

Checks if the available (free) heap memory is above the configured threshold of 25%.

A health check ends with one of the following states:

- Success: The check completed, and passed.

- Error: The check completed, but did not pass.

- Warning: The check completed and passed, but something may need user attention.

- Failure: The check could not be completed/executed.

- Skipped: The check is not applicable for the environment.

- Disabled: The check is disabled and cannot be run.

4.6.2 SOA Health Check Categories

The SOA health check framework logically groups health checks into health check categories. A health check can be part of more than one category.

When you execute a health check category, using the WLST command for example, all health checks in the category automatically get executed. Certain health check categories are automatically executed. For example, the Startup category, if enabled, runs all the startup health checks at server startup.

Table 4-3 summarizes the SOA health check categories and their constituent health checks.

Table 4-3 SOA Health Check Categories

Health Check Category

Description

Default Health Checks included in the Category

Startup

Runs at server startup

DatasourceCheck, JDBCPoolsCheck, SOAAppCheck, SOALibraryCheck, ServiceCheck, MemoryCheck

Quick

Lightweight set of checks

JDBCPoolsCheck, ServiceCheck, MemoryCheck

Intermediate

Intermediate set of checks

BPELAsyncRequestCheck, BPELComponentInstanceCheck, DBStatsCheck, EDNMessageCheck

Extensive

Extensive set of checks

For future use

Config

Configuration checks

DatasourceCheck, SOAAppCheck, SOALibraryCheck

4.6.3 Invoking SOA Health Checks

The SOA health checks can be invoked in a number of ways. You can have checks that run automatically at server startup or those that run at periodic intervals. You can use the WLST command-line utility to manually run health checks.

Server Startup

When a production SOA server starts, health checks in the Startup category are automatically run. The startup health check is enabled by default. The result of the startup run is logged in the SOA server logs.

You can choose to disable the startup run using WLST commands. You can also change the category of tests run at startup using the appropriate WLST command. See "enableHCStartupRun" and "setHCStartupRunCategory" in Oracle Fusion Middleware WLST Command Reference for SOA Suite.

Periodic Invocation

SOA health check is pre-configured with periodic runs that automatically run on the production SOA server.Table 4-4 lists the pre-configured periodic runs.

Table 4-4 Pre-Configured Periodic Runs

Periodic Run Name

Category

Scheduling

Enabled by Default?

Frequently

Quick

Every two hours at :07

Yes

Daily

Intermediate

Every day at 05:15

Yes

Weekly

Extensive

Every Sunday at 03:30

No (for future use)

Periodic runs are enabled by default. The result of the periodic runs are logged in the SOA server logs.

You can disable periodic runs, or change the health-check category associated with a periodic run. You can also change the scheduling, or add new periodic runs. See "createHCPeriodicRun", "enableHCPeriodicRun", "setHCPeriodicRunInterval", "setHCPeriodicRunSchedule", and "setHCPeriodicRunCategory" in Oracle Fusion Middleware WLST Command Reference for SOA Suite.

WLST Invocation

You can use WLST commands to:

- List health checks

- Configure health checks

- List health check categories

- Execute a health check by name

- Execute a category of health checks

- Get results (Returned as an HTML report at the specified location)

- Purge results

See "SOA Health Check Commands" in Oracle Fusion Middleware WLST Command Reference for SOA Suite for details on all health check commands.

The WLST commands need to be executed in the online mode. You must be connected to the SOA server.

4.7 Monitoring and Troubleshooting SOA-Wide Issues Using IWS Reports

Integration Workload Statistics (IWS) Reports provide SOA system-wide reports that can help you analyze utilizations, identify potential bottlenecks and backlogs, and perform top-down analysis of your integration system.

Note:
This SOA Suite feature is part of Oracle Integration Continuous Availability. Please refer to the Oracle Fusion Middleware Licensing Information for more details on Oracle SOA Suite for Middleware Options.

So, for instance, if there are stressed components or endpoints in your SOA system that are slowing down the system, IWS reports can help you narrow down on these. For example, a slow FTP or database adapter reference endpoint can be identified in the reports. Likewise, a BPEL process running slower than usual can also be identified. You can look at internal queue backlogs, like BPEL queues and EDN queues. SOA composite-wise summaries are also available.

IWS reports can include metrics like system resource usage, composite statistics, statistics for internal system queues, statistics for synchronous and asynchronous business processes, and endpoint statistics. The components supported in this release include BPEL Service Engine, EDN, Web Service Binding, File Adapter, JMS Adapter, FTP Adapter, DB Adapter, AQ Adapter, and MQ adapter.

Refer to Statistics Included in an IWS Report for more information on the statistics collected.

IWS takes periodic snapshots of performance statistics to generate these reports. You can choose the granularity of data collected for your IWS reports. The following table illustrates the data collection levels, or statistics levels, and the data collected for each level.

Table 4-5 Data Collection Levels for IWS Reports

Data Collection Level/Statistics Level

Data Collected

OFF

No data is collected. This is the default level.

MINIMUM

System-wide resource usage data.

BASIC

MINIMUM + Service and reference endpoint statistics, BPEL and EDN backup queue statistics, BPEL instance statistics.

NORMAL

BASIC + Data on BPEL activities like Receive, Invoke, Pick, and onMessage.

FINEST

NORMAL + Data on all BPEL activities.

4.7.1 Enabling and Configuring IWS

Integration Workload Statistics (IWS) snapshot data is collected at periodic intervals. You can enable snapshot data collection, configure snapshot interval, and the granularity of data collected.

Use the following steps to enable and configure IWS using Enterprise Manager Fusion Middleware Control:

1. Select Monitoring > IWS Reports from the SOA Infrastructure menu.
The IWS Reports page appears.

2. Click Configure near the top right corner of the page.
The Configure IWS Data Collection dialog appears.

3. Select a Snapshot Interval in minutes.
The snapshot interval is the periodic interval at which data snapshots are collected.

4. Select a Data Collection Level. The level selected determines the metrics that are collected.
The default level is OFF, which in effect disables IWS data collection. Use the Minimum level to collect only system-wide resource usage data. The Basic level additionally includes service and reference endpoint statistics, BPEL and EDN backup queue statistics, and BPEL instance statistics. If you choose Normal, it includes additional statistics on BPEL activities like Receive, Invoke, Pick, and onMessage. The Finest level additionally includes data on all BPEL activities.

5. Click OK to save your configuration changes.

You have now configured the IWS data collection settings.

4.7.2 Generating an IWS Report

Use the IWS Reports page to create SOA-wide reports that help you identify bottlenecks and backlogs in the system. Integration Workload Statistics (IWS) include metrics like system resource usage, composite statistics, statistics for internal system queues, statistics for synchronous and asynchronous business processes, and endpoint statistics.

Use the following steps to create an IWS report in Enterprise Manager Fusion Middleware Control:

You must have already configured IWS data collection and set a snapshot interval. See Enabling and Configuring IWS for more information.

1. Select Monitoring > IWS Reports from the SOA Infrastructure menu.
The IWS Reports page appears.

2. Select the period for which you wish to generate a report. Select timestamps for Start Date and End Date.
Ensure that the time period does not span server restarts, or periods where you have disabled IWS by setting Data Collection Level to OFF.

3. Select the SOA Server Name.
You can either accept the default server, or choose a different node in cases of multi-cluster environments. For clusters, you can also choose the cluster name to generate a consolidated report for all nodes in the cluster.

(Optional) Enter the result of the step here.

4. Optionally choose a partition name if you are using composite partitions and wish to limit your report to a particular partition.
The Select Composites field appears. This option enables you to select from all composites in the selected partition.

5. Under Select Composites, optionally choose one or more composite names to restrict your report to the specified composite applications.

6. Optionally change the number of results that are displayed.
So, if you choose the default of 10, the 10 slowest endpoints, the 10 longest running business processes, and so on, are selected.

7. Click the appropriate report format near the top right of the window to generate and download the report.
You can choose between CSV (comma-separated values), HTML, and XML formats.

The IWS report is generated and downloaded.

4.7.2.1 About the IWSReport MBean

You can use the IWSReport MBean, and its associated operations, to retrieve information about the data collected for your Integration Workload Statistics (IWS) reports. Data such as snapshot IDs, date, and timestamps can be retrieved. IWS report operations enable you to generate IWS reports using the supplied snapshot parameters.

Select Administration > System MBean Browser from the SOA Infrastructure menu to access the System MBean Browser. Refer to for more information on the System MBean Browser.

You can search for the IWSReport MBean, which can be found under Application Defined MBeans > oracle.as.soa.iws > Server : name > Application : name > SOAIWSReportMXBean.

The following image shows the various operations, and their descriptions, available for the IWSReport MBean.

4.7.2.2 WLST Commands to Generate IWS Reports

You can use WLST commands to generate IWS reports or retrieve IWS metrics like IWS data collection level or IWS snapshot information.

IWS WLST Commands

You can retrieve detailed help, and list of parameters, for any command by typing help(‘command’) while connected to the SOA server in the WLST online mode.

The following table lists the various WLST IWS configuration commands.

Table 4-6 IWS Configuration Commands

WLST Command Name

Description

getSoaIWSSnapshotInterval

Retrieves the snapshot metrics collection interval.

setSoaIWSSnapshotInterval

Sets the snapshot metrics collection interval in minutes.

getSoaIWSStatisticsLevel

Retrieves the SOA IWS Statistics level (data collection level).

setSoaIWSStatisticsLevel

Sets the SOA IWS Statistics level.

getSoaIWSStatisticsLevelList

Retrieves the SOA IWS Statistics level list.

The following table lists the various WLST IWS snapshot retrieval and reporting commands.

Table 4-7 IWS Snapshot Retrieval and Reporting Commands

WLST Command Name

Description

getSoaIWSSnapshotInfo

Retrieves snapshot info from a SOA server or all servers for the supplied number of hours.

getSoaIWSSnapshotInfoByDate

Retrieves snapshot info from a SOA server or all servers for the supplied time period.

getSoaIWSReportBySnapshotID

Generates a SOA IWS Report for the supplied snapshot IDs.

getSoaIWSReportByDateTime

Generates a SOA IWS Report for the supplied time period.

4.7.3 Statistics Included in an IWS Report

An Integration Workload Statistics (IWS) report contains various statistics, depending on the data collection level that you have set. In addition to system-wide resource usage data, the report can include service and reference endpoint statistics, BPEL and EDN backup queue statistics, and BPEL instance statistics. Statistics on BPEL activities may also be included.

The IWS report contains the following broad sections when the data collection level is set to finest:

- System Resource Usage
Statistics include Java Virtual Machine (JVM) statistics like CPU utilization and memory utilization (for JVM heap and non-heap memory), SOA Data Source statistics that show active connections and connection pool details, and SOA Work Manager statistics that include details on threads.

- Composite (Rollup) Statistics
Aggregate composite-wise statistics that indicate flow rate (throughput/transactions per second) and latency (in milliseconds) for the composite endpoints and internal backup queues (EDN and BPEL queue).

- Slowest Composite Endpoints
Aggregate composite-wise statistics that indicate the latency (in milliseconds) and flow rate (throughput) for the slowest endpoints.

- Backups in Internal Queues
Aggregate statistics for the backups in internal system queues (BPEL queue and EDN queue).

- Longest Running Business Processes
Aggregate statistics for top asynchronous and synchronous business (BPEL) process instances based on execution time

- Most Time-Consuming Business Process Activities
Aggregate statistics for top business process activities (BPEL activities like Receive, Invoke, etc) based on execution time.

5 Tracking Business Flow Instances

This chapter describes how to track the status of business flow instances, including specifying and saving business flow search criteria, deleting and terminating instances, viewing the current state of an instance, recovering and aborting faults in an instance, viewing composite sensor values in an instance, viewing the initiating and participating composites in an instance, viewing resequencing groups in an instance, and viewing business flows that extend across domains.

This chapter includes the following section:

- Tracking Business Flow Instances at the SOA Infrastructure or Partition Level

For more information about business flow instances and differences between instances in Release 12c and Release 11g, see Introduction to Business Flow Instances.

For information about managing faults on the Error Hospital page, see Recovering From Faults in the Error Hospital.

5.1 Tracking Business Flow Instances at the SOA Infrastructure or Partition Level

You can track the instances of business flows from the Flow Instances page of the SOA Infrastructure, individual partition, or individual SOA composite application. A business flow instance corresponds to an end-to-end business transaction. Business flows consist of a single SOA composite application or multiple SOA composite applications connected together to fulfill a specific business process.

Tracking business flow instances enables you to identify the following:

- Determine what happened to a specific request

- Has the request been received?

- Has request processing completed or is it still in progress?

- If processing has finished, has it completed successfully or did errors occur?

- If processing is still in progress, is it stuck on an external request, awaiting a scheduled recovery, or in need of any administrative action?

- Analyze and resolve a large number of failures
For example, a runtime failure of a back end service (such as a database) has occurred. In high volume systems, a very large number of faults can occur in a short duration because of a single cause. These faults may be spread across SOA composite applications.You can identify the following under these circumstances:

- Determine the root cause of the failure (typically done by analyzing one or two individual instances).

- Find the number of requests with the same root cause of failure across different SOA composite applications.

- Apply a bulk recovery/termination action to all instances with the same root cause of failure and recovery status (for example, a BPEL recovery or EDN recovery).

- Specify a batch size.

- Optionally perform a quick purge to remove the faults that have been handled or abort faults so that the next batch can be addressed.

You can manage business flow instances from the Flow Instances and Error Hospital pages at the following levels:

- SOA Infrastructure level (provides access to all partitions)

- Individual partition level

Note:

You can also manage business flow instances from the Flow Instances page of an individual SOA composite application. Flows that are initiated by a particular composite or passing through a composite are listed at the composite level. There are separate filter criteria for each. There is no Error Hospital page at the individual SOA composite application level. For information, see Tracking Business Flow Instances at the SOA Composite Application Level.

You can configure your environment to provide some administrators with access to the top level SOA Infrastructure Flow Instances and Error Hospital pages and other administrators with access to only the individual partition's Flow Instances and Error Hospital pages. For more information, see Managing Partitions and Work Manager Groups.

Access the Flow Instances page through one of the following options:

To access business flow instances in all partitions:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

1. Select Home > Flow Instances.

1. Expand the SOA folder.

2. Click soa-infra.

3. Click the Flow Instances tab.

1. Select SOA Infrastructure.

2. Click the Flow Instances tab.

To access business flow instances in an individual partition:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

1. Select Manage Partitions.

2. In the SOA Partitions column, click a specific partition.

3. Click the Flow Instances tab.

1. Expand SOA > soa-infra.

2. Click a specific partition.

3. Click the Flow Instances tab.

To access business flow instances for an individual SOA composite application, see Tracking Business Flow Instances at the SOA Composite Application Level.

The Flow Instances page displays the following details:

- A utility for specifying and saving comprehensive instance and fault search criteria and clicking Search.

Note:

When you initially access the Flow Instances page, the Search Results table is empty. You must click Search to populate this table with business flow instance details.

- A Search Results table that displays the flow ID that uniquely identifies a business flow, the composite initiating the business flow (business flows can span multiple composites), the state of the flow instance (for example, completed successfully, running, failed, recovery required, and so on), the instance start time, the last update to the instance, the partition in which this flow was initiated, the flow instance name (if set during design time in a BPEL process or Oracle Mediator service component), and a link to the log files. To display additional columns in the table, select View > Columns.

- An Error Hospital button above the Search Results table that takes you to the Error Hospital page for a view of the results of the search criteria you executed on the Flow Instances page. This action does not require you to select any rows in the Search Results table. Use this option to view the error report for the flow instances currently displayed in the Flow Instances page. In the Error Hospital page, you can view aggregated fault statistics for these instances. You can also perform bulk recover and bulk abort operations on these flow instances without having to access each individual instance.

Note:

- Business flow instances and faults data is delimited by the time period for which instances and faults are retrieved. The current delimiter is displayed to the right of the Search Results table title. The default value is 24 hours. You can change this value with the Default Query Duration property on the SOA Infrastructure Common Properties page. For information, see Configuring the Audit Trail_ Payload Validation_ and Default Query Duration.

- When you undeploy and redeploy the same SOA composite application, you cannot retrieve the business flow instances created prior to composite undeployment. The business flows are still available. However, the active instances are aborted or they are untouched based on your configuration while redeploying. For more information, see Redeploying SOA Composite Applications.

You can perform the following business flow instance tasks:

- Specifying and Saving Business Flow Search Criteria

- Deleting or Terminating Business Flow Instances

- Viewing the Current State of the Business Flow Instance

- Recovering from Faults in a Business Flow Instance

- Viewing Composite Sensor Values in a Business Flow Instance

- Viewing the Initiating and Participating SOA Composite Applications in a Business Flow Instance

- Viewing Resequencing Groups in a Business Flow Instance

- Viewing Business Flows that Extend Across Domains

5.1.1 Specifying and Saving Business Flow Search Criteria

The Search Options section enables you to specify and save comprehensive instance and fault search criteria. Search criteria results are displayed in the Search Results table. Saved search criteria are user-specific, and are not common across users. Each Oracle Enterprise Manager Fusion Middleware Control user can save their own preferred searches. Upon creation, saved searches are displayed on the Dashboard page and also as links on the Error Hospital and Flow Instances pages.

To specify and save business flow search criteria:

1. Click the Search Options icon to display the Search Options section. The Search Options section displays in a sliding panel and may not be visible on the page at all times.

The Search Options section is displayed.

2. See the following sections to specify and save comprehensive instance and fault search criteria.

- Executing Predefined Business Flow Instance Searches

- Using the Search Options Toolbar

- Adding and Removing Search Filters

- Configuring and Saving Business Flow Instance Search Filter Criteria

5.1.1.1 Executing Predefined Business Flow Instance Searches

You can quickly find business flows without entering any search criteria by selecting a predefined search option. Results are displayed in the Search Results table. The searches are constrained by a predefined time period. The default time period is 24 hours. This value can be changed by modifying the Default Query Duration property in the SOA Infrastructure Common Properties page, accessible under SOA Administration in the SOA Infrastructure menu.

The following options are available:

- Recent Instances: Displays recent instances.

- Instances With Faults: Displays recent instances that have faults. This predefined search option is also available on the Error Hospital page, where you can select it from the Report Filters list.

- Recoverable Instances: Displays recent instances awaiting recovery.

At the top of the Search Options section, select the option for which to search.

or:

The search results are displayed in the Search Results table (for this example, the search results for the Recoverable Instances option are displayed).

For more information about executing predefined searches, select Help > Help for This Page from the weblogic main menu on the Flow Instances page.

For information about saved searches, see Using the Search Options Toolbar.

5.1.1.2 Using the Search Options Toolbar

The Search Options toolbar enables you to perform search-related tasks, such as executing predefined or custom searches, saving search criteria, resetting displayed search criteria, bookmarking searches, and adding and removing filters. By default, only predefined searches can be invoked. You can extend the list of available searches by saving custom searches. The Search Options toolbar displays in a sliding panel and may not be visible on the page at all times. If not already open, you can invoke it by clicking the large Search Options icon.

Go the toolbar in the Search Options section.

The following options are available.

Element

Description

Click to reset the search fields in the currently invoked saved search to the last saved values. This is useful when you have modified a saved search and want to restart the query building process.

Click to save your current search criteria. This saves both the selected search fields and their values, enabling you to run the identical search at a later time and view a fresh set of results.

You must provide a name when saving a search. You cannot overwrite an existing saved search, but you can save it with a different name. You can delete the saved searches you created. To manage your saved searches, select All Saved Searches from the Search Options list.

Click to bookmark your current search criteria. A message is displayed with a URL containing the search parameters. Copy the URL to a browser bookmark window, email, or chat. The generated URL includes information about both the selected search fields and their values. This enables you to run the identical search at a later time and view a fresh set of results.

For more information about the Search Options toolbar, select Help > Help for This Page from the weblogic main menu on the Flow Instances page.

5.1.1.3 Adding and Removing Search Filters

You can add and remove the search filters that are displayed for configuration. Filters are the attributes of a business flow that you can use to create your search criteria. After selecting a filter, you can customize it in the Search Options section. All filters with specified search criteria are added together (treated as logical AND values) when the resulting query is run. Empty fields are ignored.

1. Click Add/Remove Filters.

The filters available for selection are displayed. Some filters are interdependent. When you remove them, your current search parameters may be reset. The time filter is required and cannot be removed.

2. Select and deselect appropriate filters to use in search criteria, and click OK.

3. Click Search.

The selected criteria are displayed in the Search Options section. You can further customize the selected filters, as described in Configuring and Saving Business Flow Instance Search Filter Criteria.

5.1.1.4 Configuring and Saving Business Flow Instance Search Filter Criteria

You can configure parameters for each search filter selected in Adding and Removing Search Filters to create a business flow instances search query. Search results are displayed in the Search Results table.

1. Go to the Search Options section.

2. Configure parameters for appropriate search filters. Filters left blank are ignored. You do not need to remove them. For more information about configuring each filter, select Help > Help for This Page from the weblogic main menu on the Flow Instances page.

Element

Description

Time

Restrict your search query to a specific time in the past. A time filter is required to search for business flows. At least one time filter is required. If more than one time filter list is displayed, ensure that you specify values for both. Click Options to display the filters available for selection. Once selected, you can specify the time periods to be searched.

- Instance Created (displays by default and cannot be deselected)

- Instance Updated

- Fault Occurred

You can also specify a custom time period for which to search by selecting the Custom time period checkbox. This search is for all three time periods (Instance Created, Instance Updated and Fault Occurred).

Composite

Restrict your search query for business flows to a specific composite.

- If searching at the partition level, only instances that were initiated and participated in by SOA composite applications in that partition are returned.

- If searching at the SOA Infrastructure level, instances initiated or participated in by SOA composite application in any partition are returned.

Perform the following tasks:

- Select Initiating if you want to limit your search only to the business flows that started in the selected composite. To search for all business flows in that composite, select Participating.

- Select the partition to search. If you access the Flow Instances page at the individual partition level, that partition is already selected and you cannot change it. If you do not select a partition, all are searched.

- Select the specific SOA composite application name from the list or click Search to specify a complete or partial name for which to search. The partial name search supports only entering the beginning part of the name and is case sensitive. If you do not specify a composite, all are searched.

Resequencer

Select the resequencing groups for which to search. Use this filter to limit your search only to business flows in which a resequenced component participated. If you leave this section blank, this search filter is ignored. The resequencer in Oracle Mediator rearranges a stream of related but out-of-sequence messages into a sequential order.

- Any Group: Select to search for all resequenced flows in all groups.

- Specific Group: Select to find the business flow associated with a specific resequencing group. Specify the group's name and location. The location is the Oracle Mediator component and SOA composite application revision containing the group. The group name filter returns only one group instance.

For more information about resequencing groups, see Monitoring Resequencing Groups.

Flow Instance

To find a specific business flow instance, identify the instance in at least one of the following ways:

- Flow ID: Select to search by flow ID, initiating ECID, or correlation flow ID.

- Instance Name: Specify the name or title of the flow instance that you created at design time in Oracle JDeveloper.

- Composite Instance Name: Specify the name or title of the composite instance name. SOA composite applications upgraded from Release 11g can contain a composite instance name or title.

- Add Sensor Value (Up to 6): Click to specify up to six composite sensor name and value pairs.

Note: You can populate the Sensor Name fields by either manually entering names or by using the lookup feature. If you use the lookup feature, you must specify a composite for each sensor you add in the search. All sensor-based search conditions are connected with a logical AND. However, if you specify multiple sensors from different composites, you likely end up with an empty results table. As a best practice, stick with sensors from the same composite because they are more likely to have matching values in the same flow instance.

Note these additional sensor guidelines:

- All sensor conditions are connected with a logical AND. You cannot enter alternative sensor names. The search attempts to find an instance that matches all the names.

- When manually entering names, you must provide the exact sensor name and value.

- You must specify both the name and value for each sensor.

- Leaving the Value field empty is not supported (no results are returned). It is not possible to use the search to find all instances in which a sensor is defined, regardless of the value.

- If you want to use operators other than equals (=), use the lookup feature.

- If you know the exact sensor name, but not the composite, use the main search, which attempts to find instances across all composites. However, if you want to see a list of sensors from which to select, use the lookup feature. You also must know the composite name, because the lookup feature makes you specify the composite first (it is looking for sensors one composite at a time). Also, all composites are listed: those with sensors defined for them and those without. Trying every composite is not efficient.

State

Restrict your search to only the business flows in a given state. For descriptions of states, see Viewing the Current State of the Business Flow Instance.

Select Active to search active instances. Active instances have not reached one of the terminal states. The list is refreshed to display the following selections for further filtering:

- All active

- Recovery

- Suspended

- Running

Select Inactive to search inactive instances. Inactive instances have reached one of the terminal states. The list is refreshed to display the following selections for further filtering:

- All inactive

- Completed

- Failed

- Aborted

Fault

Restrict the search for business flows to only those with faults. If you leave this field blank, this filter is ignored. Select to specify the types of faults for which to search.

- All Faults: Select to search for business flows containing any type of fault.

- Recovery Required: Select to search for stuck flows awaiting human recovery to proceed. To further specify a particular type of recovery, use the Fault Recovery Type filter.

- Nonrecoverable: Select to search for flows containing nonrecoverable faults.

- Recovered: Select to search for flows that contain at least one recovered fault.

- System Auto Retries: Select to find the faulted flows in which system automatic retries occurred.

To further customize fault filtering, click More next to the Faults filter to display additional filtering attributes.

- Fault Recovery Type: Filter your search for faulted business flows to stuck flows awaiting a particular type of recovery action. This field is available when you select Recovery Required in the Fault filter and click More. If you leave this field blank, the Fault Recovery Type filter is ignored. The fault recovery types are as follows:
Admin Recovery

BPEL Activity Recovery

BPEL Invoke Message Recovery

BPEL Callback Message Recovery

EDN Recovery

Mediator Recovery

Human Workflow Recovery

Rejected Message Recovery

- Fault Type: Filter your search for faulted business flows. If you leave this field blank, the Fault Type filter is ignored. Select one of the following to restrict your search to only the flows containing that fault type.
System: Network errors or other types of errors such as a database server or a web service being unreachable.

Business: Application-specific faults that are generated when there is a problem with the information being processed (for example, a social security number is not found in the database).

OWSM: Errors on Oracle Web Service Manager (OWSM) policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

- Fault Owner: Select the specific component, service, or reference in which the fault was handled (also known as the fault owner). Use this filter to further narrow down your search for faulted business flows. If you leave it blank, the Fault Owner filter is ignored. The fault owner is similar to the fault location, but they are not always the same. The fault owner is the component that executes the recovery or from where to attempt a recovery, in which case the flow is re-executed. The fault location is the component that created or caused the fault.

- Fault Details: Filter a search for faulted business flows. If you leave all fields blank, the Fault Details filter is ignored. Specify at least one of the following fault details. To find only faults for which these values are not set, enter NOT SPECIFIED in the search field.
Error Message Contains: Use to find only faulted business flows with the same error message text. You can enter any part of the message. This search is case sensitive.

Fault Name: Use to find only faulted business flows with a specific descriptive fault name such as NegativeCredit. You must enter the exact name (the entire string). This search is case sensitive.

Fault Code: Use to find only faulted business flows with the same fault code.

To customize fault search criteria, click More next to Fault Details to display additional configuration fields such as HTTP host, JNDI name, event name, and event namespace.

User

Finds all instances associated with a specific Oracle Enterprise Manager user or business owner. The user is set only in SOA composite applications in which user credentials are explicitly propagated (for example, when a composite has a user authentication OWSM policy attached to the composite web service).

3. If you want to save search criteria for future use, click the Save Search icon to specify a name.

Your saved search is then available for selection in the Search Options dropdown list and in the Report Filters section of the Error Hospital page.

4. When search criteria creation is complete, click Search.

5. View search results in the Search Results table.

6. Click Error Hospital to display aggregated fault details in the search results, including the fault name, total number of faults, faults requiring recovery, unrecoverable faults, recovered faults, and automatic fault retries. No selections are necessary, as this aggregates the fault information for all flow instances that are already displayed in the table.

For more information about the Error Hospital, see Managing Faults in the Error Hospital.

5.1.2 Deleting or Terminating Business Flow Instances

You can delete or abort business flow instances in the Search Results table.

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.

The Search Results table is populated with business flow instances.

2. Select a specific business flow or select multiple business flows by pressing Shift-Click.

3. Click the Actions list and select to delete or abort a business flow instance. You can also click the Deleted Selected or Abort Selected icons above the table.

- Delete Selected: Deletes selected business flow instances in the table. When you select to confirm the deletion of instances, the page is refreshed and the deleted instances are removed from the list. You can no longer access the flow trace details of the instance once it is deleted.

- Abort Selected: Terminates selected business flow instances in the table. When you confirm to abort the selected instances, the page is refreshed and the states of the aborted instances are displayed as Aborted. In some cases there may be a delay in updating the instances state. You still can access the flow trace and audit trail details of the instance after it has been aborted.
To abort a large number of instances based on search criteria without selecting each one individually, do not use the Abort Selected action on the Flow Instances page. Instead, use the Bulk Abort option on the Error Hospital page.

Note:

If you selected a running instance, the Abort option is available for stopping a running instance.

5.1.3 Viewing the Current State of the Business Flow Instance

You can view the components that comprise the business flow instance. Business flows can consist of multiple SOA composite applications connected together in a flow.

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.

The Search Results table is populated with business flow instances.

2. In the Flow State column of the Search Results table, view the state of a specific business flow instance.

The business flow instance can exist in one of the following states:

State

Description

Running

The instance is still running (for example, it may be stopped in a human workflow service component awaiting an approval). There are no recoverable faults associated with this state and the instance has not yet successfully completed.

Recovery

A fault in the instance is awaiting recovery. See Recovering from Faults in a Business Flow Instance.

Suspended

The instance is currently suspended. This is related to the migration of one version of the composite to another. This is applicable to Oracle BPM Suite components.

Aborted

The instance has been explicitly terminated by a user. When a composite is undeployed, running instances are marked aborted. Upon redeployment, you are given a choice to abort or keep running.

Completed

The instance successfully completed and there are no recoverable and nonrecoverable faults.

Failed

The instance completed, but there are nonrecoverable faults.

3. In the Flow ID column, click a specific flow ID number to access more specific details about the state of the business flow instance.

The Flow Trace page is displayed and shows the path taken by the flow (entry points, components executed, and exit points). The flow trace is available only if the Audit Level property is set to Production or Development. If the audit level is set to Off, the trace view is replaced by a component instance listing. You can recover from faults using the Faults tab on the Flow Trace page.

4. In the Trace table, click a specific service component to view the audit trail and process flow. You can also view XML of the flow trace by selecting the Actions list.

See the following sections for specific details:

- Monitoring the Flow Trace of a Business Flow Instance.

- Viewing the Audit Trail and Process Flow of a BPMN Process Service Component.

Note:

If you invoke an Oracle SOA Suite Release 12c direct binding service from Oracle Service Bus Release 11g (releases 11.1.1.4 through 11.1.1.7), no entry is displayed in the Trace table of the Flow Trace page in Oracle Enterprise Manager Fusion Middleware Control Release 12c that shows the direct binding service getting invoked from Oracle Service Bus. The display of this type of invocation is not supported.

In Oracle SOA Suite Release 12c, direct binding service invocation from Oracle Service Bus Release 12c is displayed in the Trace table of the Flow Trace page in Oracle Enterprise Manager Fusion Middleware Control.

A direct binding service is also displayed in a flow with Oracle Enterprise Scheduler or Oracle Service Bus at the start or middle of the flow.

5.1.4 Recovering from Faults in a Business Flow Instance

You can recover from faults identified as recoverable in the selected business flow.

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.
The Search Results table is populated with business flow instances.

2. In the Search Results table, identify instances with faults labeled as Recovery in the Flow State column. Faults in this state are awaiting recovery.

3. Select the business flow instance, and click Show Details.
The Faults tab is displayed below the Search Results table. This tab displays the error message, the fault owner (the service component, service binding component, or reference binding component in which the fault was handled), the composite in which the fault occurred, the time of the fault, if the fault is recoverable, and links to the fault logs. To display additional columns, select View > Columns. Select Reset Columns to remove all customizations such reordering columns and showing and hiding columns on the Faults table.

4. In the Error Message column, place your cursor over the error message to display the entire error message or click the red fault icon to display a popup dialog from which to copy the message. You can also place your cursor over the link or icon in the Recovery column to see what type of recovery is required.

5. Select a method for performing fault recovery. Either method enables you to automatically perform a recovery or perform a recovery through human intervention. This human intervention action is defined with the ora-human-intervention action in the fault-policies.xml file that you designed in Oracle JDeveloper.

To Perform Fault Recovery From...

Go To Step...

The Recover list above the table

6

The Recovery Required message in the Recovery column

7

6. Select the row in the table on which to perform fault recovery.

a. From the Recover list above the table, select a fault recovery action to perform. The Retry and Abort options are available for all recoverable faults. The Continue, Rethrow, and Replay options depend upon the contents of the fault policy file attached to the SOA composite application.

The Fault Details and Recovery Options dialog is displayed.

b. Go to Step 8.

7. In the Recovery column, click the Recovery Required message.

A dialog describing the fault is displayed.

a. Click Retry or Abort to automatically retry or abort the fault or click More Recovery Options to perform human intervention.
If automatic recovery is successful, the flow in the Search Results table of the Flow Instances page is refreshed to display a different flow state (for example, recovery is changed to completed). In some cases, there may be a delay in getting the updated state and consequently the display does not show the changed state. However, in all cases, a confirmation message is displayed that indicates that the recovery request was sent. Perform an explicit page level refresh either on the button at the fault level or the Refresh button at the page level.

If you clicked More Recovery Options, the Fault Details and Recovery Options dialog is displayed.

b. Go to Step 8.

8. In the Recovery Options section of the Fault Details and Recovery Options dialog, view the options for performing fault recovery. Other recovery types such as BPEL message recovery show different sets of options. Any type of fault can be recovered from this console, such as fault policy-triggered recovery and BPEL invoke, callback, and activity message recovery. As with Release 11g, you can also browse to the BPEL process service engine Recovery tab and perform invoke, callback, and activity recovery.

9. From the Recovery Action list, select an action to perform.

Action

Description

Action is Available for...

Abort

Terminates the entire instance.

BPEL process and Oracle Mediator

Retry

Retries the instance directly. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.

BPEL process and Oracle Mediator

Continue

Ignores the fault and continues processing (marks the faulted activity as a success).

BPEL process

Rethrow

Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.

BPEL process

Replay

Replays the entire scope again in which the fault occurred.

BPEL process

10. From the Variable list, select a variable. The content of this variable is displayed in the Value field. For this example, the variable crInput is selected. This variable is used in an invoke activity and contains an incorrect social security number value.

11. Enter the correct value in the Value field. For this example, the social security number is edited to begin with 1.

12. Click Recover.

For information about designing a fault policy, see Section "Handling Faults with the Fault Management Framework" of Developing SOA Applications with Oracle SOA Suite.

5.1.5 Viewing Composite Sensor Values in a Business Flow Instance

The Composite Sensor Values tab displays the values of composite sensors detected in the selected business flow. Composite sensors provide a method for implementing trackable fields on messages. Composite sensors may be included in the service and reference binding components of the SOA composite application associated with the flow. This tab only has data displayed if the sensors are defined for the composite and the values captured by the selected business flow are not null.

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.

The Search Results table is populated with business flow instances.

2. In the Search Results table, select a specific business flow instance, and click Show Details.

3. Click the Composite Sensor Values tab.

This tab displays composite sensor names and their values included in this flow.

For more information about composite sensors, see Chapter "Defining Composite Sensors" of Developing SOA Applications with Oracle SOA Suite.

5.1.6 Viewing the Initiating and Participating SOA Composite Applications in a Business Flow Instance

You can view all the SOA composite applications participating in a business flow instance. This tab displays a list of the composites that are associated with this flow, their sequence in the flow (the composite that initiated the business flow and all subsequent composites that participated in the business flow), the time at which a flow entered the specific composite, and links to logs.

To view the initiating and participating composites in a business flow instance:

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.

2. In the Search Results table, select a specific business flow instance, and click Show Details.

3. Click the Composites tab.

The initiating and participating SOA composite applications included in this business flow instance are displayed. The Name column shows the value of the flow instance title (In Release 11g, you specified the title or name for each composite instance). In Release 12c, this value is displayed under the Name column.

5.1.7 Viewing Resequencing Groups in a Business Flow Instance

The Resequencing Groups tab is only displayed if a resequenced component participated in the flow. Such a flow instance is indicated by a small triple-arrow icon. The resequencer in Oracle Mediator rearranges a stream of related but out-of-sequence messages into a sequential order. The groups are ordered by the last processing time (most recent first). Alternatively, you can reorder them by the group name or state.

You cannot select the rows in the table or perform any actions under the Resequencing Groups tab on the Flow Instances page.

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.

2. In the Search Results table, select a specific business flow instance that includes a resequencing group, and click Show Details.

3. Click the Resequencing Groups tab.

The group name, group location, group state, and last processed time are displayed.

4. In the Group column, click the name to display group details.

If a resequencing group has faults, you can view the faults associated with a resequenced flow instance by clicking the Faults tab. Recoverable faults can be recovered from the Faults tab.

5. Click All Resequencing Groups to access the Mediator Resequencing Groups page to view details about all defined groups, such as the group name, the Oracle Mediator and SOA composite application in which the group is included, the group state (for example, timed out or faulted), the last processing time, and the total number of backlogged messages.

For more information, see Monitoring Resequencing Groups.

5.1.8 Viewing Business Flows that Extend Across Domains

A flow correlation ID is a GUID value that uniquely identifies a business flow that extends across domains. The flow correlation ID differs from the flow ID, which uniquely identifies a business flow within an Oracle SOA Suite domain. A business flow that crosses two Oracle SOA Suite domains has a single flow correlation ID and two flow IDs. Similarly, a business flow that originates outside of Oracle SOA Suite cannot create a flow ID because it does not have access to the Oracle SOA Suite schema. However, it can create a flow correlation ID.

To view business flows that extend across domains:

1. Specify search criteria in the Search Options section as described in Configuring and Saving Business Flow Instance Search Filter Criteria, and click Search.

2. In the Search Results table, select Columns > Correlation Flow ID from the View main menu.

Any flow correlation IDs are displayed in the table.

When a SOA composite application submits an Oracle Enterprise Scheduler request, the flow correlation ID, and not the flow ID, is propagated to Oracle Enterprise Scheduler and displayed in the Submission FlowID field of the Execution Status section of the Request Details page. The Oracle Enterprise Scheduler submitter flow ID associated with a request corresponds to the Dynamic Monitoring Service (DMS) flow ID. The DMS Flow ID corresponds to the SOA flow correlation ID.

5.1.9 Partition-Level and Composite-Level Search Results for Redeployed Composites with the Same Revision Number

A partition-specific search shows all versions of a SOA composite application (even those that were redeployed with the same revision number), whereas a composite-specific search shows only the versions of the current deployment. Because the revision numbers do not change, it is not possible to determine which row in the Search Results table of the Flow Instances page belongs to which version. This can be confusing when it appears in the partition-level search, but not in the composite-level search. To prevent this situation, increment the revision number between deployments. This makes multiple deployments more evident.

For example, assume you perform the following steps:

1. Deploy composite A and create several instances. Both a composite-specific search and a partition-specific search show these instances.

2. Redeploy and overwrite composite A and create instances. The composite-specific search shows instances from the first revision in addition to the latest version. A partition-specific search shows instances from the first revision in addition to the latest version.

3. Undeploy and redeploy composite A and create instances. The composite-specific search only shows instances from the latest version. The partition-specific search shows all instances from the first and second versions in addition to the existing version.

6 Recovering From Faults in the Error Hospital

This chapter describes how to recover from faults in the error hospital, including specifying and saving fault search criteria, viewing aggregated fault statistics, performing bulk fault recoveries and bulk fault terminations in a single operation, accessing recoverable faults to perform a single fault recovery, and creating error notification rules that trigger the sending of alert messages when specific fault criteria are met.

This chapter includes the following sections:

- Managing Faults in the Error Hospital

- Creating Error Notification Rules

For information about tracking the status of business flow instances, see Tracking Business Flow Instances .

6.1 Managing Faults in the Error Hospital

You can manage all faults occurring within Oracle SOA Suite and view aggregated statistics associated with faults data on the Error Hospital page.

The Error Hospital page provides the following benefits:

- A single location for managing and recovering from all aggregated faults occurring within Oracle SOA Suite (including rejected message recovery and BPEL message recovery). Regardless of the service engine or binding component in which the fault occurred, you manage faults from the Error Hospital page at the following levels:

- At the SOA Infrastructure level, where all system-wide faults data is aggregated for each business flow instance.

- At the individual partition level, where only faults data for the business flow instances associated with that specific partition is aggregated.

- Error notification rules configuration for triggering an alert when specific fault criteria are met. For example, you define a rule to trigger an alert if more than 10 errors occur in a 48 hour period.

- Fault filtering and searching capabilities, and the ability to aggregate fault statistics by name, code, type, owner, and other grouping criteria.

- Bulk fault recovery and termination capabilities.

- Details of flow instances associated with the aggregated faults for examining fault trends.

To manage faults in the error hospital:

Access this page through one of the following options:

To access faults in all partitions:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

1. Select Home > Error Hospital.

1. Expand SOA > soa-infra.

2. Click soa-infra (server_name).

3. Click the Error Hospital tab.

1. Select SOA Infrastructure.

2. Click the Error Hospital tab.

To access faults in an individual partition:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

1. Select Manage Partitions.

2. In the SOA Partition column, select a specific partition.

3. Click the Error Hospital tab.

1. Expand SOA > soa-infra (server_name).

2. Select a specific partition.

3. Click the Error Hospital tab.

The Error Hospital page displays the following details:

- A utility for specifying and saving comprehensive fault search criteria and clicking Search.

Note:

When you initially access the Error Hospital page, the Fault Statistics table is empty. You must click Search to populate this table with fault details.

- A Fault Statistics table that provides the fault name, total number of faults, faults requiring recovery, unrecoverable faults, recovered faults, and automatic fault retries. Click a number to search for flow instances associated with the aggregated faults (this takes you to the Flow Instances page). To display a different fault attribute in the first column of the table (such as fault name, code, type, owner, and other grouping criteria), select the Group By list. To display additional columns in the table, select View > Columns.

- Bulk Recovery and Bulk Abort buttons above the Fault Statistics table for performing bulk actions (recovery or abort) on a selected group of similar faults in a single operation.

Note:

- When you click a faults link or similar links elsewhere in Oracle Enterprise Manager Fusion Middleware Control, you are taken to the Error Hospital page with the fault report data already displayed. For example, when you click the Error Hospital button above the Search Results table in which business flow instances are displayed on the Flow Instances page, you see the aggregated fault statistics reported for those flow instances. In addition, when you click a specific fault state in the graph in the Business Transaction Faults section of the Dashboard page, you are taken to the Error Hospital page with the fault report data of the selected state already displayed.

- Report data is delimited by the time period for which instances and faults are retrieved. The current delimiter is displayed to the right of the Fault Statistics table title. The default value is 24 hours. You can change this value with the Default Query Duration property on the SOA Infrastructure Common Properties page. For information, see Configuring the Audit Trail_ Payload Validation_ and Default Query Duration.

You can perform the following fault management tasks:

- Specifying and Saving Fault Search Criteria

- Viewing Aggregated Fault Statistics to Examine Fault Trends

- Performing Bulk Fault Recoveries and Terminations in a Single Operation

- Accessing Faults in the Fault Statistics Table to Perform Single Fault Recovery Operations

6.1.1 Specifying and Saving Fault Search Criteria

The Report Filters section enables you to specify and save comprehensive fault search criteria. Search results are displayed in the Fault Statistics table.

To specify and save fault search criteria:

1. Click the Search icon to display the Report Filters section. The Report Filters section displays in a sliding panel and may not be visible in the page at all times.

The Report Filters section is displayed.

2. See the following sections to specify and save comprehensive fault search criteria.

- Executing Predefined Fault Instance and Custom Searches

- Using the Report Filters Toolbar

- Configuring and Saving Fault Search Filter Criteria

6.1.1.1 Executing Predefined Fault Instance and Custom Searches

You can quickly find faults without entering any search criteria by selecting a predefined search option. Results are displayed in the Fault Statistics table. The searches are constrained by a predefined time period. The default time period is 24 hours. This value can be changed by modifying the Default Query Duration property in the SOA Infrastructure Common Properties page, accessible under SOA Administration in the SOA Infrastructure menu.

The following options are available:

- Instances With Faults: Displays recent instances that have faults. This predefined search option is also available on the Flow Instances page, where you can select it from the Search Options list or click the Instances With Faults link.

- All Saved Searches: Displays custom searches you have created and saved. Saved searches are also displayed in the Search region of the Dashboard page.

To execute predefined or custom fault instance searches:

At the top of the Search Options section, select the option for which to search.

The search results are displayed in the Fault Statistics table.

For more information about predefined fault instance searches, select Help > Help for This Page from the weblogic main menu on the Error Hospital page.

For information about saved searches, see Using the Report Filters Toolbar.

6.1.1.2 Using the Report Filters Toolbar

The Report Filters toolbar enables you to perform search-related tasks, such as resetting displayed fault search filter criteria, saving fault search filter criteria, and bookmarking searches. By default, only predefined searches can be invoked. You can extend the list of available searches by saving custom searches. The Report Filters toolbar displays in a sliding panel and may not be visible in the page at all times. If not already open, you can invoke it by clicking the large Search Options icon.

To use the Report Filters toolbar.

Go the toolbar in the Report Filters section.

The following options are available.

Element

Description

Click to reset the search fields in the currently invoked saved search to the last saved values. This is useful when you have modified a saved search and want to restart the query building process.

Click to save your current search criteria. This saves both the selected search fields and their values, enabling you to run the identical search at a later time and view a fresh set of results. Searches are saved per user, and not globally. For example, user A cannot log in to Oracle Enterprise Manager Fusion Middleware Control and access the saved search criteria of user B.

You must provide a name when saving a search. You cannot overwrite an existing saved search, but you can save it with a different name. You can delete the saved searches you created. To manage your saved searches, select All Saved Searches from the Report Filters list.

Click to bookmark your current search criteria. A message is displayed with a URL containing the search parameters. Copy the URL to a browser bookmark window, email, or chat. The generated URL includes information about both the selected search fields and their values. This enables you to run the identical search at a later time and view a fresh set of results.

For more information about the Report Filters toolbar, select Help > Help for This Page from the weblogic main menu on the Error Hospital page.

6.1.1.3 Configuring and Saving Fault Search Filter Criteria

You can configure parameters for each search filter to create a fault search query. Search results are displayed in the Fault Statistics table.

To configure and save fault search filter criteria:

1. Go to the Report Filters section.

2. Specify search criteria. If you want to further customize fault search criteria, click More next to the Fault filter to display additional configuration fields such as fault owner, recovery type, fault type, and fault details (error message contents, fault name, fault code, HTTP host, and JNDI name).

3. Configure parameters for appropriate search filters. Filters left blank are ignored. You do not need to remove them. For more information about configuring each filter, select Help > Help for This Page from the weblogic main menu on the Error Hospital page.

Element

Description

Time

Use this filter to restrict your query to a specific time in the past. A time filter is required to search for faults. Ensure that you select values from both lists. For example, select 2 and Weeks to restrict your query to the last two weeks.

Click Options to display the filters available for selection. Once selected, you can specify the time period to search.

- Instance Created (displays by default and cannot be deselected)

- Instance Updated

- Fault Occurred (displays by default, but you can deselect it)

You can also specify a custom time period for which to search by selecting the Custom time period checkbox.

Composite

Restrict your search query for faults to a specific composite.

- If searching at the partition level, only faults that were initiated and participated in by SOA composite applications in that partition are returned.

- If searching at the SOA Infrastructure level, faults initiated or participated in by SOA composite applications in any partition are returned.

Perform the following tasks:

- Select Initiating if you want to limit your search only to the faults that started in the selected composite. To search for all faults in that composite, select Participating.

- Select the partition to search. If you access the Error Hospital page at the individual partition level, that partition is already selected and you cannot change it. If you do not select a partition at the SOA Infrastructure level, all are searched.

- Select the specific SOA composite application name from the list or click Search to specify a complete or partial name for which to search. The partial name search supports only entering the beginning part of the name and is case sensitive. If you do not specify a composite, all are searched.

Resequencer

Select the resequencing groups for which to search. Use this filter to limit your search only to business flows in which a resequenced component participated. If you leave this section blank, this search filter is ignored. The resequencer in Oracle Mediator rearranges a stream of related but out-of-sequence messages into a sequential order.

- Any Group: Select to search for faults in all resequenced flows in all groups.

- Specific Group: Select to find faults associated with a specific resequencing group. Specify the group's name and location. The location is the Oracle Mediator service component and SOA composite application revision containing the group. The group name filter returns only one group instance.

For more information about resequencing, see "Resequencing in Oracle Mediator" of Developing SOA Applications with Oracle SOA Suite and Monitoring Resequencing Groups.

State

Select Active to search active instances. Active instances have not reached one of the terminal states. The list is refreshed to display the following selections for further filtering:

- All active: Finds all business flows in nonterminal states.

- Recovery: A business flow with a recoverable fault (recoverable faults, recovered faults, and system automatic retries are all included in this category). Use the Fault filter to further specify a particular type of recovery, such as selecting Recovery Required from the Fault list, clicking More, and selecting an option from the Fault Recovery Type list.

- Suspended: A business flow that is typically related to migration of one version of the SOA composite application to another.

- Running: A business flow is currently running. The flow may include a human task component that is currently awaiting approval.

Select Inactive to search inactive instances. Inactive instances have reached one of the terminal states. The list is refreshed to display the following selections for further filtering:

- All inactive: Finds all terminated business flows.

- Completed: A business flow has completed successfully. There are no faults awaiting recovery.

- Failed: Finds completed business flows with nonrecoverable faults. Use the Fault filter to further filter based on fault type and other fault details. For example, if State is set to Failed, Nonrecoverable or All Faults can be used.

- Aborted: Finds business flows explicitly terminated by the user or for which there was a system error.

If you leave the State field blank, the State filter is ignored.

Fault

Restrict the search for business flows to only those with faults. If you leave this field blank, this filter is ignored. Select to specify the types of faults for which to search.

- All Faults: Select to search for business flows containing any type of fault.

- Recovery Required: Select to search for stuck flows awaiting a human recovery action to proceed. To further specify a particular type of recovery, use the Fault Recovery Type filter.

- Nonrecoverable: Select to search for flows containing nonrecoverable faults. Nonrecoverable faults includes aborted and failed instances.

- Recovered: Select to search for flows that contain at least one recovered fault.

- System Auto Retries: Select to find the faulted flows in which system automatic retries occurred. This applies only to fault policy-configured automatic retries.

To further customize fault filtering, click More next to Faults to display additional filtering attributes.

- Fault Recovery Type: Filter your search for faulted business flows to stuck flows awaiting a particular type of recovery action. This field is available when you select Recovery Required in the Fault filter and click More. If you leave this field blank, the Fault Recovery Type filter is ignored. The fault recovery types are as follows:
Admin Recovery

BPEL Activity Recovery

BPEL Invoke Message Recovery

BPEL Callback Message Recovery

EDN Recovery

Mediator Recovery

Human Workflow Recovery

Rejected Message Recovery

- Fault Type: Filter your search for faulted business flows. If you leave this field blank, the Fault Type filter is ignored. Select one of the following to restrict your search to only the flows containing that fault type:
System: Network errors or errors such as a database server or web service being unreachable.

Business: Application-specific faults that are generated when there is a problem with the information being processed (for example, a social security number is not found in the database).

OWSM: Errors on Oracle Web Service Manager (OWSM) policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

- Fault Owner: Select the specific component, service, or reference in which the fault was handled (also known as the fault owner). Use this filter to further narrow down your search for faulted business flows. If you leave it blank, the Fault Owner filter is ignored. The fault owner is similar to the fault location, but they are not always the same. For more information about this filter, see the online help for the Error Hospital page.

- Fault Details: Filter a search for faulted business flows. If you leave all fields blank, the Fault Details filter is ignored. Specify at least one of the following details about the fault. To find only faults for which these values are not set, enter NOT SPECIFIED in the search field.
Error Message Contains: Use to find only faulted business flows with the same error message text. You can enter any part of the message. This search is case sensitive.

Fault Name: Use to find only faulted business flows with a specific descriptive fault name such as NegativeCredit. You must enter the exact name (the entire string). This search is case sensitive.

Fault Code: Use to find only faulted business flows with the same fault code.

To further customize fault search criteria, click More next to Fault Details to display configuration fields such as HTTP host, JNDI name, event name, and event namespace.

4. If you want to save search criteria for future use, click the Save Search icon to specify a name.

Your saved search is then available for selection in the Report Filters dropdown list and the Search Options section of the Flow Instances page.

5. When search criteria creation is complete, click Search.

View search results in the Fault Statistics table.

6.1.2 Viewing Aggregated Fault Statistics to Examine Fault Trends

The Fault Statistics table displays a report on faults data specified and created in either of the following ways:

- Specified and created in the Report Filters section of the Error Hospital page.

- Specified and created in the Search Options section and displayed in the Search Results table of the Flow Instances page, and then displayed in the Fault Statistics table by clicking the Error Hospital link above the Search Results table.

The data is always aggregated by one of the primary fault attributes selected from the Group By list, such as Fault Name, Fault Code, and so on. The default aggregation is by Fault Name.

The Error Hospital page does not show individual faulted instances. To track individual business flows that have faults, perform one of the following tasks:

- Go to the Flow Instances page and click Instances With Faults.

- Click a fault count in the Fault Statistics table of the Error Hospital page to access details about that fault in the Search Results table of the Flow Instances page.

The Fault Statistics table enables you to examine fault trends (such as for diagnostic purposes). For example, aggregate by Fault Code to see which code has the most faults. You can also perform bulk actions (recovery or abort) on a selected group of similar faults in a single operation.

6.1.2.1 To View Aggregated Fault Statistics to Examine Fault Trends:

1. Specify search criteria in the Report Filters section as described in Specifying and Saving Fault Search Criteria, and click Search.
The Fault Statistics table is populated with details about faults. This represents the total number of faults, faults requiring recovery, unrecoverable faults, recovered faults, and automatic fault retries.

The legend above the Fault Statistics table displays the color symbols used in the columns of the table to identify the state of faults.

State

Description

Nonrecoverable

Displays the total count of nonrecoverable faults. This includes failed and aborted faults.

Clicking the value in the column takes you to the Search Results table on the Flow Instances page and filters the list to show the flow instances associated with nonrecoverable faults. Terminal (fatal) faults cannot be recovered.

Recovery Required

Displays the total count of recoverable faults.

Clicking the value in the column takes you to the Search Results table on the Flow Instances page and filters the list to show the flow instances associated with recoverable faults. These are faults awaiting a human recovery action so that stuck flows can proceed.

Recovered

Displays the total count of recovered faults.

Clicking the value in the column takes you to the Search Results table on the Flow Instances page and filters the list to show flow instances associated with recovered faults. These are recoverable faults on which a recovery action was performed successfully. Processing has resumed in the business flow instance.

System Auto Retries

Displays the total count of faults that are automatically retried by the system.

Clicking the value in the column takes you to the Search Results table on the Flow Instances page and filters the list to show the flow instances associated with these system retried faults.

2. From the Group By list above the Fault Statistics table, select the fault attribute by which to aggregate data. Fault Name is the default aggregation field.

The following options are available:

Element

Description

Fault Name

Aggregates by the fault name. This aggregation option is selected by default.

Fault Code

Aggregates by the fault code.

Fault Type

Aggregates by the fault type:

- System: Network errors or errors such as a database server or web service being unreachable.

- Business: Application-specific faults generated when there is a problem with the information being processed (for example, a social security number is not found in the database).

- OWSM: Errors on OWSM policies attached to SOA composite applications, service components, or binding components. Policies apply security to message delivery.

Composite

Aggregates by the SOA composite application name.

Partition

Aggregates by the partition of the SOA composite application in which the fault occurred.

Fault Owner

Aggregates by the name of the service component, service binding component, or reference binding component that handled the fault. In some cases, this can be both the fault owner and fault location.

Fault Owner Type

Aggregates by the type of service component, service binding component, or reference binding component that handled the fault (for example, if a BPEL process service component owns the fault, BPEL is displayed).

JNDI Name

Aggregates by the JNDI name (for example, eis/FileAdapter).

HTTP Host

Aggregates by the HTTP host on which the fault occurred.

3. If you select Fault Code, each row in the first column represents a specific code and the remaining columns show the fault statistics aggregated for each code. Regardless of your selection, the remaining rows in the table always show the total number of faults; the number of recoverable, nonrecoverable, and currently recovered faults; and the number of automatic retries performed after a fault occurred.

4. If you select Fault Type, each row in the first column represents a specific fault type and the remaining columns show the fault statistics aggregated for each type. As with all selections in the list, you can click the total, recoverable, and recovered numbers that are displayed to access the Flow Instances page for performing fault recovery actions.

5. If you select Composite, each row in the first column represents a specific SOA composite application name and the remaining columns show the fault statistics aggregated for each composite.

6.1.3 Performing Bulk Fault Recoveries and Terminations in a Single Operation

You can perform bulk fault recoveries and bulk fault terminations on any aggregated fault row in the Fault Statistics table that has recoverable faults. Options for performing these actions are displayed above the Fault Statistics table.

To perform bulk fault recoveries and terminations:

1. Specify search criteria in the Report Filters section as described in Specifying and Saving Fault Search Criteria, and click Search.

The Fault Statistics table is populated with details about faults.

2. Select a row in the table in which the Recovery Required column has a value of more than one. Note that you can also recover single instances through this option.

3. Click an appropriate action above the table (for this example, Bulk Recovery is selected). You can also right-click a row to display the same actions.

Element

Description

Bulk Recovery

Select this option to perform a bulk recovery. Only rows with faults identified as recoverable can be recovered in bulk.

Bulk Abort

Select this option to perform a bulk termination. Rows with faults identified as recoverable and rows with faults in the System Auto Retried column can be terminated in bulk.

This attempts a recovery on all recoverable faults associated with that aggregated row. For this example, the selected row includes three faults that require recovery in the Recovery Required column.

4. Click Yes when prompted to continue with the bulk recovery. You can also expand the Schedule Properties and Throttling Properties sections to display recovery details.

Note:

Scheduling and throttling properties are not applicable for non-Oracle Enterprise Scheduler setups. You can only schedule bulk recoveries with Oracle Enterprise Scheduler. Otherwise, this dialog does not include Schedule and Throttling properties, and bulk recovery is attempted immediately. The bulk recovery job status link for non-Oracle Enterprise Scheduler setup takes you to the log viewer page where you can see the logs corresponding to bulk recovery execution.

A message is displayed indicating that recovery is in progress. If Oracle Enterprise Scheduler is deployed, you can click the link in the message to access the Request Details page of Oracle Enterprise Scheduler. If Oracle Enterprise Scheduler is not deployed, clicking the job ID invokes the Log Messages page.

Note the following details about the Oracle Enterprise Scheduler job request number and fault alert message:

- You can search for the job request number by clicking Bulk Recovery Jobs in the Search section of the Dashboard page and specifying the number in the Job Request ID field. Click the ID to go to the Oracle Enterprise Scheduler Job Request page. For more information, see Searching for Instances and Bulk Recovery Jobs.

- When an alert message is triggered, the name is displayed in the Fault Alerts section of the Dashboard page. For more information, see Viewing Error Notification Alerts.

5. Click OK to acknowledge that the bulk recovery job is being handled through an Oracle Enterprise Scheduler job request number.

6. At the top of the Error Hospital page, click the Refresh icon.

If fault recovery was successful, the number of recovered faults that are displayed in the Recovered column of the Fault Statistics table is increased (for this example, by three).

7. In the Recovered column, click the number.

The Flow Instances page is displayed. The business flow instance that previously was displayed as Recovery in the State column is now displayed as Completed in the Search Results table.

8. Select the row that includes the business flow instance in the Search Results table, and click Show Details.

The Faults tab is displayed at the bottom of the Flow Instances page. In the Recovery column, the fault status is displayed as Recovered.

6.1.4 Accessing Faults in the Fault Statistics Table to Perform Single Fault Recovery Operations

The Error Hospital page does not show individual faulted instances. However, you can click a fault count in the Fault Statistics table of the Error Hospital page to access that fault for performing single fault recovery operations in the Search Results table of the Flow Instances page.

To access faults in the Faults Statistics table to perform single fault recovery:

1. Specify search criteria in the Report Filters section as described in Specifying and Saving Fault Search Criteria, and click Search. For example, select Recovery Required in the Fault filter.

The Fault Statistics table is populated with details about faults that require recovery.

2. In the Recovery Required column, click the number of faults requiring recovery for a specific fault name. The number can be a value of more than one. Note that you can also recover single instances through this option.

You are taken to the Search Results table of the Flow Instances page.

The faults requiring recovery are displayed. If you instead clicked the value in a different column (for example, the Total Faults or Recovered column in the Fault Statistics table), results appropriate to that selection are displayed.

3. Select a specific row in the Search Results table, and click Show Details.

The page is refreshed to display the Faults (selected), Sensor Values, Composites, and (if resequencing groups are included in the composite) Resequencing Groups tabs below the Search Results table. Each tab describes specific details about the flow.

4. To perform fault recovery actions from the Faults tab, see Step 4 of Recovering from Faults in a Business Flow Instance.

6.1.5 Understanding Additional Message and Fault Recovery Behavior Scenarios

This section describes additional fault message behavior issues on the Error Hospital page.

6.1.5.1 Recoverable Messages are Displayed as Unrecoverable in the Error Hospital

When message delivery fails on one node (the managed server) of a cluster, undelivered messages are displayed as follows:

- Unrecoverable on the Error Hospital page

- Recoverable on the BPEL process service engine Recovery page

This occurs when BPEL process invoke activities are processing during a server shutdown. These activities may not complete, even if a graceful shutdown occurs. In these cases, the instances are shown as running and unrecoverable on the Error Hospital page because the BPEL process service engine cannot update the business flow state during a server shutdown.

You can manually recover the BPEL invoke activities on the BPEL process service engine Recovery page. Otherwise, they are recovered during automatic recovery.

For more information, see Performing BPEL Process Service Engine Message Recovery.

6.1.5.2 Unrecoverable Binding Component Faults are Displayed as Recoverable

A FabricInvocationException.RetryType.NO_RETRY error returned by a database adapter reference binding component is treated as a binding fault. Even though the fault is nonretriable, the following is displayed:

- There is a recoverable message on the BPEL process service engine Recovery page.

- The flow state is displayed as recoverable because of the message in the BPEL process invoke activity recovery queue.

This is the expected behavior. In 12c (12.1.3), common faults and BPEL process messages are linked together. This means the fault and flow state both indicate that an invoke activity recovery is required.

For more information, see Performing BPEL Process Service Engine Message Recovery.

6.1.5.3 BPEL Process Messages Awaiting Recovery with no Associated Instance Faults Do Not Appear on the Error Hospital Page

If messages are awaiting recovery on the BPEL process service engine Recovery page and there is no associated fault with the instance, this is not shown on the Error Hospital page. This can occur in the following scenarios:

- If a callback message arrives late and the instance has already completed.

- If a race condition occurs when using message aggregation with reenableAggregationOnComplete=true. When messages are sent around the same time, most of them are marked as midprocess receive messages and there are no new instances to pick them up.

For more information about message aggregation, see "Routing Messages to the Same Instance" of Developing SOA Applications with Oracle SOA Suite.

6.2 Creating Error Notification Rules

You can create error notification rules at the SOA Infrastructure or individual partition level that cause an alert message to be triggered when specific fault criteria are met. For example, you can create a rule that sends an alert if more than 10 errors occur in a 48 hour period. You can configure the alert to be sent to the Fault Alerts section of the Dashboard page described in Viewing Error Notification Alerts. and also to a delivery channel such as an email address.

Note:

To create error notification rules, Oracle Enterprise Scheduler must be deployed to the SOA Infrastructure. If Oracle Enterprise Scheduler is not deployed, you cannot access this page.

The error notification rules provide the following benefits:

- An aggregated notification of faults occurring in the system.

- A scheduled-based notification system with a configurable reoccurrence interval. For example, send an alert every 24 hours if rule criteria are met.

- Rule-configured faults and notification channel specifications. When a fault policy is triggered, an email is sent.

You can create fault notification rules at the following levels:

- SOA Infrastructure (for system-wide alerts)

- Individual partition level (for alerts specific to that partition)

The following roles are required for creating, updating, and deleting rules:

- partition_nameApplicationOperator: This role is partition-specific. A user in this partition-specific role has the permissions to manage alerts for that partition.

- MiddlewareOperator

- MiddlewareAdministrator

- SOAAdmin

- SOAOperator

For more information, see Securing Access to Partitions.

Note the following details about the display of rules in Oracle Enterprise Manager Fusion Middleware Control:

- Rules created at the SOA Infrastructure (system-wide) level are not displayed in the Error Notification Rules page at the individual partition level.

- Rules created at the individual partition level are not displayed in the Error Notification Rules page at the SOA Infrastructure (system-wide) level.

The Fault Alerts section of the SOA Infrastructure Dashboard page shows all system-wide alerts, including all partitions.

6.2.1 To create error notification rules:

1. To receive an alert notification when an error occurs, you must specify the address of the user and the delivery channel to use (email, IM, or SMS). Those tasks are performed on different pages in Oracle Enterprise Manager Fusion Middleware Control,

For This Delivery Channel...

Perform These Tasks...

Email

a. Configure the email addresses on the Workflow Notification Properties page.
See Configuring Human Workflow Notification Properties.

b. When complete, click Go to the Messaging Driver page on the Workflow Notification Properties page.

c. Configure the email driver on the User Messaging Service page.
See Section "Configuring the Email Driver" of Administering Oracle User Messaging Service.

SMS

a. Configure the Short Message Peer-to-Peer (SMPP) driver on the User Messaging Service page.
See Section "Configuring the SMPP Driver" of Administering Oracle User Messaging Service.

IM

a. Configure the Extensible Messaging and Presence Protocol (XMPP) on the User Messaging Service page.
See Section "Configuring the XMPP Driver" of Administering Oracle User Messaging Service.

2. Create an alert at the appropriate level:
To create error notification rules at the SOA Infrastructure level:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Error Notification Rules.

a. Expand SOA.

b. Right-click soa-infra (server_name).

c. Select Error Notification Rules.

To create error notification rules at the individual partition level:

From the SOA Partition Menu of a Specific Partition...

From the SOA Folder in the Navigator...

a. Select Error Notification Rules.

a. Right-click a specific partition.

b. Select Error Notification Rules.

The Error Notification Rules page displays the following details:

- An Error Notification Rules table for viewing existing rules and details about each rule. Select one or more rules to manage.

- Links for creating a new rule, creating a new rule from an existing rule, editing a rule, deleting a rule, disabling a rule, and searching for a rule. For more information, click the weblogic icon and select Help > Help for This Page on the Error Notification Rules page.

3. Create a new rule in either of the following ways:

a. Click Create to create a new rule.

or

a. Click Create Like to create a new rule from a selected rule.

4. Enter the following information.

Element

Description

Name

Enter a name for the rule. Once the new rule is saved, the name cannot be changed. This name is also used for alerts that display on the Dashboard page or which are sent to the notification recipients through a channel such email, SMS, or instant messaging (IM).

Description

Enter a description for the rule. This description is visible only to administrators. An end user receiving fault notification alerts or viewing alerts on the Dashboard page cannot see this description.

Schedule Names

Select a predefined schedule. This indicates how often to trigger the scheduler (for example, invoke the scheduler every two minutes). When you select a schedule, the page is refreshed to display the Schedule Description and Frequency fields.

You define the schedule names in the Create Schedule page of Oracle Enterprise Manager Fusion Middleware Control.

a. In the Navigator, expand Scheduling Services > ESSAPP or right-click soa-infra (server_name) and select Define Schedules.

b. From the Scheduling Service menu, select Job Requests > Define Schedules.
The schedules available for selection in the Schedule Names list are displayed.

c. Click Create to create additional schedules and their execution frequency.
Note: While defining a schedule name, ensure that you specify the schedule package name of /oracle/apps/ess/custom/soa. Otherwise, the schedule is created, but is not accessible on the Create or Edit Error Notification Rule page.

For more information about using the Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control, see Administering Oracle Enterprise Scheduler.

Description.

Displays the schedule description configured on the Create Schedule page.

Frequency

Displays the schedule frequency configured on the Create Schedule page.

5. Use the IF-THEN table to define the fault notification rule, and click Apply.

Element

Description

IF

Define the IF part of the rule. At least one rule condition is mandatory, and cannot be removed.

- At the SOA Infrastructure level, the mandatory parameter is:
Fault Occurred in Last 48 Hours

- At the individual partition level, the mandatory parameters are:
Fault Occurred in Last 48 Hours

Partition is partition_name

You can edit the default value of 48.

Additional rule conditions are optional. Each condition can be added only once. Once a condition is added, it is removed from the list of available conditions.

Click the + sign to select rule conditions and assign values. For example, define a rule to trigger an alert if more than 3 faults occur in a 48 hour period in the default partition.

IF Fault Occurred in Last 48 Hours and

Partition is default and

Fault Count is over 3

THEN

Define the THEN part of the rule. Any number of THEN conditions can be specified. At least one condition is required. (Send Alerts to Dashboard is a valid condition.)

- Send Alerts to Dashboard

Select whether to send an alert to the Fault Alerts section of the Dashboard pages at the SOA Infrastructure or partition levels when the specified fault criteria are met. Use this selection with care to prevent the Dashboard page from overflowing with fault alerts. If you do not select this option, the alert is not displayed on the Dashboard pages.

- Send Message To User Via Delivery_Channel

Specify the address of the user to receive the alert notification and the delivery channel to use (email, IM, or SMS). Click the - sign to remove the users. It is your responsibility to ensure that the user contact information you enter is correct.

Note: You must also configure the notification email properties on the Workflow Notification Properties page, as described in Configuring Human Workflow Notification Properties. The delivery channels must also be configured in the Oracle User Messaging Service, which is accessible from the Workflow Notification Properties page by clicking the Go to the Messaging Driver page link.

The notification message the alert recipients receive provides the following details. The message content cannot be configured.

- Fault information. For example:
16 faults occurred in the last 48 hours

- A link to the Error Hospital page for viewing details about the faults in this notification alert. From the Error Hospital page, you can drill down to see the individual flow instances and further details about the faults.

For information about configuring delivery channels in Oracle User Messaging Service, see Administering Oracle User Messaging Service.

When complete, alert notification rule design looks as follows.

By default, the alert is enabled. You can disable the alert by selecting the alert on the Edit Notification Rules page and clicking Disable. This button acts as a toggle for enabling or disabling one or more selected alerts.

When error notification rule criteria are met, the alert is triggered and displayed in the Fault Alerts section of the Dashboard page at the SOA Infrastructure or partition level. The frequency with which a rule is invoked is based upon your selection from the Schedule Names list in Step 5.

a. Click the link that identifies the number of faults.
The Error Hospital page is displayed.

b. Click Search.
The Fault Statistics table shows details about the faults and the Fault Occurred field of the Time filter of the Report Options section is populated with the same time period specified on the Create Error Notification Rules page.

c. In the Recoverable column, click the values to perform fault recovery. For more information, see Viewing Error Notification Alerts.

6. When you receive an error notification alert (for example, an email), click the link in the email to access the Error Hospital page.

16 Faults occurred in the last 48 hours
Click the link for more details http://link_to_Error_Hospital_Page

For information about assigning alerts in the fault management framework in Oracle JDeveloper, see Section "How to Design a Fault Policy with the Fault Policy Wizard" of Developing SOA Applications with Oracle SOA Suite.

For information about roles, see Securing Access to Partitions.

6.2.2 Error Notification Rules Associated with an Expired Schedule

You cannot enable, disable, or delete a rule when the schedule associated with the rule has expired. The following error message appears:

<Error> <oracle.soa.scheduler> <BEA-000000> <ESS-01054 Cannot hold request 5.
Current state is Finished.
oracle.as.scheduler.IllegalStateException: ESS-01054 Cannot hold request 5.
Current state is Finished.
at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:258)
at
weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:472
)
at

These actions can be performed if the rule has an active schedule.

7 Managing SOA Folders and Work Manager Groups

This chapter describes how to manage folders, manage work manager groups, and secure access to folders, including how to create, delete, and edit folders; perform bulk management lifecycle tasks on composites; view and configure work manager properties; view work manager pending and completed requests; view and create work manager groups; view SOA Folder roles; and assign users to SOA Folder roles.

This chapter includes the following sections:

- Managing SOA Folders

- Managing Work Manager Groups

- Securing Access to SOA Folders

For information about monitoring the overall status of a specific folder, see Monitoring the Overall Status of the SOA Infrastructure or Individual Partition.

For information about tracking the status of business flow instances in a specific folder, see Tracking Business Flow Instances .

For information about performing error recovery in a specific folder, see Recovering From Faults in the Error Hospital.

7.1 Managing SOA Folders

You can deploy SOA composite applications into separate sections of the SOA Infrastructure known as folders. Deploying composites to folders enables you to:

- Logically group SOA composites

- Perform the following bulk lifecycle management tasks on all SOA composite applications within a specific folder:

- Start all composites

- Shut down all composites

- Retire all composites

- Activate all composites

- Undeploy all composites

- Secure access to folders

At least one folder is required for deploying SOA composite applications. A default folder named default is automatically included with Oracle SOA Suite. You can delete the default folder. You cannot rename existing folders; only creation and deletion of folders is supported.

Folders are not associated with a particular state such as started, stopped, activated, or retired. Only the composites within the folder are associated with a particular state. Therefore, you cannot start, stop, activate, or retire a folder.

Note:

If SOA composite applications using the same inbound resource are deployed to different folders, it cannot be guaranteed which folder picks up the message for processing.

For example, assume you are using the file adapter and /home/Directory1 is the inbound directory for the composite SOAComposite1. If this composite is deployed to both Partition1 and Partition2, when a file is placed in /home/Directory1, either the composite in Partition1 or Partition2 may pick up the file.

With the socket adapter, however, there is a limitation that does not permit you to deploy any composite that uses the same inbound port. In that case, an exception is thrown indicating that the inbound port is in use.

To manage folders:

Access the Manage SOA Folders page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Node in the Target Navigation Tree...

1. Select Manage SOA Folders.

1. Expand the SOA node.

2. Right-click soa-infra, select Manage SOA Folders.

The Manage SOA Folders page displays the following details:

- A utility for searching for a specific folder. Enter a full or partial folder name and click the Search icon or press the Return key. The search is not case-sensitive.

- Links for creating, deleting, and editing folders.

- A Composites Control list for starting up, shutting down, activating, and retiring all composites in the selected folder.

- A Deployment list for deploying to this folder or undeploying all from this folder.

- A table that lists each folder, the work manager group, the number of active and retired SOA composite application revisions in each folder, and the name of the composites contained in each folder (under the View link).

You can perform the following folder management tasks:

- Creating SOA Folders

- Deleting Folders

- Changing the Work Manager Group of a SOA Folder

- Performing Bulk Lifecycle Management Tasks on Composites in SOA Folders

For more conceptual information about folders, see Introduction to SOA Folders.

7.1.1 Creating SOA Folders

You can create folders from the Manage SOA Folders page.

Note:

You must ensure that the Session Lock on the Change Center in the Oracle WebLogic Server Administration Console is released before creating a folder.

To create a folder:

1. Access the Manage SOA Folders page as described in Managing SOA Folders.

2. Click Create.
The Create New SOA Folder dialog is displayed.

a. In the Name field, enter a folder name.

Note:

The name must conform to the following conventions:

- ASCII letters and numbers are permitted.

- Underscores (_) are permitted.

- Hyphens (-) are permitted (except as the first character).

- Non-ASCII letters are permitted.

- Spaces are not permitted.

Examples of valid names are mypartition, partition2, dept-a, customer_services, and 22. Examples of invalid names are -part2, /partition, and null or empty names.

b. From the Work Manager Group list, select an existing work manager group or click Add to create a new work manager group. To create a new work manager group, see Viewing and Creating Work Manager Groups.
You cannot rename an existing folder or later transfer the composite applications you deployed to it to a different folder.

3. Click Create.
The new folder is displayed under the SOA Folder column of the Manage Partitions page. You can now deploy composites to this partition by selecting Deploy to This Folder from the Deployment dropdown list. Once deployed, a composite cannot be transferred to a different folder.

For information about performing bulk lifecycle management tasks from the Composites Control and Deployment lists, see Performing Bulk Lifecycle Management Tasks on Composites in SOA Folders.

You can also create partitions with the Oracle WebLogic Scripting Tool (WLST) and ant commands. For information, see WLST Command Reference for SOA Suite and Developing SOA Applications with Oracle SOA Suite.

7.1.2 Deleting Folders

Note:

You must have at least one folder. If you delete all folders, you cannot deploy a SOA composite application.

You can delete folders from the Manage SOA Folders page.

Note the following:

- If you want to re-create some of your composite deployments in another folder, you can export those composites to a JAR file before you delete this folder.

- Before deleting the selected folder, all SOA composite application revisions in the folder are undeployed. The states of all active instances of undeployed composites are changed to aborted.

To delete a folder:

1. Access the Manage SOA Folders page as described in Managing SOA Folders.

2. Select a specific folder and click Delete.
The Delete SOA SOA Folder dialog is displayed.

3. Click Delete (Undeploy All Composites).

All composites that were deployed in the folder are undeployed and no longer appear in the navigator. The folder is then deleted from the SOA Folder column of the Manage SOA Folders page.

7.1.3 Changing the Work Manager Group of a SOA Folder

You can change the work manger group associated with a folder by either selecting an existing group or creating a new group.

Note:

You must ensure that the Session Lock on the Change Center in the Oracle WebLogic Server Administration Console is released before changing the work manager group of a folder.

To change the work manager group of a folder:

1. Access the Manage SOA Folders page as described in Managing SOA Folders.

2. Select a specific folder, and click Edit.

The Edit SOA Folder dialog is displayed.

3. From the Work Manager Group list, select an existing work manager group or click Add to create a new work manager group. To create a new work manager group, see Viewing and Creating Work Manager Groups.

4. Click Apply.

5. Restart the server for the work manager group change to take effect.

7.1.4 Performing Bulk Lifecycle Management Tasks on Composites in SOA Folders

You can perform bulk lifecycle management tasks on all SOA composite applications in a specific folder on the Manage SOA Folders page or on the SOA Folder page of a specific folder.

Bulk lifecycle management tasks impact not one, but many, composites at once. If a composite has running instances and a lifecycle changing operation is performed on the composite, the instances may not complete. For information about how different lifecycle operations impact the business flow instances, Managing the State of All Applications at the SOA Infrastructure Level.

To perform bulk lifecycle management tasks on all SOA composite applications in a specific folder:

1. Access the Manage SOA Folders page as described in Managing SOA Folders.
Two dropdown lists enable you to perform bulk lifecycle management actions:

- Composites Control list

- Deployment list

On the Manage SOA Folders page, these lists are displayed above the SOA Folder table.

2. To perform one of the following bulk lifecycle management tasks for all SOA composite applications contained in the selected folder, select the Composites Control list:

- Start all composites.

- Shut down all composites.

- Activate all composites.

- Retire all composites.

a. Select an operation to perform.
A dialog is displayed that prompts you to confirm your selection. When the operation completes, a confirmation message is displayed at the top of the page.

b. Click OK to continue.

Note:

Be aware that when you select Retire All from the Composite Control list, all composites in that folder are retired with no warning message to indicate that the default, last active composite is being retired.

This is the expected behavior when performing a bulk retirement of all composites in a folder.

3. To perform one of the following management tasks, select the Deployment list:

- Specify a composite to deploy to this folder. This selection invokes the Deploy SOA Composite wizard where you specify a composite revision to deploy.

- Undeploy all composites in this folder.
A dialog is displayed that prompts you to confirm your selection. When the operation completes, a confirmation message is displayed at the top of the page.

7.2 Managing Work Manager Groups

Each folder must be associated with a work manager group that consists of work managers. A work manager is an Oracle WebLogic Server entity that represents a logical thread pool. It is similar to a queue in which work items line up for processing. You can define priorities for the work to be processed by work managers. Work managers manage thread pools internally and automatically, providing for optimal scheduling. Work managers provide the following capabilities:

- A single internal global pool.

- A multiple, priority-based, work request queue. The priority is computed internally based on the work manager constraints.

- New threads that are automatically added and removed based on the work load.

Oracle WebLogic Server manages the thread pool on behalf of Oracle SOA Suite. It automatically controls the number of threads required based on defined criteria. You define the priority and Oracle WebLogic Server determines if more threads are required.

There are two ways to define work priorities in the Oracle WebLogic Server Administration Console.

- Request classes:

- Defines the necessary percentage of server resources to share

- Defines the necessary application response times

- Constraints:

- Maximum thread constraints: Once reached, the server does not schedule requests of this type until the number of concurrent executions falls below the limit. If you do not specify a value, the default value is unlimited.

- Minimum thread constraints: Ensures the number of threads the server allocates to impacted requests to avoid deadlocks. The default value is zero.

- Capacity: Causes the server to reject requests when it has reached its capacity.

Note:

The minimum and maximum threads are defined using the work manager names and they can be shared by multiple work managers. Work managers are defined at the domain level.

Oracle WebLogic Server includes a number of Oracle SOA Suite work managers. You can create Oracle SOA Suite work manager groups that are automatically associated with these work managers. A work manager group consists of work managers dedicated to processing Oracle SOA Suite background work for a given folder. Work manager groups isolate folder configuration and request processing. A work manager group can be shared by multiple folders.

The mapping works as follows:

- Mapping between a service engine thread pool (for example, a BPEL invoke pool) and a work manager in a work manager group.

- Mapping between a folder and a single work manager group. A work manager group comprises all logical thread pools for background processing tasks in a given folder. Multiple folders can share a single work manager group. For example:

- The default and HR folders can be associated with a standard work manager group.

- The sales folder can be associated with a high priority work manager group.

However, each folder is associated with only one work manager group.

7.2.1 Viewing and Configuring Work Manager Properties

You can view and configure work manager properties through one of the following options:

- Configure the following properties:

- The SOADataSource property in the Oracle WebLogic Server Administration Console to configure the number of database connections in the data source.

- The SOAMaxThreadsConfig property in the System MBean Browser to allocate percentages for the various work managers in the group.

Maximum thread constraints are automatically created based on these settings. For information, see Configuring Database-bound Processing Threads.

- Configure work manager properties such as minimum thread, maximum thread, and capacity constraints from Oracle WebLogic Server Administration Console. This option is a more advanced method than the first one. For information, see Viewing and Configuring Work Manager Constraints.

7.2.1.1 Viewing and Configuring Work Manager Constraints

You can view and configure Oracle SOA Suite work managers in Oracle WebLogic Server Administration Console:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure under domain_name (for example, named soainfra), expand Environment > Work Managers.

The default work managers automatically included with each partition are displayed. The work managers for the group are prefixed with the partition name (for this example, default). This enables you to easily identify which work manager is for which partition.

3. Click Next to display additional work managers automatically included with the partition.

4. Click a specific work manager to display details about request classes and constraint settings. You can change settings, as necessary.

7.2.2 Viewing Work Manager Pending and Completed Requests

You can view the number of pending and completed requests of each work manager.

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Navigator under soainfra, click Deployments.

3. In the table, browse for and select soa-infra.

4. At the top, click Monitoring, then Workload.

Details about pending and completed requests in the work managers are displayed. The Oracle WebLogic Server default thread is used to process all client-initiated work.

For information about exception messages caused by the unavailability of work manager threads, see Unavailability of Work Manager Threads for Incoming Processing.

7.2.3 Viewing and Creating Work Manager Groups

You can create work manager groups for each partition. When you create a group, the Oracle SOA Suite work managers shown in Managing Work Manager Groups are automatically added to the group. A default work manager group named default is automatically included with Oracle SOA Suite.

Note:

You must ensure that the Session Lock on the Change Center in the Oracle WebLogic Server Administration Console is released before creating or deleting work manager groups.

To create work manager groups:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Work Manager Groups.

a. Right-click soa-infra > server_name.

b. Select Work Manager Groups.

The Manage Work Groups page is displayed.

2. Expand the work manager groups to display the work managers automatically created with each group, the maximum thread constraint values and classes, the minimum thread constraint values and classes, and the fair share request classes. Constraints define the configuration values for work to be processed by work managers.
A fair share request class expresses a scheduling guideline that Oracle WebLogic Server uses to allocate threads to requests. Request classes ensure that high priority work is scheduled before less important work, even if the high priority work is submitted after the lower priority work. Oracle WebLogic Server takes into account how long it takes for requests to each module to complete.

A fair share request class specifies the average thread-use time required to process requests. The value of a fair share request class is specified as a relative value, not a percentage. Therefore, if two request classes are defined as 400 and 100, they have the same relative values as 80 and 20 or 4 and 1, respectively.

For example, RequestClass1, RequestClass2, and RequestClass3 have the fair share values of 10, 20, and 50, respectively. There is a 12.5% (10/80) chance that the next free thread performs work for RequestClass1. Similarly, there is a 25% (20/80) chance it next services RequestClass2 and a 62.5% (50/80) chance it next services RequestClass3.

3. From the View list, select Metrics to display the number of processes:

- Completed

- Active and pending

- Active and stuck

4. From the Server list, select a managed server in a cluster for which to view statistics.

5. Click Create.
The Create Work Manager Group dialog is displayed.

6. Enter a name and an optional description, and click OK.

The work manager group is displayed in the table (for this example, testgroup). The Oracle SOA Suite work managers are automatically included in the work manager group, and display beneath the work manager group name.

7. From the SOA Infrastructure menu, select Manage Partitions.

8. Assign the work manager group to a partition in either of the following ways:

a. Click Create to create a new partition to which you assign the work manager group, as described in Creating Partitions.

b. Click Edit to change the work manager group of the selected partition, as described in Changing the Work Manager Group of a Partition.
This change requires a server restart.

Note:

You cannot delete a work manager group that is currently associated with a partition.

7.3 Securing Access to SOA Folders

All folders are automatically secured with application roles and folder roles. Folder-based security provides the following benefits:

- Administrative access control

- Access control of information is provided at folder levels. You can only view the folder and composites to which you have access. For example, a user with access to only Partition1 can only see Partition1 and its deployed composites. This user cannot see any other folders.

- Association of different users to separate roles for each folder.

- Striping of instance data by folders

- Oracle Enterprise Manager Fusion Middleware Control pages such as Flow Instances and Error Hospital show instance data filtered by folder.

- The audit trail is displayed based on access control.

- Folder level resource management

- Separate thread pools and work managers are configured per folder. For more information, see Managing Work Manager Groups.

Application roles and folder roles consist of various combinations of Java permission classes and actions.

Table 7-1 shows the Oracle SOA Suite-wide application roles. These applications roles are not limited to a specific folder.

Table 7-1 Application Roles

Application Role

Description

MiddlewareOperator

This role provides the following capabilities:

- Ensures the continued operation of Oracle SOA Suite.

- Provides the main contact when a deployed SOA composite application does not operate correctly.

- Customizes operational settings such as the audit level; configures error notification rules; enables, disables, and monitors composites; and manages composite sensors.

MiddlewareAdministrator

This role provides the following capabilities:

- Ensures the continued operation of Oracle Fusion Middleware servers.

- Not always responsible for deployed SOA composite applications.

- Provides backup for operational roles and super user access to perform any tasks required for the continued operation of Oracle SOA Suite.

Table 7-2 describes the roles available with each folder. These folder-specific roles include various combinations of permission classes and actions.

Table 7-2 Folder Roles

Folder Role

Description

Composer

For making changes to SOA composite application artifacts, such as business rules, security policies, fault policies, and so on.

Deployer

For deploying new SOA composite applications, upgrading existing SOA composite applications, and managing the continuous integration and build process.

Tester

For performing testing on preproduction systems typically using a combination of command line tools, Oracle Enterprise Manager Fusion Middleware Control, and custom user interfaces.

Monitor

For the successful operation of deployed SOA composite applications in the folder.

ApplicationOperator

For handling user complaints and making decisions on requests that result in faults in the automated process. An administrator receives notifications regarding these transactions and can take steps to recover from the fault or terminate the transaction.

Note: This role does not include the Deployer and Tester roles.

You can perform the following folder access management tasks:

- Viewing SOA Folder Roles

- Viewing the Permissions Assigned to Each SOA Folder Role

- Assigning Users to SOA Folder Roles

- Understanding Additional Permission and Role Behavior Scenarios

7.3.1 Viewing SOA Folder Roles

You can view the roles associated with each folder on the Application Roles page.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Node in the Navigator...

a. Select Security > Application Roles.

a. Expand SOA.

b. Right-click soa-infra (server_name).

c. Select Security > Application Roles.

The Application Roles page is displayed.

2. Click the Search application roles icon.
For each folder, the roles described in Table 7-2 are displayed:

- folder_name_Monitor

- folder_name_Composer

- folder_name_Tester

- folder_name_Deployer

- folder_name_ApplicationOperator

7.3.2 Viewing the Permissions Assigned to Each SOA Folder Role

You can view the permissions assigned to each folder role on the Application Policies page.

Note:

Oracle SOA Suite roles grant Oracle Enterprise Scheduler permissions to those roles. These permissions are permission sets. Permission sets are not currently displayed in Oracle Enterprise Manager Fusion Middleware Control.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Node in the Navigator...

a. Select Security > Application Policies.

a. Expand SOA.

b. Right-click soa-infra (server_name).

c. Select Security > Application Policies.

2. Select a folder role in the table.
The bottom of the page is refreshed to display the permission class and actions assigned to the selected folder role.

7.3.3 Assigning Users to SOA Folder Roles

You can assign the specific SOA Folder roles you want a user to possess on a folder. These roles determine the tasks that a user can perform in Oracle Enterprise Manager Fusion Middleware Control.

Note the following authorization checking changes for Release 12c:

- Authorization checking occurs against permissions, which allows for finely granular Oracle SOA Suite roles based on these permissions.

- Only the Oracle WebLogic Server monitor role and appropriate Oracle SOA Suite roles are required for Oracle Enterprise Manager Fusion Middleware Control access.

- Avoid granting WLSOperator and WLSAdmin with added privileges for Oracle SOA Suite monitoring.

Support for folder level permissions and roles:

- In Release 11g, Oracle SOA Suite APIs and runtime were protected using Oracle SOA Suite application roles and Oracle Enterprise Manager Fusion Middleware Control was protecting user actions with the Oracle WebLogic Server enterprise role. Role mapping was required.

- In Release 12c, Oracle SOA Suite APIs and runtime and Oracle Enterprise Manager Fusion Middleware Control both protect the action and user interface using Oracle SOA Suite permissions. (Oracle SOA Suite application roles consist of a set of permissions.) Therefore, mapping a user to one of the application roles gives them the required permissions.

To assign users to SOA Folder roles:

1. Create a user in which to assign folder roles:

a. In the Navigator, select WebLogic Domain > soainfra.

b. From the WebLogic Domain menu, select Security > Users and Groups.

c. In the Users tab, click the Create icon to create a user.

d. Create the user name and password, and click OK.

Note:

When you create users in Oracle WebLogic Server Administration Console, folder-specific users only require the Monitor role. This role enables these users to access Oracle Enterprise Manager Fusion Middleware Control. Only the system administrator or super user requires the Administrator role.

2. Log in to Oracle Enterprise Manager Fusion Middleware Control with a user account that includes the Oracle WebLogic Server Admin role. Application policies are controlled by Oracle Platform Security Services. You directly access Oracle Platform Security Services to create SOA roles. This role enables you to view and map application roles to the user you created in Step 1.

3. Access the Application Roles page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Security > Application Roles.

a. Expand SOA > soa-infra.

b. Right-click soa-infra (server_name).

c. Select Security > Application Roles.

4. Click the Search application roles icon.

5. Select the folder role to which to map to the user, and click Edit.
For this example, the ApplicationOperator role in the folder consoleTests is selected. For all folders, the folder roles shown in Table 7-2 are automatically assigned.

The Edit Application Role page is displayed.

6. Click Add.
The Add Principal dialog is displayed.

7. From the Type list, select User. This becomes the user assigned to this permission.

8. To the right of the Display Name field, click the Search icon.

9. From the list that is displayed, select the user you created in Step 1, and click OK.

This adds the selected user to the folder role ApplicationOperator for the folder consoleTests.

10. Select additional application roles, as necessary, and click Edit to add more users.

11. Log out of Oracle Enterprise Manager Fusion Middleware Control.

12. Log in to Oracle Enterprise Manager Fusion Middleware Control as the user you assigned to the folder role in Step 9.
Because the user was given permissions on only the consoleTests folder, they:

- Cannot expand non-SOA folders in the Application Navigator.

- Can only see the consoleTests folder in the Application Navigator of which they are a member. All folders to which they do not belong are hidden from view.

- Cannot create other folders.

- Cannot change properties in the SOA Infrastructure Common Properties page.

Note:

When you create an application role and assign it a user on the Application Roles page, it is not immediately visible during a search on the Application Policies page. For the role to be visible, create a policy on the Application Policies page and assign it the application role and some permissions. These actions make the role visible.

7.3.4 Understanding Additional Permission and Role Behavior Scenarios

This section describes additional permission and role behavior scenarios.

7.3.4.1 Understanding Permissions on Initiating and Participating Composites in Different SOA Folders

The administration operations that you can perform on initiating and participating SOA composite applications in different folders are based on the initiating composite in the business flow instance, and not on the participating composite.

For example, assume you perform the following steps:

1. In the Security Realms section of Oracle WebLogic Server Administration Console, create a user (for this example, named soamonuser) to which you assign the Monitor group.

2. Log in to Oracle Enterprise Manager Fusion Middleware Control (for example, as the weblogic user).

3. Create a new folder (for this example, named test), assuming that the default folder is already present.

4. From the SOA Infrastructure menu, select Security > Application Roles.

5. Add the soamonuser user to the test_ApplicationOperator role.

6. Deploy a SOA composite application (for this example, named ResponseCreditRating) to the default folder.

7. Deploy a SOA composite application (for this example, named RequestCreditRating) to the test folder.

8. Create an instance of RequestCreditRating and verify the instance details in the Composites tab of the Flow Instances page. The roles of the composites in this business flow instance are as follows:

- Initiating composite: RequestCreditRating

- Participating composite: ResponseCreditRating

9. Log in to Oracle Enterprise Manager Fusion Middleware Control with the user soamonuser.

The soamonuser user has administration permissions on the test folder and no permissions on the default folder. However, the soamonuser user can abort and delete instances of the initiating RequestCreditRating composite even though this instance flow also calls the participating ResponseCreditRating composite on the default folder on which the soamonuser user has no permissions.

7.3.4.2 Viewing Oracle SOA Composer Permission Actions in a SOA Folder

Oracle SOA Composer users have the following permission actions by default for any artifact (domain value maps (DVMs), business rules, composite sensors, and so on) in that folder:

- CompositePermission with the read permission action for inspecting any artifact in that folder.

- CompositePermission with the write permission action for changing any artifact in that folder.

- SOAPlatformPermission with the read-shared-data permission action for inspecting any artifact in the shared folder. The shared folder is the location for all shared artifacts between SOA composite applications that can span multiple folders.

- SOAPlatformPermission with the write-shared-data permission action for changing any artifact in the shared data folder.

For more information about shared data, see Chapter "Managing Shared Data with the SOA Design-Time MDS Repository" of Developing SOA Applications with Oracle SOA Suite.

To view Oracle SOA Composer permission actions for a folder.

1. From the SOA Infrastructure menu, select Security > Application Policies.

2. Click the Search application security grants icon.

3. Select folder_name_Composer in the table.

The permission actions are displayed at the bottom of the page.

7.3.4.3 Understanding the MDS Configuration Page and Oracle SOA Suite Permissions

The MDS Configuration page in Oracle Enterprise Manager Fusion Middleware Control does not understand Oracle SOA Suite permissions. For example, assume you perform the following steps:

1. Create and assign a user to the Monitor group in Oracle WebLogic Server Administration Console.

2. Log in to Oracle Enterprise Manager Fusion Middleware Control and assign the default_Composer role to that user on the Application Roles page (where default represents the folder for this example).

3. Log back in to Oracle Enterprise Manager Fusion Middleware Control as that user, and select Administration > MDS Configuration from the SOA Infrastructure menu.

4. Note that the Import and Export options are disabled. This is the expected behavior.

As a workaround, Oracle SOA Suite users can read and write shared data using the SOA Deployment and Export operations available from the SOA Composite menu for a specific SOA composite application in Oracle Enterprise Manager Fusion Middleware Control.

Part IV Administering SOA Composite Applications and Instances

This part describes how to administer SOA composite applications and instances.

This part includes the following chapters:

- Securing SOA Composite Applications

- Monitoring SOA Composite Applications

- Deploying and Managing SOA Composite Applications

- Managing SOA Composite Application Business Flow Instances

- Developing a Database Growth Management Strategy

- Managing Database Growth

- Diagnosing Problems with SOA Composite Applications

8 Securing SOA Composite Applications

This chapter describes security configuration procedures unique to SOA composite applications. Most SOA composite application security procedures do not require SOA-unique configuration steps. References are provided to additional documentation for performing those tasks.

This chapter includes the following sections:

- Introduction to Securing SOA Composite Applications

- Configuring Oracle HTTP Server with Oracle BPM Worklist

- Setting up SAML Message-Protected Policy Configuration for the SOA Infrastructure

- Automatically Authenticating and Users

- Setting the Authentication Provider

- Configuring SSL

- Configuring Security for Human Workflow WSDL Files

Note:

See the following sections for information on attaching and detaching policies:

- Managing SOA Composite Application Policies

- Managing BPEL Process Service Component Policies

- Managing Policies.

- Managing Human Workflow Service Component Policies

- Managing Binding Component Policies

8.1 Introduction to Securing SOA Composite Applications

This chapter describes security procedures unique to SOA composite applications. Most SOA composite application security procedures do not require SOA-unique steps and can be performed by following the documentation listed in Table 8-1.

Table 8-1 Security Documentation

For Information On...

See The Following Guide...

Securing Oracle Fusion Middleware, including Oracle Single Sign-On (OSSO) configuration

Securing Applications with Oracle Platform Security Services

Securing and administering web services

Administering Web Services

Understanding Oracle WebLogic Server security

Understanding Security for Oracle WebLogic Server

Securing an Oracle WebLogic Server production environment

Securing a Production Environment for Oracle WebLogic Server

Securing Oracle WebLogic Server

Administering Security for Oracle WebLogic Server 12c (12.2.1)

Developing new security providers for use with Oracle WebLogic Server

Developing Security Providers for Oracle WebLogic Server

Securing web services for Oracle WebLogic Server

Securing WebLogic Web Services for Oracle WebLogic Server

Programming security for Oracle WebLogic Server

Developing Applications with the WebLogic Security Service

Securing Oracle User Messaging Service

Administering Oracle User Messaging Service

8.2 Configuring Oracle HTTP Server with Oracle BPM Worklist

You must add the /integration location in the mod_wl_ohs.conf file of Oracle HTTP Server for Oracle BPM Worklist to work through Oracle HTTP Server.

<Location /integration>
SetHandler weblogic-handler
#   PathTrim /weblogic
ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
</Location>

8.3 Setting up SAML Message-Protected Policy Configuration for the SOA Infrastructure

This section describes how to set up and validate Security Assertion Markup Language (SAML) message-protected policy configuration for the SOA Infrastructure with the Oracle WebLogic Scripting Tool (WLST). The example in this section describes task query service configuration. However, these instructions are relevant to all human workflow services that support SAML-token ports:

- Activity guide query service

- Activity guide metadata service

- Activity guide admin service

- Task query service

- Task service

- Task metadata service

- Runtime config service

- Task evidence service

- User metadata service

If you want to change the policy for another service, you must apply the same WLST commands to that service's SAML-token port.

To set up an SAML message-protected policy configuration:

1. Log in to the SOA domain (for example, named base_domain) using WLST.

2. Detach the existing out-of-the-box service policy named wss10_saml_token_service_policy.

wls:/base_domain/domainRuntime> detachWebServicePolicy('/base_domain/soa
_server1/soa-infra','integration/services/TaskQueryService','web',
'WorkflowProvider','TaskQueryServicePortSAML','oracle/
wss10_saml_token_service_policy')

3. Restart the application to activate any policy or configuration change.

4. Attach the new policy. In this case, the policy is named oracle/wss10_saml_token_with_message_protection_service_policy.

wls:/base_domain/domainRuntime> attachWebServicePolicy('/base_domain/soa
_server1/soa-infra','integration/services/TaskQueryService',
'web','WorkflowProvider','TaskQueryServicePortSAML','ora
cle/wss10_saml_token_with_message_protection_service_policy')

5. Restart the application to activate any policy or configuration change.

6. List the policy to validate.

wls:/base_domain/domainRuntime> listWebServicePolicies('/base_domain/soa
_server1/soa-infra','integration/services/TaskQueryService',
'web','WorkflowProvider','TaskQueryServicePortSAML')
TaskQueryServicePortSAML :
security :
oracle/wss10_saml_token_with_message_protection_service_policy,
enabled=true
Attached policy or policies are valid; endpoint is secure.

7. Create a keystore, add the orakey alias, and run the Oracle Web Service Manager (OWSM) configuration to activate the SAML message-protected policy. For example:

keytool -genkeypair
-keystore  domain_home/config/fmwconfig/default-keystore.jks
-keyalg RSA
-dname "cn=consumer,dc=example,dc=com"
-alias clientalias
-keypass  password
-storepass password
-validity 3600

keytool -exportcert
-keystore domain_home/config/fmwconfig/default-keystore.jks
-v
-alias clientalias
-storepass password
-rfc
-file domain_home/config/fmwconfig/certificate.cer

keytool -importcert
-keystore domain_home/config/fmwconfig/default-keystore.jks
-alias orakey
-file domain_home/config/fmwconfig/certificate.cer
-storepass password
createCred(map="oracle.wsm.security", key="keystore-csf-key",
user="owsm", password="welcome1", desc="Keystore key")
createCred(map="oracle.wsm.security", key="enc-csf-key",
user="clientalias", password="welcome1", desc="Encryption key")
createCred(map="oracle.wsm.security", key="sign-csf-key",
user="clientalias", password="welcome1", desc="Signing key")

8. Restart the servers.

8.4 Automatically Authenticating Oracle BPM Worklist and Oracle Business Process Management Users

This section describes how to authenticate Oracle BPM Worklist and Oracle Business Process Management users in different environments.

8.4.1 Automatically Authenticating Oracle BPM Worklist Users in SAML SSO Environments

To be automatically authenticated when accessing a second Oracle BPM Worklist from a first Oracle BPM Worklist in SAML SSO environments, you must perform the following steps. Otherwise, you are prompted to log in again when you access the second Oracle BPM Worklist. In these environments, the first Oracle BPM Worklist is configured as the SAML identity provider and the second Oracle BPM Worklist that you access is configured as the SAML service provider.

To automatically authenticate Oracle BPM Worklist users in SAML SSO environments:

1. Add /integration/worklistapp/* as the redirect URL for worklistapp to the SAML service provider site's SAML2IdentityAsserter configuration as follows.

a. In the Oracle WebLogic Server Administration Console, select Security Realms.

b. Click the realms for the service providers.

c. Select the Providers tab, and then the Authentication subtab.

d. From the provider list, select the provider with the description SAML 2.0 Identity Assertion Provider.
If you do not see the SAML identity assertion provider configuration, follow the instructions in Administering Security for Oracle WebLogic Server.

e. Select the Management tab.
Under the Management tab, you see a list of identity provider partners. These are hosts that have been configured as the SAML identity provider partners for this SAML identity service provider site. Remember that this configuration step is performed on the identity service provider site on which Oracle BPM Worklist is hosted.

f. Select the identity provider site where you want the user to perform the initial login.

g. Scroll down the page until you see the field Redirect URIs.

h. Add /integration/worklistapp/* to the list.

After performing this step, you can log in to Oracle BPM Worklist at the SAML identity provider site though the regular URL of/integration/worklistapp. If necessary, you can then navigate to the URL /integration/worklistapp/ssologin at the SAML service provider site, where you gain access to Oracle BPM Worklist and are automatically authenticated.

For more information about SAML2IdentityAsserter and configuring SSO with web browsers and HTTP clients, see Administering Security for Oracle WebLogic Server.

8.4.2 Automatically Authenticating Oracle BPM Workspace Users in SAML SSO Environments

To be automatically authenticated when accessing a second Oracle BPM Workspace from a first Oracle BPM Workspace in SAML SSO environments, you must perform the following steps. Otherwise, you are prompted to log in again when you access the second Oracle BPM Workspace. In these environments, the first Oracle BPM Workspace is configured as the SAML identity provider and the second Oracle BPM Workspace that you access is configured as the SAML service provider.

To automatically authenticate Oracle BPM Workspace users in SAML SSO environments:

1. Add /bpm/workspace/* as the redirect URL for workspace to the SAML service provider site's SAML2IdentityAsserter configuration as follows.

a. In the Oracle WebLogic Server Administration Console, select Security Realms.

b. Click the realms for the service providers.

c. Select the Providers tab, and then the Authentication subtab.

d. From the provider list, select the provider with the description SAML 2.0 Identity Assertion Provider.
If you do not see the SAML identity assertion provider configuration, follow the instructions in Administering Security for Oracle WebLogic Server.

e. Select the Management tab.
Under the Management tab, you see a list of identity provider partners. These are hosts that have been configured as the SAML identity provider partners for this SAML identity service provider site. Remember that this configuration step is performed on the identity service provider site on which Oracle BPM Workspace is hosted.

f. Select the identity provider site where you want the user to perform the initial login.

g. Scroll down the page until you see the field Redirect URIs.

h. Add /bpm/workspace/* to the list.

After performing this step, you can log in to Oracle BPM Workspace at the SAML identity provider site though the regular URL of/bpm/workspace. If necessary, you can then navigate to the URL /bpm/workspace/ssologin at the SAML service provider site, where you gain access to Oracle BPM Workspace and are automatically authenticated.

For more information about SAML2IdentityAsserter and configuring SSO with web browsers and HTTP clients, see Administering Security for Oracle WebLogic Server.

8.4.3 Automatically Authenticating Oracle Business Process Composer Users in SAML SSO Environments

To be automatically authenticated when accessing a second Oracle Business Process Composer from a first Oracle Business Process Composer in SAML SSO environments, you must perform the following steps. Otherwise, you are prompted to log in again when you access the second Oracle Business Process Composer. In these environments, the first Oracle Business Process Composer is configured as the SAML identity provider and the second Oracle Business Process Composer that you access is configured as the SAML service provider.

To automatically authenticate Oracle Business Process Composer users in SAML SSO environments:

1. Add /bpm/composer/* as the redirect URL for composer to the SAML service provider site's SAML2IdentityAsserter configuration as follows.

a. In the Oracle WebLogic Server Administration Console, select Security Realms.

b. Click the realms for the service providers.

c. Select the Providers tab, and then the Authentication subtab.

d. From the provider list, select the provider with the description SAML 2.0 Identity Assertion Provider.
If you do not see the SAML identity assertion provider configuration, follow the instructions in Administering Security for Oracle WebLogic Server.

e. Select the Management tab.
Under the Management tab, you see a list of identity provider partners. These are hosts that have been configured as the SAML identity provider partners for this SAML identity service provider site. Remember that this configuration step is performed on the identity service provider site on which Oracle Business Process Composer is hosted.

f. Select the identity provider site where you want the user to perform the initial login.

g. Scroll down the page until you see the field Redirect URIs.

h. Add /bpm/composer/* to the list.

After performing this step, you can log in to Oracle Business Process Composer at the SAML identity provider site though the regular URL of/bpm/composer. If necessary, you can then navigate to the URL /bpm/composer/ssologin at the SAML service provider site, where you gain access to Oracle Business Process Composer and are automatically authenticated.

For more information about SAML2IdentityAsserter and configuring SSO with web browsers and HTTP clients, see Administering Security for Oracle WebLogic Server.

8.4.4 Automatically Authenticating Oracle BPM Worklist Users in Windows Native Authentication Environments

For Windows native authentication through Kerberos to work with Oracle BPM Worklist, you must use the /integration/worklistapp/ssologin protected URL. For example, after configuring Windows native authentication, you access Oracle BPM Worklist as follows:

http://host_name.domain_name:8001/integration/worklistapp/ssologin

For information on configuring SSO with Microsoft clients, see Administering Security for Oracle WebLogic Server.

8.4.5 Automatically Authenticating Oracle Business Process Composer Users in Windows Native Authentication Environments

For Windows native authentication through Kerberos to work with Oracle Business Process Composer, you must use the bpm/composer/ssologin protected URL. For example, after configuring Windows native authentication, you access Process Composer as follows:

http://host_name.domain_name:8001/bpm/composer/ssologin

For information on configuring SSO with Microsoft clients, see Administering Security for Oracle WebLogic Server.

8.5 Setting the Authentication Provider

The authentication provider that you want to use should appear first in the list of authentication providers. This section describes how to set the first authentication provider.

8.5.1 Listing Oracle Internet Directory as the First Authentication Provider

Oracle BPM Worklist and workflow services use Java Platform Security (JPS) and the User and Role API. For this reason, the Oracle Internet Directory authenticator must be the first provider listed when workflow is used with Oracle Internet Directory. If Oracle Internet Directory is not listed first (for example, it is listed below DefaultAuthenticator), login authentication fails.

For information about changing the order of authentication providers, see Administering Security for Oracle WebLogic Server.

8.5.2 Accessing Web-based Applications with the Default Authentication Provider

Logging in to web-based applications may fail when using Oracle Internet Directory authentication. This is caused when the Oracle WebLogic Server configuration is set to use the Oracle Internet Directory authentication before default authentication.

This may produce the following error:

"@ User "weblogic" is not found in configuration "jazn.com" Check if the user
exists in the repository specified by the configurations. Check the error stack
and fix the cause of the error. Contact oracle support if error is not fixable."

The order of the security providers should be:

1. Default authentication

2. Oracle Internet Directory/LDAP authentication

8.5.3 Enabling Multiple Authentication Providers

The Adjudication provider determines what to do if multiple Authorization providers are configured in a security realm.

For information about the Adjudication provider and enabling multiple authentication providers, see "Configuring the WebLogic Adjudication Provider" in Administering Security for Oracle WebLogic Server.

8.6 Configuring SSL

This section describes how to configure secure socket layer (SSL) in Oracle SOA Suite and Oracle Business Process Management environments.

8.6.1 Using SSL Certificates When the SOA/BPM Server Is Configured with an HTTPS Port

If the SOA/BPM server is configured with an HTTPS port, ensure that your SSL certificate adheres to the following standards:

- The certificate that the server presents to SSL clients (the browser or other internal clients such as the notification senders) is a trusted certificate by its own trust store (the CA store).

- If the certificate for the server is self-signed, ensure that you add it to the trust store.

Not doing so can cause problems when task notifications are sent. For example, you can receive the following task notification error message in the server out log (soa_server_name.out).

<Sep 13, 2011 12:59:41 AM PDT> <Error> <oracle.soa.services.workflow.common>
<BEA-000000> <<.>
ORABPEL-0
at
oracle.bpel.services.workflow.task.notification.
TaskNotifications.getEmailPaylOad
(TaskNotifications.java:1354)
at
oracle.bpel.services.workflow.task.notification.
TaskNotifications.getEmailNotificationContent
(TaskNotifications.java:987)
at
weblogic.jms.client.JMSSession$UseForRunnable.run
(JMSSession.java:5170)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerI
mpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain
received from myhost.us.example.com - 10.232.152.78 was not trusted causing
SSL handshake failure.
at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireException(UnknownSource)
at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireAlertSent(UnknownSource)
at
com.certicom.tls.record.handshake.HandshakeHandler.
fireAlert(Unknown Source).
ficationContent(TaskNotifications.java:987)
at
weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerI
mpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain
received from myhost.us.example.com - 10.232.152.78 was not trusted causing
SSL handshake failure.
at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireException(UnknownSource)
at
com.certicom.tls.interfaceimpl.TLSConnectionImpl.
fireAlertSent(UnknownSource)
at
com.certicom.tls.record.handshake.HandshakeHandler.
fireAlert(Unknown Source

For more information about concepts and configuration details, see Administering Security for Oracle WebLogic Server.

8.6.2 Recommendation to Configure Either All or No Managed Servers with SSL

As a best practice, Oracle recommends that you configure either all managed servers or no managed servers with SSL (SOA, BAM, and so on). Configuring some managed servers with SSL, while not configuring others, may lead to undesirable results in Oracle BPM Worklist and Oracle Web Services Manager (OWSM). For example, if there is an SSL-configured, managed server (bam_server), servers not configured with SSL are not used by OWSM. In cases in which an SSL-configured server is down, it causes OWSM to be in a down state, which in turn causes Oracle BPM Worklist to be in a down state. For more information, see "Unable to Connect to the Policy Manager" in the Securing Web Services and Managing Policies with Oracle Web Services Manager.

8.6.3 Switching from Non-SSL to SSL Configurations with Oracle BPM Worklist

Switching from non-SSL to SSL configurations with Oracle BPM Worklist requires the Frontend Host and Frontend HTTPS Port fields to be set in the Oracle WebLogic Server Administration Console. Not doing so will result in errors when attempting to create to-do tasks.

To switch from non-SSL to SSL configurations with Oracle BPM Worklist:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Environment section, select Servers.

3. Select the name of the managed server (for example, soa_server1).

4. Select Protocols, then select HTTP.

5. In the Frontend Host field, enter the hostname on which Oracle BPM Worklist is located.

6. In the Frontend HTTPS Port field, enter the SSL listener port.

7. Click Save.

8.6.4 Configuring SOA Composite Applications for Two-Way SSL Communication

Oracle SOA Suite uses both Oracle WebLogic Server and Oracle Secure Socket Layer (SSL) stacks for two-way SSL configurations.

- For the inbound web service bindings, Oracle SOA Suite uses the Oracle WebLogic Server infrastructure and, therefore, the Oracle WebLogic Server libraries for SSL.

- For the outbound web service bindings, Oracle SOA Suite uses JRF HttpClient and, therefore, the Oracle JDK libraries for SSL.

Due to this difference, start Oracle WebLogic Server with the following JVM option.

To configure SOA composite applications for two-way SSL communication:

1. Open the following file:

- On UNIX operating systems, open $MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh.

- On Window operating systems, open MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.bat.

2. Add the following line in the JAVA_OPTIONS section, if the server is enabled for one-way SSL (server authorization only):

-Djavax.net.ssl.trustStore=your_truststore_location

For two-way SSL, the keystore information (location and password) is not required.

In addition, perform the following steps to enable two-way SSL for a SOA composite application to invoke another SOA composite application or another non-SOA application.

Note:

Both the server and client are assumed to have been configured for two-way SSL.

8.6.4.1 To enable two-way SSL for a SOA composite application to invoke another application:

1. On the client side, provide the keystore location.

a. From the SOA Infrastructure menu, select SOA Administration > Common Properties.

b. At the bottom of the page, click More SOA Infra Advanced Configuration Properties.

c. Click KeystoreLocation.

d. In the Value column, enter the keystore location.

e. Click Apply.

f. Click Return.

2. On the client side, provide the keystore location in DOMAIN_HOME\config\soa-infra\configuration\soa-infra-config.xml.

<keystoreLocation>absolute_path_to_the_keystore_location_and_the_file_name
</keystoreLocation>

3. During design time in Oracle JDeveloper, update the reference section in the composite.xml file with the oracle.soa.two.way.ssl.enabled property.

<reference name="Service1"
ui:wsdlLocation=". . .">
<interface.wsdl interface=". . ."/>
<binding.ws port=". . .">
<property name="oracle.soa.two.way.ssl.enabled">true</property>
</binding.ws>
</reference>

4. In Oracle Enterprise Manager Fusion Middleware Control, select WebLogic Domain > domain_name.

5. Right-click domain_name and select Security > Credentials.

6. Click Create Map.

7. In the Map Name field, enter a name (for example, SOA), and click OK.

8. Click Create Key.

9. Enter the following details.

Field

Description

Select Map

Select the map created in Step 7 (for this example, SOA).

Key

Enter the key name (KeystorePassword is the default).

Type

Select Password.

User Name

Enter the keystore user name (KeystorePassword is the default).

Password

Enter the password that you created for the keystore.

Note:

When you set up SSL in Oracle WebLogic Server, a key alias is required. You must enter mykey as the alias value. This value is required.

10. Set the keystore location in Oracle Enterprise Manager Fusion Middleware Control. See Step 1 for instructions.

11. Modify composite.xml to use https and sslport to invoke a SOA composite application. For example, change the syntax shown in bold:

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 1.0 at [4/1/09 11:01 PM]. -->
<composite name="InvokeEchoBPELSync"
revision="1.0"
label="2009-04-01_23-01-53_994"
mode="active"
state="on"
xmlns="http://xmlns.oracle.com/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:ui="http://xmlns.oracle.com/soa/designer/">
<import
namespace="http://xmlns.oracle.com/CustomApps/InvokeEchoBPELSync/BPELProcess1"
location="BPELProcess1.wsdl" importType="wsdl"/>
<import namespace="http://xmlns.oracle.com/CustomApps/EchoBPELSync/
BPELProcess1"location="http://hostname:port/soa-infra/services/default/EchoBPEL
Sync/BPELProcess1.wsdl"
importType="wsdl"/>

to use https and sslport:

location="https://hostname:sslport/soa-infra/services/default/EchoBPELSync
/BPELProcess1.wsdl"

8.6.5 Invoking References in One-Way SSL Environments in Oracle JDeveloper

When invoking a web service as an external reference from a SOA composite application in one-way SSL environments, ensure that the certificate name (CN) and the hostname of the server exactly match. This ensures a correct SSL handshake.

For example, if a web service is named adfbc and the certificate has a server name of myhost05, the following syntax results in an SSL handshake exception.

<import namespace="/adfbc1/common/"

location="https://myhost05.us.example.com:8002/CustomApps-adfbc1-context-root/Ap
pModuleService?WSDL"
importType="wsdl"/>
<import namespace="/adfbc1/common/" location="Service1.wsdl"
importType="wsdl"/>

If you switch the order of import, the SSL handshake passes.

<import namespace="/adfbc1/common/" location="Service1.wsdl"
importType="wsdl"/>
<import namespace="/adfbc1/common/"
location="https://myhost05.us.example.com:8002/CustomApps-adfbc1-context-root/Ap
pModuleService?WSDL"
importType="wsdl"/>

Note the following restrictions around this issue:

- There are no options for ignoring hostname verification in Oracle JDeveloper as exist with the Oracle WebLogic Server Administration Console. This is because the SSL kit used by Oracle JDeveloper is different. Only the trust store can be configured from the command line. All other certificate arguments are not passed.

- In the WSDL file, https://hostname must match with that in the certificate, as described above. You cannot perform the same procedures as you can with a browser. For example, if the hostname is myhost05.us.example.com in the certificate's CN, then you can use myhost05, myhost05.us.example.com, or the IP address from a browser. In Oracle JDeveloper, always use the same name as in the certificate (that is, myhost05.us.example.com).

8.6.6 Configuring Oracle SOA Suite and Oracle HTTP Server for SSL Communication

Follow these steps to configure SSL communication between Oracle SOA Suite and Oracle HTTP Server.

8.6.6.1 Configuring Oracle HTTP Server for SSL Communication

To configure Oracle HTTP server for SSL communication:

1. Update mod_ssl.conf with the <Location /integration/services> location directive.

LoadModule weblogic_module   ${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so

<IfModule mod_weblogic.c>
WebLogicHost host.domain.com
WLLogFile <logdir>/ohs_ssl.log
Debug ALL
DebugConfigInfo ON
SecureProxy ON
MatchExpression *.jsp
WlSSLWallet <OHS_
HOME>/instances/instance1/config/OHS/ohs1/keystores/default
</IfModule>

<Location /soa-infra>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /b2bconsole>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /b2b>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /integration/worklistapp>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /integration/services>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /DefaultToDoTaskFlow>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /OracleBAM>
WebLogicPort 9002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

<Location /OracleBAMWS>
WebLogicPort 9002
SetHandler weblogic-handler
ErrorPage  http://host.domain.com:port/error.html
</Location>

<Location /sdpmessaging/userprefs-ui/>
WebLogicPort 8002
SetHandler weblogic-handler
ErrorPage http://host.domain.com:port/error.html
</Location>

2. Start the Oracle WebLogic Servers as described in Configuring SOA Composite Applications for Two-Way SSL Communication.

8.6.6.2 Configuring Certificates for Oracle Client, Oracle HTTP Server, and Oracle WebLogic Server

To configure certificates for Oracle Client, Oracle HTTP Server, and Oracle WebLogic Server:

1. Export the user certificate from the Oracle HTTP Server wallet.

orapki wallet export -wallet . -cert cert.txt  -dn 'CN=\"Self-Signed
Certificate for ohs1 \",OU=OAS,O=ORACLE,L=REDWOODSHORES,ST=CA,C=US'

2. Import the above certificate into the Oracle WebLogic Server trust store as a trusted certificate.

keytool -file cert.txt -importcert -trustcacerts -keystore DemoTrust.jks

3. Export the certificate from the Oracle WebLogic Server trust store.

keytool -keystore DemoTrust.jks -exportcert -alias wlscertgencab -rfc -file
certgencab.crt

4. Import the above certificate to the Oracle HTTP Server wallet as a trusted certificate.

orapki wallet add -wallet . -trusted_cert -cert certgencab.crt -auto_login_only

5. Restart Oracle HTTP Server.

6. Restart the Oracle WebLogic Servers as described in Configuring SOA Composite Applications for Two-Way SSL Communication.

8.6.7 Configuring SSL Between Business Flow Instances and Oracle WebCache

The Test Web Service page in an Oracle WebCache and Oracle HTTP Server environment may require communication back through Oracle WebCache. Therefore, SSL must be configured between the business flow instance and Oracle WebCache (that is, export the user certificate from the Oracle WebCache wallet and import it as a trusted certificate in the Oracle WebLogic Server trust store).

8.6.8 Using a Custom Trust Store for One-Way SSL During Design Time

To invoke a SOA composite application from another composite over HTTPS when using a custom trust store created with a tool such as keytool or orapki, perform the following actions in Oracle JDeveloper.

To use a custom trust store for one-way SSL during design time:

1. To fetch a WSDL file in the reference section, set the trust store information in Tools > Preferences > Http Analyzer > HTTPS Setup > Client Trusted Certificate Keystore.

2. During deployment to an SSL-enabled server, use the JSSE property at the command line:

jdev -J-Djavax.net.ssl.trustStore=your_trusted_location

8.6.9 Configuring an Asynchronous Process Deployed to an SSL-Enabled Managed Server to Invoke Another Asynchronous Process Over HTTP

Assume you create the following environment:

- Asynchronous BPEL process A invokes asynchronous BPEL process B

- Asynchronous BPEL process A is deployed to a one-way SSL enabled, managed server

- All WSDL references and bindings use plain HTTP

At runtime, the WSDL is found over HTTPS, and the callback message from asynchronous BPEL process B fails.

To resolve this issue, the callbackServerURL property must be passed at the reference binding level in the composite.xml file. This explicitly indicates the value of the callback URL for the given reference invocation. The callback is made over HTTP instead of the default HTTPS. If the client composite is running in an SSL-managed server, then the callback defaults to SSL.

<binding.ws port="http://xmlns.oracle.com/Async/AsyncSecondBPELMTOM/BPELProcess1#wsdl.
endp oint(bpelprocess1_client_ep/BPELProcess1_pt)"
location="http://localhost:8000/soa-infra/services/default/AsyncSecondBPELMTOM/
bpelprocess1_client_ep?WSDL">
<wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
orawsp:category="security" orawsp:status="enabled"/>
<wsp:PolicyReference URI="oracle/wsaddr_policy" orawsp:category="addressing"
orawsp:status="enabled"/>
<property name="callbackServerURL">http://localhost:8000/</property>
</binding.ws>

8.7 Configuring Security for Human Workflow WSDL Files

If the WSDL files for human workflow services should not be exposed to external consumers, then set the flag that exposes the WSDL to false for each of the services:

<expose-wsdl>false</expose-wsdl>

9 Monitoring SOA Composite Applications

This chapter describes how to monitor the performance summary metrics of a SOA composite application, view a graphical representation of the SOA composite application, and monitor the total messages processed and average processing time of service and reference binding components in a SOA composite application.

This chapter includes the following topics:

- Monitoring SOA Composite Application Performance Summary Metrics

- Viewing the SOA Composite Application Diagram

- Monitoring the Service Components and Binding Components of a SOA Composite Application

For more information, see Introduction to SOA Composite Applications.

9.1 Monitoring SOA Composite Application Performance Summary Metrics

You can view a summary of SOA composite application performance metrics on the Performance Summary page.

1. Access this page through one of the following options:

From the SOA Composite Menu...

From the SOA Folder in the Navigator...

a. Select Monitoring > Performance Summary.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

c. From the SOA Composite menu, select Monitoring > Performance Summary.

The Performance Summary page provides a graphical representation of the following information by default:

- Total number of business flow instances since the last server restart.

- Total number of faults since the last server restart.

2. Click Show Metric Palette to display a hierarchical tree of all metrics for the SOA composite application. The tree organizes the metrics into various categories of performance data.

3. Expand a folder and select a metric in the Metric Palette to display a performance chart that shows the changes in the metric value over time. The chart refreshes automatically to show updated data.

4. Click Slider to display a slider tool that lets you specify the time frame shown in the charts.

For more information about the Performance Summary page, see the online Help for the Performance Summary page and Section "Viewing the Performance of Oracle Fusion Middleware" of Administering Oracle Fusion Middleware.

For information about monitoring SOA Infrastructure performance summary metrics, see Monitoring SOA Infrastructure Performance Summary Metrics.

For information about monitoring message delivery processing requests, see Monitoring Message Delivery Processing Requests.

For information about monitoring service engine statistics, see the following:

- Monitoring BPEL Process Service Engine Request and Thread Performance Statistics.

- Monitoring Request Breakdown Statistics

- Monitoring Business Rules Service Engine Performance Statistics

- Monitoring Human Workflow Service Engine Active Requests and Operation Performance Statistics

- Monitoring BPMN Process Service Engine Performance Statistics

9.2 Viewing the SOA Composite Application Diagram

You can view a diagram of the SOA composite application you designed in Oracle JDeveloper in Oracle Enterprise Manager Fusion Middleware Control.

Note:

If the SOA composite application was designed using a Release 11g version of Oracle JDeveloper, the diagram cannot be displayed, and you receive an error message. To resolve this issue, reopen the composite in the Release 12c version of Oracle JDeveloper and redeploy it.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Infrastructure Home Page...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Click the SOA Folders tab.

b. Click View Composites for the SOA Folder that contains the composite.

c. Select a specific SOA composite application.

2. Click Composite Definition.
The Design view of the SOA composite application is displayed.

3. Above the diagram, click the Show Control Panel icon.

4. Select an option to customize the view of the diagram:

- zoom to fit

- zoom in

- zoom out

5. Click the Source tab to display the composite.xml source file of the SOA composite application.

9.3 Monitoring the Service Components and Binding Components of a SOA Composite Application

You can monitor the service components and binding components of a SOA composite application and the total number of messages processed and average processing time of the service and reference binding components.

To monitor the service components and binding components of a SOA composite application:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

The Dashboard page displays the following details:

- A summary of composite lifecycle state actions at the top of the Dashboard page (retire, activate, shut down, and start up). For information about these states, see Managing the State of Deployed SOA Composite Applications

- The name and type of service components used in this SOA composite application.

- The name and type of service (inbound) and reference (outbound) binding components used in this SOA composite application.

- Details about the total number of messages processed and average processing time of the service and reference binding components

2. In the Name column of the Components section, click a service component to access its home page.

3. In the Name column of the Services and References section, click a service or reference to access its home page.

For more information, see the following sections:

- Introduction to Business Flow Instances

- Introduction to Service Components

- Introduction to Binding Components

- Administering Oracle Fusion Middleware for details about viewing and searching log files

10 Deploying and Managing SOA Composite Applications

This chapter describes how to deploy and manage SOA composite applications, including deploying, redeploying, and undeploying a SOA composite application; managing the state of deployed SOA composite applications; automating the testing of SOA composite applications; managing policies; exporting deployed composites; disabling and enabling the collection of analytic, BPEL sensor, and composite sensor data; and linking to runtime applications.

This chapter includes the following sections:

- Deploying SOA Composite Applications

- Updating Instance_ Fault_ and Rejected Message States to Aborted During Undeployment or Redeployment

- Redeploying SOA Composite Applications

- Undeploying SOA Composite Applications

- Managing the State of Deployed SOA Composite Applications

- Automating the Testing of SOA Composite Applications

- Managing SOA Composite Application Policies

- Exporting a Deployed SOA Composite Application

- Disabling and Enabling the Collection of Analytic_ BPEL Sensor_ and Composite Sensor Data

- Linking to Runtime Applications

For information on the following:

- Creating SOA composite application archives and configuration plans in which you define the URLs and property values to use for test, development, and production environments, see Developing SOA Applications with Oracle SOA Suite

- Deploying with ant scripts, see Developing SOA Applications with Oracle SOA Suite

- Deploying with Oracle WebLogic Scripting Tool (WLST), see WLST Command Reference for SOA Suite

Note:

If Oracle Enterprise Manager Fusion Middleware Control is run in a single sign-on (SSO)-enabled environment, you are again prompted to enter the user name and password credentials as part of the last step of the Deploy SOA Composite, Undeploy SOA Composite, and Redeploy SOA Composite wizards. This information is only requested once per Oracle Enterprise Manager Fusion Middleware Control session.

10.1 Deploying SOA Composite Applications

You can deploy SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control with the Deploy SOA Composite wizard. You must first create a deployable archive in Oracle JDeveloper or with the ant or WLST command line tool. Use the Deploy SOA Composite wizard to deploy any of the following:

- A new SOA composite application for the first time.

- A new revision (for example, 2.0) alongside an older revision (for example, 1.0) without having an impact on the latter. The revision deployed last becomes the new default revision of that composite (unless you specify otherwise at a later step during deployment).

- A SOA bundle (ZIP file) containing any shared data JAR files and multiple revisions (for example, revisions 2.0, 3.0, and 4.0) of a SOA composite application that has different revisions currently deployed (for example, 1.0). This option enables you to deploy revisions 1.0, 2.0, 3.0, and 4.0 together. When deploying a SOA bundle, all shared metadata JAR files are deployed first, after which the composite SAR files are deployed in random order.
The bundle can also contain revisions of different composites. There is no restriction that all revisions must be of the same composite application. There should not be any cross references between the composites in the same bundle. For example, composite A revision 1.0 should not reference composite B revision 1.0.

Deployment extracts and activates the composite application in the SOA Infrastructure. After an application is deployed, you can perform administration tasks, such as creating instances, configuring properties, monitoring performance, managing instances, and managing policies and faults.

Note:

- If you want to redeploy an existing revision of an application, do not use this wizard. Instead, use the Redeploy SOA Composite wizard.

- Do not remove the user OracleSystemUser. This user is required for the proper functioning of Oracle SOA Suite, including deployment of SOA composite applications.

10.1.1 To Deploy SOA Composite Applications:

1. Access the Deploy SOA Composite wizard through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Infrastructure Home Page...

From the SOA Composite Menu...

a. Select SOA Deployment > Deploy.

a. Right-click soa-infra.

b. Select SOA Deployment > Deploy.

a. Click the Deployed Composites tab.

b. Above the Composite table, click Deploy.

a. Select SOA Deployment > Deploy Another Composite.

Note:

You can also access the Deploy SOA Composite wizard in the following ways:

- Selecting Deploy To This Partition from the Deployment dropdown list on the Manage Partitions page or home page of a specific partition

- From the SOA Partition menu at the top of the home page of a specific partition

- Right-clicking a specific partition in the navigator

The Select Archive page appears.

2. In the Archive or Exploded Directory section, specify the archive of the SOA composite application to deploy. The archive contains the project files of the composite to be deployed (for example, HelloWorld_rev1.0.jar for a single archive or OrderBooking_rev1.0.zip for multiple archives). This information is required.

3. In the Configuration Plan section, optionally specify the configuration plan to include with the archive. The configuration plan enables you to define the URL and property values to use in different environments. During process deployment, the configuration plan is used to search the SOA project for values that must be replaced to adapt the project to the next target environment.

4. Click Next.
The Select Target page appears.

This page lists the Oracle SOA Suite managed server or cluster to which to deploy the SOA composite application archive.

5. Select the partition into which to deploy this SOA composite application.
Partitions enable you to logically group SOA composite applications into separate sections. Even if there is only one partition available, you must explicitly select it. Once deployed, a composite cannot be transferred to a different partition.

If you want to deploy a SOA composite application to a partition that does not exist, exit the wizard and create the partition before deploying the composite. You create partitions in the Manage Partitions page, accessible from the SOA Infrastructure menu.

If the server contains no partitions, you cannot deploy composite applications to that server. Also, if the server is not in a running state, you cannot deploy this archive. By default, a partition named default is automatically included with Oracle SOA Suite. You can delete the default partition.

Note:

Human workflow artifacts such as task mapped attributes (previously known as flex field mappings) and rules (such as vacation rules) are defined based on the namespace of the task definition. Therefore, the following issues are true when the same SOA composite application with a human workflow task is deployed into multiple partitions:

- For the same task definition type, mapped attributes defined in one partition are visible in another partition.

- Rules defined on a task definition in one partition can apply to the same definition in another partition.

If you invoke the Deploy SOA Composite wizard by selecting Deploy To This Partition from the Deployment dropdown list on the Manage Partitions page or home page of a specific partition, the partition to which to deploy is selected. Therefore, the Select Target page is skipped.

6. Click Next.
The Confirmation page appears.

7. Review your selections.
If your SOA composite application is using global token variables, a warning message is displayed asking you to verify that all tokens are configured in the system's mdm-url-resolver.xml file. If the token is not configured in the system or is defined in an incorrect location (for example, the import section of the composite.xml file), the SOA composite application does not deploy and an error message is displayed. For information about managing global token variables, see Managing Global Token Variables for Multiple SOA Composite Applications.

8. Select whether to deploy the SOA composite application as the default revision. The default revision is instantiated when a new request comes in.

9. Click Deploy.
Processing messages are displayed.

At this point, the deployment operation cannot be canceled. Deployment continues even if the browser page is closed.

10. When deployment has completed, the home page of the newly deployed composite revision is displayed automatically. A confirmation message at the top of the page tells you that the composite has been successfully deployed. In the case of a bundle deployment, the Deployed Composites page of the SOA Infrastructure is displayed.

For information about creating configuration plans and deploying applications from Oracle JDeveloper, see Developing SOA Applications with Oracle SOA Suite.

10.1.2 Understanding Additional Deployment Behavior Scenarios

This section describes additional deployment behavior scenarios.

10.1.2.1 PermGen Memory Requirements for Multiple ADF Task Form Deployments

Memory consumption in the SOA and BPM servers increases with the deployment of each ADF task form.

If you must use Oracle JDK for production environments, deploy multiple task forms, and encounter a java.lang.OutOfMemoryError: PermGen space error, update the PermGen memory in $Domain/bin/setSOADomainEnv.sh file (for Unix) or DOMAIN_HOME\bin\setSOADomainEnv.cmd file (for Windows) to a value appropriate to your environment.

10.1.2.2 Deploying SOA Composite Applications with Task Flows

When you deploy a SOA composite application with a task flow Enterprise Resource Archive (EAR) file from Oracle Enterprise Manager Fusion Middleware Control or Oracle WebLogic Server Administration Console to a multiple partition environment, you cannot specify partition details. To specify a partition, modify the hwtaskflow.xml file to include the partition name in the generated EAR file (the project version of the file remains unchanged). This file is located under the TaskForm project adfmsrc directory (for example, HelpDeskRequestTaskFlow\adfmsrc\hwtaskflow.xml). The following example provides the details:

<hwTaskFlows
xmlns="http://xmlns.oracle.com/bpel/workflow/hwTaskFlowProperties">
<ApplicationName>worklist</ApplicationName>
<LookupType>LOCAL</LookupType>
<TaskFlowDeploy>false</TaskFlowDeploy>
<PartitionName>partition2</PartitionName>

If you want to deploy the task flow for the SOA composite application on all partitions, leave PartitionName blank. If you want to use different task flows for the composites on different partitions, then PartitionName must be specified.

In addition, if you want to reuse the same task flow project for another partition, you must change the web context-root.

10.1.2.3 Deploying SOA Composite Applications with ant Scripts and the WLST Command Line Tool

You can also deploy SOA composite applications with ant scripts and the WLST command line tool.

- For information about deploying with ant scripts, see Developing SOA Applications with Oracle SOA Suite.

- For information about deploying with WLST, see WLST Command Reference for SOA Suite.

10.2 Updating Instance, Fault, and Rejected Message States to Aborted During Undeployment or Redeployment

When you undeploy or redeploy a SOA composite application, the behavior of some states of instances, faults, and rejected messages is updated to aborted. This section describes which states are updated to aborted for the following instances, faults, and rejected messages:

- SOA composite business flow instances

- Oracle Mediator instances

- BPEL process instances

- Oracle BPMN instances

- Human workflow task instances

- Business rules instances

- Oracle B2B instances

- Reference binding component instances

- Rejected messages

- Business flow instance faults

Note:

Note the following details about business flow instances:

- Instances no longer marked as aborted can still be purged.

- Instances that are in the completed or failed state are not changed to aborted after undeployment or redeployment. This is a change from Release 11g (11.1.1.6) and earlier.

Table 10-1 shows the states that are updated to aborted during a SOA composite application redeployment or undeployment.

Table 10-1 Instance, Fault, and Rejected Message States Updated to Aborted During Undeployment or Redeployment

Element

Instance, Fault, And Rejected Message States Updated to Aborted

SOA composite business flow instances

The following flow instance states are updated to aborted:

- Running

- Requires recovery

- Suspended

Oracle Mediator instances

The following instance states are updated to aborted when their associated composite is redeployed and undeployed:

- Running

- Requires recovery

BPEL process instances

The following instance states are updated to aborted when their associated composite is redeployed and undeployed:

- Running

- Requires recovery

There are scenarios under which you can redeploy a SOA composite application with the same revision ID and not have the initial instance marked as aborted. For information, see Redeploying SOA Composite Applications with the Same Revision ID Without Changing the Initial Running Instance to Aborted.

Oracle BPMN

The following instance states are updated to aborted when their associated composite is redeployed and undeployed:

- Running

- Requires recovery

Human workflow task instances

The following instance states are updated to aborted when their associated composite is redeployed and undeployed:

- Assigned

- Information requested

- Outcome updated

- Suspended

- Alerted

Business rule instances

The following instance states are updated to aborted when their associated composite is redeployed and undeployed:

- Running

- Completed successfully

- Faulted

Reference binding component instances

Reference binding component instances are not updated to aborted. Instead, the original state for the reference binding component is retained:

- Completed successfully

- Policy faulted

- Business faulted

- Faulted (neither policy or business)

Rejected messages

The following error categories associated with the rejected message are updated to aborted:

- System

- Business

- Policy

- Aborted

- Unknown

Instance faults

The following error categories associated with the business flow instance fault are updated to aborted:

- System

- Business

- Policy

- Aborted

- Unknown

For information about redeployment and undeployment, see Redeploying SOA Composite Applications and Undeploying SOA Composite Applications.

10.3 Redeploying SOA Composite Applications

You can redeploy SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control with the Redeploy SOA Composite wizard. Use of the Redeploy SOA Composite wizard has the following consequences:

- When you undeploy and redeploy the same SOA composite application, you cannot retrieve the business flow instances created prior to composite undeployment. This is because if a composite is deployed, undeployed, and then deployed again, the two composites are not considered the same. Undeployment means the composite (and all related artifacts) has been removed from the system. The redeployed composite is treated as a completely new composite.

- A new version of a revision of a currently deployed SOA composite application is redeployed on the same deployment target (for example, old version 1.0 is redeployed as new version 1.0).

- If the older, currently deployed version of this revision has running instances, you can select whether to change the state of those instances to aborted. See Step 6 for a description of the Running Instances section of the Redeploy SOA Composite wizard and limitations on this option.
The instance state is available in the instance listing, and you can access audit and flow trace details.

For information about instance, fault, and rejected message states that are updated to aborted during redeployment, see Updating Instance_ Fault_ and Rejected Message States to Aborted During Undeployment or Redeployment.

Note:

- If you want to maintain multiple revisions of a deployed application (for example, revisions 1.0 and 2.0), do not use this wizard. Instead, use the Deploy SOA Composite wizard.

- Redeploying multiple SOA composite applications at once is not supported.

To redeploy applications:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Infrastructure Home Page...

From the SOA Composite Menu...

a. Select SOA Deployment >Redeploy.
The Select Composite page appears.

b. In the SOA Composite Deployments section, select the SOA composite application revision you want to redeploy, and click Next.

a. Right-click soa-infra.

b. Select SOA Deployment > Redeploy.
The Select Composite page appears.

c. In the SOA Composite Deployments section, select the SOA composite application revision you want to redeploy, and click Next.

a. Click the Deployed Composites tab.

b. In the Composite table, select a specific SOA composite application. Only one application can be redeployed at a time.

c. Above the Composite table, click Redeploy.

a. Select SOA Deployment > Redeploy.

Note:

You can also access the Redeploy SOA Composite wizard by right-clicking a partition and selecting SOA Deployment > Redeploy.

The Select Archive page appears.

2. In the Archive or Exploded Directory section, select the location of the SOA composite application revision you want to redeploy.

3. In the Configuration Plan section, optionally specify the configuration plan to include with the archive.

4. Click Next.
The Confirmation page appears.

5. In the Default Revision section, select whether to redeploy the SOA composite application as the default revision.

6. In the Running Instances section, select whether to continue running the current business flow instance.

- Change states of running instances to aborted:

- Select to change the states of currently running instances to aborted after redeployment of the SOA composite application.

- Continue instances on redeploy (current instance states will not be changed):

Note:

This option is displayed if Oracle BPM Suite is installed in the SOA Infrastructure, and only supported for the deployment of BPM composites. Do not select this option if you are deploying:

- A SOA composite application from a SOA Infrastructure environment in which Oracle BPM Suite is also installed.

- A BPM composite that includes a durable BPEL process, regardless of whether that process has been modified, or a BPEL process that includes an embedded Java snippet with a dehydration call. Durable BPEL processes are those that take time to complete execution. Examples of durable BPEL processes are asynchronous processes (which are always durable) and synchronous processes that include a durable activity such as a wait activity.
If you select this option and attempt to redeploy a durable BPEL process, then deployment fails.

- Select to continue running instances after redeployment of the BPM composite application. This prevents these instance states from being changed to aborted.
Instances of different service components behave differently after redeployment. Ensure that you understand the following details:

For...

Description

Oracle Business Process Management Notation (BPMN) instances

You must manually migrate instances.

BPMN service component instances are displayed as running in Oracle Enterprise Manager Fusion Middleware Control after redeployment. However, to ensure that your redeployed application is running correctly, search for instances with the pending migration state in Oracle BPM Workspace and manually migrate these instances to the new component definition.

Oracle Business Process Management Notation (BPMN) instances

You must manually migrate instances.

BPMN service component instances are displayed as running in Oracle Enterprise Manager Fusion Middleware Control after redeployment. However, to ensure that your redeployed application is running correctly, search for instances with the pending migration state in Oracle BPM Workspace and manually migrate these instances to the new component definition.

7. Click Redeploy.
Processing messages are displayed.

At this point, the deployment operation cannot be canceled. Deployment continues even if the browser page is closed.

8. When redeployment has completed, click Close.
When redeployment has completed, the home page of the newly redeployed composite revision is displayed. A confirmation message at the top of the page tells you that the composite has been successfully redeployed.

10.3.1 Redeploying SOA Composite Applications with the Same Revision ID Without Changing the Initial Running Instance to Aborted

You can redeploy SOA composite applications with the same revision ID without changing the initial running instance to aborted. Redeployment is permitted in the following situations:

- The composite does not include a durable BPEL process. Durable BPEL processes take time to complete execution. Examples of durable BPEL processes are asynchronous processes (which are always durable) and synchronous processes that include a durable activity such as a wait activity.

- None of the durable BPEL processes have changed since the last deployment.

During redeployment, a check is performed to determine if the BPEL component has changed since the last deployment. If a change is detected, redeployment is rejected.

Note the following guidelines:

- Modifying or deleting partner links is not allowed.

- Dehydration activities must exactly match. For example, if the original BPEL process had three receive activities, the modified process must also have three identical receive activities.

10.3.1.1 Examples of Redeployment Behavior for Synchronous and Asynchronous BPEL Processes

This section provides several examples of redeployment behavior.

Assume you perform the following actions to redeploy a synchronous process:

1. Deploy a SOA composite application that includes synchronous BPEL process A.

2. Initiate several instances of a composite.

3. Modify synchronous BPEL process A by adding and deleting activities.

4. Redeploy the composite in promiscuous mode.

These actions result in the following:

- Older instances of synchronous BPEL process A are not marked as aborted.

- The audit trail of older instances shows the old process execution.

- The audit trail of new instances shows the new process execution.

Assume you perform the following actions to redeploy an asynchronous process waiting on an activity.

1. Deploy a SOA composite application that includes asynchronous BPEL process B. This process is waiting on dehydration activity (wait/receive) act1.

2. Modify asynchronous BPEL process B by adding and deleting activities after act1.

3. Redeploy the composite in promiscuous mode.

These actions result in the following:

- Old instances of asynchronous BPEL process B are not marked as aborted.

- The audit trail of old instances still shows the old process execution.

- The audit trail of new instances shows the new process execution.

- The instances of asynchronous BPEL process B waiting on act1 continue from the activity using the new process definition.

Note:

For asynchronous processes waiting on a human task, the behavior for this scenario is identical to waiting on a receive activity.

Assume you perform the following actions to redeploy an asynchronous process waiting on a deleted activity.

1. Modify asynchronous BPEL process B by adding and deleting activities after act1 and also deleting activity act1.

2. Redeploy the process in promiscuous mode.

These actions result in deployment failing with an error indicating that the new process definition must include the activity act1.

10.4 Undeploying SOA Composite Applications

You can undeploy SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control with the Undeploy SOA Composite wizard. Use of the Undeploy SOA Composite wizard has the following consequences:

- You can no longer configure and monitor this revision of the application.

- You can no longer process instances of this revision of the application.

- The state of currently running instances is changed to aborted and no new messages sent to this composite are processed.

- The instance state of the undeployed composite application is set to aborted. The instance state is available in the instance listing, and you can access audit trail and flow trace details.

- If you undeploy the default revision of the SOA composite application (for example, 2.0), the next active, available revision of the application is automatically designated as the new default (for example, 1.0).

- A warning message is displayed at the end of this wizard when you undeploy the default composite revision.
If no active revision is available and the default revision is undeployed, your composite may be unable to process new incoming requests. It is recommended that you have at least one active revision of this composite deployed before you undeploy the default revision.

If you undeploy this revision and no active revisions of this composite are found, a retired revision is automatically designated as the new default revision. A warning message is displayed after this wizard closes. Although all currently executing instances complete normally in retired composites, they cannot process any incoming requests. To process new incoming requests for this composite after the current default revision is undeployed, you must deploy a new revision or reactivate a previously retired revision.

For information about instance, fault, and rejected message states that are updated to aborted during undeployment, see Updating Instance_ Fault_ and Rejected Message States to Aborted During Undeployment or Redeployment.

Note:

If you want to undeploy and then redeploy an existing revision of this application, do not use this wizard. Instead, use the Redeploy SOA Composite wizard. The Redeploy SOA Composite wizard enables you to redeploy an existing revision of a SOA composite application and remove (overwrite) the older, currently deployed version of the revision.

To undeploy applications:

Note:

You can undeploy multiple SOA composite applications together if they are located in the same partition. For information, see Managing Partitions and Work Manager Groups.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Infrastructure Home Page...

From the SOA Composite Menu...

a. Select SOA Deployment >Undeploy.
The Select Composite page appears.

b. In the SOA Composite Deployments section, select a specific SOA composite application to undeploy, and click Next.

a. Right-click soa-infra.

b. Select SOA Deployment > Undeploy.
The Select Composite page appears.

c. In the SOA Composite Deployments section, select a specific SOA composite application to undeploy, and click Next.

a. Click the Deployed Composites tab.

b. In the Composite table, select a specific SOA composite application. Only one application can be undeployed at a time.

c. Above the Composite table, click Undeploy.

a. Select SOA Deployment > Undeploy.

Note:

You can also access the Undeploy SOA Composite wizard through these additional partition options:

- Right-clicking a partition and selecting SOA Deployment > Undeploy All From This Partition

- Selecting Deployment > Undeploy All From This Partition on the partition home page

- Selecting Deployment > Undeploy All From This Partition for the selected partition from the Manage Partitions page

The Confirmation page appears.

2. If you are satisfied, click Undeploy. You are warned if you are about to undeploy the last remaining revision of a deployed composite application.
Processing messages are displayed.

At this point, the undeploy operation cannot be canceled. Undeployment continues even if the browser page is closed.

3. When undeployment has completed, the SOA Infrastructure Deployed Composites page is displayed automatically. A confirmation message at the top of the page tells you that the composite has been successfully undeployed.

Note:

When a partition is deleted, all SOA composite applications in it are automatically undeployed. A message is displayed indicating that all the applications in that partition are to be undeployed.

10.5 Managing the State of Deployed SOA Composite Applications

You can manage the lifecycle state of deployed SOA composite applications from either of two pages:

- From the Deployed Composites page of the SOA Infrastructure, which lists all SOA composite applications deployed to the SOA Infrastructure

- From the application home page of a specific SOA composite application (all tabs)

The management tasks that you can perform are based on the page you are on. Table 10-2 provides details.

Table 10-2 Application State Actions

Action

Perform on the Deployed Composites Page of the SOA Infrastructure?

Perform on the Application Home Page (All Tabs)?

Shut Down and Start Up

Yes

Yes

Retire and Activate

Yes

Yes

Set as Default

Yes

- No: If only one version of the composite application is set as the default.

- Yes: If there are multiple versions of the same composite application, this option is visible for all other versions of the same composite except the one that is the default.

Deploy

Yes

Yes (through the Composite menu by selecting SOA Deployment > Deploy Another Composite)

Undeploy

Yes

Yes (through the Composite menu by selecting SOA Deployment > Undeploy)

Redeploy

Yes

Yes (through the Composite menu by selecting SOA Deployment > Redeploy)

Test

No

Yes

Settings: Composite Audit Level

No

Yes

Settings: Payload Validation

No

Yes

Settings: Enable/Disable Analytics & Sensors

No

Yes

Show WSDL and endpoint URI icon

No

Yes

Note:

To view the XML definition of the SOA composite application, click the Source tab at the bottom of the Composite Definition tab.

See the following section based on the action you want to perform:

- Managing the State of All Applications at the SOA Infrastructure Level

- Managing the State of an Application from the SOA Composite Application Home Page

For more information, see Introduction to SOA Composite Applications.

10.5.1 Managing the State of All Applications at the SOA Infrastructure Level

You can manage the state of all SOA composite applications from the Deployed Composites page at the SOA Infrastructure level.

To manage the state of all applications at the SOA Infrastructure level:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select Home.

a. Click soa-infra.

a. Select SOA Infrastructure.

2. Click the Deployed Composites tab.
The Deployed Composites page displays the following details:

- A utility for searching for a specific SOA composite application by specifying a full or partial composite name and clicking Search. You can also search for SOA composite applications by partition.

- A checkbox for searching only for activate SOA composite applications.

- A set of options for managing the lifecycle states of SOA composite applications (start up, shut down, set as default, and so on).

- A list of all SOA composite applications deployed in the SOA Infrastructure, including the partition in which they are deployed, current mode (active or retired), and last modification date (deployment time, redeployment time, or any composite configuration change). The green dot to the left of the composite name indicates that this is the default revision of the application.

Note:

To always see the latest details about deployed SOA composite applications, click the Refresh icon in the upper right corner or navigate away from this page and return to it.

3. Click Deploy to deploy a new application. For all other options listed above the Composite section, first select the composite application by clicking the column to the left of the name, then select a specific option to perform.

The following table describes the available options:

Action

Description

Shut Down

Shuts down a running SOA composite application revision. Any request (initiating or a callback) to the composite is rejected if the composite is shut down. New incoming requests cannot be processed. All existing instances are allowed to complete as usual (the same as when a composite is retired).

Note: The behavior differs based on which binding component is used. For example, if it is a web service request, it is rejected back to the caller. A JCA adapter binding component may do something else in this case (for example, put the request in a rejected table).

This option is displayed when the composite application has been started.

Start Up

Restarts a composite application revision that was shut down. This action enables new requests to be processed (and not be rejected). No recovery of messages occurs.

This option is displayed when the composite application has been stopped.

Retire

Retires the selected composite revision. If the process lifecycle is retired, you cannot create a new instance. Existing instances are allowed to complete normally.

An initiating request to the composite application is rejected back to the client. The behavior of different binding components during rejection is as described for the shut down option.

A callback to an initiated business flow instance is delivered properly.

This option is displayed when the composite application is active.

Note the following details when you attempt to retire the default composite revision, or have already retired a default composite revision. A warning page is also displayed with these details.

- When you attempt to retire the default composite revision, if another active revision of the composite is found, it is designated as the new default revision. If there are multiple active revisions, the active composite that was most recently the default revision (based on the time stamp) is designated as the default revision. If you then re-activate the retired revision, it does not automatically become the default revision again. You must explicitly make it the default revision again.

- If you retire the default composite revision and no active revision of this composite is found, a new default revision is not designated and a warning message is displayed. The retired revision remains the default revision. However, this composite can no longer process any incoming requests. To process new incoming requests for this composite, you must deploy a new revision or re-activate one of the previously retired revisions.

Activate

Activates the retired composite application revision. Note the following behavior with this option:

- All composite applications are automatically active when deployed.

- Other revisions of a newly deployed composite application remain active (that is, they are not automatically retired). If you want, you must explicitly retire them.

This option is displayed when the application is retired.

Set As Default

Sets the selected composite application revision to be the default. Default revisions are indicated by a green dot in the Composite table. If a new request comes in for a specific composite application revision, that composite application revision is invoked. If a new request comes in without specifying a revision, the default revision is invoked.

The default revision can change when a composite application is retired. The change is based on whether there is another active revision of the composite. For details, see the description for the Retire action in this table.

The default revision is changed automatically when a default composite application revision is undeployed.

The default composite revision also changes automatically when you redeploy a composite application. The newly redeployed revision automatically becomes the default revision, unless at the time of redeployment, you specify to keep the previous default revision unchanged. For details, see the description of the Undeploy action in this table.

Inbound adapters are activated only on the default revision.

Deploy

Deploys a revision. Deployment activates the composite application in the SOA Infrastructure. Use this selection when you want to deploy:

- A new SOA composite application for the first time.

- A new revision (for example, 2.0) of a SOA composite application that has a different revision that is currently deployed (for example, 1.0). This option enables both revisions 1.0 and 2.0 to be deployed at the same time.

If you specify a revision that exists, you receive an error. You must change this revision outside of the Deploy SOA Composite wizard.

For more information, see Deploying SOA Composite Applications and Managing Partitions and Work Manager Groups.

Undeploy

Undeploys the selected composite application revision. The consequences of this action are as follows:

- You can no longer configure and monitor this revision of the composite application.

- You can no longer process instances of this revision of the composite application.

- You cannot view previously completed processes.

- The state of currently running instances is changed to aborted and no new messages sent to this composite application are processed.

- If you undeploy the default revision of the composite application (for example, 2.0), the next available, active revision of the composite application becomes the default (for example, 1.0).
If no active revision is available and the old default revision is undeployed, your composite may be unable to process new incoming requests. It is recommended that you have at least one active revision of this composite deployed before you undeploy the default revision.

If you undeploy the default revision and no active revisions of this composite are found, a retired revision is automatically designated as the new default revision. A warning message is displayed after this wizard closes. Although all currently executing instances complete normally in retired composites, they cannot process any incoming requests. To process new incoming requests for this composite after the current default revision is undeployed, you must deploy a new revision or reactivate a previously retired revision.

Note: Undeploying multiple SOA composite applications at the same time is supported if they are in the same partition.

For more information, see Undeploying SOA Composite Applications and Managing Partitions and Work Manager Groups.

Redeploy

Redeploys an existing revision of a SOA composite application. The consequences of this action are as follows:

- A new version of a revision of a currently deployed SOA composite application is redeployed (for example, old version 1.0 is redeployed as new version 1.0).

- The older, currently deployed version of this revision is removed (overwritten).

- If the older, currently deployed version of this revision has running instances, you can select whether to change the state of those instances to aborted.

For more information, see Redeploying SOA Composite Applications.

For more information, see Introduction to the Lifecycle State of SOA Composite Applications.

10.5.2 Managing the State of an Application from the SOA Composite Application Home Page

You can manage the state of an individual SOA composite application from the application's home page.

To manage the state of an application from the SOA composite application home page:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. Select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

The Dashboard page of the selected SOA composite application is displayed.

2. From the list of options at the top of the page, select a specific action to perform. These options are also displayed at the top of the Composite Definition, Flow Instances, Unit Tests, and Policies pages of the SOA composite application.

Action

Description

Shut Down

See the table under Step 3 of Managing the State of All Applications at the SOA Infrastructure Level for a description of this option.

Start Up

See the table under Step 3 of Managing the State of All Applications at the SOA Infrastructure Level for a description of this option.

Retire

See the table under Step 3 of Managing the State of All Applications at the SOA Infrastructure Level for a description of this option.

Activate

See the table under Step 3 of Managing the State of All Applications at the SOA Infrastructure Level for a description of this option.

Test

Enables you to initiate a test instance from the Test Web Service page.

Note: This button is disabled when the SOA composite application is stopped or retired. This is because you cannot create an instance of a stopped or retired application. This button is also disabled when there are no web services available for the application. Only composite applications having services with web service bindings can be tested from this page.

For more information, see Initiating a Test Instance of a Business Flow

Settings: Composite Audit Level

Sets the level of audit tracking to perform at the SOA composite application level. This setting can override the audit level defined at the SOA Infrastructure level. By default, the value is Inherit, which does not override the parent level setting.

depicts setting the audit level using the Composite home page.

If you select to set the audit tracking level, the following options are available:

- Inherit: Logging level is inherited from the parent (Service Engine/SOA Infrastructure) audit level. This is the default setting.
See Introduction to the Order of Precedence for Audit Level Settings for more information.

- Production: Minimal information for business flow instances is collected. For example, the BPEL process and Oracle Mediator service engines do not capture the payload. Therefore, the payload details are not available in the flow audit trails. The BPEL process service engine collects payload details for all activities except assign activities. This level is optimal for most standard operations and testing.

- Development: Complete information for business flow instances is collected. This option allows both instance tracking and payload tracking. This setting may have an impact on performance because the payload is stored at each step in the message flow. This setting is useful for debugging purposes.

- Off: No logging is performed. Instance tracking information and payload tracking information are not collected.

Setting audit level tracking at the SOA composite application level overrides the same tracking set at the SOA Infrastructure level. By default, the settings are the same at the SOA composite application and SOA Infrastructure levels. SOA composite application settings are automatically changed when the global SOA Infrastructure settings are changed. By choosing any other setting at the SOA composite application level, you are overriding the inherited settings.

One form of overriding is when you explicitly select the same local composite value that happens to be the current global value. If the SOA Infrastructure setting is then changed, this specific composite application does not inherit the new value. For example, assume the SOA Infrastructure setting is Off. Therefore, all composite applications have their audit tracking set to Off. Then, you explicitly set composite application XYZ to Off. Then, go to the SOA Infrastructure and change the setting to Production. The tracking levels for all composite applications are now Production; except for XYZ, which is still set to Off.

Settings: Payload Validation

Validates the XML schema-based payload at the inbound and outbound points of the composite application revision. If you enable payload validation and there is an invalid payload (that does not follow the schema), a fault is generated for that message.

The exception to this is the response message of a synchronous service. That message is not validated, even with payload validation enabled. The inbound message is still validated; only the outbound message is not.

Settings: Enable/Disable Analytics & Sensors

Select to enable or disable the collection of the following data in the SOA composite application:

- Analytics: Enable you to collect analytic data (BPMN measurement marks and BPEL monitors).

- BPEL Sensors: Enable you to collect sensor data in BPEL faults, activities, and variables. This option is only displayed if the SOA composite application includes BPEL sensors.

- Composite Sensors: Enable you to collect composite sensor data.

You can perform the following data collection actions:

- Globally enable or disable the collection of analytic and sensor data for all SOA composite applications at the SOA Infrastructure level.

- Individually disable the collection of analytics and sensor data for a specific SOA composite application.

For more information, see Configuring Analytics and Sensors and Disabling and Enabling the Collection of Analytic_ BPEL Sensor_ and Composite Sensor Data.

Note: The options of Enable/Disable Analytics & Sensors are only displayed for composites that include a BPEL process service component.

Show WSDL and endpoint URI (icon)

Click to display the endpoint addresses and WSDLs of all external services for this SOA composite application.

Note: If you are using the Safari Browser to view this information, see Limitation on Using the Safari Browser to View WSDL File Content.

The following image depicts an example of setting the audit level from the composite home page:

For more information, see the following sections:

- Introduction to the Lifecycle State of SOA Composite Applications

- Configuring SOA Infrastructure Properties

10.5.3 Understanding Additional Lifecycle State Behavior Scenarios

This section describes additional lifecycle state behavior issues.

10.5.3.1 Starting and Stopping a Managed Oracle WebLogic Server on Which the SOA Infrastructure is Deployed in the Middle of BPEL Processing

If you start and stop a managed Oracle WebLogic Server on which the SOA Infrastructure is deployed in the middle of BPEL processing in a SOA composite application, note the following issues:

- For synchronous BPEL processes
The whole scenario is synchronous and the instances that are in a running state (after server restart) are pending in the BPEL wait activity. Therefore, the flow thread ends with the server (while sleeping in the wait activity). When the server is restarted, the same instance is not restarted because the flow is synchronous. Therefore, these instances always remain in a running state because no processing can happen on them after server restart.

- For asynchronous BPEL processes
If server shutdown occurred in the middle of a BPEL invoke activity, the messages received by BPEL are not handled. BPEL does not automatically recover these messages during restart; they must be recovered manually.

10.5.3.2 Setting the Business Flow Instance Name

You can set the business flow instance name during design time for Oracle Mediator and Oracle BPEL Process Manager. For more information, see Section "How to Set the Business Flow Instance Name or Composite Instance Name at Design Time" of Developing SOA Applications with Oracle SOA Suite.

10.6 Automating the Testing of SOA Composite Applications

You can create, deploy, and run test cases that automate the testing of SOA composite applications. Test cases enable you to simulate the interaction between a SOA composite application and its web service partners before deployment in a production environment. This helps to ensure that a process interacts with web service partners as expected by the time it is ready for deployment to a production environment.

You create test cases in Oracle JDeveloper and include them in a SOA composite application that is then deployed and administered from either of the following locations:

- From Oracle Enterprise Manager Fusion Middleware Control (as described in this section)

- From Oracle JDeveloper
For more information, see Section "How to Deploy and Run a Test Suite from Oracle JDeveloper" of Developing SOA Applications with Oracle SOA Suite.

You can also create BPEL process service component test cases in the SOA composite application test case.

To automate the testing of SOA composite applications:

Note:

Before testing SOA composite applications or BPEL process service components from Oracle Enterprise Manager Fusion Middleware Control, see Chapter "Automating Testing of SOA Composite Applications" of Developing SOA Applications with Oracle SOA Suite for instructions on creating test cases.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select Home.

b. Select Deployed Composites.

c. In the Composite section, select a specific SOA composite application.

d. Click the Unit Tests tab.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

c. Click the Unit Tests tab.

a. Select Unit Test.

The test cases that are displayed were designed in Oracle JDeveloper and included in a deployed SOA composite application.

2. Select the entire test suite or individual tests of a suite to run, and click Execute.

You are prompted to create a test.

3. Enter the following values, and click OK.

Field

Description

Test Run Name

Enter a name for the test instance. When testing is complete, report details are captured under this name.

Timeout

Enter a value in seconds in which to complete this test. If the test does not complete within this time limit, then testing is terminated.

Number of Concurrent Test Instances

Enter the number of test instances to create.

The Test Runs page is automatically displayed for tracking the running tests.

The Test Runs page enables you to track running test cases and view test results. Test suites consist of a logical collection of one or more test cases. Each test case contains a set of commands to perform as the test instance is executed. The execution of a test suite is known as a test run.

4. In the Test Run Name column, click a specific test run to display details in the Results of Test Run section. If you want to create more test runs, you can switch back to the Test Cases page at any time.
The Results of Test Run section displays details about the executed test run, such as a test summary and the success rate. Under the weblogic link, click Help > Help for This Page for additional details.

5. View assertion details at the bottom of the page. Assertions enable you to verify variable data or process flow.

6. Click an instance number to view specific test details.
The business flow instances created by executing unit test runs are displayed with a yellow square. This yellow box distinguishes these instances from test instances created on the Test Web Service page or automatically created by external consumers of the application.

For more information, see the following documentation:

- Introduction to SOA Composite Application Automated Testing

- Chapter "Automating Testing of SOA Composite Applications" of Developing SOA Applications with Oracle SOA Suite for instructions on creating and running test cases for SOA composite applications and BPEL process service components in Oracle JDeveloper

10.6.1 Increasing Response Message Size When Executing Test Suites in Bulk

When executing test suites with large numbers of tests in bulk (for example, with 50 tests) with the sca-test ant command, the Results tab of the Unit Tests page in Oracle Enterprise Manager Fusion Middleware Control may not display any test results. The following error message appears in the server log files:

<Nov 13, 2013 7:31:45 AM PST> <Error> <Socket> <BEA-000403> <IOException
occurred on socket:
Socket[addr=2606:b400:2010:4049:216:3eff:fe52:613d/2606:b400:2010:4049:216:3ef
f:fe52:613d,port=16139,localport=3872]
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'.
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'
at
weblogic.socket.BaseAbstractMuxableSocket.incrementBufferOffset(BaseAbstractMu
xableSocket.java:230)
at
weblogic.rjvm.t3.MuxableSocketT3.incrementBufferOffset(MuxableSocketT3.java:35
1)
at weblogic.socket.SocketMuxer.readFromSocket(SocketMuxer.java:991)
at
. . .
. . .

This error can occur when the test response message is too large. To resolve this error, increase the MaxMessageSize property.

To increase the response message size:

1. Open the setDomainEnv.sh file.

2. Set MaxMessageSize to a larger value.

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Dweblogic.MaxMessageSize=30000000" export EXTRA_JAVA_PROPERTIES
How to Manage SOA Composite Applications with ant Scripts

For information about the sca-test ant script, see the "Deploying and Managing SOA Composite Applications with ant Scripts" section of Developing SOA Applications with Oracle SOA Suite.

10.7 Managing SOA Composite Application Policies

You can attach or detach security policies to and from currently deployed SOA composite applications. Policies apply security to the delivery of messages. Policies can require a credential to be entered in the CSF keystore or a certificate to be entered into the certificate store.

Note:

- Before attaching policies, see Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use in your environment.

- For information about overriding policy settings, see Section "Overriding Policy Configuration Properties Using Fusion Middleware Control" of Securing Web Services and Managing Policies with Oracle Web Services Manager.

To manage SOA composite application policies:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select Home.

b. Select Deployed Composites.

c. In the Composite section, select a specific SOA composite application.

d. Click the Policies tab.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

c. Click the Policies tab.

a. Select Policies.

The Policies page enables you to attach and detach policies to and from SOA composite applications. The policies table displays the attached policy name, the component to which the policy is attached, the policy reference status (enabled or disabled) that you can toggle, the category (such as Management, Reliable Messaging, MTOM Attachment, Security, or WS-Addressing), the violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

2. Click Attach/Detach To.
If multiple services or components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

3. Select the component to or from which to attach or detach a policy.

This invokes a dialog for attaching or detaching policies.

Currently attached policies appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

4. Select policies to attach that are appropriate to your environment.

5. Click Attach.
The attached policy appears in the Directly Attached Policies section.

6. Attach additional policies as needed.

7. When you are finished attaching policies, click Validate.

8. If an error message appears, make the necessary corrections until you no longer have any validation errors.

9. Click OK.
The attached policy is displayed in the policies table.

For more information about policies, see the following documentation:

- Introduction to Policies

- Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use for your environment

10.7.1 Policy Subject of a Local Policy Can Become Invalid After a Server Restart

The policy subject of a local policy attached to a SOA composite application can become invalid after a server restart. You must invoke the WSLT listWebServicePolicies command a second time to resolve this issue. For example, perform the following steps:

1. Restart the SOA server.

2. Issue the following WLST command with data appropriate to your environment.

wls:/soainfra/serverConfig>
listWebServicePolicies('','default/LocalPolicyTest[1.0]','soa','
bpelprocess1_client_ep','BPELProcess1_pt')

BPELProcess1_pt :
URI="oracle/wss_username_token_service_policy",
category=security, policy-status=null; source=local policy set;
reference-status=enabled; effective=true
Property name="local.policy.reference.source",
value="LOCAL_ATTACHMENT"

The policy subject is invalid in this context:, and the following error is displayed.

WSM-02557 : The documents required to configure the Oracle Web Services
Manager runtime have not been retrieved from the Policy Manager
application (wsm-pm), possibly because the application is not running
or has not been deployed in the environment. The query
"/policies/oracle/wss_username_token_service_policy" is queued for later
retrieval.

3. Issue the same WLST command a second time.

The command is successful this time, as indicated by the following message.

The policy subject is secure in this context.

10.7.2 Policy Attachments and Local Optimization in Composite-to-Composite Invocations

OWSM supports an Oracle SOA Suite local optimization feature for composite-to-composite invocations in which the reference of one composite specifies a web service binding to a second composite. Local optimization enables you to bypass the HTTP stack and SOAP/normalized message conversions during runtime. Local optimization is not used if the composites are in different containers. If a policy is attached to the web service binding, the policy may not be invoked if local optimization is used.

By default, an OWSM security policy includes a local-optimization property that identifies if the policy supports local optimization. You can view the setting for a policy in Oracle Enterprise Manager Fusion Middleware Control.

To view the local optimization setting for policies:

1. In the navigator, expand the WebLogic Domain folder.

2. Right-click WLS_SOAWC, and select Web Services > Policies.

3. Select a policy and click Export to File.

4. Open the file with a text editor and search for local-optimization to identify the value. This property supports the following values:

- on: Local optimization is used in the attached policy, and the policy is not applied at runtime.

- off: Local optimization is not used in the attached policy, and the policy is applied at runtime.

- check-identity: If a JAAS subject exists in the current thread, local optimization is used. Otherwise, local optimization is not used.

For information on the default local optimization settings for security policies, see Securing Web Services and Managing Policies with Oracle Web Services Manager.

You can override the local optimization setting for a policy by adding the oracle.webservices.local.optimization property in the binding section of the composite.xml file. The following values are supported:

- true (default value): Local optimization is used, and the policy is applied if it is applicable to optimized calls (details are defined in the individual policy file).

- false: Local optimization is not used, regardless of the default setting for the local-optimization property at the OWSM policy level. This setting forces the policy to be applied.

For example, the following setting of false causes oracle/wss_username_token_client_policy to be applied.

<binding.ws
port="http://xmlns.oracle.com/CalledBPELProcessApp_
jws/CalledBPELProcess/CalledBPELProcess#wsdl.endpoint(calledbpelprocess_client_
ep/CalledBPELProcess_pt)"

location="http://myhost.us.example.com:8001/soa-infra/services/default/CalledBPEL
Process!1.0/calledbpelprocess_client_ep?WSDL">
<wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
orawsp:category="security"
orawsp:status="enabled"/>
<wsp:PolicyReference URI="oracle/log_policy"
orawsp:category="management"
orawsp:status="enabled"/>
<property
name="oracle.webservices.local.optimization">false</property>
</binding.ws>

For more information about local optimization, see Configuring Local Optimization

10.7.3 WS-RM Sessions

Multiple requests from Oracle SOA Suite in a single WS-RM session are not currently supported. Each request is in an individual WS-RM session.

10.8 Exporting a Deployed SOA Composite Application

You can export the contents of a deployed SOA composite application to an archive JAR file. The file can include some or all of the following data:

- The original design-time composite

- Postdeployment changes in the rules dictionary and domain value maps (DVMs)

- Postdeployment property changes such as binding component properties, composite properties such as audit level settings and payload validation status, and policy attachments

Note:

- SOA composite application exporting is currently only allowed at the individual SOA composite level.

- Shared data is not exported as part of the composite export SOA archive (SAR).

To export a running SOA composite application:

1. Go to the home page of the SOA composite application to export.

2. From the SOA Composite menu, select Export.

The Export Composite page appears.

3. Select an option.

- Option 1: Generates an archive file containing the original design-time composite and the postdeployment details described in Option 2 and Option 3.

- Option 2: Includes the original design-time composite and postdeployment changes in the rules dictionary and DVMs.

- Option 3: Includes the original design-time composite and postdeployment property changes such as binding component properties, and composite properties such as audit level settings and payload validation status.

- Option 4: Generates an archive file containing only the original design-time composite. Options 2 and 3 are not included.

4. If you want to append an additional name to the existing file, select Specify Custom Extension Text. For example, adding MyText to a file named sca_OrderBookingComposite_rev1.0.jar names the exported file as sca_OrderBookingComposite_rev1.0-MyText.jar.

5. Click Export.

The Processing: Export Composite dialog displays the progress of archive file generation. When generation completes, you are prompted to save the file.

6. Click Save File.

A dialog appears for either opening or saving the file to a directory on your local host.

Note:

It is important that you click the Save File button. Do not close this dialog. Although the composite is exported, you cannot retrieve the actual exported file.

7. Specify the local directory in which to save the JAR file.

8. In the upper right of the Processing: Export Composite dialog, click the x icon to close the dialog.

9. On the Export Composite page, note that the Cancel button has changed to Done.

10. Click Done.

The dialog is closed and you are returned to the SOA composite application home page.

10.9 Disabling and Enabling the Collection of Analytic, BPEL Sensor, and Composite Sensor Data

You can enable and disable the collection of data for the following analytics and sensors in SOA composite applications:

- Analytics (consist of BPMN measurement marks and BPEL monitors):
Enable you to collect the following types of data:

- Business indicator measurements at a certain point in the process or in a section of the process.

- BPEL process metrics that are sent to Oracle BAM Server, and then used for analysis and graphical display.

- BPEL sensors:
Enable you to collect sensor data in BPEL faults, activities, and variables.

- Composite sensors:
Enable you to collect composite sensor data:

- Monitor incoming and outgoing messages.

- Specify composite sensor details in the Flow Instance filter of the Search Options section of the Flow Instances page. This action enables you to locate a particular instance.

- Publish JMS data computed from incoming and outgoing messages.

You can globally enable and disable the collection of analytic and sensor data at the SOA Infrastructure level or you can individually disable the collection of analytics and sensor data composite level. The following order of precedence occurs when disabling or enabling a selection on the SOA Infrastructure Common Properties page or the individual SOA composite application page:

- Disabling a selection on the Common Properties page disables the collection of data for that selection for all SOA composite applications. For example, if you disable composite sensors on the Common Properties page, composite sensor details are not collected for any flow instances created after this change.

- Enabling a selection on the Common Properties page enables you to disable that setting at the individual SOA composite application level. For example, if you enable composite sensors on the Common Properties page and disable composite sensors for an individual SOA composite application (for example, named LoanFlow) on its home page under Settings > Enable/Disable Analytics & Sensors, composite sensor details are not collected for any instance of the LoanFlow SOA composite application after this change. However, all other flow instances continue to collect composite sensor details.

You cannot selectively enable or disable sensors defined for a specific type of service component for just one composite. However, you can globally disable service component-type specific sensors for all composites on the SOA Infrastructure Common Properties page.

Note:

Disabling BPEL sensors on the BPEL Service Engine Properties page has the same effect as disabling BPEL sensors on the SOA Infrastructure Common Properties page.

For more information about BPEL sensors, see Section "Using Oracle BPEL Process Manager Sensors and Analytics" of Developing SOA Applications with Oracle SOA Suite.

For more information about BPMN measurements, see Developing Business Processes with Oracle Business Process Management Studio.

10.9.1 Disabling Analytics and Sensors for a Specific SOA Composite Application

To disable analytics and sensors for a specific SOA composite application:

1. Access the SOA Infrastructure Common Properties page by following the steps in Configuring Analytics and Sensors

All analytics, BPEL sensors, and composite sensors are enabled by default.

2. Go to the home page of the SOA composite application in which you want to disable analytics and sensors.

3. From the Settings menu of the composite, select Enable/Disable Analytics & Sensors.

All analytics and sensors are enabled by default. Since this composite includes BPEL sensors, they are displayed in this message. If there are no BPEL sensors in a composite, the BPEL Sensors checkbox is not displayed.

4. Disable all analytics and sensors, and click OK.

This disables the collection of analytic and sensor data for this specific SOA composite application. Because the collection of all analytic and sensor data is enabled at the SOA Infrastructure level, all other SOA composite applications in the SOA Infrastructure continue to collect data.

10.9.2 Disabling Analytics and Sensors for All SOA Composite Applications

To disable analytics and sensors for all SOA composite applications:

1. Access the SOA Infrastructure Common Properties page by following the steps in Configuring Analytics and Sensors

2. In the Analytics and Sensors Configuration section, disable all checkboxes.

3. Click Apply, then Yes when prompted to save your changes.

4. Go to the home page of SOA composite applications.

5. From the Settings menu, select Enable/Disable Analytics & Sensors.

The Enable/Disable Analytics & Sensors dialog shows that all analytics and sensors are globally disabled for this composite and all other composites.

10.9.3 Selectively Disabling Specific Analytic and Sensor Settings for All SOA Composite Applications

To selectively disable specific analytic and sensor settings for all SOA composite applications:

1. Return to the SOA Infrastructure Common Properties page and select all checkboxes except Composite Sensors.

2. Click Apply, then Yes when prompted to confirm.

3. Go to the home page of SOA composite applications.

4. From the Settings menu, select Enable/Disable Analytics & Sensors.

Note that composite sensors are globally disabled.

10.10 Linking to Runtime Applications

Some runtime applications such as Oracle SOA Composer include a Links main menu with references to other runtime applications. Figure 10-1 shows the Links menu.

Figure 10-1 Links Main Menu in Runtime Application

A link is only shown when the application is running and accessible. The following runtime applications are supported for links:

- Oracle SOA Composer

- Oracle BPM Worklist

- Oracle Business Process Composer

- Oracle Business Process Management Workspace

- Oracle B2B Console

- Oracle SOA Suite for Healthcare

- Oracle MFT Console

You can customize the Links main menu to display the URLs of other applications.

To customize the Links main menu:

1. Create a file named ext-app-menu.xml that lists the runtime application and its URL and port. The content of this file looks as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:appMenu xmlns:ns2="http://xml.oracle.com/soa/appMenu">
<groups>
<group>
<app name="Oracle OTN" url="http://otn.oracle.com"/>
<app name="Oracle Home Page" url="http://www.oracle.com"/>
</group>
<group>
<app name="MyApplication" url="http://www.myapplication.com"/>
</group>
</groups>
</ns2:appMenu>

2. Add ext-app-menu.xml to the $ORACLE_HOME/soa/soa/modules/oracle.soa.ext_11.1.1/classes/META-INF directory.

3. Change your current directory to $ORACLE_HOME/soa/soa/modules/oracle.soa.ext_11.1.1.

4. Run ant.

Buildfile: build.xml
create-manifest-jar:
[delete] Deleting:
/scratch/bdhenriq/fmwhome12/soa/soa/modules/oracle.soa.ext_
11.1.1/oracle.soa.ext.jar
[jar] Building MANIFEST-only jar:
/scratch/myhome/fmwhome12/soa/soa/modules/oracle.soa.ext_
11.1.1/oracle.soa.ext.jar
BUILD SUCCESSFUL
Total time: 0 seconds

5. Restart the server.

11 Managing SOA Composite Application Business Flow Instances

This chapter describes how to manage SOA composite application business flow instances, including initiating a test instance of an application and tracking business flow instances of the SOA composite application.

This chapter includes the following sections:

- Initiating a Test Instance of a Business Flow

- Tracking Business Flow Instances at the SOA Composite Application Level

11.1 Initiating a Test Instance of a Business Flow

This section describes how to initiate a test instance of a deployed SOA composite application.

To initiate a SOA composite application test instance:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the Composite Menu...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite table, select a specific SOA composite application.

d. At the top of the composite home page, click Test.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

c. At the top of the composite home page, click Test.

a. Select Test Service > client_name.

Note:

The Test button is disabled in the following situations:

- The SOA composite application revision is stopped or retired.

- There are no web services available for the application. Only composites having services with web service bindings can be tested from this page.

2. If the composite includes multiple services, the Test button has a drop-down list to select the service to test.
The Test Web Service page for initiating an instance appears.

This page provides many options for initiating an instance. At a minimum, you must specify the XML payload data to use in the Input Arguments section at the bottom of the page. For more information about the fields on this page, select Help > Help for This Page from the weblogic menu in the upper right corner.

For additional details about using the Test Web Service page, see Administering Web Services.

The WSDL file and endpoint URL are populated automatically based on the service you selected to test. The endpoint URL is derived from the WSDL and can be overridden to invoke that service at a different location. If the service selected has multiple ports, a drop-down list is displayed. Otherwise, the port of the current service is displayed.

Field

Description

Parse WSDL or WADL

If you change the WSDL or Web Application Description Language (WADL) file, click this link to reload the file.

WADL files are used with REST operations. For more information, see Chapter "Integrating REST Operations in SOA Composite Applications" of Developing SOA Applications with Oracle SOA Suite.

If the WSDL URL does not contain the revision number, it is processed by the default composite application. For example, if there are two revisions of a composite application named HelloWorld, then the following endpoints are exposed by them:

- http://host:port/soa-infra/services/default/HelloWorld!1.0/client

- http://host:port/soa-infra/services/default/HelloWorld!2.0/client

However, if the WSDL specified for web service invocation does not contain the revision details (for example, http://host:port/soa-infra/services/default/HelloWorld/client), it is processed by the composite revision that is set as default.

HTTP Basic Auth Option for WSDL or WADL Access

Click to insert the username and password credentials in the HTTP transport header. Both the Username and Password fields are required.

Operation

Select the operation that you want to test from the Operation menu. The available operations are determined from the WSDL.

To test a REST service, select the GET or POST service port operation.

Edit Endpoint URL

Click to edit the endpoint URL.

3. Accept the default values for these fields or provide values appropriate to your test environment.
The lower part of the Test Web Service page consists of the Request tab. This tab enables you to specify security, quality of service, HTTP transport, stress testing options, and XML input arguments:

The Security section enables you to test web services security. This section includes the following fields for passing security properties with messages:

Field

Description

OWSM Security Policies

Inserts a WS-Security SOAP header. The Username field is required, and the Password field is optional. When you select this option, the page is refreshed to display security policies for selection.

HTTP Basic Auth

Inserts the username and password credentials in the HTTP transport header. Both the Username and Password fields are required.

Advanced

Uses a custom policy to authenticate the user (specifies the URI for the custom policy). The Username and Password fields are optional.

None

Select to not specify security credentials. This is the default selection.

When testing REST services, the SOAP protocol is not used. The only security options are HTTP Basic Auth or None.

4. Accept the default values for these fields or provide values appropriate to your test environment.
The Quality of Service section enables you to test Reliable Messaging (WS-RM), Message Transmission Optimization Mechanism (MTOM), or WS-Addressing. This section is not available when testing REST services. This section includes the following fields:

Field

Description

WS-RM

Select one of the following options for testing WS-Reliable Messaging protocol policies. Reliable messaging policies support this protocol, which guarantees the end-to-end delivery of messages.

- WSDL Default: Executes the default behavior of the WSDL. For example, if the WSDL contains a reference to a WS-RM policy, then the policy is enforced. If the WSDL does not contain a reference to a WS-RM policy, then reliable messaging is not tested.

- None: No policy for WS-RM is tested even if the WSDL contains a reference to a policy.

- Custom: Enforces a custom policy. Specify the URI of the custom policy in the Policy URI field. If a WS-RM policy is referenced in the WSDL, it is ignored, and the policy specified in the Policy URI field is used instead.

MTOM

Select one of the following options for testing MTOM policies. MTOM policies ensure that attachments are in MTOM format, a format for efficiently sending binary data to and from web services.

- WSDL Default: Executes the default behavior of the WSDL. For example, if the WSDL contains a reference to an MTOM policy, then the policy is enforced. If the WSDL does not contain a reference to an MTOM policy, then MTOM is not tested.

- None: No policy for MTOM is tested, even if the WSDL contains a reference to a policy.

- Custom: Enforces a custom policy. Specify the URI of the custom policy in the Policy URI field. If an MTOM policy is referenced in the WSDL, it is ignored, and the policy specified in the Policy URI field is used instead.

WS-Addressing

Select one of the following options for testing WS-Addressing policies. WS-Addressing policies verify that SOAP messages include WS-Addressing headers in conformance with the WS-Addressing specification.

- WSDL Default: Executes the default behavior of the WSDL. For example, if the WSDL contains a reference to a WS-Addressing policy, then the policy is enforced. If the WSDL does not contain a reference to a WS-Addressing policy, then WS-Addressing is not tested.

- None: No policy for WS-Addressing is tested even if the WSDL contains a reference to a policy.

- Custom: Enforces a custom policy. Specify the URI of the custom policy in the Policy URI field. If a WS-Addressing policy is referenced in the WSDL, it is ignored, and the policy specified in the Policy URI field is used instead.

5. Accept the default values for these fields or provide values appropriate to your test environment.
The HTTP Header section enables you to add, modify, or delete HTTP headers to pass request information to a web service. This section is not available when testing REST services. This section includes the following fields:

Field

Description

Add

Click to add a new row for an HTTP header, and then enter the appropriate information in the Name and Value fields.

Delete

Place this curser in either the Name or Value field and click to remove the selected HTTP header row.

6. Accept the default values for these fields or provide values appropriate to your test environment.
The Additional Test Options section includes the following fields. This section provides a simple stress test that simultaneously invokes multiple instances.

Note:

This is not a real stress test tool. Therefore, do not enter huge values for both concurrent threads and the number of times to invoke the operation. Doing so can result in errors.

Field

Description

Enable Stress Test

Click Enable to create a simple stress test. With this enabled, no conversation ID is displayed.

Concurrent Threads

Enter the number of concurrent threads on which to send the invocations. The default is 5 threads.

Loops per Thread

Enter the number of times to invoke the operation. The default is 10 times.

Delay in Milliseconds

Specify the delay of milliseconds to wait between operation invocations. The default is 1000 milliseconds (1 second).

Asynchronous Test Response

When testing an asynchronous web service, this specifies whether to request an asynchronous response upon running the test.

- Resource Key: When testing an asynchronous web service, enter a value (for example, testkey) that correlates with the asynchronous response. Each response key must be unique. The asynchronous response can also be tracked later on the Asynchronous Test Response page by specifying the associated response key.

- None: Select if you do not want to specify a resource key.

7. Accept the default values for these fields or provide values appropriate to your test environment.
The Input Arguments section includes the following fields for entering XML payload data.

Field

Description

Tree View

Displays a graphical interface of text fields in which to enter information. This field automatically generates the required headers and XML structure.

XML View

Displays the XML file format for inserting values. You can paste the raw XML payload of your message into this field.

Enable Validation

Select to enable validation of the input arguments.

8. Click Test Web Service.
The test results appear in the Response tab upon completion.

Note:

The Response tab does not display payload data if you are performing a stress test or are testing an asynchronous service.

9. Click Launch Flow Trace to access the flow trace of the instance. The ID of the new flow instance is displayed in the top right corner of the Flow Trace page.

10. To return to the composite home page, click the name of the composite that appears at the top of the page or select Home from the composite target menu. On the composite home page, click Flow Instances and then click Recent Instances. The new test instance is displayed at the top of the instances table.

For more information, see the following sections:

- Introduction to Business Flow Instances for conceptual details about instances

- Introduction to Policies for an overview of policies

- Administering Web Services for specific details about policies and testing web services from the Test Web Service page

11.1.1 Specifying RPC/Literal-Style WSDL Files on the Test Web Service Page

If you are specifying an RPC/literal-style WSDL file with a message defined by "element=" in the Test Web Service page in Oracle Enterprise Manager Fusion Middleware Control, use the XML View option of the Input Arguments section to modify the SOAP message. The SOAP body should look like the following:

<soap:Body>
<ns:initiate>
<payload>
<value xmlns="...">3</value>
</payload>
</ns:initiate>
</soap:Body>

where initiate is the operation name, payload is the part name, and value is the element defined in the WSDL message/part.

11.2 Tracking Business Flow Instances at the SOA Composite Application Level

In addition to tracking business flow instances in the SOA Infrastructure and in an individual partition, you also can track instances on the Flow Instances page of a specific SOA composite application. A business flow instance corresponds to an end-to-end business transaction. Business flows consist of a single SOA composite application or multiple SOA composite applications connected together to fulfill a specific business process.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

2. Click Flow Instances.

The Flow Instances page displays the following details:

- A utility for specifying and saving comprehensive instance and fault search criteria and executing Search.

Note:

When you initially access the Flow Instances page, the Search Results table is empty. You must click Search to populate this table with business flow instance details.

- A Search Results table that displays the flow trace ID that uniquely identifies a business flow, the composite initiating the business flow (business flows can span multiple composites), the state of the flow instance (for example, completed successfully, running, failed, recovery required, and so on), the instance start time, the last update to the instance, the partition in which this flow was initiated, the flow instance name (if set during design time in a BPEL process or Oracle Mediator service component), and a link to the log files. To display additional columns in the table, select View > Columns.

Note:

The Flow Instances page of the individual SOA composite application does not include a link to the Error Hospital page. To access that functionality, go to the Flow Instances page of the SOA Infrastructure or individual partition and search with similar criteria, restricting your search to the appropriate SOA composite application.

You can perform the following business flow instance tasks:

- Specifying and Saving Business Flow Search Criteria

- Deleting or Terminating Business Flow Instances

- Viewing the Current State of the Business Flow Instance

- Recovering from Faults in a Business Flow Instance

- Viewing Composite Sensor Values in a Business Flow Instance

- Viewing the Initiating and Participating SOA Composite Applications in a Business Flow Instance

- Viewing Resequencing Groups in a Business Flow Instance

12 Developing a Database Growth Management Strategy

This chapter describes how to develop a database growth management strategy, including determining the optimal profile or size for the database; monitoring disk space usage, hardware resources, and database performance; understanding growth management challenges and testing strategies; and understanding space management.

This chapter includes the following sections:

- Introduction to Planning for Database Growth

- Identifying the Profile or Size of the Database

- Monitoring Space Usage_ Hardware Resources_ and Database Performance

- Understanding Growth Management Challenges and Testing Strategies

- Understanding Space Management

For information about managing database growth with the purge scripts and component table partitioning, see Managing Database Growth .

For information about troubleshooting, see Parallel Purging and Table Partitioning Issues.

Note:

This chapter is intended for database administrators.

12.1 Introduction to Planning for Database Growth

An Oracle SOA Suite 12c installation presents several challenges for database administrators, including managing the growth of the Oracle SOA Suite database. Underestimating the importance of managing the database can lead to issues when the database is moved to a production environment. This chapter helps you determine an appropriate strategy and highlights the need for capacity planning, testing, and monitoring.

The recommended strategies are based on the profile or the predicted size of the Oracle SOA Suite installation. The tools and techniques that implement the strategies are straight forward, which helps to simplify the recommendations. However, this does restrict administrators to a set of tools that must be implemented as designed.

Testing and monitoring are required to determine the effectiveness and resource requirements of a growth management strategy. Thorough testing ensures that the tools, the database, and hardware resources all come together to meet the needs of current and future database growth estimates.

12.2 Identifying the Profile or Size of the Database

This section describes how to identify the profile or size of the Oracle SOA Suite database to determine an optimal growth management strategy. For more information, see Understanding Growth Management Challenges and Testing Strategies.

The calculations detailed in this section approximate disk space usage and are not a replacement for conducting a thorough space capacity plan. However, the estimates are sufficient to draw conclusions on the appropriate growth management strategy, while highlighting the need for disk space planning.

Note:

This section provides frequent references to Monitoring Space Usage_ Hardware Resources_ and Database Performance for details about space calculation instructions.

Table 12-1 provides a profile of small, medium, and large installations based on the composite space persisted daily and the minimum retention space. These two metrics are related in an and/or condition because the retention policy may not retain more than several days of data, but instance inflow may be high.

Table 12-1 Oracle SOA Suite Database Profiles

Database Profile

Composite Space Persisted Daily

Minimum Retention of Space

Small

< 10 GB

< 100 GB

Medium

10-30 GB

100-300 GB

Large

> 30 GB

> 300 GB

12.2.1 Identifying the Inflow of Data

The rate of composite inflow and space usage is best understood as an average derived after many days of load testing. This allows for allocated space (segment extents) to be better utilized. To understand inflow, the following data points are investigated:

- Identifying the Number of Instances Produced Daily.

- Identifying the Disk Space Used by Each Instance.

- Identifying the Composite Space Persisted Daily.

- Analyzing Space Distribution of Segments.

12.2.1.1 Identifying the Number of Instances Produced Daily

Use the following formula to identify the number of instances produced daily:

Daily-inflow-composite = (Instance Total / Period)

For example, calculate the average number of instances produced daily based on 5 days of load testing with a total composite count of 100,000:

(20,000 = (100,000 / 5))

For more information, see Determining the Growth Trend of Components.

12.2.1.2 Identifying the Disk Space Used by Each Instance

Use the following formula to identify the disk space used by each instance:

Inflow-space-per-instance = (SOA Schema Size /Instance Total)

For example, calculate the average disk space used by each instance with a total of 100,000 composites and an Oracle SOA Suite schema size of around 200 GB:

(2MB = (200 GB / 100,000))

For more information, see Determining the Growth Trend of the Schema.

12.2.1.3 Identifying the Composite Space Persisted Daily

Use the following formula to identify the composite space persisted daily:

Daily-inflow-composite-space = (Daily-inflow-composite * Inflow-space-per-composite)

For example, calculate the average disk space used by composites daily with 20,000 composites daily of 2 MB each:

(40 GB = (20,000 * 2 MB))

Alternatively:

Daily-inflow-composite-space = (SOA Schema Size / Period)

12.2.1.4 Analyzing Space Distribution of Oracle SOA Suite Segments

Analyze the shape of the Oracle SOA Suite schema so that the distribution of segment space (tables, indexes, and large objects (LOBs)) is understood and segments that may be problematic are identified:

- Determine the growth trend of the components. For more information, see Determining the Growth Trend of Components.

- Collect component statistics after each day of load testing so that growth averages can be determined.

- Determine the growth trend of the Oracle SOA Suite schema. For more information, see Determining the Growth Trend of the Schema.

- Collect schema sizing statistics after each day of load testing so that growth averages can be determined.

- Determine the largest segments. For more information, see Determining the Largest Segments.

- Determine the growth trend of tables and indexes. For more information, see Determining the Growth Trend of Tables and Indexes.

- The growth statistics for table and indexes are automatically gathered through the Automatic Workload Repository (AWR).

For more information, see Determining the Growth Trend of Components.

12.2.2 Developing a Retention Policy

You must consider how long composites are retained in the database. This affects the size of the Oracle SOA Suite schema and the performance of the purge scripts. The following factors drive the retention policy:

- Legal requirements

- Line of business requirements

- Overall company policy on retention of data

The longer the retention policy, the greater the volume of data that must be stored and, correspondingly, the higher the disk capacity requirements.

12.2.2.1 Determining the Minimum Retained Disk Space

Use the following formula to identify the minimum retained disk space. For information about identifying Daily-inflow-composite-space, see Identifying the Composite Space Persisted Daily.

Min-space-retain = Daily-inflow-composite-space * Retention Period in days

For example, calculate the minimum retained disk space with 40 GB of composite space persisted daily and a retention period of 10 days:

(400 GB = (40 GB * 10))

12.2.2.2 Determining the Minimum Number of Retained Composites

Use the following formula to identify the minimum number of retained composites. For information about identifying Daily-inflow-composite, see Identifying the Number of Instances Produced Daily.

Min-composites-retain = Daily-inflow-composite * Retention Period in days

For example, calculate the minimum number of retained composites with 20,000 composites created daily and a retention period of 10 days:

(200,000 = (20,000 * 10))

From this, it can be stated that 200,000 composites retain on average 400 GB of data based on a 10 day retention policy.

Note:

The above calculation defines an approximation on the minimum disk space usage. The actual minimum disk space usage is more accurately determined through quality assurance testing. For more information, see Quality Assurance Testing.

12.2.3 Identifying the Outflow of Data

The outflow of composites is a measurement of the number of instances that are deleted. It is not a factor when determining the database profile, but is an important metric when evaluating the effectiveness of the growth management strategy.

The goal of measuring outflow is to ensure the following:

- That the inflow can be deleted.

- A steady state for space usage, hopefully just above the minimum retained disk space usage.

For more information, see Determining the Minimum Retained Disk Space.

There are two cycles that must first be defined:

- The purge cycle: Refers to a period that may involve multiple executions of the purge scripts.

- The maintenance cycle: Refers to the number of days required to perform all space management operations. For more information, see Introduction to the Components of a Data File.

The appropriate growth management strategy may include both purging and partitioning. Therefore, outflow should not be measured until eligible partitions have been dropped. The dropping of partitions is a maintenance operation. Therefore, it makes little sense to measure outflow metrics until the maintenance cycle has finished.

The following metrics can be captured before and after the completion of the maintenance cycle to understand the effectiveness of the strategy and to re-evaluate space distribution:

- Determine the growth trend of the components. For more information, see Determining the Growth Trend of Components.

- Determine the growth trend of the Oracle SOA Suite schema. For more information, see Determining the Growth Trend of the Schema.

- Determine the largest segments. For more information, see Determining the Largest Segments.

- Determine the growth trend of tables and indexes. For more information, see Determining the Growth Trend of Tables and Indexes.

Note:

If a steady state has been reached, then the difference between the before and after metrics for components and schema growth should be near zero or negative. Otherwise, the purge strategy may not be coping or the inflow of data may have increased.

12.2.4 Identifying Long Running Composites and Table Partitioning

Long running composites are composites that remain open beyond the retention period. These composites do not have significant implications for the purge scripts, but their impact is felt when table partitioning is implemented. (Understanding Growth Management Challenges and Testing Strategies recommends that table partitioning be considered for medium and large installations.)

The partitioned tables are (should be) excluded from the purge scripts because their space is reclaimed through the database ALTER TABLE ... DROP PARTITION command. Long running composites remain open beyond the desired retention period, preventing the partition from being dropped and the space from being reclaimed. Therefore, when estimating the size of the partitioned tables, the retention period that is used should equal the longest running composite:

Retention period = Longest Running Composite

The space implications of long running transactions and the size of the partitioned tables are best understood through quality assurance testing, as described in Understanding Growth Management Challenges and Testing Strategies. However, use the calculations in the following sections to estimate the space used by each table that is partitioned.

12.2.4.1 Recommendations for Each Table to Partition

It is best to load the tables over a period of several days to produce reasonable averages. Table 12-2 provides details.

Table 12-2 Table Partitioning Recommendations

Action

Command

Determine the average number of rows generated daily for each table.

(Total rows / period)

Estimate the number of rows based on the longest running composite.

((Total rows / period) * Longest running composite in
days)

Estimate space usage for the table and index based on row calculations.

See Estimating Table Size and Estimating Index Size.

Note:

In Oracle SOA Suite Release 11g R1 (11.1.1.6), a set of scripts called row migration were provided. These scripts move long running composites from one partition to another, thereby facilitating the removal of the partition. However, it is a best practice to plan for the space requirements of the partition tables and not rely on the row migration scripts.

12.3 Monitoring Space Usage, Hardware Resources, and Database Performance

The following sections describe how to monitor space usage:

- Determining the Growth Trend of Components

- Determining the Growth Trend of the Schema

- Determining the Largest Segments

- Determining the Growth Trend of Tables and Indexes

- Estimating Table Size

- Estimating Index Size

- Monitoring Unused Indexes

The following sections describe how to monitor hardware resources and database performance:

- Hardware - OSWatcher Black Box

- Database – AWR / ADDM

- Disk I/O - Oracle Orion

12.3.1 Monitoring Space Usage

Monitoring space is an essential task of database and system administration to avoid unplanned outages. This section provides advice to help with capacity planning and determine the effectiveness of the growth management strategy. It is not meant to be a comprehensive guide on all aspects of monitoring and capacity planning.

12.3.1.1 Determining the Growth Trend of Components

The component master tables record the creation date of each row used to determine growth trends over a given period:

- SCA_FLOW_INSTANCE: CREATED_TIME

- CUBE_INSTANCE: CREATION_DATE

However, querying the component master tables is limited as purging constantly removes data, making trend predictions difficult. To determine a trend over a given period requires data to be regularly collected with an associated time stamp. This can be achieved with a simple component history table that is populated each day. This table should be sufficient to determine the effectiveness of the growth management strategy and growth trends.

- For performance reasons, it may be best to create a history table per component, as shown in the following example:

SQL> CREATE TABLE SOA_FABRIC_HIST (SFH_DATE TIMESTAMP, SFH_COUNT NUMBER);

SQL> INSERT INTO SOA_FABRIC_HIST SELECT SYSTIMESTAMP, COUNT(*) FROM
SCA_FLOW_INSTANCE GROUP BY SYSTIMESTAMP;

SQL> CREATE TABLE SOA_BPEL_HIST (SBH_DATE TIMESTAMP, SBH_COUNT NUMBER);

SQL> INSERT INTO SOA_BPEL_HIST SELECT SYSTIMESTAMP, COUNT(*) FROM CUBE_INSTANCE
GROUP BY SYSTIMESTAMP;

and so on.

- An alternate to counting the rows in each component table is to query the NUM_ROWS column from USER_TABLES as long as the tables are analyzed.

12.3.1.2 Determining the Growth Trend of the Oracle SOA Suite Schema

The objects (table, index, and LOBs) created for the Oracle SOA Suite schema may be spread over many tablespaces, but all have the same owner (*soainfra) to group space usage. When trying to determine the space requirements of each composite, measuring the whole schema allows for better space metrics because indexes and LOB segments are taken into account.

To monitor the growth of the Oracle SOA Suite schema, a simple history table can be populated daily. This table should be sufficient to determine the effectiveness of space management. For more information, see Understanding Space Management.

- Create a schema growth table based on object type, as shown in the following example:

SQL> CREATE TABLE SOA_SIZE_SCHEMA_HIST (SSCH_DATE TIMESTAMP, SSCH_SUM_MB
NUMBER);

SQL> INSERT INTO SOA_SIZE_SCHEMA_HIST SELECT SYSTIMESTAMP, SUM(BYTES)/1024/1024
FROM DBA_SEGMENTS WHERE OWNER='<SOA_OWNER>' GROUP BY SYSTIMESTAMP;

- Optionally, a history table by object type (for example, table, index, and LOB) may be helpful when coupled with the largest segment to verify which tables may need partitioning or lack space management. The following example creates a history table:

SQL> CREATE TABLE SOA_SIZE_TYPE_HIST (SSCH_DATE TIMESTAMP, SSCH_TYPE
VARCHAR2(18), SSCH_SUM_MB NUMBER);

SQL> INSERT INTO SOA_SIZE_TYPE_HIST SELECT SYSTIMESTAMP, SEGMENT_TYPE,
SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE OWNER='SOA_OWNER' GROUP BY
SYSTIMESTAMP, SEGMENT_TYPE;

12.3.1.3 Determining the Largest Segments

Understanding which segments are the largest in the schema helps to determine the tables that may be better managed as range partitioned tables. In addition, monitoring the largest segments may uncover missing space management operations or inappropriate audit settings.

- Identify the largest 20 segments for the Oracle SOA Suite schema, as shown in the following example:

SQL> SELECT SEGMENT_NAME, SEGMENT_TYPE, (SUM(BYTES)/1024/1024) MB_SIZE FROM
DBA_SEGMENTS WHERE OWNER='SOA_OWNER' AND ROWNUM < 20 GROUP BY SEGMENT_NAME,
SEGMENT_TYPE ORDER BY 3 DESC;

- The largest segments may be LOB segments, as shown in the following example:

SQL> SELECT L.TABLE_NAME, S.SEGMENT_NAME, (SUM(BYTES)/1024/1024) MB_SIZE FROM
DBA_LOBS L, DBA_SEGMENTS S WHERE S.OWNER='<SOA_OWNER>' AND S.SEGMENT_TYPE =
'LOBSEGMENT' AND S.SEGMENT_NAME = L.SEGMENT_NAME AND S.OWNER='SOA_OWNER''
GROUP BY L.TABLE_NAME, S.SEGMENT_NAME;

or

SQL> SELECT L.TABLE_NAME FROM DBA_LOBS L WHERE L.OWNER ='<SOA_OWNER>' AND
L.SEGMENT_NAME = ‘SEGMENT_NAME';

- To determine the size of an individual segment:

SQL> SELECT SEGMENT_NAME, (SUM(BYTES)/1024/1024) MB_SIZE FROM DBA_SEGMENTS
WHERE OWNER='SOA_OWNER' AND SEGMENT_NAME = ‘TABLE_NAME' GROUP BY SEGMENT_
NAME;

12.3.1.4 Determining the Growth Trend of Tables and Indexes

Use the OBJECT_GROWTH_TREND function of the DBMS_SPACE package to show the trend in space growth for a table. For more information, see Oracle Database Administrator's Guide.

The OBJECT_GROWTH_TREND function of the DBMS_SPACE package produces a table of one or more rows, where each row describes the space use of the object at a specific time. The function retrieves the space totals from the AWR or computes current space and combines it with historic space changes retrieved from AWR.

The following example displays the growth in used and allocated space over time for the SCA_FLOW_INSTANCE table.

SQL> SELECT TIMEPOINT, SPACE_USAGE, SPACE_ALLOC, QUALITY FROM TABLE (DBMS_
SPACE.OBJECT_GROWTH_TREND ('DEV_SOAINFRA','SCA_FLOW_INSTANCE','TABLE'));

The following example shows the complete syntax for the dbms_space.object_growth_trend procedure:

dbms_space.object_growth_trend (
object_owner in varchar2,
object_name in varchar2,
object_type in varchar2,
partition_name in varchar2 default null,
start_time in timestamp default null,
end_time in timestamp default null,
interval in dsinterval_unconstrained default null,
skip_interpolated in varchar2 default 'false',
timeout_seconds in number default null,
single_datapoint_flag in varchar2 default 'true')

Table 12-3 describes the object_growth_trend function parameters.

Table 12-3 OBJECT_GROWTH_TREND Function Parameters

Parameter

Description

object_owner

The schema containing the object.

object_name

The name of the object.

OBJECT_TYPE

The type of the object.

partition_name

The name of the table or index partition, if relevant. Otherwise, specify NULL.

start_time

A time stamp value indicating the beginning of the growth trend analysis.

end_time

A time stamp value indicating the end of the growth trend analysis. The default is NOW.

interval

The interval (yes) or not (no). This setting is useful when the result table is displayed as a table rather than a chart. This is because you can see more clearly how the actual recording interval relates to the requested reporting interval. The function returns a table, each row of which provides space use information on the object for one interval. If the return table is very large, the results are pipelined so that another application can consume the information as it is being produced.

skip_interpolated

Specify whether to skip interpolation of missing values (true or false).

timeout_seconds

The timeout value for the function in seconds.

single_data_point_flag

Specify whether in the absence of statistics to sample the segment.

Returned values are shown in the following example:

TYPE object_growth_trend_row IS RECORD(
timepoint timestamp,
space_usage number,
space_alloc number,
quality varchar(20));

Table 12-4 describes the object_growth_trend_row return values.

Table 12-4 OBJECT_GROWTH_TREND_ROW Return Values

Parameter

Description

timepoint

A timestamp value indicating the time of the reporting interval. Records are not produced for values of time that precede the oldest recorded statistics for the object.

space_usage

The number of bytes actually being used by the object data.

space_alloc

The number of bytes allocated to the object in the tablespace at that time.

quality

A value indicating how well the requested reporting interval matches the actual recording of statistics. This information is useful because there is no guaranteed reporting interval for object size use statistics, and the actual reporting interval varies over time and from object to object.

- good: The value whenever the value of time is based on recorded statistics with a recorded timestamp within 10% of the interval specified in the input parameters. (The output returned by this function is an aggregation of values recorded across all instances in an Oracle Real Application Clusters environment. Each value can be computed from a combination of good and interpolated values. The aggregate value returned is marked good if at least 80% of that value was derived from good instance values.

- interpolated: The value did not meet the criteria for good, but was based on recorded statistics before and after the value of time. Current in-memory statistics can be collected across all instances in a cluster and treated as the recorded value for the present time.

- projection: The value of time is in the future (the time the table was produced). In an Oracle Real Application Clusters environment, the rules for recording statistics allow each instance to choose independently which objects are selected.

12.3.1.5 Estimating Table Size

The create_table_cost procedure of the dbms_space package allows the size of a table to be estimated using the predicted number of rows for an existing table or based on a table column definition. The size of tables can vary widely based on the tablespace storage attribute that is accounted for by this procedure. There are two overloads of this procedure:

- The first procedure takes the column information of the table.

- The second procedure takes the average row size of the table.

Because the Oracle SOA Suite tables already exist, it is the second variant that is most useful. The following example estimates the size of the CUBE_INSTANCE table with 10.000 rows, an average row length of 360, and a PCT FREE 0f 10.

1. Execute the following command. The average row length and current PCT_FREE is derived from DBA_TABLES after ensuring that the table has been analyzed:

SQL> SELECT AVG_ROW_LEN, PCT_FREE FROM DBA_TABLES WHERE TABLE_NAME =
'CUBE_INSTANCE' AND OWNER = 'DEV_SOAINFRA';

2. Execute the dbms_space.create_table_cost procedure:

set serverout on
declare

v_used number(10);
v_alloc number(10);

begindbms_space.create_table_cost
('SOA1_SOAINFRA',360,10000,10, v_used,v_Alloc);
dbms_output.put_line('used bytes: ' || to_char(v_used));
dbms_output.put_line('allocated bytes: ' || to_char(v_alloc));

end;
/

The following example estimates the space usage of a table based on its column definition:

set serveroutput on
declare

v_used_bytes number(10);
v_allocated_bytes number(10);
v_type sys.create_table_cost_columns;

begin

v_type := sys.create_table_cost_columns
( sys.create_table_cost_colinfo('number',9),
sys.create_table_cost_colinfo('varchar2',50),
sys.create_table_cost_colinfo('varchar2',15),
sys.create_table_cost_colinfo('date'f,null),
sys.create_table_cost_colinfo('date'f,null) );
dbms_space.create_table_cost
('users',v_type,10000,7,v_used_bytes,v_allocated_bytes);
dbms_output.put_line('used bytes: ' || to_char(v_used_bytes));
dbms_output.put_line('allocated bytes: ' || to_char(v_allocated_bytes));
end;
/

Complete syntax for the dbms_space.create_table_cost procedure is shown in the following examples:

- First overload:

dbms_space.create_table_cost (tablespace_name in varchar2,
colinfos in create_table_cost_columns, row_count in number,
pct_free in number, used_bytes out number,
alloc_bytes out number); create type
create_table_cost_colinfo is object (col_type varchar(200),
col_size number);

- Second overload:

dbms_space.create_table_cost (tablespace_name in varchar2,
avg_row_size in number, row_count in number, pct_free in number,
used_bytes out number, alloc_bytes out number);

Both variants require the input values shown in Table 12-5 and Table 12-6.

Table 12-5 CREATE_TABLE_COST Procedure Parameters

Parameter

Description

tablespace_name

The tablespace in which the object is created. The default is the SYSTEM tablespace.

row_count

The anticipated number of rows in the table.

pct_free

The percentage of free space you want to reserve in each block for future expansion of existing rows due to updates.

In addition, the first variant also requires as input a value for avg_row_size, which is the anticipated average row size in bytes.

The second variant also requires for each anticipated column values for colinfos, which is an object type comprising the attributes col_type (the data type of the column) and col_size (the number of characters or bytes in the column).

Table 12-6 CREATE_TABLE_COST Procedure Return Values

Parameter

Description

used_bytes

The actual bytes used by the data, including overhead for block metadata, PCT_FREE space, and so forth.

alloc_bytes

The amount of space anticipated to be allocated for the object taking into account the tablespace extent characteristics.

12.3.1.6 Estimating Index Size

The create_index_cost procedure of the dbms_space package enables you to estimate the space use cost of creating an index on an existing table. Use this to determine the cost of adding an index to the Oracle SOA Suite schema.

The following example estimates the size of a new index based on the data definition language (DDL):

set serveroutput on
declare
v_used_bytes number(10);
v_allocated_bytes number(10);
begin
dbms_space.create_index_cost(
‘create index cube_index on cube_instance(cikey)'
v_used_bytes, v_allocated_bytes);
dbms_output.put_line(‘used bytes: ‘ || to_char(v_used_bytes));
dbms_output.put_line(‘allocated bytes: ‘|| to_char(v_allocated_bytes));end; /

The complete syntax for DBMS_SPACE.CREATE_INDEX_COST procedure is as follows:

dbms_space.create_index_cost (ddl in varchar2, used_bytes out number,
alloc_bytes out number, plan_table in varchar2 default null);

The procedure requires the input values shown in Table 12-7.

Table 12-7 DBMS_SPACE.CREATE_INDEX_COST Values

Parameter

Description

ddl

The CREATE INDEX statement that creates the index. The DDL statement must be against an existing table.

plan_table

(Optional]) The name of the plan table to use. The default is null. The results returned by this procedure depend on statistics gathered on the segment. Therefore, be sure to obtain statistics shortly before executing this procedure. In the absence of recent statistics, the procedure does not issue an error, but it may return inappropriate results. The procedure returns the following values:

- used_bytes
The number of bytes representing the actual index data.

- alloc_bytes
The amount of space allocated for the index in the tablespace.

Usage notes:

- The table on which the index is created must already exist.

- The computation of the index size depends on statistics gathered on the segment.

- It is imperative that the table has been analyzed recently.

- In the absence of correct statistics, the results may be inaccurate.

12.3.1.7 Monitoring Unused Indexes

The Oracle database provides a means of monitoring indexes to determine whether they are used. If an index is not used, it can be dropped, eliminating unnecessary statement overhead.

1. Enter the following statement to start monitoring the usage of an index:

SQL> ALTER INDEX INDEX_NAME MONITORING USAGE;

2. Enter the following statement to stop monitoring:

SQL> ALTER INDEX INDEX_NAME NOMONITORING USAGE;

The view V$OBJECT_USAGE can be queried for the index being monitored to see if the index has been used. The view contains a USED column whose value is YES or NO, depending upon if the index has been used within the time period being monitored. The view also contains the start and stop times of the monitoring period, and a MONITORING column (YES/NO) to indicate if usage monitoring is currently active. Each time that you specify MONITORING USAGE, the V$OBJECT_USAGE view is reset for the specified index. The previous usage information is cleared or reset, and a new start time is recorded. When you specify NOMONITORING USAGE, no further monitoring is performed, and the end time is recorded for the monitoring period. Until the next ALTER INDEX...MONITORING USAGE statement is issued, the view information is left unchanged.

12.3.2 Monitoring the Hardware Resources and Database

The hardware resource must support the tools selected to implement the growth strategy. It is important to monitor hardware resources during online transaction processing (OLTP) and maintenance periods and especially when these periods overlap.

12.3.2.1 Hardware - OSWatcher Black Box

To monitor CPU, disk, memory, and network O/S resources, Oracle provides OSWatcher Black Box, which must be installed on all tiers in the Oracle SOA Suite installation.

OSWatcher Black Box is a collection of UNIX shell scripts intended to collect and archive operating system and network metrics to aid Oracle Support Services in diagnosing performance issues. OSWatcher Black Box operates as a set of background processes on the server and gathers OS data on a regular basis, invoking such UNIX utilities as vmstat, netstat, and iostat.

The OSWatcher Black Box User Guide and product can be downloaded through Metalink Support note 301137.1.

https://support.oracle.com

12.3.2.2 Database – AWR / ADDM

Oracle provides AWR and the Automatic Database Diagnostic Monitor (ADDM) to gather and analyze database performance statistics.

AWR can be configured to automatically collect performance statistical snapshots at regular intervals, or it can be manually triggered. The ADDM utility can then analyze the statistics between two snapshot intervals to produce a performance summary report that includes the following:

- CPU bottlenecks

- Undersized memory structures

- I/O capacity issues

- High load SQL statements

- High load PL/SQL execution and compilation issues, and high-load Java usage

- Oracle Real Application Clusters specific issues

- Suboptimal use of the Oracle database by the application

- Database configuration issues

- Concurrency issues

- Hot objects

The AWR and ADDM utilities can be executed manually or through Oracle Enterprise Manager Database Control. For more information, see Oracle Database 2 Day + Performance Tuning Guide.

12.3.2.3 Disk I/O - Oracle Orion

A complete Oracle SOA Suite I/O design plan is beyond the scope of this chapter. However, good advice can be found in the Oracle Database Performance Tuning Guide. A well designed I/O plan considers capacity, availability, and performance.

The AWR reports identify segments, data files, and tablespaces that are accessed frequently. OSWatcher identifies lengthy I/O queues. The combination of these tools identifies the disk devices and files of concern. This may identify a need to redistribute files to balance I/O or to modify the redundant arrays of independent disks (RAID) levels on slow volumes.

The I/O calibration feature (Oracle Orion) of the Oracle database issues random I/O using the Oracle data files to access the storage media. This produces results that closely match the actual performance of the database. Oracle Orion is expressly designed for simulating Oracle database I/O workloads using the same I/O software stack as Oracle. Oracle Orion can also simulate the effect of striping performed by Oracle Automatic Storage Management. For more information, see Oracle Database Performance Tuning Guide.

12.4 Understanding Growth Management Challenges and Testing Strategies

This section provides recommendations on the appropriate tools to manage the growth of the Oracle SOA Suite database. The provided advice is for new installations or existing installations whose current strategy may lack procedures such as monitoring and space management. For additional advice, see Parallel Purging and Table Partitioning Issues.

It is advisable to read Monitoring Space Usage_ Hardware Resources_ and Database Performance before this section to become familiar with the Oracle SOA Suite purging and partitioning tools described in Managing Database Growth .

12.4.1 Database Growth Management Challenges

The challenges described in this section provide background by describing situations that have contributed to the recommended strategies.

12.4.1.1 Excessive Growth of Oracle SOA Suite Tables Due to an Ineffective Growth Management Strategy

When an ineffective purging strategy has been implemented, the Oracle SOA Suite tables may grow very large. This leads to an urgent need to reclaim space. The larger the tables, the harder it is to delete rows and reclaim space.

The performance of the parallel purge script relies on factors such as CPU resources and the speed of disk I/O. However, very large tables have proven to be challenging. The challenge is due to the amount of data that must be parsed to determine composites that can be deleted. This parsing can monopolize the elapsed time of the entire purge script. For more information, see Using Parallel Query Slaves.

This situation highlights the need to constantly monitor the effectiveness of the growth management strategy and to take corrective actions as soon as possible before the tables become very large.

12.4.1.2 Tuned Parallel Purge Script Cannot Handle the Inflow

To help the performance of the parallel purge script, tables with long elapsed times can be range partitioned and excluded from the script. However, this raises concerns about downtime, if table partitioning is necessary in a live production environment. While tables can be partitioned online through the redefinition packages, this operation may not complete in a reasonable time when presented with a very large table.Starting in Oracle SOA Suite Release 11g R1 (11.1.1.6), the granularity of tables that can be partitioned improved. It is possible to partition high volume tables with only their master table. This should make partitioning more attractive and feasible.

12.4.1.3 Table Partitions Cannot Be Dropped Due to Long Running Composites

Long running composites are composites that remain open beyond the retention period. This has implications for Oracle SOA Suite table partitions because they cannot be dropped until all composites they contain are completed. A single flow instance can prevent a partition from being dropped and space reclaimed. This situation gave rise to the row migration scripts that were introduced with Oracle SOA Suite Release 11g R1 (11.1.1.6).

Plan for sufficient disk space to accommodate partitioned tables that include the retention period of the longest running composites. The row migration scripts are recommended for corrective actions when there is an urgent need to reclaim space.

The movement of composite data by the row migration script raises the following concerns:

- The scripts were written with an assumption that around 5% of the data in a partition be moved to avoid performance concerns with the script.

- To maintain the requirements of equipartitioning requires the movement of 5% of the rows across many tables. For more information about equipartitioning, see Referential Integrity and Equipartitioning.

- The arbitrary figure of 5% does not convey the size of the partition, which depends on inflow rate and partition period (daily, weekly, and monthly).

- Repeated migration of long running composites to either the latest partition or to a partition specifically created to pool active composites may lead to an accumulation.

- A given partition may become very large and require purging that has other implications. For more information, see Partition Pruning.

12.4.2 Quality Assurance Testing

Testing the growth management strategies is essential to ensure that tools and techniques are practiced and understood.The hardware resources available for quality assurance testing are unlikely to be identical to a production environment. Therefore, administrators must make conservative predictions when projecting results onto the production host.

The following topics are described:

- Reviewing Metalink Support Note 1384379.1

- Configuring the Production Audit Level Setting

- Creating an Schema - Test Environment

- Executing the Parallel or Single Threaded Script and Reclaiming Space

- Reviewing the Testing Results

- Partitioning the Tables Causing a Bottleneck

- Repeating Purge Testing and Review and Excluding the Partitioned Table

12.4.2.1 Reviewing Metalink Support Note 1384379.1

Review support note Doc ID 358.1 Maintenance and Administration Advisor: Oracle Fusion Middleware (FMW) SOA 11g Infrastructure Database.

https://support.oracle.com

12.4.2.2 Configuring the Production Audit Level Setting

Ensure that audit settings are appropriate for a production environment. For more information, see Reducing Audit Levels.

12.4.2.3 Creating an Oracle SOA Suite Schema - Test Environment

Though difficult, it is important to create a test environment that is comparable to a production environment. The performance of the purge scripts are adversely affected by the amount of data that requires parsing. Therefore, a well-sized test environment is important to understand purge performance. For more information, see Using Parallel Query Slaves.

The workload mix that populates the schema must resemble a production environment in payload size and number of composite invocations. The data must simulate many days of loading, so that space averages and size estimates can be better determined.

12.4.2.3.1 Measure Inflow and Space Estimations

During the loading of data, take time to determine the space used per table and respective space distribution. For more information, see Identifying the Inflow of Data for calculations on inflow.

- Determine the growth trend of the components. For more information, see Determining the Growth Trend of Components.

- Determine the growth trend of the Oracle SOA Suite schema. For more information, see Determining the Growth Trend of the Schema.

Collect metrics with partitioning in mind:

- Determine the largest segments. For more information, see Determining the Largest Segments.

- Determine the growth trend of tables and indexes. For more information, see Determining the Growth Trend of Tables and Indexes.

- Estimate the table size. For more information, see Estimating Table Size.

- Estimate the index size. For more information, see Estimating Index Size.

12.4.2.3.2 Base Point Backup of Test Environment

Perform a backup of the test environment.

12.4.2.4 Executing the Parallel or Single Threaded Script and Reclaiming Space

There are two cycles that must first be understood:

- The purge cycle: Refers to a period that may involve multiple executions of the purge scripts.

- The maintenance cycle: Refers to the number of days required to perform all space management operations. For more information, see Introduction to the Components of a Data File.

The goal is to execute the purge scripts and maintenance operations to determine the optimal cycle for each, ensuring that the purge has room to grow. The purge script may need to be executed multiple times per day and maintenance operations may span multiple days.

The following sections describe how to tune, monitor, and reclaim space:

- Parallel purge. For more information, see Executing the Parallel Purge Script.

- Hardware and database monitoring. For more information, see Monitoring the Hardware Resources and Database.

- Space management operations. For more information, see Introduction to the Components of a Data File.

12.4.2.5 Reviewing the Testing Results

The goals should be as follows:

- Determine if the purge can delete and reclaim space, either equal to or above the inflow. For more information, see Developing a Retention Policy and Identifying the Outflow of Data.

- Determine how many times the purge must be executed and the total elapsed time of the purge cycle to meet purging requirements. This purge cycle must complete within 80% of the time allocated for its execution.

- Determine the bottleneck tables. For more information, see Debugging and Tracing Purging Operations.

- Review database and O/S reports for resource contention and waits. For more information, see Monitoring the Hardware Resources and Database.

12.4.2.6 Partitioning the Tables Causing a Bottleneck

Large installations should consider partitioning the tables identified as difficult to purge. These tables may also be the largest tables. Table partitioning is a proven method of removing bulk data. The Oracle SOA Suite schema is instrumented with a partition key to facilitate range partitioning.

Starting in Oracle SOA Suite Release 11g R1 (11.1.1.6), the granularity of tables that can be partitioned improved. You can partition high volume tables with only their master table. This should make partitioning more attractive and feasible:

- Partial partitioning.

- Long running composites. For more information, see Identifying Long Running Composites and Table Partitioning.

12.4.2.6.1 Base Point Backup with Partitioned Table

Perform a backup that includes the partitioned table.

12.4.2.7 Repeating Purge Testing and Review and Excluding the Partitioned Table

Repeat the purge testing and test results review described in Executing the Parallel or Single Threaded Script and Reclaiming Space and Reviewing the Testing Results. Exclude the partitioned table.

12.4.3 Recommended Growth Management Strategies

The following recommended growth management strategies are based on the Oracle SOA Suite database profile:

- Recommendations for Large Database Profiles.

- Recommendations for Small Database Profiles.

The strategies require testing to determine their effectiveness. The testing must ensure the following:

- Purge scripts have room to grow.

- Partitioned tables have sufficient disk space.

- Growth is monitored.

- Maintenance is performed with minimal impact to OLTP performance.

12.4.3.1 Recommendations for Large Database Profiles

Installations with large database profiles must seriously consider table partitioning as part of their strategy. Table range partitioning is a proven method for managing large tables:

1. Range interval partitioning is an extension of range partitioning in which the database automatically allocates partitions. For more information, see Range Interval Partitioning.

2. Execute the parallel purge excluding the tables that are partitioned. For more information, see Looped Purge in Parallel Script with dbms_scheduler.

3. Partition the tables that result in bottlenecks when running the purge script. For more information, see Partitioning Component Tables.

4. Reclaim space as part of the maintenance cycle. For more information, see Introduction to the Components of a Data File.

5. Drop eligible partitions as part of the maintenance cycle. For more information, see Running the Verification Script.

6. Monitor the inflow and outflow. For more information, see Developing a Retention Policy and Identifying the Outflow of Data.

7. Monitor database and hardware resources. For more information, see Reclaiming Segment and Data File Space.

12.4.3.2 Recommendations for Small Database Profiles

Small installations with limited CPU, memory, and disk space should start with the single-threaded purge and then move to the parallel purge:

1. Execute the single threaded purge. For more information, see Looped Purge Script.

2. Execute the parallel purge. For more information, see Looped Purge in Parallel Script with dbms_scheduler.

a. If the single threaded purge is not performing, then the parallel purge should be tested.

3. Monitor the inflow and outflow. For more information, see Developing a Retention Policy and Identifying the Outflow of Data.

4. Monitor database and hardware resources. For more information, see Reclaiming Segment and Data File Space.

12.5 Understanding Space Management

Much of the information in this section can be found in the various Oracle Database administration guides. The space management concepts and commands summarized in this section address a common misconception that the Oracle SOA Suite purge scripts reclaim space. To reclaim space, database maintenance operations must be executed.

By default, the Oracle SOA Suite schema is created on locally managed tablespaces with automatic segment space management (ASSM). Therefore, all advice is limited by this situation. This section is not meant as a comprehensive guide to all database space management features.

12.5.1 Introduction to the Components of a Data File

A data file scan can be divided into the following components:

- Segment: Contains a specific type of database object. That is, a table is stored in a table segment, and an index is stored in an index segment.

- Extent: A contiguous set of data blocks within a segment. The Oracle database allocates space for segments in units of one extent.

- Data block: Also called a database block, this is the smallest unit of I/O-to-database storage. An extent consists of several contiguous data blocks.

- Tablespace: Consists of one or more physical data files. A locally managed tablespace maintains a bitmap in the data file header to track free and used space in the data file body. Each bit corresponds to a group of blocks. When space is allocated or freed, the Oracle database changes the bitmap values to reflect the new status of the blocks.

Segments, extents, and data blocks are all logical structures.

Figure 12-1 shows the relationship between logical and physical storage.

Figure 12-1 Logical and Physical Storage

12.5.1.1 Segment High Water Mark

To manage space, the Oracle database tracks the state of blocks in the segment. The high water mark (HWM) is the point in a segment beyond which data blocks are unformatted and have never been used. When the blocks between the HWM and low HWM are full, the HWM advances to the right and the low HWM advances to the location of the old HWM. Figure 12-2 provides details. As the database inserts data over time, the HWM continues to advance to the right, with the low HWM always trailing behind it. Unless you manually rebuild, truncate, or shrink/deallocate the object, the HWM never retreats.

Figure 12-2 HWM

12.5.2 Reclaiming Segment and Data File Space

The following sections provide instructions on common techniques used to reclaim segment and data file space.

- Performing an Online Segment Shrink

- Deallocating Unused Space

- Coalescing or Rebuilding indexes

- Dropping Table Partitions

- Configuring Secure File LOBs

- Additional Database Management Methods

12.5.2.1 Performing an Online Segment Shrink

The purge scripts delete rows from database segments (tables and indexes) and release space within the data blocks for reuse, but may also cause fragmentation with some space too small for reuse. The space can be defragmented and the extents reclaimed by performing an online segment shrink. The shrink operation consolidates free space below the HWM and compacts the segment. After this, it then moves the HWM and deallocates the space above the HWM.

Data manipulation language (DML) can still be issued during the data movement phase of segment shrink. However, DML operations are blocked for a short time at the end of the shrink operation when the space is deallocated. Indexes are maintained during the shrink operation and remain usable.

The Segment Advisor can identify segments that benefit from online segment shrink. However, after constant purging, most Oracle SOA Suite segments should be candidates for online segment shrink operations. For more information on the Segment Advisor, see Oracle Database Administrator's Guide.

The general online segment shrink steps are as follows:

- Before executing the shrink command, row movement must be enabled:

SQL> ALTER TABLE TABLE_NAME ENABLE ROW MOVEMENT;

- To shrink a segment:

SQL> ALTER TABLE TABLE_NAME SHRINK SPACE;

- The COMPACT clause lets you divide the shrink segment operation into two phases. When you specify COMPACT, the segment space is defragmented and rows are compacted, but it postpones the resetting of the HWM and the deallocation of space. Dividing the operations into two phases is useful for large tables and reduces the impact on the blocking of DML during the deallocation phase.
You can reissue the shrink space without the COMPACT clause during off-peak hours to complete the second phase:

SQL> ALTER TABLE TABLE_NAME SHRINK SPACE COMPACT;

- The CASCADE clause extends the segment shrink operation to all dependent segments of the object. For example, if you specify CASCADE when shrinking a table segment, all indexes of the table are also shrunk:

SQL> ALTER TABLE TABLE_NAME SHRINK SPACE COMPACT CASCADE;

- For very large tables, it is advisable to perform the shrink in two phases and not to use the CASCADE clause. Perform the COMPACT operation first, perhaps even compact the basic LOBs before that, then execute the normal shrink command to reclaim the unused space.

- All segment types are eligible for online segment shrink, except the following:

- Index-organized table (IOT) mapping tables

- Tables with row ID-based materialized views

- Tables with function-based indexes

- Secure file LOBs

- Compressed tables

Table 12-8 provides online segment shrinking examples.

Table 12-8 Online Segment Shrink Examples

Scenario

Example

Shrink a large table in two phases.

SQL> ALTER TABLE TABLE_NAME ENABLE ROW MOVEMENT;
SQL> ALTER TABLE TABLE_NAME SHRINK SPACE COMPACT;
SQL> ALTER TABLE TABLE_NAME SHRINK SPACE;

Shrink a table and all its dependent segments (including BASICFILE LOB segments).

SQL> ALTER TABLE TABLE_NAME SHRINK SPACE CASCADE;

Shrink a BASICFILE LOB segment only.

SQL> ALTER TABLE TABLE_NAME MODIFY LOB (LOB_NAME)
(SHRINK SPACE);

Shrink a single partition of a partitioned table.

SQL> ALTER TABLE TABLE_NAME MODIFY PARTITION P1 SHRINK SPACE;

12.5.2.2 Deallocating Unused Space

The DEALLOCATE UNUSED command can be used to manually deallocate unused space. This command frees unused space above the HWM. The online segment shrink also releases space above HWM.

SQL> ALTER TABLE TABLE_NAME DEALLOCATE;

Use the optional KEEP clause to specify the amount of space retained in the segment of table, index, or cluster:

SQL> ALTER TABLE TABLE_NAME DEALLOCATE UNUSED KEEP INTEGER;
SQL> ALTER INDEX INDEX_NAME DEALLOCATE UNUSED KEEP INTEGER;

Note:

The UNUSED_SPACE procedure of the DBMS_SPACE package returns information about the position of the HWM and the amount of unused space in a segment. For segments in locally managed tablespaces with ASSM, use the SPACE_USAGE procedure for more accurate information on unused space. (Use the DBA_FREE_SPACE view to verify the deallocated space.)

12.5.2.3 Coalescing or Rebuilding indexes

Whether to rebuild BTREE indexes is a point of contention for database administrators. Unfortunately, over time the Oracle SOA Suite purge scripts fragment most of the Oracle SOA Suite BTREE indexes in a manner that requires them to be rebuilt to maintain SQL performance.

The purge scripts delete only closed composites, leaving the open ones in each index data block. Because many of the Oracle SOA Suite index keys are monotonically increasing, the free space in the data block is not reused.

SQL> ALTER INDEX INDEX_NAME REBUILD OR COALESCE

Table 12-9 describes the costs and benefits of coalescing or rebuilding indexes.

Table 12-9 Costs and Benefits of Coalescing or Rebuilding Indexes

Rebuild Index

Coalesce Index

Quickly moves index to another tablespace.

Cannot move index to another tablespace.

Higher costs: Requires more disk space.

Lower costs: does not require more disk space.

Creates new tree and shrinks height, if applicable.

Coalesces leaf blocks within the same branch of the tree.

Enables you to quickly change storage and tablespace parameters without having to drop the original index.

Quickly frees up index leaf blocks for use.

One method to combat the need for index rebuilding is to convert them to global hash indexes. Hashing monotonically increasing keys distributes them randomly across data blocks, thereby improving space reuse. There are other improvements that include a reduction in buffer busy waits for hot index blocks. However, not all Oracle SOA Suite indexes are good candidates for conversion. See the following documentation:

http://www.oracle.com/technetwork/database/options/clustering/overview/index-086583.html

12.5.2.4 Dropping Table Partitions

Table partitions can be dropped to remove table data in bulk and reclaim space. Within Oracle SOA Suite, do not drop the partitions unless identified as eligible. For more information, see Running the Verification Script.

12.5.2.4.1 Dropping a Partition

SQL> ALTER TABLE TABLE_NAME DROP PARTITION P1;

Although the DROP PARTITION operation takes longer, it is worth specifying the UPDATE INDEXES clause to avoid the need to rebuild indexes.

Many table maintenance operations on partitioned tables invalidate (mark UNUSABLE) the corresponding indexes or index partitions. You must then rebuild the entire index or, for a global index, each of its partitions. The database lets you override this default behavior if you specify UPDATE INDEXES in your ALTER TABLE statement for the maintenance operation. Specifying this clause tells the database to update the indexes at the time it executes the maintenance operation DDL statement. This provides the benefits described in this section.

The following operations support the UPDATE INDEXES clause:

- ADD PARTITION

- COALESCE PARTITION

- DROP PARTITION

- EXCHANGE PARTITION

- MERGE PARTITION

- MOVE PARTITION

- SPLIT PARTITION

- TRUNCATE PARTITION

Under certain circumstances, the partition operations shown in Table 12-10 may be required to assist with issues.

Table 12-10 Partition Operations

Partition Operation

Description

Shrink table partition

SQL> ALTER TABLE TABLE_NAME MODIFY PARTITION P1 SHRINK
SPACE;

Truncate table partition

SQL> ALTER TABLE ... TRUNCATE PARTITION

Compress table partition

SQL> ALTER TABLE TABLE_NAME MOVE PARTITION PART_NAME
TABLESPACE TABLESPACE_NAME NOLOGGING COMPRESS FOR
OLTP;

Notable restrictions:

- Online segment shrinking is not supported for compressed tables.

- Secure file LOBs have their own compression methods.

- Compression technology increases CPU resource usage.

- Altering a partition to enable compression applies only to new data. To compress existing data, you must move the partition. Moving table partitions drops the old partition segment and creates a new segment, even if you do not specify a new tablespace.

12.5.2.5 Configuring Secure File LOBs

Secure files are a LOB storage architecture that provides performance benefits that many factor as faster and better than traditional LOB access. Secure files are a complete rewrite of the original LOB storage architecture, now called basic files.

Secure files support the following advanced features:

- Deduplication: Stores only one copy of identical secure file data.

- Compression: Reduces storage, I/O, redo log, and encryption overhead. The online segment shrink command is not supported for secure file LOBs due to compression.

- Encryption

Secure files were a feature introduced in the Oracle 11g database. It is recommended that the highest available database patch set be applied to avoid known problems.

12.5.2.5.1 Secure File Requirements

The following settings are required to use secure files.

1. Set the COMPATIBLE initialization parameter higher than 11.0.0.0.0.

SQL> show parameter COMPATIBLE;

2. The DB_SECUREFILE initialization parameter controls the default action of the database with regards to LOB storage (default if PERMITTED):

SQL> ALTER SYSTEM SET DB_SECUREFILE = 'ALWAYS';
SQL> SHOW PARAMETER DB_SECUREFILE

Parameter

Description

ALWAYS

All LOBs in ASSM tablespaces are created as secure file LOBs. LOBs in non-ASSM tablespaces are created as basic file LOBs unless explicitly specified as secure files. Basic file storage options are ignored, and secure file default storage options are used for any unspecified options.

FORCE

All LOBs are created as secure file LOBs. If the LOB is being created in a non-ASSM tablespace, an error is thrown. Basic file storage options are ignored, and secure file default storage options are used for any unspecified options.

PERMITTED

The default setting that enables secure file LOB storage when the SECUREFILE keyword is used. The default storage method is BASICFILE.

NEVER

Secure file LOBs are not permitted.

IGNORE:

Prevents creation of secure file LOBs, and ignores any errors associated with secure file storage options.

3. Configure the tablespace to support ASSM:

SQL> SELECT SEGMENT_SPACE_MANAGEMENT FROM DBA_TABLESPACES WHERE TABLESPACE_NAME
= 'TABLESPACE_NAME';

12.5.2.5.2 Converting Secure Files

The Repository Creation Utility (RCU) that creates the Oracle SOA Suite tables by default also creates basic files. However, secure file LOBs can also be created at the time of SOA schema creation. The process below is only for the time of creation. Otherwise, see Migrating Secure Files.

1. Ensure the requirements are met and the DB_SECUREFILE database initialization parameter is set to ALWAYS or FORCE. For more information about requirements, see Secure File Requirements.

2. Run the appropriate Oracle SOA Suite RCU utility to create the schema. Although the LOBs are defined as basic, they are created as secure files. The basic file LOB storage parameters are ignored.

The advanced features of compression, deduplication, and encryption are not enabled by default.

3. Enter the following command to determine if the advanced features are enabled for the secure file LOB column:

SQL> SELECT TABLE_NAME, COLUMN_NAME, SECUREFILE, RETENTION, ENCRYPT,
COMPRESSION, DEDUPLICATION FROM DBA_LOBS;

The ALTER command to enable the advanced features must be performed immediately after using RCU:

SQL> ALTER TABLE LOB_TABLE MODIFY LOB(LOB_COLUMN) (COMPRESS);
SQL> ALTER TABLE LOB_TABLE MODIFY LOB(LOB_COLUMN) (DEDUPLICATE);

Note:

Oracle recommends that you enable compression, deduplication, or encryption through the CREATE TABLE statement and/or online redefinition. For existing data, if you enable these features through the ALTER TABLE statement, all secure file LOB data in the table is read, modified, and written. This causes the database to lock the table during a potentially lengthy operation. Therefore, the ALTER table command is not recommended for converting populated tables, and causes locking.

12.5.2.5.3 Migrating Secure Files

The online redefinition is the recommended online method for converting to secure file LOBs. However, there are offline methods:

- Create Table as Select (CTAS) script

- Insert Table as Select (ITAS)

- Export/import

Advantages of online redefinition:

- No requirement to take the table or partition offline.

- Can be performed in parallel.

Disadvantages of online redefinition:

- Additional storage equal to the entire table or partition and all LOB segments must be available.

- Global indexes must be rebuilt.

For best practices about executing the online REDFINITON package, including preventing redo generation and parallel execution, see Section "Migrating Columns from BasicFiles LOBs to SecureFiles LOBs" of the Oracle Database SecureFiles and Large Objects Developer's Guide.

12.5.2.6 Additional Database Management Methods

This section describes additional methods available for managing database growth.

12.5.2.6.1 TRUNCATE Statement

The truncate statement removes all rows from a table. Therefore, this is unlikely to be performed or required in a Oracle SOA Suite production environment. For more information, see Removing Records from the Runtime Tables Without Dropping the Tables.

12.5.3 Resizing Data Files

To first avoid application errors and the need for manual intervention when a tablespace runs out of space, set the data files to AUTOEXTEND.

1. To determine whether a data file is auto-extensible, query the DBA_DATA_FILES view column AUTOEXTENSIBLE:

SQL> SELECT AUTOEXTENSIBLE FROM DBA_DATA_FILES

2. Specify automatic file extension by specifying an AUTOEXTEND ON clause when the data file is created or altered:

SQL> ALTER TABLESPACE TABLESPACE_NAME ADD DATAFILE '/U01/DATAFILE.DBF' SIZE 10M
AUTOEXTEND ON;

SQL> ALTER DATABASE DATAFILE '/U01/DATAFILE.DBF' AUTOEXTEND ON;

If the initial allocation of the data files was excessive or segments were allowed to grow excessively, the data file can be resized.

Resize the data file. However, this is assuming that the space is not used by segments.

SQL> ALTER DATABASE DATAFILE '/U01/DATAFILE.DBF'' RESIZE 50M;

It is not always possible to decrease the size of a file to a specific value. In which case, the database returns the following error.

ORA-03297: file contains used data beyond requested RESIZE value

13 Managing Database Growth

This chapter describes how to manage the growth of large numbers of flow instances, adapter reports, and fault alerts in the database with the purge scripts in Oracle Enterprise Manager Fusion Middleware Control or SQL*Plus, table partitioning for enabling schema tables to be range-partitioned on time intervals, and the truncate script for removing all records from runtime tables without dropping the tables.

This chapter includes the following sections:

- Introduction to Managing Database Growth

- Developing a Purging and Partitioning Methodology

- Deleting Large Numbers of Flow Instances_ Adapter Reports_ and Fault Alerts

- Partitioning Component Tables

- Removing Records from the Runtime Tables Without Dropping the Tables

Note:

Table partitioning is an advanced database task and must only be performed by an experienced database administrator (DBA).

For additional information about troubleshooting database growth issues, see Parallel Purging and Table Partitioning Issues, Extending Tablespaces to Avoid Problems at Runtime, and Resolving Database Growth Issues Caused by a High Volume of Transactions.

For information about database growth management strategies, see Developing a Database Growth Management Strategy .

13.1 Introduction to Managing Database Growth

When the amount of data in the Oracle SOA Suite database grows very large, maintaining the database can become difficult. To address this challenge, several methods for managing database growth are provided, as described in Table 13-1.

Table 13-1 Database Growth Strategies

Environment

Use

See Section

Small development installations with more than 100K rows in the database

Auto Purge page of Oracle Enterprise Manager Fusion Middleware Control or the looped purge script

Deleting Large Numbers of Instances with

or

Deleting Large Numbers of Instances with SQL*Plus

Medium installations that generate less than 10 GB of data per day and retain less than 500 GB of data

Auto Purge page of Oracle Enterprise Manager Fusion Middleware Control or a scheduled parallel purge with optimal thread count

Deleting Large Numbers of Instances with

or

Deleting Large Numbers of Instances with SQL*Plus

Large installations that generate more than 10 GB of data per day or retain more than 500 GB of data

- Partitioning (for infrequent, long running processes).

- Combination of parallel purge and partitioning (for long running processes than span several months). For example, perform daily purges and monthly partition dropping.

- Auto Purge page of Oracle Enterprise Manager Fusion Middleware Control

Deleting Large Numbers of Flow Instances_ Adapter Reports_ and Fault Alerts

Partitioning the Component Database Tables

Partitioning Component Tables

- For recreating and rerunning test scenarios

- For creating a production or test environment clone in which to keep the schemas from the production environment so that the production customizations and new job definitions are kept, but all instance data is truncated, regardless of state

Truncate scripts

Removing Records from the Runtime Tables Without Dropping the Tables

13.2 Developing a Purging and Partitioning Methodology

This section summarizes the main points into an action plan that you can follow to purge and partition the dehydration store. Purging is an essential part of any plan and should be performed when data is consuming too much space or you have some other reason for removing the data.

There are three main strategies for reducing the size of the schemas:

- Purge script, which can be executed through either of the following methods:

- Automatically from the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control

- Manually in SQL*Plus

- Purge script + partitioning (or, more correctly, dropping table partitions)

- Partitioning all tables

The purge script uses standard SQL DELETE statements to remove rows from the BPEL tables. For most sites, this is sufficient. However, some sites accumulate so much data that the purge script takes too long to run. In this case, partitioning becomes the better solution. The trade off is that partitioning involves significantly more database maintenance. Moreover, partitioning is an advanced technique and requires a knowledgeable and skilled DBA. By contrast, running the purge script is straightforward and does not require significant DBA knowledge.

Try to profile the input messages, database growth rate, and how much data is purged in the purge process. If the input rate and purge rate match, then regular purging is sufficient. Otherwise, consider partitioning.

If you use partitioning, Oracle recommends that you add disk space and eventually drop the partition. However, this creates additional requirements for managing disk capacity, deciding on the correct partition size, and so on. Do not use partitioning and then rely on the purge script to reclaim disk space.

13.3 Deleting Large Numbers of Flow Instances, Adapter Reports, and Fault Alerts

You can delete flow instances, adapter reports, and fault alerts with the purge scripts (invoked either automatically from the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control or manually in SQL*Plus).

Note the following details:

- The purge scripts delete instances that have completed or are in error (have faulted). For more information, see Purge States.

- The purge scripts do not delete instances that are in-flight or can be recovered (are in a recovery required state).

- The purge scripts delete all Oracle SOA Suite-related tables except for Oracle B2B. If you have an installation in which Oracle SOA Suite and Oracle B2B are co-located, ensure that you also invoke the Oracle B2B purge scripts. If you have separate Oracle SOA Suite and Oracle B2B installations, you must run only the appropriate purge scripts on the respective product schemas. For information about purging Oracle B2B, see Chapter "Purging Data" and Chapter "B2B Command-Line Tools" of the User's Guide for Oracle B2B.

- Beginning with 12c (12.1.3), Oracle Enterprise Manager Fusion Middleware Control and the purge scripts delete the MEDIATOR_RESEQUENCER_MESSAGE and MEDIATOR_GROUP_STATUS tables.

- Installers must configure the database scheduler timezone properly or the purge job may run at unexpected times.

- You can delete the following tables by running the purge scripts from SQL*Plus or from the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control:

- MEDIATOR_GROUP_STATUS

- EIS_CONNECTION_DOWN_TIME and MESSAGE_STATISTICS (JCA adapter reports).

- FAULT_ALERT

- Group information for resequencing groups is not deleted. Groups contain the necessary information about the next sequence ID for that group. Purging this information is the same as starting the group from the initial sequence ID, which may not be your intent.

The following sections describe how to invoke the purge scripts from the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control or from SQL*Plus to delete flow instances, adapter reports, and fault alerts:

- Purge States

- Deleting Large Numbers of Instances with

- Deleting Large Numbers of Instances with SQL*Plus

- Monitoring the Status of Purging

- Generating a Database SQL Trace

Note:

There is no purge script support on the IBM DB2 database.

13.3.1 Purge States

Instances in the following states are purged with the Oracle Enterprise Manager Fusion Middleware Control or the purge scripts:

- Completed successfully

- Faulted

- Terminated by user

- Aborted

- Unknown (instance tracking is disabled)

Purging of the following instance states is not supported:

- Instances pending recovery at the BPEL process service engine level or SOA composite application level

- Running instances

To purge these instances, you must first move them to one of the instance states supported by the purge scripts.

13.3.2 Deleting Large Numbers of Instances with Oracle Enterprise Manager Fusion Middleware Control

Use the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control to schedule and execute jobs that automatically remove older flow instances, adapter reports, and fault alerts data from the database.

Note:

- Oracle recommends that you enable automatic purging on the Auto Purge page to optimize runtime environment performance. The status of automatic purging is displayed in the Key Configuration section of the Dashboard page at the SOA Infrastructure and individual partition levels. Automatic purging is automatically enabled for new 12c installations, but not for upgraded environments.

- Ensure that you back up important data before enabling or changing purge configurations.

- The Auto Purge page is not available if you are using the Java database included with the SOA Developer Install option. Use the truncate_soa_javadb.sql script to purge the database.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the Key Configuration Section of the Dashboard Page...

From the Key Configuration Section of the Dashboard Page...

a. Select SOA Administration > Auto Purge.

a. Right-click soa-infra.

b. Select SOA Administration > Auto Purge.

a. Click the Related Links icon.

b. Select Auto Purge.

a. Click the icon to the right of Auto Purge Status.

b. In the message that is displayed, click Set Up Auto Purge.

The Auto Purge page is displayed.

2. Select values appropriate to your environment, and click Apply.

Field

Description

Auto Purge Job

Select the predefined database purge jobs to run. You cannot add jobs. For example; you can select the following:

- Run delete_instances_auto_job1 on a schedule appropriate for weekdays (Monday through Friday at midnight). This job is automatically enabled.

- Run delete_instances_auto_job2 on a weekend schedule (Saturday and Sunday) that may be more aggressive. This job is not automatically enabled.

Warning: When you enable or disable an auto purge job, you must save or revert your changes before selecting a different job or navigating away from this page. Otherwise, any unsaved changes made to the currently selected job are lost.

Enabled

Select to enable automatic database purging with the database purge job selected from the Auto Purge Job list.

The purge interval begins when it is enabled. For example, If you specify seven days in the Retain Data field, data is retained from the day you re-enabled this checkbox. Newer data is retained for seven days from when it was created.

Calendaring Expression icon

Click to view examples of job scheduling syntax. Copy and paste the syntax appropriate to your environment into the Job Schedule field and modify as necessary. Click More Info to access documentation about how to configure job frequency by setting the repeat_interval attribute.

Job Schedule

Specify a job execution schedule to purge instances. The default schedule is to perform a daily purge at midnight. This is a required field. To specify the schedule, use valid calendaring expressions. Click the information icon or the Calendaring Expression icon to view examples of commonly used expressions. The scheduling syntax is not case sensitive.

Purge Type

Select the type of purge script to run. This is a required field.

- Single: Single, loop purged script that performs a batched purge.

- Parallel: Functionality is the same as the single, looped purge script. However, this option enables the dbms_scheduler package to spawn multiple purge jobs, with each job working on subset data.
Note: If you have a multiple CPU host, use of the parallel script can be beneficial. However, Oracle recommends that you enable the parallel script only during off hours. In addition, when purging data during off hours, Oracle recommends that you drop indexes before purging large amounts of data and then add the indexes back in. This speeds up the purge process, and also keeps indexes from becoming unbalanced.

For more information about the single (looped) and purge parallel scripts, see Looped Purge Script and Looped Purge in Parallel Script with dbms_scheduler.

Retain Data

Specify the time interval in days for which to retain data. Data within this interval is not purged when the job runs. The default value is seven days. For example, if you specify a data retention interval of seven days, data is protected from purging for the seven days since it was created. Older data already in the system is retained seven days from when automatic purging was enabled.You can ignore the retain data filter by setting this property to -1.

Maximum Flows to Purge

Select the maximum number of instance flows to purge in a single job run.

Batch Size

Select the maximum number of business flows to delete at a time. The default value is 20000.

This field is displayed if Parallel is selected from the Purge Type list.

Degree of Parallel

Select the number of job executions to run in parallel. The default value is 4.

This field is displayed if Parallel is selected from the Purge Type list.

3. To view and configure advanced configuration properties in the System MBean Browser, click More Auto Purge Configuration Properties.

4. Click PurgeJobDetails.
The two predefined database purge jobs are displayed.

- delete_instances_auto_job1

- delete_instances_auto_job2

5. Expand a job to display all properties for single and parallel purges. When either the single or parallel purge type is executed, the appropriate property values for the selected type are executed.

Note:

If you need to edit the advanced purge properties, do so with extreme care. For example, do not change the job names.

6. View or change values, then click Apply.

Field

Description

DOP

Defines the number of job executions to run in parallel. The default value is 4.

PQS

Displays the number of parallel query slaves. You can add additional slaves to improve performance of expensive SQL commands.

batchSize

Displays the maximum number of business flows to delete at a time. The default value is 20000.

Enabled

Indicates if the database purge job is enabled.

executionSchedule

Displays the job scheduling syntax.

ignoreState

When set to true, purges all open and closed instances within the specified date range. The default value is false.

Note: Use this parameter cautiously because purging open instances may leave your system in an inconsistent state.

maxCount

Displays the maximum number of flows to purge.

maxCreationPeriodDays

Displays the maximum creation period in days. This property is used with minCreationPeriodDays for selecting the flows created between a certain period.

maxRuntime

Expiration at which the purge script exits the loop. The default value is 60. This value is specified in minutes.

minCreationPeriodDays

Displays the minimum creation period in days. This property is used with maxCreationPeriodDays for selecting the flows created between a certain period.

purgePartitionedComponent

Indicates if partitioned tables should be purged. If set to true, the same purge job is invoked to delete partitioned data. The default value is false.

Note: If tables are partitioned, you do not want to purge them because they are maintained by a DROP statement.

purgeType

Displays either single or parallel.

retentionPeriodDays

Specifies the time interval in days for which to retain data. Data within this interval is not purged when the purge job runs.

sqlTrace

If set to true, indicates that SQL Trace is set.

For information about SQL Trace, see the Oracle Database SQL Tuning Guide.

Note:
Retention period does not operate at the granularity of hours. So, if the retention period is set to 1 day, it does not mean that a job will be purged within 24 hours of its completion. Instead, it can take up to 48 hours (i.e. with a retention period of 1 day, if a flow completes at 12:01am on the 20th, it will not be purged until 12:00am on the 22nd).

13.3.3 Deleting Large Numbers of Instances with SQL*Plus

Note:

When upgrading Oracle SOA Suite Release 11g to 12c, 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 fails if the purge scripts are running while using the Upgrade Assistant to upgrade your schemas. For more information about upgrading, see Upgrading Oracle SOA Suite and Business Process Management.

You can run the purge scripts in SQL*Plus to automatically remove older flow instances, adapter reports, and fault alerts data from the database. There are two types of purge scripts:

- Looped purge script

- Looped purge in parallel script with dbms_scheduler

13.3.3.1 Looped Purge Script

The master purge script includes a looping construct that allows for a batched purge. You can also provide this script with a max_runtime parameter that stops looping after the value for this parameter is exceeded.

The master script drives the purge of SOA database tables. You can use the delete_instances procedure to purge SOA database tables.

Note:

Set max_runtime to a higher value if there are many instances to purge. In this case, you should expect to wait for a longer time before the script exits. Alternatively, use a smaller batch size if you want the purge script to exit sooner.

13.3.3.1.1 delete_instances Procedure

Use the delete_instances procedure to delete instances. The following example shows the syntax:

procedure delete_instances (
min_creation_date in timestamp,
max_creation_date in timestamp,
batch_size in integer,
max_runtime in integer,
retention_period in timestamp,
purge_partitioned_component in boolean
ignore_state in boolean
composite_name in varchar2
composite_revision in varchar2
soa_partition_name in varchar2
sql_trace in boolean
PSQ integer
);

Table 13-2 describes the script parameters.

Table 13-2 delete_instances Procedure Parameter Descriptions

Parameter

Description

min_creation_date

Minimum creation period in days for the business flow instances.

max_creation_date

Maximum creation period in days for the business flow instances.

batch_size

Maximum number of flows selected for deletion and committed in one execution of the single loop purge. The default value is 20000.

max_runtime

Expiration at which the purge script exits the loop. The default value is 60. This value is specified in minutes.

retention_period

Specify the time interval in days for which to retain data. Data within this interval is not purged when the job runs. The default value is seven days. The retention period is based on the entire flow. The period is compared to SCA_FLOW_INSTANCE.UPDATED_TIME.

This parameter checks for and deletes records in the CUBE_INSTANCE table. The value for this parameter must be greater then or equal to max_creation_date. The default value is null.

Specify a retention period if you want to retain the business flow instances based on the modify_date of the BPEL instances (CUBE_INSTANCE).

In this example, the modify_date of the BPEL instances table, which can be different than the composite created_date, is used as a second level of filtering:

min_creation_date = 1st June 2011
max_creation_date = 30  June 2011
retention_period = 1st July 2011

This deletes all business flow instances in which the creation_time of the composite is between 1st June 2011 and 30 June 2011 and the modify_date of the CUBE_INSTANCE is less than 1st July 2011

purge_partitioned_component

Indicates if partitioned tables should be purged. If set to true, the same purge job is invoked to delete the partitioned data. The default value is false.

Note: If tables are partitioned, you do not want to purge them because they are maintained by a DROP statement.

ignore_state

When set to true, purges all open and closed instances within the specified date range. The default value is false.

Note: Use this parameter cautiously because purging open instances may leave your system in an inconsistent state.

composite_name

The name of the SOA composite application. This parameter, along with the composite_revision and soa_partition_name parameters, enables you to purge the instances of a specific SOA composite application. For more information, see Purging the Instances of a Specific SOA Composite Application.

composite_revision

The revision number of the SOA composite application.

soa_partition_name

The partition in which the SOA composite application is included.

sql_trace

When set to true, this parameter configures a SQL trace that generates a trace file in the destination specified with the USER_DUMP_DEST initialization parameter. The SOA_INFRA user must be granted the ALTER SESSION privilege, which can then be revoked by the database administrator once the trace details are collected.

GRANT ALTER SESSION TO SOA_INFRA

Note: Only use this parameter for debugging because it impacts performance.

PQS

Displays the number of parallel query slaves. You can add additional slaves to improve performance of expensive SQL commands.

Note:

- If you do not provide a value for retention_period, the value for this property defaults to the value of max_creation_date (this is, if retention_period equals null, then retention_period = max_creation_date). This consequence also applies to the script parameters described in Looped Purge in Parallel Script with dbms_scheduler.

- If you are not upgrading from Release 11g to 12c, the max_creation_date and min_creation_date parameters are optional. The purge can be run entirely by retention_period, which is also optional.

- The purge scripts are restricted to purging only the database and existing rows in a table. There is no way for the purge script to look at runtime execution. Therefore, assume you attempt an automatic recovery immediately after an active row has been deleted with the purge scripts (with the ignore_state parameter set to true). Because of this, a row is created after the purge has been executed. This row remains dangling because the SCA_FLOW_INSTANCE table row has already been deleted.

13.3.3.2 Looped Purge in Parallel Script with dbms_scheduler

This script is functionally the same as the looped purge script described in Looped Purge Script. However, this script uses the dbms_scheduler package to spawn multiple purge jobs, with each job working on subset data.

You can use the following procedure to purge SOA database tables.

Note:

If you have a multiple CPU host, use of the parallel script can be beneficial. However, Oracle recommends that you enable the parallel script only during off hours. In addition, when purging data during off hours, Oracle recommends that you drop indexes before purging large amounts of data and then add the indexes back in. This speeds up the purge process, and also keeps indexes from becoming unbalanced.

13.3.3.2.1 delete_instances Procedure in Parallel

Use the delete_instances procedure in parallel to delete instances. The following example shows the syntax.

PROCEDURE delete_instances_in_parallel (
min_creation_date in timestamp,
max_creation_date in timestamp,
batch_size in integer,
max_runtime in integer,
retention_period in integer,
DOP in integer
max_count integer,
purge_partitioned_component in boolean)
ignore_state in boolean
composite_name in varchar2
composite_revision in varchar2
soa_partition_name in varchar2
sql_trace in boolean

Table 13-3 describes the script parameters.

Table 13-3 delete_instances in Parallel Procedure Parameter Descriptions

Parameter

Description

min_creation_date

Minimum creation period in days for the business flow instances.

max_creation_date

Maximum creation period in days for the business flow instances.

batch_size

Maximum number of flows selected for deletion. The default value is 20000.

max_runtime

Expiration time at which the purge script exits the loop. The default value is 60. This value is specified in minutes.

retention_period

Specify the time interval in days for which to retain data. Data within this interval is not purged when the job runs. The default value is seven days. The retention period is based on the entire flow. The period is compared to SCA_FLOW_INSTANCE.UPDATED_TIME. The default value is null. For more information about this parameter, see Table 13-2.

DOP

Defines the number of job executions to run in parallel. The default value is 4.

max_count

Defines the number of rows processed (not the number of rows deleted). A big temp table is created and then jobs are scheduled to purge based on the data. This is the maximum purge row count to use; it defaults to one million. The default value is 1000000.

purge_partitioned_component

You can invoke the same purge to delete partitioned data. The default value is false.

Note: If tables are partitioned, you do not want to purge them because they are maintained by a DROP statement.

ignore_state

When set to true, purges all open and closed instances within the specified date range. The default value is false.

Note: Use this parameter cautiously because purging open instances may leave your system in an inconsistent state.

composite_name

The name of the SOA composite application. This parameter, along with the composite_revision and soa_partition_name parameters, enables you to purge the instances of a specific SOA composite application. For more information, see Purging the Instances of a Specific SOA Composite Application.

composite_revision

The revision number of the SOA composite application.

soa_partition_name

The partition in which the SOA composite application is included.

sql_trace

When set to true, this parameter configures a SQL trace that generates a trace file in the destination specified with the USER_DUMP_DEST initialization parameter. The SOA_INFRA user must be granted the ALTER SESSION privilege, which can then be revoked by the database administrator once the trace details are collected.

GRANT ALTER SESSION TO SOA_INFRA

Note: Only use this parameter for debugging because it impacts performance.

13.3.3.3 Running the Purge Scripts

This section describes how to execute the purge scripts. You can also execute these scripts in Deleting Large Numbers of Instances with .

To execute the purge scripts:

1. In SQL*Plus, connect to the database AS SYSDBA:

CONNECT SYS AS SYSDBA

2. Execute the following SQL commands:

GRANT EXECUTE ON DBMS_LOCK TO USER;
GRANT CREATE ANY JOB TO USER;

where USER is the soainfra account to execute the scripts. These privileges are required to run the scripts.

3. Load the purge scripts by running the main purge script at MW_HOME/SOA_ORACLE_HOME/soa/common/sql/soainfra/sql/oracle/121300/soa_purge/so a_purge_scripts.sql.
For a parallel purge, the debug logs from the jobs spawned by a parallel purge are logged into files created in the directory named SOA_PURGE_DIR. This directory must be accessible to the Oracle database.

4. Create SOA_PURGE_DIR and grant write permissions to the soainfra user.

mkdir -p /tmp/purgelog
CREATE OR REPLACE DIRECTORY SOA_PURGE_DIR AS 'SERVER_DIRECTORY'

where SERVER_DIRECTORY is the name of the directory to create (for example, '/tmp/purgelog/'). Note the required single quotes around the directory path.

5. If you want to execute the scripts in debug mode, run common/debug_on.sql and set serverout to on in SQL*Plus. This step is optional.

SET SERVEROUT ON

The logs from the spawned jobs are logged into the directory created in Step 4(separate files per job). The rest of the logs are displayed on stdout (or the spool file, if configured).

There are two options for purging:

- Looped purge

- Parallel purge

6. Execute the purge scripts as shown below. Examples are provided for both options.

a. For looped purge:

DECLARE

MAX_CREATION_DATE timestamp;
MIN_CREATION_DATE timestamp;
batch_size integer;
max_runtime integer;
retention_period timestamp;
composite_name varchar2(500);
composite_revision varchar2(50);
soa_partition_name varchar2(200);
PQS integer;
ignore_state boolean;

BEGIN

MIN_CREATION_DATE := to_timestamp('2010-01-01','YYYY-MM-DD');
MAX_CREATION_DATE := to_timestamp('2010-01-31','YYYY-MM-DD');
max_runtime := 60;
retention_period := to_timestamp('2010-01-31','YYYY-MM-DD');
batch_size := 10000;
composite_name := 'example_composite';
composite_revision := '1.0';
soa_partition_name := 'default';
ignore_state := false;
PQS := 5;
soa.delete_instances(
min_creation_date => MIN_CREATION_DATE,
max_creation_date => MAX_CREATION_DATE,
batch_size => batch_size,
max_runtime => max_runtime,
retention_period => retention_period,
purge_partitioned_component => false);
ignore_state => ignore_state,
sql_trace => true);
END;
/

b. For parallel purge:

DECLARE

max_creation_date timestamp;
min_creation_date timestamp;
batch_size integer;
max_runtime integer;
retention_period timestamp;
composite_name varchar2(500);
composite_revision varchar2(50);
soa_partition_name varchar2(200);
PQS integer;
DOP integer;
max_count integer;
ignore_state boolean;

BEGIN

min_creation_date := to_timestamp('2010-01-01','YYYY-MM-DD');
max_creation_date := to_timestamp('2010-01-31','YYYY-MM-DD');
batch_size integer;
max_runtime integer;
retention_period := to_timestamp('2010-01-31','YYYY-MM-DD');
composite_name := 'michael_composite';
composite_revision := '1.0';
soa_partition_name := 'default';
ignore_state := true;
PQS := 5;
DOP := 2;
max_count := 100000;
soa.delete_instances_in_parallel(
min_creation_date => min_creation_date,
max_creation_date => max_creation_date,
batch_size => batch_size,
max_runtime => max_runtime,
retention_period => retention_period,
DOP => DOP,
max_count => max_count,
purge_partitioned_component => false,
ignore_state => ignore_state,
sql_trace => true);
END;

13.3.3.4 Resolving Dead Locks After Running the Looped Purge in Parallel Script

You may observe a dead lock in the thread logs for one thread after running the looped purge in parallel script. The following example shows the error found in the thread logs:

SOA_PURGE_LOG_THREAD1 (total of 4 threads)
17-JUL-2012 03:03:48
: Purge AUDIT_DETAILS. Error Code = -60, Error Message = ORA-00060: deadlock
detected while waiting for resource
17-JUL-2012 03:03:48
: ERROR(delete_inst_in_parallel_job. Error Code = -60, Error Message =
ORA-00060: deadlock detected while waiting for resource

To resolve the dead lock issue, rebuild the AUDIT_DETAILS table and increase the values for either of the following:

- Increase PCTFREE (to allow for more interested transaction list (ITL) allocation).

- Increase INITRANS (initial ITLs). This option is described below.

To recreate the AUDIT_DETAILS table and increase the INITRANS value:

1. Create a temporary table and increase the value for INITRANS (for this example, a table named AUDIT_DETAILS_TMP is created).

SQL> CREATE TABLE "PS6_SOAINFRA"."AUDIT_DETAILS_TMP"
(    "CIKEY" NUMBER(*,0),
"DETAIL_ID" NUMBER(*,0),
"BIN_CSIZE" NUMBER(*,0),
"BIN_USIZE" NUMBER(*,0),
"DOC_REF" VARCHAR2(300),
"BIN" BLOB,
"CI_PARTITION_DATE" TIMESTAMP (6)
) SEGMENT CREATION IMMEDIATE
PCTFREE 0 PCTUSED 1 INITRANS 4 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 331350016 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 6 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE
DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "PS6_SOAINFRA"
LOB ("BIN") STORE AS BASICFILE (
TABLESPACE "PS6_SOAINFRA" ENABLE STORAGE IN ROW CHUNK 8192 PCTVERSION 0
CACHE
STORAGE(INITIAL 16384 NEXT 8192 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE
DEFAULT CELL_FLASH_CACHE DEFAULT)) ;

SQL> INSERT /*+ APPEND */ into audit_details_TMP select * from audit_details;

SQL> COMMIT;

2. Drop the AUDIT_DETAILS table.

SQL> DROP TABLE PS6_SOAINFRA.AUDIT_DETAILS CASCADE CONSTRAINTS;

3. Rename the AUDIT_DETAILS_TMP temporary table to AUDIT_DETAILS.

SQL> ALTER TABLE PS6_SOAINFRA.AUDIT_DETAILS_TMP RENAME TO AUDIT_DETAILS;

4. Create a unique index on AUDIT_DETAILS.

SQL> CREATE UNIQUE INDEX "PS6_SOAINFRA"."AD_PK" ON "PS6_SOAINFRA"."AUDIT_ DETAILS" ("CIKEY", "DETAIL_ID");

5. Add a constraint and primary key to AUDIT_DETAILS.

SQL> ALTER TABLE "PS6_SOAINFRA"."AUDIT_DETAILS" ADD CONSTRAINT "AD_PK" PRIMARY
KEY ("CIKEY", "DETAIL_ID") ENABLE;

13.3.3.5 Purging the Instances of a Specific SOA Composite Application

You can purge the instances of a specific SOA composite application and leave the instances of other composites unpurged. This action enables you to purge certain flows more frequently than others due to high volume or retention period characteristics.

The purge scripts include an option for purging based on COMPOSITE_DN. Purging based on COMPOSITE_DN is supported with the parameters composite_name and composite_revision.

The purge logic is based on flows IDs, and not COMPOSITE_IDs. Therefore, apart from the intended COMPOSITE_DNs, other composites sharing the same flow ID may get deleted. The following scenarios may occur:

- A business flow instance is closed, but the flow is still open:
In a scenario in which composite A calls composite B, the purge intends to delete instances of composite A. However, there may be a case in which an instance of composite A is closed, but the corresponding composite B instance is still open. Therefore, because the overall flow is still in an open state, the composite A instance (even though closed) is not purged.

- The business flow instance is closed and the flow is also closed:
Composite A again calls composite B. The purge intends to delete instances of composite A. Therefore, in a case in which composite A is closed and composite B is also closed, because the overall flow is closed, both business flow instances A and B are purged.

These scenarios maintain the consistency of the flow.

For information about the composite_name and composite_revision parameters, see Looped Purge Script and Looped Purge in Parallel Script with dbms_scheduler.

13.3.3.6 Resequenced Message Purge States for Oracle Mediator

The purge scripts include purge commands to purge the information persisted in the Oracle Mediator resequencer tables (MEDIATOR_GROUP_STATUS and MEDIATOR_RESEQUENCER_MESSAGE). The following information is purged from the resequencer tables when you run the purge scripts:

- Completed and aborted messages for all resequencer types

- Timed out messages for standard resequencers

- Groups in a ready state for best effort and FIFO (first in/first out) resequencers (these are the only groups that can be purged)

To allow fault recovery and message processing to be completed, the purge scripts do not purge all resequenced message information. In addition, standard resequencer groups store information that should not be purged. The following are not purged when you run the purge scripts:

- Faulted messages for all resequencer types

- Running messages for all resequencer types

- Group information for standard resequencers

- Groups in a state other than ready for best effort and FIFO resequencers

Note:

The purge scripts for the Oracle Mediator resequencer purge messages first and then move on to groups. If there are messages for a group in the MEDIATOR_RESEQUENCER_MESSAGE table, the group cannot be deleted.

The above describes processing for both looped and parallel processing of the purge scripts, and regardless of whether instance tracking is enabled or disabled. Before any sequence groups are purged, a check is performed to verify that all messages associated with the group are processed.

Below is a list of group state codes used in the resequencer tables:

- 0: Ready

- 1: Locked

- 2: Error

- 4: Timed out

- 6: Group error

Below is a list of message state codes used in the resequencer tables:

- 0: Ready

- 1: Locked

- 2: Completed

- 3: Error

- 4: Timed out (this is ignored)

- 5: Aborted

13.3.4 Monitoring the Status of Purging

You can monitor purge jobs executed from Oracle Enterprise Manager Fusion Middleware Control with the SQL commands described in Table 13-4.

Table 13-4 SQL*Plus Commands for Monitoring the Status of Purging

To...

Execute This Command...

Show the job history and status

SQL> select log_date, status from user_scheduler_job_
log where job_name = 'DELETE_INSTANCES_AUTO_JOB1' order
by log_date;

DELETE_INSTANCES_AUTO_JOB1 is enabled by default. DELETE_INSTANCES_AUTO_JOB2 can also be enabled.

For information about selecting the job on the Auto Purge page, see Deleting Large Numbers of Instances with .

Show a running job

SQL> select session_id, running_instance, elapsed_time, cpu_used
from user_scheduler_running_jobs
where job_name = 'DELETE_INSTANCES_AUTO_JOB1';

Show job details

SQL> select log_date, status, req_start_date, actual_start_date, run_duration
from user_scheduler_job_run_details
where job_name = 'DELETE_INSTANCES_AUTO_JOB1'
order by log_date;

Find the job schedule

SQL> select SCHEDULE_TYPE,START_DATE,REPEAT_INTERVAL
from user_scheduler_schedules
where schedule_name = 'DELETE_INSTANCES_AUTO_SCH1';

DELETE_INSTANCES_AUTO_SCH1 and DELETE_INSTANCES_AUTO_SCH2 are based on the job selected.

Find the default job schedule

BEGIN
DBMS_SCHEDULER.set_attribute (
name      => 'DELETE_INSTANCES_AUTO_SCH1',
attribute => 'repeat_interval',
value     => 'freq=daily; byhour=0; byminute=0; bysecond=0');
END;

Change the job schedule (for this example, to hourly at the thirtieth minute)

BEGIN
DBMS_SCHEDULER.set_attribute (
name      => 'DELETE_INSTANCES_AUTO_SCH1',
attribute => 'repeat_interval',
value     => 'freq=hourly; byminute=30');
END;

13.3.5 Generating a Database SQL Trace

The purge scripts include a parameter to generate a SQL trace:

- If running the purge scripts directly from SQL*Plus, the parameter is named a sql_trace parameter.

- If running the purge scripts from the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control, the parameter is named sqlTrace (located beneath the More Auto Purge Configuration Properties link).

Setting this parameter to true generates a database SQL trace that is placed in the database user dump directory. For the parallel purge script, the SQL trace is also generated for each subordinate parallel purge jobs (J000, J001, and so on).

If parallel query slaves have been enabled in the purge scripts, then trace files are created. The trace files are generated when sql_trace is set. With the parallel purge script, multiple trace files are produced named J*.

For information about SQL Trace, see the Oracle Database SQL Tuning Guide.

13.4 Partitioning Component Tables

The runtime and schema code for the following components has been modified to store the flow creation date column with their transactional tables.

- Oracle BPEL Process Manager

- Oracle Mediator

- Human workflow

- Oracle B2B

- SOA Infrastructure

- Oracle BPM Suite

The CPST_CREATED_DATE column contains the flow creation date time populated by the instance tracking code. This is available as the normalized message property oracle.integration.platform.instance.CommonConstants.SCA_FLOW_INSTANCE_CREATED_TIME.

All SOA components are partitioned on the same partition key. These partitioned components use the same time range and partition ID.

Note:

Before performing complete or partial partitioning, run the purge scripts.

13.4.1 Partitioning the Database with the Repository Creation Utility

You can select a database profile when running the Repository Creation Utility. The profile determines the size of the SOA database and enables you to use existing performance features of the Oracle database for Oracle SOA Suite-related storage.

- Large: Provides a large partitioned schema. This selection is for databases of 200 GB or more.

- Small: Provides a small schema with no partitions.

For more information, see Section "Custom Variables" of Creating Schemas with the Repository Creation Utility.

13.4.2 Partitioning the Component Database Tables

Oracle SOA Suite has been instrumented with partition keys that enable DBAs to take advantage of Oracle RDBMS partitioning features and capabilities. This action enables the schema tables to be range-partitioned on time intervals. This is useful when you must reduce the database maintenance window of large tables. (Though not discussed in this chapter, this also provides for the possibility of archiving partitioned data.)

The task of partitioning the Oracle SOA Suite tables must be performed by an experienced DBA. Since partitioning tables is considered a core DBA skill, this chapter does not provide detailed, step-by-step instructions on how to partition tables. Rather, it provides the DBA with the knowledge and understanding of Oracle SOA Suite schemas and their associated scripts. With this knowledge, the DBA can customize any partitioning strategy for their environment, and incorporate any tuning parameters in response to the performance of their database. Tuning is never a one-size-fits-all proposition or a one-off configuration change. Rather, it is an iterative process of monitoring and tuning.

The following components are associated with their own database schemas:

- Oracle BPEL Process Manager

- Oracle Mediator

- Human workflow

- Oracle B2B

- SOA Infrastructure

- Oracle BPM Suite

For more information about table partitioning, see the Oracle database administration documentation library located at the following URL:

http://www.oracle.com/technetwork/indexes/documentation/index.html

Note:

- A hash subpartition is an option the DBA may want to explore, especially for tables with large object (LOB) segments. This can assist with high water (HW) enqueue contention.

- A global hash index on primary keys that are monotonically increasing (like CIKEY) may relieve block contention.

13.4.2.1 Referential Integrity and Equipartioning

For performance reasons, the Oracle BPEL Process Manager, Oracle Mediator, human workflow, Oracle B2B, SOA Infrastructure, and Oracle BPM Suite schemas have no foreign key constraints to enforce integrity. This fact discounts the use of the RDBMS feature known as referential partitioning. This feature provides significant benefits because it equipartitions master and detail tables across foreign key constraints. Equipartioning means that the associated dependent table rows are in a database partition with the same partition key interval as their master table rows.

One benefit of this feature is that the state (for example, completed, faulted, and so on) of each detail row in the equipartition can be inferred from its associated master table row.

Although the RDBMS referential partitioning feature cannot be used, similar behavior can be mimicked to achieve some of the same benefits. The Oracle BPEL Process Manager, Oracle Mediator, human workflow, Oracle B2B, SOA Infrastructure, and Oracle BPM Suite components ensure that the partition key of every detail table row is the same as the partition key of its master table row (that is, the date (timestamp) that is the partition key is pushed down). To then complete the setup, the DBA must ensure that the master and detail tables are range-partitioned on the same intervals. Some examples are provided in subsequent sections of this chapter.

Note:

You may decide that referential integrity of aged partitions is not a concern for your site. For example, the site may have ample disk space, allowing data to significantly age, or there may be no apparent, adverse impact of allowing unreferenced data to be stored in the dependent tables.

13.4.3 Range Interval Partitioning

Range interval partitioning is a Release 12c extension of the Release 11g range partitioning feature. With range partitioning, you had to manually allocate each partition. With range interval partitioning, you do not need to manually allocate partitions. Partitions of a specified interval are automatically created when the interval value of the partition key that you assign exceeds all of the existing range partitions. The verification scripts support range interval partitioning.

For more information about range interval partitioning, see Oracle Database VLDB and Partitioning Guide.

13.4.4 Equipartitioning and Range Interval Partitioning

A goal of equipartitioning is to ensure that all dependent table partitions contain the complete set of associated rows for their master table partitions. This is accomplished as follows:

- A partition key value is propagated down from the master key to all dependents so that they have the same range.

- The master key contains the state of each flow (open, closed). When the master is checked and everything is closed, dependent tables with the same partition range can be dropped.

The range interval partitioning verification scripts check the following for each dependent table partition against the master partition:

- The same interval definition (each table requires the same interval definition for monthly, weekly, number of days, and so on).

- The upper and lower bound high values are automatically maintained by the database.

- Partitions that must be dropped require the same upper bound high value.

13.4.5 Range Interval Partitioning Example

The following example describes how range interval partitioning works. For this example, the SCA_FLOW_INSTANCE master table is used.

CREATE TABLE SCA_FLOW_INSTANCE
(FLOW_ID INTEGER NOT NULL;
. . .
. . .
CREATED_TIME TIMESTAMP NOT NULL)
PARTITION BY RANGE (CREATED_TIME)
INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
PARTITION p0 VALUES LESS THAN (TO_DATE('1-2-2007', 'DD-MM-YYYY')));

Table 13-5 describes the syntax shown in the preceding example.

Table 13-5 Range Interval Partitioning Example

Syntax

Description

PARTITION BY RANGE (CREATED_TIME)

The partition key (for example, a date of July 1, 2013, which is specified as 01-07-2013).

INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))

The interval (for this example, one month is specified). Therefore, if a partition key is specified for July 1 (as 01-07-2013), a partition is created for July. Partitions are then automatically allocated monthly for August 1, September 1, October 1, and so on. You do not need to manually allocate each partition.

Note: All Oracle SOA Suite tables must be created with this same interval value so that the upper and lower bounds are created with respect to equipartitioning.

PARTITION p0 VALUES LESS THAN (TO_DATE
('1-2-2007', 'DD-MM-YYYY')));

The first partition must be a range partition. This is the transition point after which all partitions are automatically allocated. It is recommended that the first range partition have a DATE interval that is never used (such as the completed date of 1-2-2007).

The date for this partition makes it virtual metadata. This date makes it easier to drop the partition, if necessary.

The SQL command shown in the following example identifies the first range partition created. A value of No in the last column indicates that this is a range partition, and not an interval partition.

SQL> select partition position, partition name, high value, interval
from user_tab_partitions
where table_name = 'SCA_FLOW_INSTANCE';

--------------------------------------------------------------
1     P0        TIMESTAMP' 2007-02-01 00:00:00'    No

The SQL command shown in the following example identifies the system name, the upper bound high value, and whether this is an interval partition. A value of Yes in the last column indicates that this is an interval partition. The second row in the output is dropped. The first row is simply metadata and is not dropped. The partitions are automatically allocated as you insert the date. System names are automatically generated and partitions are allocated as necessary based on the date.

SQL> INSERT INTO SCA_FLOW_INSTANCE VALUES(..TO_TIMESTAMP('1-5-2013', 'DD-MM-YYYY')...};

--------------------------------------------------------------
1     P0        TIMESTAMP' 2007-02-01 00:00:00'    No
2     SYS_P532  TIMESTAMP' 2013-06-01 00:00:00'    Yes

The SQL command shown in the following example identifies the second and third rows as the partitions to drop. Because this is performed over an earlier month (March 2013 instead of May 2013), another partition is inserted. The positions of the partitions are changed.

SQL> INSERT INTO SCA_FLOW_INSTANCE VALUES(..TO_TIMESTAMP('1-3-2013', 'DD-MM-YYYY')...};

--------------------------------------------------------------
1     P0        TIMESTAMP' 2007-02-01 00:00:00'    No
2     SYS_P578  TIMESTAMP' 2013-04-01 00:00:00'    Yes
3     SYS_P532  TIMESTAMP' 2013-06-01 00:00:00'    Yes

13.4.6 Introduction to Partition Key Selection

The following factors were considered when selecting the schema partition keys:

- Convey or imply state (for example, completed) for referential integrity

- Allow range partitioning on time intervals for maintenance operations

- Be static to avoid row movement that may lead to unreferenced data

- Be static to avoid row movement when table maintenance operations are performed

- Provide performance benefits for console queries through partition pruning

13.4.7 Configuring Partitions

Partitioning is not configured by default; it is a postinstallation step that must be performed manually. Once you decide to implement partitioning of the database, you must perform some initial configuration tasks only once:

- Using the information in this chapter, decide which groups you want to partition.

- For each of those groups, decide which tables you want to partition, remembering that there are some mandatory tables in each group that must be partitioned.

- For each group, decide on the partition interval.

- Create the partition scripts to partition the Oracle SOA Suite schemas. No scripts are supplied; each DBA is responsible for creating the partition scripts appropriate for their environment.

13.4.8 Introduction to the Verification Script

A verification script is provided for a DBA to identify when to drop a partition and its equipartitioned dependent table. The verification script also identifies if there are active, long running instances. You can then move these instances to a different partition, and then drop the original partition. The verification scripts support range interval partitioning.

Note:

The verification script does not drop any partitions; it just ensures that partitions are eligible to be dropped. It is important to enable partitioning for all tables for the scripts to get correct data

13.4.8.1 Component Tables

This section describes partitioning constraints and lists the component tables, the groups to which they belong, and their partition key.

13.4.8.1.1 Partitioning Constraints

Note the following table partitioning constraints:

- You have the choice of the following approach to partitioning:

- Complete partitioning: All tables of a service component/service engine are partitioned.

- No partitioning: No tables of a service component/service engine are partitioned.

- Partial partitioning: Restrict partitioning to specific tables with a high growth rate.
You can partition any of the tables by following these constraints:

- If you want to partition a dependent table, you must also partition its master table.

- All tables should be equipartitioned along the same date ranges and the same name.

- Always partition the SCA_FLOW_INSTANCE table. This constraint is essential when the Audit Level property is set to Development or Production for any of the composites. The verification script checks for active flows based on the active business flow instances within that partition. Therefore, if the SCA_FLOW_INSTANCE table is not partitioned, the entire verification script logic based on the equipartitioning of all the tables fails.

- Regardless of the group and component, all tables that are partitioned use the same time range and the partition ID.

13.4.8.1.2 Component Tables, Range Partition Keys, and Groups

Table 13-6 through Table 13-11 are divided into three groups.

- Group 1: This includes tables that are directly related to the end-to-end flow trace of a composite. A majority of the tables fall into this group.

- Group 1A: This includes a small set of tables that are not directly related to the flow trace.

- Group 2: This includes a small set of tables that have a dependency on multiple tables from Group 1 and 1A tables. You must first execute the group 1 verification script and drop the group 1 partitions before running the group 2 verification script.

Note:

Groups 1 and 1A are combined in the verification script. Running the verification script does not require you to have knowledge of this classification.

Table 13-6 Component: SOA Infrastructure

Table

Range Partition Key

Group

SCA_FLOW_INSTANCE

CREATED_TIME

1

SCA_FLOW_TO_CPST

PARTITION_DATE

1

SCA_COMMON_FAULT

PARTITION_DATE

1

SCA_FLOW_ASSOC

PARTITION_DATE

1

SCA_META_DATA

PARTITION_DATE

1

SCA_REJECTED_MESSAGE

PARTITION_DATE

1

SCA_ATTACHMENT_REF

PARTITION_DATE

1

SCA_SENSOR_VALUE

PARTITION_DATE

1

AUDIT_DETAILS

CI_PARTITION_DATE

1

AUDIT_TRAIL

CI_PARTITION_DATE

1

Table 13-7 Component: Oracle BPEL Process Manager

Table

Range Partition Key

Group

CUBE_INSTANCE

CPST_INST_CREATED_TIME

1

CI_INDEXES

CI_PARTITION_DATE

1

CUBE_SCOPE

CI_PARTITION_DATE

1

WI_FAULT

CI_PARTITION_DATE

1

WORK_ITEM

CI_PARTITION_DATE

1

DLV_SUBSCRIPTION

CI_PARTITION_DATE

1

DOCUMENT_CI_REF

CI_PARTITION_DATE

1

DLV_MESSAGE

RECEIVE_DATE

1A

HEADERS_PROPERTIES

DLV_PARTITION_DATE

1A

DOCUMENT_DLV_MSG_REF

DLV_PARTITION_DATE

1A

XML_DOCUMENT

DOC_PARTITION_DATE

2

Table 13-8 Component: Oracle Mediator

Table Name

Range Partition Key

Group

MEDIATOR_DEFERRED_MESSAGE

CREATION_DATE

1

MEDIATOR_PAYLOAD

CREATION_TIME

2

Table 13-9 Component: Human Workflow

Table

Range Partition Key

Group

WFASSIGNEE

COMPOSITECREATEDTIME

1

WFATTACHMENT

COMPOSITECREATEDTIME

1

WFEVIDENCE

COMPOSITECREATEDTIME

1

WFHEADERPROPS

COMPOSITECREATEDTIME

1

WFMESSAGEATTRIBUTE

COMPOSITECREATEDTIME

1

WFNOTIFICATION

COMPOSITECREATEDTIME

1

WFREVIEWER

COMPOSITECREATEDTIME

1

WFROUTINGSLIP

COMPOSITECREATEDTIME

1

WFTASK

COMPOSITECREATEDTIME

1

WFTASK_TL

COMPOSITECREATEDTIME

1

WFTASKAGGREGATION

COMPOSITECREATEDTIME

1

WFTASKERROR

COMPOSITECREATEDTIME

1

WFTASKHISTORY

COMPOSITECREATEDTIME

1

WFTASKHISTORY_TL

COMPOSITECREATEDTIME

1

WFTASKTIMER

COMPOSITECREATEDTIME

1

Table 13-10 Component: Oracle B2B

Table

Range Partition Key

Group

B2B_BUSINESS_MESSAGE

CPST_INST_CREATED_TIME

1

B2B_APP_MESSAGE

CPST_INST_CREATED_TIME

1

B2B_WIRE_MESSAGE

CPST_INST_CREATED_TIME

1

B2B_DATA_STORAGE

CPST_INST_CREATED_TIME

1

B2B_EXT_BUSINESS_MESSAGE

CPST_INST_CREATED_TIME

1

Table 13-11 Component: Oracle BPM Suite

Table

Range Partition Key

Group

BPM_AUDIT_QUERY

CI_PARTITION_DATE

1

BPM_MEASUREMENT_ACTIONS

CI_PARTITION_DATE

1

BPM_MEASUREMENT_ACTION_EXCEPS

CI_PARTITION_DATE

1

13.4.8.2 Equipartitioning and Interval Partitioning Verification Script Checks

The verification script uses following two tables when performing checking:

- USER_PART_TABLES

- USER_TAB_PARTITIONS

To check the interval definition that you defined for your table:

SQL> select INTERVAL from USER_PART_TABLES
where table_name = 'table_name';

To check the upper bound high value for a partition:

SQL> select high_value from USER_TAB_PARTITIONS
where table_name = 'table_name'
and partition_name = 'partition_name';

13.4.9 Running the Verification Script

The verification script is located in the following directory: MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/verify. There are two versions of the verification script, depending on whether your schema is Interval partitioned or Range partitioned:

- soa_exec_interval_verify.sql

- soa_exec_verify.sql

The verification script helps determine if a partition can be dropped. When you execute the verification script, a log file and a result file is generated for each partition. The log file should be examined by the database administrator to assess if a partition can be dropped by running the result file.

On examining the log file, the database administrator might find that there are too many active instances, and decide to let the partition age further. If the database administrator finds that only a small number of instances are open, say 5%, the administrator may decide to execute row movement to move these instances to another partition. Once the active instances in a partition have been moved to another partition, the partition can be dropped.

To execute the verification script:

1. Set up a database directory for the result and log files.
Before you run the script, the operating system directory, say /tmp/verify, must exist with the appropriate access.
Log in to SQL*Plus as the SOAINFRA user and map the directory to store the result and log files.

sqlplus soainfra
Enter password:
SQL> CREATE OR REPLACE DIRECTORY PART_DIR AS '/tmp/verify';

2. Truncate the temporary tables for Group 1 and Group 2.
For Group 1 tables:

$ sqlplus soainfra
SQL> BEGIN
SQL> verify_soa.trunc_verify1_temp_tables;
SQL> END;
SQL> /

For Group 2 tables:

$ sqlplus soainfra
SQL> BEGIN
SQL> verify_soa.trunc_verify2_temp_tables;
SQL> END;
SQL> /

3. Edit the Group 1 verification script.
Edit the RANGE or INTERVAL script, as per the type of partition used.

Note:

The partitions assessed by the verification scripts are those belonging to the SCA_FLOW_INSTANCE fabric table, as all other tables are equi-partitioned on this fabric table.

- For the Range verification script soa_exec_verify.sql:
Update the PL/SQL table with the SCA_FLOW_COMPOSITE partitions that are candidates to be dropped from the schema. For example:

mySoa_drv_list   := verify_soa.soa_drv_table();
mySoa_drv_list.extend(1);    -- Ensure that you set this correctly
mySoa_drv_list(1) := 'P01';  -- One entry per partition.

- For the Interval verification script soa_exec_interval_verify.sql:
Update the SOA_MAX_TIMESTAMP variable to an appropriate date. Any partitions with a high value less than this date become candidates to be dropped from the schema. For example:

soa_max_timestamp := to_timestamp('2013-08-15','YYYY-MM-DD');

4. Run the verification script for Group 1.
The verification script does not drop the partitions, but generates the log and result files in the PART_DIR database directory. The database administrator must examine the log file to determine if the partitions can be dropped by running the result file, or whether row movement is necessary.
The Group 1 partitions for an interval must always be dropped before the Group 2 partitions. The verification procedure assesses the Group 2 tables partitions based on whether they are still referenced by the Group 1 tables. So, if the Group 1 table partitions are dropped first, then it increases the chance that the Group 2 table partitions can be dropped.

- For range partitioning:

sqlplus soainfra
SQL> @soa_exec_verify.sql 1   -- 1 for Group1.

- For interval partitioning:

sqlplus soainfra
SQL> @soa_exec_interval_verify.sql 1   -- 1 for Group1.

5. Review the log and result files in the PART_DIR directory.
The SCA_FLOW_INSTANCE partition name is included in the log and result file each interval. For Interval partitioning, this partition name is an RDBMS system-generated name.
Example log and result files for range partitioning are SOA_P01_LOG_1 and SOA_P01_RESULT_1.sql. Example log and result files for interval partitioning are SOA_SYS_P579_LOG_1 and SOA_SYS_P579_RESULT_1.sql.

For each partition interval, the database administrator must review the log file carefully to ensure that the partition for that interval has passed all tests. If there are open/active flows reported, then row movement is required before the partition can be dropped.

Moving Active, Long Running Instances to a Different Partition describes the process to move rows across partitions.

6. Drop Group 1 partitions that can be dropped.
The generated result file contains the command to drop the partition. The foreign keys must be disabled before you can drop table partitions with foreign keys. This is an RDBMS requirement, and the SOAINFRA schema presently defines many foreign keys. It is best to DISABLE the foreign keys, and then run all the required verification result scripts. You should re-enable the foreign keys after you have dropped the partitions.

Note:

To help with the disabling and enabling of foreign keys, a routine is provided, which generates a script with the appropriate commands. You only need to generate the script once. The database administrator can choose to customize the script. See Alter Foreign Keys (verify_soa.alter_FK) for more details.

To drop the partitions for an interval, run the result script. For example:

sqlplus soainfra
SQL> SOA_SYS_P579_RESULT_1.sql

7. Run row restore if rows were moved.
This procedure is required only if you used the row movement procedure to move open Group 1 instances. This procedure updates the partition key of the moved open instances back to their original flow creation date value. The mechanism for range and interval partitions is as follows:

- For range partitions, the row movement procedure moves the open flows to a safe partition, enabling the aged partition to be dropped. The row restore procedure then updates the partition key back to the original creation date, which moves the flows to the appropriate, still-available partition. This usually does not trigger any row movement, as the current partition is likely to be the only appropriate and still-available partition.

- For interval partitions, the row movement procedure moves the open flows to a safe partition, enabling the aged partition to be dropped. The row restore procedure then updates the partition key back to the original creation date, which triggers the RDBMS to re-create the aged partition in order to accommodate the open flows. The re-created partition will be small, and will be picked up on the next run of the interval verification script. Note that the interval verification script uses a less-than date value to select candidate partitions.

Row restore is required only for Group 1 tables, and is the same procedure for range and interval partitions. Ensure that the table row movement is enabled. (See the Step to enable table movement in the database for more details.)

sqlplus soainfra
SQL> verify_soa.exec_row_restore_1;
SQL> END;

Run row restore truncate once the row restore routine has successfully completed. The row restore routine can be repeated until successful. Once you have run the row restore truncate routine, row restore cannot be repeated.

sqlplus soainfra
SQL> BEGIN
SQL> verify_soa.trunc_verify1_rst_temp_tables;
SQL> END;

8. Run the Group 2 verification script
The Group 2 verification scripts should only be executed once the Group 1 partitions for the same interval have been dropped.
The steps to drop Group 2 partitions are similar to those for Group 1, as described in the preceding steps:

a. Edit the Group 2 verification script like how we did for Group 1 (Details as described for Group 1).

b. Run verification script for Group 2:

- For range partitioning:

sqlplus soainfra
SQL> @soa_exec_verify.sql 2   -- 2 for Group1.

- For interval partitioning:

sqlplus soainfra
SQL> @soa_exec_interval_verify.sql 2   -- 2 for Group1.

c. Review the log and result files in the PART_DIR directory. (Details as described for Group 1).
Depending on the results, row movement might be required for Group 2 tables. See Triggering row movement for Group 2for more details.

d. Drop Group 2 partitions (Details as described for Group 1).

Note that the row restore routine is not required for Group 2 tables.

9. Re-enable the foreign keys.
See Alter Foreign Keys (verify_soa.alter_FK) for more details on scripts provided to assist with enabling and disabling foreign keys.

Note:

A verification script is not provided for business rules.

13.4.10 Moving Active, Long Running Instances to a Different Partition

The verification script logs provide a count of total instances, open instances, and the percentage of open instances in a partition. If there are open instances, the database administrator can run the row movement procedure to move these rows to a different partition. The row movement procedure updates the partition keys of the open instances, which in turn initiates a row movement of these instances to a different partition.
Moving rows is expensive, as the row movement procedure needs to move the rows in all the equi-partitioned tables. When planning a partitioning strategy, ensure that the partitions are allowed to age sufficiently, so that the percentage of open instances is less than 5% of the total number of rows in the partition.

1. Enable table row movement
The row movement procedure moves rows from one table partition to another. For the RDBMS to perform this task, row movement on the tables must also be enabled before row movement can be performed. Customize and execute the SOA_ENABLE_MVT.SQL script for your environment.

sqlplus soainfra
SQL> @SOA_ENABLE_MVT.SQL

2. If you are running row movement for Group 1, go to Step 3. If you have already dropped the Group 1 partitions, and are running row movement for Group 2, then go to Step 5.

3. Trigger row movement for Group 1.
Execute one of the following procedures to move rows for Group 1 tables, depending on whether the schema is range or interval partitioned:

- For range partitions:

sqlplus soainfra
SQL> PROCEDURE exec_row_movement_1( partition_name in varchar2,
new_partition_date in timestamp );

- For interval partitions:

sqlplus soainfra
SQL> PROCEDURE exec_row_movement_interval_1( partition_name in varchar2,
new_partition_date in timestamp );

where:

partition_name is the name of the partition on which to execute row movement.

new_partition_date is the new date with which to update the partition key column.

Note:

Once the rows have been moved, you should truncate the temporary Group 1 tables, run the Group 1 verification script again, and check the generated log file to ensure that there are no more open instances.

4. You can now proceed to dropping the Group 1 partitions.

5. Trigger row movement for Group 2.
Execute one of the following procedures to move rows for Group 2 tables, depending on whether the schema is range or interval partitioned:

- For range partitions:

sqlplus soainfra
SQL> PROCEDURE exec_row_movement_2( partition_name in varchar2,
new_partition_date in timestamp );

- For interval partitions:

sqlplus soainfra
SQL> PROCEDURE exec_row_movement_interval_2( partition_name in varchar2,
new_partition_date in timestamp );

where:

partition_name is the name of the partition on which to execute row movement.

new_partition_date is the new date with which to update the partition key column.

Note:

Once the rows have been moved, you should truncate the temporary Group 2tables, run the Group 2 verification script again, and check the generated log file to ensure that there are no more open instances.

6. You can now proceed to drop the Group 2 partitions.

13.4.11 Routines to Assist with Partition Maintenance

Oracle SOA Suite includes several routines to assist with the database side of partition maintenance. Routines include scripts to enable and disable foreign keys, alter intervals for interval-partitioned tables, and restore rows after row movement.

The row movement and other partition maintenance routines were included in 12.1.3 through patch 21181834. The routines have been included in 12.2.1 through patch 21520523. The following routines are described below:

Row Restore (verify_soa.exec_row_restore_1)

This routine is used to restore the Group 1 table partition keys back to their original values. You can run the row restore routine once the flows have been row-migrated, and the appropriate partitions have been dropped. Once the routine completes successfully, you can execute the Row Restore Truncate routine.

The following example illustrates running row restore:

BEGIN
verify_soa.exec_row_restore_1;
END;

Row Restore Truncate (verify_soa.trunc_verify1_rst_temp_tables)

This routine truncates the table verify_r_group1. Run this only after the Row Restore routine has been successfully run. The Row Restore routine should be repeated until successful. Once you run Row Restore Truncate, the Row Restore routine cannot be repeated. (NOTE: Consider backing up table verify_r_group1 prior to the truncation).

Note:

Consider backing up the table verify_r_group1 before running the truncate routine.

The following example illustrates running Row Restore Truncate:

BEGIN
verify_soa.trunc_verify1_rst_temp_tables;
END;

Alter Interval (verify_soa.alter_interval)

Use this routine to alter the interval for Interval partitioned tables. The routine generates a SQL script in the PART_DIR directory. The SQL script can then be executed by the SOAINFRA user.

The following example illustrates running Alter Interval:
Step 1: Generates the SQL Script

set echo on;
set serverout on;
/*
NUMTOYMINTERVAL(1, ''MONTH'')
NUMTODSINTERVAL(1, ''DAY'')
NUMTODSINTERVAL(7, ''DAY'')
*/
begin
verify_soa.alter_interval('NUMTODSINTERVAL(1, ''DAY'')');
end;

Step 2: Runs the Generated SQL Script

SQL> @SOA_ALTER_INTERVAL_GROUP1.SQL

Alter Foreign Keys (verify_soa.alter_FK)

Use to disable the foreign keys before dropping a partition, and then to re-enable the foreign keys after the partition drop command. The routine generates two SQL scipts in the PART_DIR directory. The SQL scripts can be customized to suite your performance requirements. The SQL scripts must be run as the SOAINFRA user.

The following example illustrates running Alter Foreign Keys:
Step 1: Generates the SQL Scripts:

set echo on;
set serverout on;
begin
verify_soa.alter_fk;
end;

Step2: Runs the enable and disable commands, as required:

SQL> @SOA_DISABLE_FK.SQL
SQL> @SOA_ENABLE_FK.SQL

13.4.12 Partial Partitioning of Components

If you have an environment in which some components are partitioned, while other components are not partitioned, the nonpartitioned data set must be purged using the purge scripts described in Deleting Large Numbers of Flow Instances_ Adapter Reports_ and Fault Alerts.

For example, assume human workflow is not partitioned, while other components are partitioned. The verification script reports that all SOA partitions can be dropped using the command for dropping partitions. However, the human workflow tables continue to hold workflow data until the data is purged using the loop/parallel purge scripts.

13.5 Removing Records from the Runtime Tables Without Dropping the Tables

The truncate scripts (truncate_soa_oracle.sql and, for the Java database provided with the Oracle SOA Suite Quick Start installation, truncate_soa_javadb.sql) enable you to remove all records from all Oracle SOA Suite runtime tables without dropping the tables. You cannot reclaim database space with the truncate scripts.

The truncate scripts are useful for the following scenarios:

- To create a production or test environment clone (test-to-production or production-to-test) in which you want to keep the schemas from the production environment so that the production customizations and new job definitions are kept, but all instance data in the SOA Infrastructure (that is, in the cloned database) must be truncated, regardless of state.

- For testing purposes in which test scenarios must be recreated and rerun.

The truncate scripts provide this option by including truncate statements covering all the runtime tables of the following components:

- Oracle BPEL Process Manager

- Oracle Mediator

- Business rules

- Oracle B2B

- SOA Infrastructure

- Oracle BPM Suite

To remove records from the runtime tables without dropping the tables:

1. Start SQL*Plus:

sqlplus

2. In SQL*Plus, connect to the database as the SOAINFRA user:

CONNECT SYS AS SOAINFRA

3. Execute the truncate script located in the MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/truncate directory:

SQL> @truncate_soa_oracle.sql

14 Diagnosing Problems with SOA Composite Applications

This chapter describes how to diagnose Oracle SOA Suite problems early and take the proper corrective actions with the assistance of the WebLogic Diagnostic Framework (WLDF) for monitoring diagnostic scenarios using watches and notifications and the Oracle Fusion Middleware Diagnostic Framework for gathering SOA-specific diagnostic scenarios into data dumps that are formatted for viewing and analyzing.

This chapter includes the following sections:

- Introduction to the Diagnostic Frameworks

- Executing Oracle SOA Suite Diagnostic Dumps

- Executing Diagnostic Framework Thread Dumps for SOA Composite Applications

- Supported DMS Metrics

- Creating Watches and Notifications

- Manually Triggering and Executing Dumps

- Viewing Incident Packages with ADR Tools

- Querying Problems and Incidents

For information about troubleshooting, see Troubleshooting Oracle SOA Suite and Oracle BPM Suite.

Note:

The information in this chapter applies only to Oracle databases. Your experience may differ if using a non-Oracle database.

14.1 Introduction to the Diagnostic Frameworks

When you monitor and diagnose problems in Oracle SOA Suite, you face the following challenges:

- Capturing diagnostic data at the moment of occurrence (also known as just-in-time diagnostics), especially for intermittent issues such as obtaining multiple thread dumps when the system hangs or obtaining heap dumps before a system runs out of memory.

- Obtaining advanced information such as data shape (counts by state and growth patterns for the SOA schema and MDS schema).

- Communicating back and forth with Oracle Support Services to provide basic information such as versions, logs, configuration files, patches applied, and so on.

- Detecting problems and taking corrective actions early before they escalate.

To address these challenges, Oracle SOA Suite is integrated with the following diagnostic frameworks that assist you in identifying problems early and taking the proper corrective actions:

- WLDF: For monitoring diagnostic scenarios using watches and notifications.

- Diagnostic Framework: For collecting SOA-specific diagnostic information that is formatted for viewing and analysis. These data dumps can be uploaded as part of a Service Request (SR).

14.1.1 Introduction to WLDF

WLDF is a monitoring and diagnostics framework included with Oracle WebLogic Server that defines and implements a set of services that run within server processes and participate in the standard server life cycle.

Using WLDF, you can capture diagnostic data from Oracle SOA Suite. You configure WLDF watches and notifications from Oracle WebLogic Server Administration Console to monitor runtime logs and metrics. This data enables you to isolate and diagnose faults when they occur.

For more information about WLDF, see Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.

14.1.1.1 Introduction to Watches and Notifications

Watches monitor server and application states and send notifications based on criteria that you set. Watches and notifications are configured as part of a diagnostic module targeted to one or more server instances in a domain. When you create a watch, you build rule expressions for monitoring using the attributes of Oracle SOA Suite and Oracle WebLogic Server MBeans in Oracle WebLogic Server Administration Console.

For example, assume you want to be notified when the percentage of free heap memory falls below 25%. You create a watch that uses the Oracle WebLogic Server MBean weblogic.management.runtime.JRockitRuntimeMBean and its attribute HeapFreePercent. You then define logic indicating that when HeapFreePercent is less than 100%, you want to receive a notification. You can also use the MBean JVMRuntimeMBean when running with a non-JRockit virtual machine (VM).

For information about creating watches and notifications in Oracle WebLogic Server Administration Console, see Creating Watches and Notifications and Section "Configuring the Diagnostic Framework" of Administering Oracle Fusion Middleware.

14.1.1.2 Introduction to Diagnostic Scenarios and MBeans

The watch rule expressions that you create use the attributes of Oracle SOA Suite and Oracle WebLogic Server MBeans to collect data and perform monitoring. You diagnose scenarios with available MBeans to provide statistics about that scenario or to log messages. Managed beans (MBeans) are Java objects that represent JMX manageable resources in a distributed environment. The attributes of the following MBeans are available for defining in watches to monitor scenarios:

- Oracle WebLogic Server MBeans

- Diagnostic Oracle SOA Suite MBeans

- Dynamic Monitoring Service (DMS) metrics exposed as MBeans

Oracle SOA Suite provides several diagnostic scenarios that you can monitor with watches and notifications. Table 14-1 provides details about the supported diagnostic scenarios and the MBeans to use for monitoring.

Table 14-1 Supported Diagnostic Scenarios and MBeans

Scenario

Description

Diagnostic Data Source

Memory issues (startup, deployment, and runtime)

Monitor the free heap available. If the free heap percentage is below a threshold, a notification is triggered to generate a thread stack dump and heap dump.

Oracle WebLogic Server MBean

Deployment hanging

Monitor the elapsed time of a deployment. If it exceeds a threshold, a notification is triggered.

Oracle SOA Suite deployment MBean

Data source issues

Monitor the suspension and connection pool/transaction timeouts

JDBC MBeans

Server overload

Monitor the server's self-health.

Oracle WebLogic Server MBean

Stuck threads

Monitor stuck threads. If any are found, a notification is triggered.

A stuck thread watch/Diagnostic Framework notification is automatically included. Diagnostic Framework incident packages can be created with a tool such as the ADR Command Interpreter (ADRCI). Incidents are created automatically.

Table 14-2 lists some of the available MBeans and DMS Metrics to select when creating watches for monitoring diagnostic data.

Table 14-2 MBeans and DMS Metrics

Diagnostic Data Source (MBean) and Usage

Description

Oracle WebLogic Server MBean

SOA MBean or DMS Metric

weblogic.management.runtime.JVMRuntimeMBean/ weblogic.management.runtime.JRockitRuntimeMBean

For memory statistics

Yes

- -

oracle.fabric.management.wldf.mbean.DeploymentWatchMXBeanImpl

For deployment elapsed time

- -

SOA MBean

weblogic.management.runtime.ServerRuntimeMBean

For health state information

Yes

- -

weblogic.management.runtime.JDBCDataSourceRuntimeMBean

weblogic.management.runtime.JTARuntimeMBean

For JDBC data sources and for accessing transaction runtime characteristics

Yes

- -

For more information about Oracle WebLogic Server MBeans, see MBean Reference for Oracle WebLogic Server.

14.1.2 Introduction to the Diagnostic Framework

The Diagnostic Framework is an Oracle Fusion Middleware feature that aids in detecting, diagnosing, and resolving problems. The problems that are targeted are critical errors such as those caused by code bugs, metadata corruption, customer data corruption, deadlocked threads, and inconsistent state. The Diagnostic Framework detects critical failures and captures dumps of relevant diagnostics information (logs, metrics, server images, and so on). WLDF watches and notifications trigger events for which the Diagnostic Framework listens and generates appropriate data dumps. The dumps are formatted into incident packages for viewing and analysis.

The problems captured as incidents include critical errors such as those described in Table 14-1. Each incident package is identified by a unique ID. When a critical error occurs, it is assigned this unique ID known as an incident number. Diagnostic data for the error (such as log files) is immediately captured and tagged with this number.

The data is then stored in the Automatic Diagnostic Repository (ADR). ADR is a file-system repository for cataloging occurrences of failures and storage of associated diagnostic data. The data is retrieved by incident package number, formatted, viewed with Oracle tools such as ADRCI, and analyzed.

ADRCI enables you to view the names of the dump files. This viewing enables you to investigate problems, and package and upload first-failure diagnostic data to Oracle Support Services.

You can also use the Diagnostic Framework WLST commands to perform the following tasks:

- Query problems

- View incident dump files

- Create manual incidents

- Manually execute dumps

The Diagnostic Framework is supported on all JRF-supported platforms.

The Diagnostic Framework includes a selection of diagnostic dumps for both Oracle WebLogic Server and Oracle SOA Suite. For information about these dumps, see Section "Investigating, Reporting, and Solving a Problem" of Administering Oracle Fusion Middleware.

In addition to these dumps, several Oracle SOA Suite dumps are also supported. For information about Oracle SOA Suite dumps, see Executing Oracle SOA Suite Diagnostic Dumps.

For more information about solving problems, incidents, and WLDF and Diagnostic Framework integration, see Chapter "Diagnosing Problems" of Administering Oracle Fusion Middleware.

For more information about ADR, see Viewing Incident Packages with ADR Tools.

14.1.2.1 Controlling the Number of Incident Packages

If you have a recurring problem in Oracle SOA Suite, this can cause the creation of multiple incident packages. To prevent the server from being overloaded when many failures are occurring, the Diagnostic Framework automatically flood controls some incidents. To avoid this problem, you can configure the Diagnostic Framework to limit the number of incident packages generated. For more information, see Section "Configuring the Diagnostic Framework" of Administering Oracle Fusion Middleware.

14.1.3 Predefined Incident Processing Rules

When you create a watch in the Oracle WebLogic Server Administration Console, you also define a notification. A notification named FMWDFW notification is automatically available for selection. While you can create your own notifications, Oracle recommends that you select FMWDFW notification because it creates the Oracle SOA Suite dumps described in Executing Oracle SOA Suite Diagnostic Dumps.

When an error is detected, the FMWDFW notification handler creates an incident and the Diagnostic Framework takes over incident processing semantics. These semantics are controlled by incident processing rules. The incident processing rules are defined in an XML file and loaded and registered with the Diagnostic Framework during SOA Infrastructure startup.

If you encounter scenarios different from those listed in Table 14-1, you must work with Oracle Support Services to obtain a copy of the customized incident processing rules file. You can place the customized rules file (for example, named custom-rules.xml) in either of the following locations.

- Server level configuration: FMW_HOME/user_projects/domains/domain_name/config/fmwconfig/servers/server_name/dfw

- Domain level configuration: FMW_HOME/user_projects/domains/domain_name/config/fmwconfig/dfw

The Diagnostic Framework automatically loads the file on server start up. All dumps are registered as system scoped unless an application name is prefixed to the file name:

- myrules.xml: System scoped. This means the rules file applies to all SOA composite applications in the SOA Infrastructure.

- application_name#name.xml: Application scoped. Everything before the # is treated as the application name. For a rules file to be associated with an application, that application must have its own deployment in the Oracle WebLogic Server config.xml file. A SOA composite application does not have its own entry as an Oracle WebLogic Server deployment. Therefore, it cannot have a Diagnostic Framework rules file associated with it. For example, myrules.xml is scoped to Oracle WebLogic Server and can only generate root level diagnostic dumps. soa-infra#rules.xml is SOA scoped and can generate SOA diagnostic dumps. Both could generate incidents coming from a SOA composite application error.

In addition, you can dynamically load the rules file into the SOA Infrastructure without restarting the server. A dynamic reload is important because a server restart can disturb the accuracy of the diagnostic data collected.

To dynamically reload the file without restarting the server, enter the following WLST command:

wls:/soainfra/serverConfig> reloadCustomRules(name='rule_file')

The following example shows a sample custom rules file. When an ERROR level message is detected in the *-diagnostic.log from the oracle.soa.bpel.engine.ws module, the soa.composite.trail diagnostic dump is executed. A restart of the system to load the rules actually disturbs the accuracy of diagnostic data collected.

<?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules"
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
<logDetectionConditions>
<condition module="oracle.soa.bpel.engine.ws"/>
</logDetectionConditions>

<defaultActions>
<dumpAction name="soa.composite.trail">
<argument name="ecid" value="ECID" valueType="Fact" mandatory="true"/>
</dumpAction>
</defaultActions>

</diagnosticRules>

14.2 Executing Oracle SOA Suite Diagnostic Dumps

In addition to the diagnostic dumps available with Oracle WebLogic Server, Oracle SOA Suite supports the creation of the diagnostic dumps shown in Table 14-3.

Table 14-3 Oracle SOA Suite Diagnostic Dumps

Dump

Description

soa.env

Runtime environment dumps.

soa.config

Runtime platform configuration dumps.

soa.db

Database dumps.

soa.composite

Deployed composite metadata dumps.

soa.composite.trail

Instance audit trail dumps.

soa.edn

Event dumps.

soa.wsdl

Deployed composite WSDL/schema cache dumps.

bpel.dispatcher

Static dumps (system, invoke, engine, and audit thread counts) and runtime scheduled and working message count dumps.

bpel.apt

Average instance processing time dumps.

bpel.apd

Average instance processing delay dumps (for asynchronous processes).

bpel.sps

Synchronous business processes dump statistics such as minimum, maximum, and average processing time (in milliseconds) and count of instances processed.

bpel.aps

Asynchronous BPEL process dump statistics such as minimum, maximum, and average processing time (in milliseconds) and count of instances processed.

bpel.rs

Request level dump statistics such as minimum, maximum, and average processing time (in milliseconds) and count of requests processed as the request flows though various layers of the BPEL process service engine.

mediator.resequencer

Resequencer group processing delay dumps.

soa.adapter.ra

Adapter connection factory configurations. Use to identify if the same Java Naming and Directory Interface (JNDI) is being used by multiple composites.

soa.adapter.connpool

JCA adapter connection pool statistics and connection pool leaks. The current open connection statistics are displayed, enabling tuning of the connection pool.

soa.adapter.stats

Adapter DMS statistics such as message size and fault count.

The Diagnostic Framework outputs and records the diagnostic dumps. You can list details about all the diagnostic dumps with the WLST listDumps and describeDump commands.

Note:

You must start WLST from MW_HOME/oracle_common/common/bin. Otherwise, the ODF functions are missing.

./wlst.sh

14.2.1 To List the Dumps:

1. Connect to the managed server on which the SOA Infrastructure is installed.

wls:/offline>connect('user_name','password','t3://myhost.us.example.com:8001')

Connecting to t3://myhost.us.example.com:8001 with userid user_name ...
Successfully connected to managed Server "soa_server1" that belongs to domain
"soainfra".

2. List the Diagnostic Framework dumps.

wls:/soainfra/serverConfig> listDumps()
odl.activeLogConfig
jvm.classhistogram
dms.ecidctx
jvm.flightRecording
wls.image
odl.logs
dms.metrics
odl.quicktrace
http.requests
jvm.threads

Use the command describeDump(name=<dumpName>) for help on a specific dump.

3. List the Oracle SOA Suite dumps.

wls:/soainfra/serverConfig> listDumps(appName='soa-infra')

adf.ADFConfigDiagnosticDump
adf.ADFConfigPropertiesDump
bpel.apd
bpel.apt
bpel.dispatcher
mediator.resequencer
soa.adapter.connpool
soa.adapter.ra
soa.adapter.stats
soa.composite
soa.composite.trail
soa.config
soa.db
soa.edn
soa.env
soa.wsdl
webservices.servlet

Use the command describeDump(name=<dumpName>) for help on a specific dump.

The Oracle SOA Suite dumps are described in subsequent sections of this chapter.

For more information about Diagnostic Framework dumps, see Chapter "Managing Log Files and Diagnostic Data" of Administering Oracle Fusion Middleware.

14.2.2 Runtime Environment Diagnostic Dumps (soa.env)

Table 14-4 provides details about runtime environment diagnostic dumps.

Table 14-4 Runtime Environment Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.env

- Dump parameters:
None

- Dump Mode:
ASYNC_SYNC

- SOA runtime version, label (can be obtained from the Discovery MBean), and topology (information about the cluster of which the runtime version is a member).

- Topology: Cluster and Oracle Coherence information such as cluster name, member name, whether the cluster is the leader, local members, machine ID, rack ID, and so on.
The leader is generally the oldest node in the cluster. This may change over time as members leave and join the cluster. This senior member is responsible for maintaining cluster membership and making other decisions for the cluster. It also acts as the final arbiter in various protocols, such as the panic protocol.

- Patch inventory

- Oracle Coherence messaging mode: Either unicast or multicast.

14.2.2.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.env.

wls:/soainfra/serverConfig> describeDump(name='soa.env', appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.env', appName='soa-infra')

14.2.3 Runtime Platform Configuration Diagnostic Dumps (soa.config)

Table 14-5 provides details about runtime platform configuration diagnostic dumps.

Table 14-5 Runtime Platform Configuration Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.config

- Dump parameters:
zip: (Optional) Supports the following values:

- true: (Default value) Zips the output file and artifacts into one ZIP file.

- false: Writes the dump text file and artifacts to the dump path location without compressing them into one ZIP file.

output: (Optional) Specifies the alternate directory location to which to write dump files. If not specified, the diagnostic dump uses the Diagnostic Framework dump path.

- Dump Mode:
ASYNC_SYNC

deployed-composites.xml - A catalog of deployed composites, including their revisions.

Service engine configurations: The following configurations are persisted in MDS (soa/configuration/default/*.xml):

- adapter-config.xml

- b2b-config.xml

- bpel-config.xml

- bpmn-config.xml

- businessrules-config.xml

- cep-config.xml

- edn-config.xml

- mediator-config.xml

- soa-infra-config.xml

- workflow-config.xml

- workflow-identity-config.xml

- workflow-notification-config.xml

14.2.3.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.config:

wls:/soainfra/serverConfig> describeDump(name='soa.config',
appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra')

The executeDump command dumps deployed-composites.xml from the MDS repository and service engine configurations for all installed service engines into a single, compressed ZIP file (for example, named soa_config364634563344231671.zip).

2. Enter the following WLST command line syntax to execute a dump of soa.config with the zip parameter set to false. This setting writes the dump text file and artifacts to the dump path location without compressing them into one ZIP file.

wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra',
args={'zip':'false'})

3. Examine the contents under the default dump path:

[jdoe@myhost /tmp]$ ls -alR oracle-dfw-7178460573556479044.tmp
oracle-dfw-7178460573556479044.tmp:
total 52
drwxr-----   3 jdoe dba   4096 Oct 24 15:43 .
drwxrwxrwt 104 root root 36864 Oct 24 15:37 ..
drwxr-----   4 jdoe dba   4096 Oct 24 15:43 soa_config199325881615155981.d
-rw-r-----   1 jdoe dba    561 Oct 24 15:43 soa_config199325881615155981.txt

oracle-dfw-7178460573556479044.tmp/soa_config199325881615155981.d:
total 16
drwxr----- 4 jdoe dba 4096 Oct 24 15:43 .
drwxr----- 3 jdoe dba 4096 Oct 24 15:43 ..
drwxr----- 2 jdoe dba 4096 Oct 24 15:43 deployed-composites
drwxr----- 2 jdoe dba 4096 Oct 24 15:43 se-configurations

oracle-dfw-7178460573556479044.tmp/soa_
config199325881615155981.d/deployed-composites:
total 12
drwxr----- 2 jdoe dba 4096 Oct 24 15:43 .
drwxr----- 4 jdoe dba 4096 Oct 24 15:43 ..
-rw-r----- 1 jdoe dba 1437 Oct 24 15:43 deployed-composites.xml

oracle-dfw-7178460573556479044.tmp/soa_
config199325881615155981.d/se-configurations:
total 56
drwxr----- 2 jdoe dba 4096 Oct 24 15:43 .
drwxr----- 4 jdoe dba 4096 Oct 24 15:43 ..
-rw-r----- 1 jdoe dba  267 Oct 24 15:43 adapter-config.xml
-rw-r----- 1 jdoe dba  425 Oct 24 15:43 b2b-config.xml
-rw-r----- 1 jdoe dba 2040 Oct 24 15:43 bpel-config.xml
-rw-r----- 1 jdoe dba 1525 Oct 24 15:43 bpmn-config.xml
-rw-r----- 1 jdoe dba  895 Oct 24 15:43 businessrules-config.xml
-rw-r----- 1 jdoe dba  119 Oct 24 15:43 cep-config.xml
-rw-r----- 1 jdoe dba  215 Oct 24 15:43 edn-config.xml
-rw-r----- 1 jdoe dba  836 Oct 24 15:43 mediator-config.xml
-rw-r----- 1 jdoe dba 1148 Oct 24 15:43 soa-infra-config.xml
-rw-r----- 1 jdoe dba 2693 Oct 24 15:43 workflow-config.xml
-rw-r----- 1 jdoe dba 2146 Oct 24 15:43 workflow-identity-config.xml
-rw-r----- 1 jdoe dba  605 Oct 24 15:43 workflow-notification

4. Enter the following WLST command line syntax to execute a dump of soa.config that compresses all dump into a ZIP file in the specified output directory.

wls:/soainfra/serverConfig> executeDump(name='soa.config', appName='soa-infra'
,args={'output':'/home/myhome/CFG_DUMP_DIR_APP_ZIP'})

14.2.4 Database Diagnostic Dumps (soa.db)

Table 14-6 provides details about database diagnostic dumps. The types of database information captured includes data shape information such as counts by state and growth patterns for Oracle SOA Suite schemas and the MDS schema.

Table 14-6 Database Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.db

- Dump parameters:
None

- Dump Mode:
ASYNC_SYNC

BPEL database table growth data using JDBC-based access to execute the query and dump the result:

SELECT dt.table_name table_name,ds.bytes/1024/1024
segment_size_mb, ds.extents extents_used, dt.num_rows
total_rows, to_char(dt.last_analyzed,'YYYY-MM-DD
HH24:MI:SS') last_analyzed_date FROM dba_segments ds,
dba_tables dt WHERE dt.owner = ds.owner and dt.owner =
'schema_user_name' and dt.tablespace_name =
ds.tablespace_name and dt.table_name = ds.SEGMENT_NAME
and ds.segment_type = 'TABLE' and dt.table_name in
('CUBE_INSTANCE', 'MEDIATOR_CASE_INSTANCE','COMPOSITE_
INSTANCE', 'AUDIT_TRAIL', 'WORK_ITEM', 'DLV_MESSAGE',
'XML_DOCUMENT','DOCUMENT_CI_REF')

14.2.4.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.db:

wls:/soainfra/serverConfig> describeDump(name='soa.db', appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.db', appName='soa-infra')

This dump shows the query string and records from the result set.

14.2.5 Deployed Composite Metadata Diagnostic Dumps (soa.composite)

Table 14-7 provides details about deployed composite metadata diagnostic dumps. The types of information captured includes the current composite processed when an incident occurs, MDS artifact references (for example, namespace exports), and abnormal transactions.

Table 14-7 Deployed Composite Metadata Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.composite

- Dump parameters:
flowid (Optional): When present, locates the flowtrace.xml file that includes the flow ID. It can be obtained from a dump context if not specified as a dump parameter. The following rules apply for actual parameter evaluation:

1) If the flow ID is available (as a dump parameter or obtained from a dump context), it retrieves the flow instance and gets the flow trace. It uses the ECID associated with the flow instance to retrieve the remaining dump artifacts.

2) If the flow ID is unavailable, but the ECID is (as a dump parameter or obtained from a dump context), it is used to look up the flow instance and retrieve the flow trace. It uses the ECID to retrieve other dump artifacts.

3) If both the flow ID and ECID are available, and the ECID is not equal to the flow's ECID, the ECID is ignored and a warning is displayed. Rule 1 is followed.

4) If both the flow ID and ECID are not available, an exception error is displayed.

ecid: (Optional) Matches SOA composite applications associated with the execution context ID (ECID). When ecid is specified, compositeName, partition, and revision are not used. When ecid is not specified, but other parameters are present, those parameters are used to match the composites. When no parameters are specified, an attempt is made to obtain the ECID from the dump context.

compositeName: (Optional) Composite name that includes MDS recorded artifacts to dump. If a value is not specified (null or blank), compositeName assumes a wild card (*). You can also enter a wild card (*) to match any composite name.

partition: (Optional) Partition name in which the composite is deployed. If not specified, the partition of the default composite specified in the deployed-composites.xml file is assumed (for example, default, partition_01, and my_partition). A wild card (*) to match any partition is supported.

revision: (Optional) Composite revision (for example, 1.0) that includes MDS recorded artifacts to dump. If not specified, the default composite revision as specified in deployed-composites.xml is assumed. A wild card (*) to match any revision is supported.

zip: (Optional) Whether to compress the dump output into a ZIP file. The following values are supported:

- true: (Default value) Compresses dump files into one ZIP file.

- false: Writes the dump to a text file and artifacts to the dump path location without compressing them into one ZIP file.

- output: (Optional) Alternate directory location to which to write dump files. If not specified, the diagnostic dump uses the Diagnostic Framework dump path.

- Dump Mode:
ASYNC_SYNC

Per composite metadata from MDS:

- All the MDS recorded artifacts for the specified composites.

- The text dump file contains logging information about which composite's MDS artifacts are dumped and to where.

- All dump files compressed into one ZIP file.

- User-specified output file location for WLST use.

- One or more generated scratch_entries.txt files. The scratch_entries.txt file is a per composite file containing a directory listing of the scratch area for that deployed composite. A scratch area for a deployed composite is for holding those artifacts generated when the composite is deployed (for example, the JAXB code generated).
The location of the scratch area is indicated by the composite-revision element in deployed-composites/deployed-composites.xml.

- The soa.composite dump calls the soa.adapter.ra dump when the composite has a JCA binding in it. It dumps the connection factory properties under the soa_adapter_ra/ adapter-cf-config-properties.txt file.

14.2.5.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.composite:

wls:/soainfra/serverConfig> describeDump(name='soa.composite'
, appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.composite',
appName='soa-infra',args={'compositeName':'WSInMedPubBpelSubFileOut',
'revision':'1.0','partition':'default','output':'/home/myhome/COMPOSITE_DUMP_
MDS_ZIP'})

A dump output file is created at the specified dump location of /home/myhome/COMPOSITE_DUMP_MDS_ZIP.

The Location field shows the dump results compressed at the specified location. In the navigator on the left are the MDS artifacts of the ZIP file (for example, the .edl file, .bpel file, and so on). The .txt file at the bottom is the main dump file in the ZIP file.

2. Enter the following WLST command line syntax to execute a dump of soa.composite that includes all SOA composite applications, revisions, and partitions.

wls:/soainfra/serverConfig> executeDump(name='soa.composite',
appName='soa-infra',args={'compositeName':'*',
'revision':'*','partition':'*','output':'/home/myhome//COMPOSITE_DUMP_
DIR_ALLCOMP_ALL_REV_ALL_PART'})

The Location field shows the dump result compressed at the specified location.

All SOA composite applications from all partitions with all revisions are dumped.

14.2.6 Instance Audit Trail Diagnostic Dumps (soa.composite.trail)

Table 14-8 provides details about instance audit trail diagnostic dumps. The type of information captured includes the business flow instance audit trail, individual service component audit trails, faults, and sensors information associated with the message flow identified by the ECID.

Table 14-8 Instance Audit Trail Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.composite.trail

- Dump parameters:
flowid (Optional): When present, locates the flowtrace.xml file that includes the flow ID. It can be obtained from a dump context if not specified as a dump parameter. The following rules apply for actual parameter evaluation:

1) If the flow ID is available (as a dump parameter or obtained from a dump context), it retrieves the flow instance and gets the flow trace. It uses the ECID associated with the flow instance to retrieve the remaining dump artifacts.

2) If the flow ID is not available, but the ECID is (as a dump parameter or obtained from a dump context), it is used to look up the flow instance and retrieve the flow trace. It uses the ECID to retrieve other dump artifacts.

3) If both the flow ID and ECID are available, and the ECID is not equal to the flow's ECID, the ECID is ignored and a warning is displayed. Rule 1 is followed.

4) If both the flow ID and ECID are not available, an exception error is displayed.

ecid (Optional): The execution content ID for tracking message flow across multiple business flow instances.

- zip (Optional): The following values are supported:
- true: (Default value) Compresses dump files into one ZIP file.

- false: Writes the dump to a text file and artifacts to the dump path location without compressing them into one ZIP file.

- Dump Mode:
ASYNC_SYNC

- The top level audit trail associated with the flow ID or ECID and the audit trails at the business flow instances level. All are written in a file per business flow instance. The main dump file logs entries for each of the individual dump artifacts (for example, for a business flow instance associated with the ECID). The entries are written in the main dump file recording the name, type, created date, location of the dump artifact, and so on (for example, the path to the file where the audit trail raw XML is located).
This dump is for the execution of message routing triggered by an inbound message.

- Business flow instances information.

- Information for each business flow instance.

- Faults related to the ECID are dumped into a dedicated faults file.

- Sensor instances information for each business flow instance.

14.2.6.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.composite.trail:

wls:/soainfra/serverConfig> describeDump(name='soa.composite.trail'
, appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.composite.trail',
appName='soa-infra', args={'flowid':'3','output':'/scratch/myhome/staging_
area/SOA_TRAIL_12C_DUMP_ZIP/'})

For information about obtaining the ECID, see Monitoring the Flow Trace of a Business Flow Instance.

14.2.7 Event Diagnostic Dumps (soa.edn)

Table 14-9 provides details about event diagnostic dumps. The types of information captured include EDN business event bus status information and EDN database log records.

Table 14-9 Event Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.edn

- Dump parameters:
ecid: Dumps the publisher and subscriber information associated with the ECID.

flowid: Dumps the publisher and subscriber information associated with the flow ID.

- Dump Mode:
ASYNC_SYNC

- Global EDN configuration information such as retry interval, maximum retries, EDN work manager class, EDN work manager JNDI name, default JMS configuration, user-defined event type-to-JMS configuration mappings, current durable flag, current JMS type, current default event priority, EDN bus class, EDN bus status, and others.

- All publishers information such as composite information, component information, and publisher event information (destination, persistence flag, time to live, priority, and JCA reference information).

- All subscribers information such as composite information, component information, and subscriber event information (subscriber name, durable flag, event target information, per subscriber poller thread number, event filter, run as role, JCA service information, and others).

All information is written to the dump text file.

14.2.7.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.edn.

wls:/soainfra/serverConfig> describeDump(name='soa.edn', appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.edn', appName='soa-infra')

2. Enter the following WLST command with the flowid parameter set. This parameter captures the publisher and subscriber information associated with the flow:

wls:/soainfra/serverConfig>
executeDump(name='soa.edn',appName='soa-infra',args={'flowid':'10002'})

3. Enter the following WLST command without the flowid and ecid parameters. Not specifying these parameters lists the publisher and subscriber deployed.

wls:/soainfra/serverConfig> executeDump(name='soa.edn',appName='soa-infra')

Note:

- You must have the administrator privilege to enable/disable the edn-db-log.

- Always disable the edn-db-log after a debugging session to disable logging. This prevents excessive database growth in the EDN database log table. If the edn-db-log remains enabled, then debugging messages related to events that are published/enqueued into the database and subscribed to/dequeued from the database continue to be persisted into certain EDN database log tables. This causes the table to grow indefinitely.

14.2.8 Deployed Composite WSDL/Schema Cache Diagnostic Dumps (soa.wsdl)

Table 14-10 provides details about service definition information cached for composites that match the specified parameters: composite name, partition, and revision.

Table 14-10 Deployed Composite WSDL/Schema Cache Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.wsdl

- Dump parameters:
flowid (Optional): When present, locates the flowtrace.xml file that includes the flow ID. It can be obtained from a dump context if not specified as a dump parameter. The following rules apply for actual parameter evaluation:

1) If the flow ID is available (as a dump parameter or obtained from a dump context), it retrieves the flow instance and gets the flow trace. It uses the ECID associated with the flow instance to retrieve the remaining dump artifacts.

2) If the flow ID is not available, but the ECID is (as a dump parameter or obtained from a dump context), it is used to look up the flow instance and retrieve the flow trace. It uses the ECID to retrieve other dump artifacts.

3) If both the flow ID and ECID are available, and the ECID is not equal to the flow's ECID, the ECID is ignored and a warning is displayed. Rule 1 is followed.

4) If both the flow ID and ECID are not available, an exception error is displayed.

ecid: (Optional) ECID for tracking message flow across multiple business flow instances. When present, this parameter locates any associated composites. Other composite matching parameters are ignored. The ECID is obtained from the dump context, if not specified as a dump parameter.

compositeName: (Optional) Composite name that includes key service definition information (WSDLs) to dump, including WSDLs and XSDs referenced. If a value is not specified (null or blank), compositeName assumes a wild card (*). A wild card (*) to match any composite is supported.

partition: (Optional) Partition name in which the composite is deployed. If not specified, the default composite's partition specified in the deployed-composites.xml file is assumed. A wild card (*) to match any partition is supported.

revision: (Optional) Composite revision (for example, 1.0) that includes the service definition information (from WSDLs) to dump. If not specified, the revision of the default composite as specified in the deployed-composites.xml file is assumed. A wild card (*) to match any revision is supported.

- Dump Mode:
ASYNC_SYNC

- Composite distinguished name (DN). For example: compositeDN:partition_1/WSInMedPubBpelSubFileOut!1.0*soa_8a169ab1-395a-4b87-9986-9fa2742a8bd3.

- Is it the default in the series.

- Composite name.

- Composite state (on or off).

- Composite mode (active or retired).

- The qualified name and the target namespace for all service definitions (including those from shared WSDLs): javax.wsdl.Definition objects:
- Service name: QName javax.wsdl.Definition.getQName()

- Target namespace: javax.wsdl.Definition.getTargetNamespace()

- SchemaManager state variables:
- SchemaManager.isPostDeploy()

- SchemaManager.isShared()

- SchemaManager.schemaAddedSinceLast Build()

- XML schema definitions referenced by service definitions:
- The message type QName

- The message type SchemaTargetNamespace

- The message type TargetNS

14.2.8.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and the available parameters and execute a dump of soa.wsdl:

wls:/soainfra/serverConfig> describeDump(name='soa.wsdl', appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='soa.wsdl', appName='soa-infra'
,arg=('compositeName':'WSInMedPubBpelSubFileOut',
'revision':'1.0','partition':'partition_1'})

14.2.9 Dispatcher Static Configuration Diagnostic Dumps (bpel.dispatcher)

Table 14-11 provides details about dispatcher static configuration diagnostic dumps.

Table 14-11 Dispatcher Static Configuration Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

bpel.dispatcher

- Dump parameters:
format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC_SYNC

It is safe to mark this SOA diagnostic dump as ASYNC_SYNC if the dump can be executed as follows: (1) In the thread context of an incident (synchronous) and (2) Not in the context of the incident, but still produces diagnostic information.

Static pool configurations (dispatcher configurations)

- Audit, invoke, and nonblocking invoke thread counts

- Engine and system threads

Runtime message queue sizes:

- Total scheduled (messages in the queue awaiting processing) message counts

- Total working (messages currently being processed) message counts

Runtime message queue breakdown sizes (total processed and erred messages, and average message pending and execution time):

- Audit queue

- Engine queue

- Invoke queue

- Nonblocking invoke queue

- System queue

14.2.9.1 WLST Command Dump Description and Execution

In addition to the WLST command described in this section, you can also obtain dispatcher static configuration diagnostic information through the System MBean Browser. This option enables you to obtain more specific details about invoke queue, delivery queue, and instance queue scheduled and working messages. For more information, see Obtaining Dispatcher Static Configuration Diagnostic Dumps with the System MBean Browser.

1. Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.dispatcher:

wls:/soainfra/serverConfig> describeDump(name='bpel.dispatcher', appName='soa-infra')

wls:/soainfra/serverConfig> executeDump(name='bpel.dispatcher', appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of bpel.dispatcher in XML format:

executeDump(name='bpel.dispatcher', appName='soa-infra', args={'format':'xml'})

14.2.9.2 Obtaining Dispatcher Static Configuration Diagnostic Dumps with the System MBean Browser

You can also display dispatcher static configuration diagnostic dumps in the System MBean Browser by invoking the readXMLDispatcherTrace property. This option enables you to obtain more specific details about invoke queue, delivery queue, and instance queue messages currently being processed or scheduled to be processed than you receive with the WLST executeDump command described in WLST Command Dump Description and Execution.

1. In the navigation tree, expand the SOA folder.

2. Right-click soa-infra, and select Administration > System MBean Browser.

3. Select Application Defined MBeans > oracle.as.soainfra.bpm > Server: server_name > bpel > CubeDispatcher.

4. Click readXMLDispatcherTrace.

5. Click Invoke.

Results are displayed in the property window.

14.2.10 Average Instance Processing Time Diagnostic Dumps (bpel.apt)

Table 14-12 provides details about average instance processing time diagnostic dumps. This information is obtained from the creation and last modified timestamp for the instance persisted in the BPEL process service engine.

Table 14-12 Average Instance Processing Time Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

bpel.apt

- Dump parameters:
format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC_SYNC

It is safe to mark this diagnostic dump as ASYNC_SYNC if the dump can be executed as follows: (1) In the thread context of an incident (synchronous) and (2) Not in the context of the incident, but still produces diagnostic information.

The average time that instances for various processes take during execution. This information is obtained from the persistence store and includes the time taken by any partners invoked by the process. The average time is in seconds.

14.2.10.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.apt:

wls:/soainfra/serverConfig> describeDump(name='bpel.apt', appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of bpel.apt in XML format:

executeDump(name='bpel.apt', appName='soa-infra', args={'format':'xml'})

14.2.11 Average Instance Processing Delay Diagnostic Dumps (bpel.apd)

Table 14-13 provides details about average instance processing delay diagnostic dumps for asynchronous processes. This dump provides the average time taken by the BPEL process service engine to retrieve the persisted message from the database and start processing that message. The statistics are generated from the database and not from in-memory.

Table 14-13 Average Instance Processing Delay Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

bpel.apd

- Dump parameters:
format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC_SYNC

It is safe to mark this SOA diagnostic dump as ASYNC_SYNC if the dump can be executed as follows: (1) In the thread context of an incident (synchronous) and (2) Not in the context of the incident, but still produces diagnostic information.

Average invoke processing delay between the receipt of the incoming message that triggers the process instance and the time at which the BPEL service engine actually started processing the message.

Note: The dump described in Average Instance Processing Time Diagnostic Dumps (bpel.apt) provides the total execution time for a process instance, which is a function of the time for processing of activities, and also includes the time that the partner takes (if it involves calling one or more). However, because the incoming message is first stored in the database for asynchronous communications before being processed, more specific details are sometimes required to diagnose system bottlenecks. Therefore, details about the delay in the BPEL process service engine selecting the message from the database is also provided with the bpel.apd dump.

This dump information is generated from the database and not from in-memory. For further details and better analysis about delays at various layers of the BPEL process service engine, see Viewing Low Level Request Breakdown Table Details.

14.2.11.1 WLST Command Dump Description and Execution

Note:

- Because this dump is executed against the database, the query may run slow if you have very large records.

- There are no filters for limiting the data to query.

- The dump runs queries provided as database views external to the normal BPEL process service engine persistence schema. You can tune the view directly and receive better results.

1. Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.apd:

wls:/soainfra/serverConfig> describeDump(name='bpel.apd', appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of bpel.apd in XML format:

wls:/soainfra/serverConfig> executeDump(name='bpel.apd', appName='soa-infra', args={'format':'xml'})

14.2.12 Synchronous Process Statistics Diagnostic Dumps (bpel.sps)

Table 14-14 provides details about synchronous process statistics diagnostic dumps. This dump provides the minimum, maximum, and average processing time (in milliseconds) and the count of instances processed. You must configure the StatsLastN System MBean Browser property described in Viewing Low Level Request Breakdown Table Details. to obtain this diagnostic dump. However, if the optional dump parameters duration and buffer are specified and StatsLastN is not configured, this dump command provides statistics for throughput (transactions per second) information.

Table 14-14 Synchronous Process Statistics Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

bpel.sps

- Dump parameters:
buffer: (Optional) Specify a value for the buffer range (100-100000).

duration: (Optional) Specify a value for the time duration (1 - 10000).

format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC_SYNC

The minimum, maximum, and average processing time (in milliseconds) and the count of instances processed for synchronous processes.

14.2.12.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.sps:

wls:/soainfra/serverConfig> describeDump(name='bpel.sps', appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of bpel.sps with StatsLastN configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.sps',
appName='soa-infra')

3. Enter the following WLST command line syntax to execute a dump of bpel.sps in XML format with StatsLastN configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.sps', appName='soa-infra',
args={'format':'xml'})

4. Enter the following WLST command line syntax to execute a dump of bpel.sps with throughput values for the duration and buffer parameters.

wls:/soainfra/serverConfig> executeDump(name='bpel.sps', appName='soa-infra',
args={'duration':'10', 'buffer':'1000'})

5. Enter the following WLST command line syntax to execute a dump of bpel.sps in XML format with throughput values for the duration and buffer parameters and StatsLastN not configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.sps', appName='soa-infra',
args={'format':'xml', 'duration':'10', 'buffer':'1000'})

14.2.13 Asynchronous Process Statistics Diagnostic Dumps (bpel.aps)

Table 14-15 provides details about asynchronous process statistics diagnostic dumps. This dump provides process level (asynchronous BPEL processes only) statistics such as minimum, maximum, and average processing time (in milliseconds) and count of instances processed. You must configure the StatsLastN System MBean Browser property described in Viewing Low Level Request Breakdown Table Details. to obtain this output. However, if the optional parameters duration and buffer are specified and StatsLastN is not configured, this dump command provides statistics for throughput (transactions per second) information.

Table 14-15 Asynchronous Process Statistics Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

bpel.aps

- Dump parameters:
buffer: (Optional) Specify a value for the buffer range (100-100000).

duration: (Optional) Specify a value for the time duration (1 - 10000).

format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC_SYNC

The minimum, maximum, and average processing time (in milliseconds) and count of instances processed for asynchronous processes.

14.2.13.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.aps:

wls:/soainfra/serverConfig> describeDump(name='bpel.aps', appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of bpel.aps with StatsLastN configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.aps',
appName='soa-infra')

3. Enter the following WLST command line syntax to execute a dump of bpel.aps in XML format with StatsLastN configured:

executeDump(name='bpel.aps', appName='soa-infra', args={'format':'xml'})

4. Enter the following WLST command line syntax to execute a dump of bpel.aps with throughput values for the duration and buffer parameters.

wls:/soainfra/serverConfig> executeDump(name='bpel.aps', appName='soa-infra',
args={'duration':'60', 'buffer':'1000'})

5. Enter the following WLST command line syntax to execute a dump of bpel.aps with throughput values for the duration and buffer parameters in XML format and StatsLastN not configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.aps', appName='soa-infra',
args={'format':'xml', 'duration':'60', 'buffer':'1000'})

14.2.14 Request Statistics Diagnostic Dumps (bpel.rs)

Table 14-16 provides details about request diagnostic dumps. This dump provides the minimum, maximum, and average processing time (in milliseconds) and count of requests processed as the request flows though various layers of the BPEL process service engine. You must configure the StatsLastN System MBean Browser property described in Viewing Low Level Request Breakdown Table Details. to obtain this diagnostic dump. However, if the optional dump parameters duration and buffer are specified and StatsLastN is not configured, this dump command provides statistics for throughput (transactions per second) information.

Table 14-16 Request Statistics Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

bpel.rs

- Dump parameters:
buffer: (Optional) Specify a value for the buffer range (100 - 100000).

duration: (Optional) Specify a value for the time duration (1 - 10000).

format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC_SYNC

The minimum, maximum, and average processing time (in milliseconds) and count of requests processed as the request flows though various layers of the BPEL process service engine.

14.2.14.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description and execute a dump of bpel.rs:

wls:/soainfra/serverConfig> describeDump(name='bpel.rs', appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of bpel.rs with StatsLastN configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra')

or

wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra',
args={'format':'xml'})

3. Enter the following WLST command line syntax to execute a dump of bpel.rs with throughput values for the duration and buffer parameters and StatsLastN not configured.

wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra',
args={'duration':'10', 'buffer':'1000'})

or

wls:/soainfra/serverConfig> executeDump(name='bpel.rs', appName='soa-infra',
args={'format':'xml','duration':'10', 'buffer':'1000'})

14.2.15 Resequencer Group Processing Delay Diagnostic Dumps (mediator.resequencer)

Table 14-17 provides details about resequencer group processing delay diagnostic dumps.

Table 14-17 Resequencer Group Processing Delay Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

mediator. resequencer

- Dump parameter:
resequencerMaxUnprocessTime: (Required) Specify the number of minutes a resequencer group should be inactive before being included in the diagnostic dump.

- Dump Mode:
ASYNC_SYNC

Group information:

- Component DN (name)

- Operation

- Group ID

- Group status

- Component status

- Last received time

- Container ID

- Pending message count

- Last refresh time

Container information:

- Container ID

- Resequencer type

14.2.15.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description of mediator.resequencer:

wls:/soainfra/serverConfig> describeDump(name='mediator.resequencer',
appName='soa-infra')

The following information appears:

Name: mediator.resequencer
Description: diagnostic information about the groups, which have not been
processed beyond user specified maximum unprocess time
Run Mode: asynchronous
Mandatory Arguments:
Name                         Type     Description
resequencerMaxUnprocessTime INTEGER  maximum duration for which the group has
not been processed, duration should be
specified in minutes
Optional Arguments:

2. Enter the following WLST command line syntax to execute a dump of mediator.resequencer:

wls:/soainfra/serverConfig> executeDump(name='mediator.resequencer',
appName='soa-infra', args={'resequencerMaxUnprocessTime':'minutes'}

For minutes, substitute the number of minutes a resequencer group can be pending before it appears in the dump. Information similar to the following appears:

Database Timestamp in UTC :2012-03-29 06:29:31.0
Max unprocess time condition:1
Mediator Resquencer pending group data
COMPONENT_DN,OPERATION,GROUP_ID,STATUS,COMPONENT_STATUS,LAST_RECEIVED_TIME,
CONTAINER_ID, PENDING MESSAGE COUNT
default/Standard!2.0/Mediator1,execute,1001,0,0,2012-03-29
06:24:22.509394,EC09D271796511E18F5CBD26553417B4,1
------------------------------------------------------------------------------
Containerid Data
containerId,renewalTime
EC09D271796511E18F5CBD26553417B4,java.util.GregorianCalendar[time=1333002526625
,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.Zon
eInfo[id="GMT-07:00",offset=-25200000,dstSavings=0,useDaylight=false,transition
s=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2012,MO
NTH=2,WEEK_OF_YEAR=13,WEEK_OF_MONTH=5,DAY_OF_MONTH=28,DAY_OF_YEAR=88,DAY_OF_
WEEK=4,DAY_OF_WEEK_IN_MONTH=4,AM_PM=1,HOUR=11,HOUR_OF_
DAY=23,MINUTE=28,SECOND=46,MILLISECOND=625,ZONE_OFFSET=-25200000,DST_OFFSET=0]

14.2.16 Adapter Diagnostic Dumps (soa.adapter.ra)

Table 14-18 provides details about connection factory configuration dumps.

Table 14-18 Adapter Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.adapter.ra

- Dump parameters:
flowid (Optional): When present, locates the flowtrace.xml file that includes the flow ID. It can be obtained from a dump context if not specified as a dump parameter. The following rules apply for actual parameter evaluation:

1) If the flow ID is available (as a dump parameter or obtained from a dump context), it retrieves the flow instance and gets the flow trace. It uses the ECID associated with the flow instance to retrieve the remaining dump artifacts.

2) If the flow ID is not available, but the ECID is (as a dump parameter or obtained from a dump context), it is used to look up the flow instance and retrieve the flow trace. It uses the ECID to retrieve other dump artifacts.

3) If both the flow ID and ECID are available, and the ECID is not equal to the flow's ECID, the ECID is ignored and a warning is displayed. Rule 1 is followed.

4) If both the flow ID and ECID are not available, an exception error is displayed.

ecid: (Optional) Specifies the ecid jndiName and adapterType.

- Dump Mode:
ASYNC

Dumps the connection factory information:

- Managed connection factory properties

- Connection pool properties

- Transaction support property

Indicates if the same JNDI is being used by multiple composites.

14.2.16.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description of soa.adapter.ra:

wls:/soainfra/serverConfig> describeDump(name='soa.adapter.ra',
appName='soa-infra')

2. Enter the following WLST command line syntax to execute a dump of soa.adapter.ra:

wls:/soainfra/serverConfig> executeDump(name='soa.adapter.ra',
appName='soa-infra', args={'compositeName':'fa', 'partition':'default',
'revision':'1.0'})

The following information appears:

CompositeDN = default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2
Endpoint Name = service
Endpoint type = Service
JNDI Name = eis/FileAdapter
Adapter Type = FileAdapter

Pool Parameters -
==================

initial-capacity = 10
test-connections-on-create = false
test-connections-on-reserve = false
connection-creation-retry-frequency-seconds = 2
shrinking-enabled = true
ignore-in-use-connections-enabled = true
highest-num-waiters = 0
shrink-frequency-seconds = 60
connection-reserve-timeout-seconds = 5
highest-num-unavailable = 0
max-capacity = 2147483647
profile-harvest-frequency-seconds = 300
capacity-increment = 100
test-connections-on-release = false
match-connections-supported = false
test-frequency-seconds = 0

Transaction Support = NoTransaction

Connection Factory Properties -
===============================

outboundDataSource = none
outboundDataSourceLocal = none
outboundLockTypeForWrite = none
controlDir = ${user.dir}
inboundDataSource = none
workingDirectory = default

================================================================

CompositeDN = default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2
Endpoint Name = reference
Endpoint type = Reference
JNDI Name = eis/FileAdapter
Adapter Type = FileAdapter

Pool Parameters -
==================

initial-capacity = 10
test-connections-on-create = false
test-connections-on-reserve = false
connection-creation-retry-frequency-seconds = 2
shrinking-enabled = true
ignore-in-use-connections-enabled = true
highest-num-waiters = 0
shrink-frequency-seconds = 60
connection-reserve-timeout-seconds = 5
highest-num-unavailable = 0
max-capacity = 2147483647
profile-harvest-frequency-seconds = 300
capacity-increment = 100
test-connections-on-release = false
match-connections-supported = false
test-frequency-seconds = 0

Transaction Support = NoTransaction

Connection Factory Properties -
===============================

outboundDataSource = none
outboundDataSourceLocal = none
outboundLockTypeForWrite = none
controlDir = ${user.dir}inboundDataSource = noneworkingDirectory = default

14.2.17 Adapter Diagnostic Dumps (soa.adapter.connpool)

Table 14-19 identifies the adapter connection pool dump.

Table 14-19 Adapter Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.adapter.connpool

- Dump parameters:
flowid (Optional): When present, locates the flowtrace.xml file that includes the flow ID. It can be obtained from a dump context if not specified as a dump parameter. The following rules apply for actual parameter evaluation:

1) If the flow ID is available (as a dump parameter or obtained from a dump context), it retrieves the flow instance and gets the flow trace. It uses the ECID associated with the flow instance to retrieve the remaining dump artifacts.

2) If the flow ID is not available, but the ECID is (as a dump parameter or obtained from a dump context), it is used to look up the flow instance and retrieve the flow trace. It uses the ECID to retrieve other dump artifacts.

3) If both the flow ID and ECID are available, and the ECID is not equal to the flow's ECID, the ECID is ignored and a warning is displayed. Rule 1 is followed.

4) If both the flow ID and ECID are not available, an exception error is displayed.

ecid: (Optional) Specifies the ecid jndiName, adapterType compositeName, partition, revision adapterType, and jndiName.

- Dump Mode:
ASYNC

Dumps the connection pool statistics for the configured connection factory JNDI.

14.2.17.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description of soa.adapter.connpool:

wls:/soainfra/serverConfig> describeDump(name='soa.adapter.connpool',
appName='soa-infra')

The following information appears:

Name: soa.adapter.connpool
Description: SOA adapter diagnostic dump that captures the Connection pool
stats for configured adapters JNDI.
Rules for actual parameter evaluation:
if ecid is specified, use it to match composites associated with the ECID,
composite name/partition/revision not used;
if ecid is not specified, then use jndiName & adapterType to retrieve the
connection pool attributes;
if jndiName and adapterType are not specified, then use composite
name/partition/revision to match composites;
if no composite name/partition/revision are specified, then all the composites
with jca binding are dumped.
Mandatory Arguments:
Optional Arguments:
Name        Type     Description
ecid        STRING   ECID(Execution Context ID - for tracking message flow
across multiple instances), when presents, will be used to locate
composites associated with it, and other composite matching parameters ignored;
it can be obtained from dump context if not specified as dump parameter, see
rules for actual parameter evaluation for details.
revision    STRING   Revision of composite, e.g. '1.0', '2.0', can be wild card
'*', meaning matching any revision, when missing, assume default composite's
revision in the composite series.
flowid      LONG       Flow ID, when presents, will be used to locate the
flowtrace.xml with it, it can be obtained from dump
context if not specified as dump parameter, see rules
for actual parameter evaluation for details.
adapterType STRING     Resource Adapter type
partition   STRING     Partition of composite, default to partition(s)
associated with resolved revision(s), can be wild
card '*', meaning matching any partition.
compositeName STRING   Composite name, e.g., 'OrderProcessing', can
be wild card '*',meaning matching any composite.
jndiName    STRING     Adapter Connection Pool JNDI

2. Enter the following WLST command line syntax to execute a dump of soa.adapter.connpool:

wls:/soainfra/serverConfig> executeDump(name='soa.adapter.connpool',
appName='soa-infra', args={'compositeName':'fa', 'partition':'default',
'revision':'1.0'})

The following information appears:

CompositeDN=default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2
Endpoint Name = service
Endpoint type = Service
JNDI Name =eis/FileAdapter
Adapter Type =FileAdapter

ConnectionPool Attributes:
==========================

Important ConnectionPool Attributes:
====================================
InitialCapacity = 10
MaxCapacity = 2147483647
CurrentCapacity = 10
State = Running
FreeConnectionsCurrentCount = 10
NumUnavailableCurrentCount = 0
NumberDetectedLeaks = 0
ConnectionsDestroyedByErrorTotalCount = 0
ConnectionsRejectedTotalCount = 0

Other ConnectionPool Attributes:
================================
ActiveConnectionsCurrentCount = 0
FreePoolSizeHighWaterMark = 0
PoolSizeLowWaterMark = 0
ConnectionsMatchedTotalCount = 0
LastShrinkTime = 0
FreeConnectionsHighCount = 10
ConnectionsDestroyedTotalCount = 0
ConnectionsDestroyedByShrinkingTotalCount = 0
ShrinkingEnabled = true
ConnectionsCreatedTotalCount = 10
NumUnavailableHighCount = 0
MaxIdleTime = 0
LoggingEnabled = true
ConnectionIdleProfileCount = 0
ConnectionProfilingEnabled = false
ShrinkCountDownTime = -10565
FreePoolSizeLowWaterMark = 0
ActiveConnectionsHighCount = 0
ProxyOn = false
NumWaitersCurrentCount = 0
NumWaiters = 0
CloseCount = 0
PoolSizeHighWaterMark = 0
AverageActiveUsage = 0
RecycledTotal = 0
ConnectionLeakProfileCount = 0
HighestNumWaiters = 0
ShrinkPeriodMinutes = 1
NumberDetectedIdle = 0
CapacityIncrement = 1

================================================================
CompositeDN=default/fa!1.0*soa_7ce2ebd9-ce17-4b5a-b436-2567eab33af2
Endpoint Name = reference
Endpoint type = Reference
JNDI Name =eis/FileAdapter
Adapter Type =FileAdapter

ConnectionPool Attributes:
==========================

Important ConnectionPool Attributes:
====================================
InitialCapacity = 10
MaxCapacity = 2147483647
CurrentCapacity = 10
State = Running
FreeConnectionsCurrentCount = 10
NumUnavailableCurrentCount = 0
NumberDetectedLeaks = 0
ConnectionsDestroyedByErrorTotalCount = 0
ConnectionsRejectedTotalCount = 0

Other ConnectionPool Attributes:
================================
ActiveConnectionsCurrentCount = 0
FreePoolSizeHighWaterMark = 0
PoolSizeLowWaterMark = 0
ConnectionsMatchedTotalCount = 0
LastShrinkTime = 0
FreeConnectionsHighCount = 10
ConnectionsDestroyedTotalCount = 0
ConnectionsDestroyedByShrinkingTotalCount = 0
ShrinkingEnabled = true
ConnectionsCreatedTotalCount = 10
NumUnavailableHighCount = 0
MaxIdleTime = 0
LoggingEnabled = true
ConnectionIdleProfileCount = 0
ConnectionProfilingEnabled = false
ShrinkCountDownTime = -10565
FreePoolSizeLowWaterMark = 0
ActiveConnectionsHighCount = 0
ProxyOn = false
NumWaitersCurrentCount = 0
NumWaiters = 0
CloseCount = 0
PoolSizeHighWaterMark = 0
AverageActiveUsage = 0
RecycledTotal = 0
ConnectionLeakProfileCount = 0
HighestNumWaiters = 0
ShrinkPeriodMinutes = 1
NumberDetectedIdle = 0
CapacityIncrement = 1

14.2.18 Adapter Diagnostic Dumps (soa.adapter.stats)

Table 14-20 identifies the adapter diagnostic dump.

Table 14-20 Adapter Diagnostic Dumps

Dump Name

Dump Parameters/Dump Mode

Information Captured

soa.adapter.stats

- Dump parameters:
format: (Optional) Specify a value of xml to display dump diagnostics output in XML format.

- Dump Mode:
ASYNC

Based on the soa.adapter.stats metrics, DMS statistics such as message size and fault count are available.

14.2.18.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to display a dump description of soa.adapter.stats:

wls:/soainfra/serverConfig> describeDump(name='soa.adapter.stats', appName='soa-infra')

The following information appears:

Name: soa.adapter.stats
Description: SOA adapter diagnostic dump that captures DMS adapter
statistics.Rules for actual parameter evaluation:
if composite name/partition/revision are specified, dumps the DMS stats for
that composite;
if no composite name/partition/revision are specified, then all the composites
with jca binding are dumped.
Mandatory Arguments:
Optional Arguments:
Name        Type     Description
revision    STRING   Revision of composite, e.g. '1.0', '2.0', can be wild
card '*', meaning matching any revision, when missing, assume default
composite's revision in the composite series.
partition   STRING   Partition of composite, default to partition(s)
associated with resolved revision(s), can be wild card '*', meaning matching
any partition.
compositeName  STRING   Composite name, e.g., 'OrderProcessing', can be
wild card '*',meaning matching any composite.

2. Enter the following WLST command line syntax to execute a dump of soa.adapter.stats:

wls:/soainfra/serverConfig> wls:/soainfra/serverConfig>
executeDump(name='soa.adapter.stats', appName='soa-infra',
args={'compositeName':'fa',
'partition':'default', 'revision':'1.0'})

The following information appears:

CompositeDN -default/fa!1.0
Service Name -service
Process Incoming Message Metrics -
================================
processIncomingMessages.time (Elapsed time in milliseconds ) - 4787 msecs
processIncomingMessages.completed (Elapsed time in milliseconds ) - 2 ops
processIncomingMessages.minTime (Elapsed time in milliseconds ) - 32 msecs
processIncomingMessages.maxTime (Elapsed time in milliseconds ) - 4755 msecs
processIncomingMessages.avg (Elapsed time in milliseconds ) - 2393.5 msecs
processIncomingMessages.active (Elapsed time in milliseconds ) - 0 threads
processIncomingMessages.maxActive (Elapsed time in milliseconds ) - 1 threads
Error Metrics -
=============
Errors.count (Number of events errored during binding processing ) - 0 ops
Process Incoming Message Events -
===============================
processIncomingMessagesEvents.count ( Number of processed events ) - 2 ops

14.3 Executing Diagnostic Framework Thread Dumps for SOA Composite Applications

When diagnosing a problem that requires a thread dump, it is useful to have sufficient context around the thread activity. The Diagnostic Framework dump jvm.threads provides DMS execution context (EC) thread stack data for SOA composite applications. The following properties are inserted when the business flow instance starts executing and reset when the HTTP request completes.

- composite_name

- component_name

- composite_instance_id

- activity_name (Lists the activities executed in the BPEL process. Activities that do not have names, such as scope activities, are not captured.)

This information is output in tabular form when the jvm.threads dump is executed. This dump identifies where each thread is during execution of the jvm.threads dump.

This is useful for diagnosing which SOA composite applications are processing slowly.

14.3.1 WLST Command Dump Description and Execution

1. Enter the following WLST command line syntax to execute a dump of jvm.threads:

executeDump(name='jvm.threads',outputFile='path',args={'context':'true'})

===== THREAD CONTEXT INFORMATION =====

id      ECID                                                          RID   Context Values
------- ------------------------------------------------------------- ----- ---------------
id=23   e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001d3f 0:1   WEBSERVICE_
PORT.name=CatchException_pt
composite_name=ExceptionHandler!1.0
J2EE_MODULE.name=fabric
component_name=CommsUtilityWS
WEBSERVICE_NAMESPACE.name=http://xmlns.
oracle.com/ExceptionHandler/CatchException
J2EE_APP.name=soa-infraWEBSERVICE.name=
catchexception_client_ep
composite_instance_id=1

id=61   e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-000000000000003c 0
id=70   e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e84 0
id=2170 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001d3f 0     DSID=0000Ĵ2fPtuDSc
Y5Hro2yf1G8M9Z000002
id=1616 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000000004 0
id=2179 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-000000000000002b 0     dbRID=0:10
id=2195 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e7e 0     dbRID=0:2
id=2196 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e82 0     dbRID=0:2
id=2197 e6e3527fc0d0bfd2:-6c720372:139026855d8:-8000-0000000000001e80 0     dbRID=0:5

===== END OF THREAD CONTEXT INFORMATION =====

This information is also available in the AdminServer-diagnostic.log file log.

For more information about the jvm.threads dump, see Chapter "Diagnosing Problems" of Administering Oracle Fusion Middleware.

14.4 Supported DMS Metrics

DMS metrics with noun types are exposed as Oracle SOA Suite MBeans to use for diagnosing problems. This section describes the supported DMS metrics. DMS nouns can be used to create watches in Oracle WebLogic Server Administration Console.

The DMS metrics provide graphical details that appear on the Statistics page of the BPEL process service engine. For more information, see Monitoring BPEL Process Service Engine Request and Thread Performance Statistics and Viewing Statistics About the Time a Request Spends in the BPEL Process Service Engine.

Table 14-21 shows the supported service engine sensors.

Table 14-21 Service Engine Sensors

Noun Path

Noun Type and Description

Sensor

Type

/soainfra/engines/ dispatcher/queuestats/
[REQUEST_TYPE]

The various request types are audit, delivery, domain, instance, invoke, maintenance, non-block-invoke, process, and system.

soainfra_cube_engine_dispatcher_queue_stats: Provides the active and scheduled count for the queues of various dispatcher sets.

active

schedule

/soainfra/engines/ [bpel|workflow|mediator|
decision]/message_
processing

soainfra_message_processing : Provides information about the total number (count) and average time taken to process various message types. The two message types are synchronous and asynchronous requests.

faultedRequestProcessingTime

faultedPostProcessingTime

requestProcessingTime

postProcessingTime

activeRequests

Phase Event

Phase Event

Phase Event

Phase Event

State

/soainfra/engines/bpel/
requests/[REQUEST_TYPE]

The request types are audit, engine, invoke, non-block-invoke, and system.

soainfra_bpel_requests

active

scheduled

State

State

/soainfra/engines/workflo
w/Task/service

soainfra_wfRequest

time

count

Phase

Event

/soainfra/engines/workflo
w/Task/[METHOD_NAME]

time

count

Phase

Event

/soainfra/engines/workflo
w/TaskQuery/[METHOD_NAME]

time

count

Phase

Event

/soainfra/engines/workflo
w/TaskMetadata/getTaskDef
inition

time

count

Phase

Event

/soainfra/engines/workflo
w/Verification/[METHOD_
NAME]

Only methods: authenticateUser, getPermissableTaskActions, and canUserPerfomTaskAction

time

count

Phase

Event

/soainfra/engines/workflo
w/TaskNotification/notify
ForTask

time

count

Phase

Event

/soainfra/engines/workflo
w/AssignmentRules/execute
Rules

time

count

Phase

Event

/soainfra/engines/bpel/di
spatcher/

soainfra_bpel_dipatcher

maxThreads

avgLifeTime

avgRequestCountPerSecond, and so on

State

State

State

Table 14-22 shows the supported binding sensors.

Table 14-22 Binding Sensors

Noun Path

Noun Type

Sensor

Type

/soainfra/bindings/[inbound|outbound]/[ws|sdo|jca|b2b]

soainfra_binding

processRequests

requests

errors

Phase

Phase

Phase

Table 14-23 shows the supported composite sensors.

Table 14-23 Composite Sensors

Noun Path

Noun Type

Sensor

Type

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[REVERSION]/[COMPONENT_NAME]

/decision/[INTERACTION_PATTERN]/[INTERACTION_PATTERN_NAME]

soainfra_decision_interaction

executed

executionTime

Event

Phase

/soainfra/apps/[COMPOSITE_DN]/[COMPONENT_NAME]/[ACTIVITY_NAME] (for bpel)

soainfra_bpel_activity: Provides details about the activity level execution times

started

executionTime

faultedExecutionTime

Standard deviation (the user interface calculates this as it comes through)

Event

Phase

Phase

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[VERSION]/[COMPONENT_NAME] /state/

soainfra_wfStateEvent

ASSIGNED

COMPLETED

ERRORED

EXPIRED

SUSPENDED

Event

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[VERSION]/[COMPONENT_NAME] /outcome/

soainfra_wfOutcomeEvent

[OUTCOME NAME]

Event

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[VERSION]/[COMPONENT_NAME] /taskCompletion/

soainfra_wfTaskCompletionTime

time

Phase

Table 14-24 shows the supported reference and service sensors.

Table 14-24 Reference and Service Sensors

Noun Path

Noun Type

Sensor

Type

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[REVERSION]/[REFERENCE_NAME]

soainfra_reference

processOutboundMessagesEvents

Errors

processOutboundMessages

Event

Event

Phase

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[REVERSION]/[SERVICE_NAME]

soainfra_service

processInboundMessagesEvents

Errors

processInboundMessages

Event

Event

Event

Table 14-25 shows the supported Oracle B2B binding sensors.

Table 14-25 Oracle B2B Binding Sensors

Noun Path

Noun Type

Sensor

Type

/soainfra/bindings/b2b/document_type/[inbound|outbound]/[DOCUMENT_NAME]

/soainfra/bindings/b2b/[inbound|outbound]

soainfra_b2b_document

soainfra_b2b_document_dir

processMessagesEvents

processMessagesErrors

processMessages

processMessageSize

Event

Event

Phase Event

State

/soainfra/bindings/b2b/trading_partner/[from|to]/[TRADING_PARTNER_NAME]

/soainfra/bindings/b2b/[from|to]/

soainfra_b2b_tradingPartner

soainfra_b2b_tradingPartner_dir

processMessagesEvents

processMessagesErrors

processMessages

processMessageSize

Event

Event

Phase Event

State

/soainfra/bindings/b2b/endpoint/[inbound|outbound]/[END_POINT]

/soainfra/bindings/b2b/[inbound|outbound]/

soainfra_b2b_endpoint

soainfra_b2b_endpoint_dir

endPointProtocol

endPointStatus

processMessagesEvents

State

State

Event

/soainfra/bindings/b2b/agreement/[AGREEMENT_NAME]

soainfra_b2b_agreement

processMessagesEvents

Event

/soainfra/bindings/b2b/activeEntities

soainfra_b2b_active_entities

activeTradingPartners

activeAgreements

activeDocuments

State

State

State

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[REVERSION]/[SERVICE_NAME]/[TRADING_PARTNER_NAME]

soainfra_service_b2b_tradingPartner

processMessagesEvents

processMessagesErrors

processMessages

processMessageSize

Event

Event

Phase Event

State

/soainfra/apps/[APP_NAME]/[COMPOSITE_NAME]/[REVERSION]/[REFERENCE_NAME]/[TRADING_PARTNER_NAME]

soainfra_reference_b2b_tradingPartner

processMessagesEvents

processMessagesErrors

processMessages

processMessageSize

Event

Event

Phase Event

State

Table 14-26 shows the supported Oracle User Messaging Service sensors.

Table 14-26 Oracle User Messaging Service Event Bridge Metrics

Noun Path

Noun Type

Sensor

Type

/soainfra/eventBridge/rfidBridge

soinfra_rfidBridge

eventsIn

eventsOut

eventsProcess

errors

Event

Event

Phase Event

Event

/soainfra/eventBridge/rfidBridge/device/[SERVER_NAME]/[DEVICE_NAME]

soainfra_rfidBridge_device

eventsIn

eventsOut

eventsProcess

status

Event

Event

Phase Event

State

/soainfra/eventBridge/rfidBridge/server/[SERVER_NAME]

soainfra_rfidBridge_server

status

State

14.5 Creating Watches and Notifications

You can create watches and send notifications around diagnosable conditions based on metrics collected from Oracle SOA Suite MBeans. When a watch expression evaluates to true (for example, heap space exceeds a specified amount), a notification is sent.

There are several options for creating watches:

- Enable preconfigured rules and watches for deployment, memory, and elapsed time of web service calls with the sca_createWatches WLST command

- Manually create Oracle SOA Suite watches in Oracle WebLogic Server Administration Console

The message IDs shown in Table 14-27 have been assigned for diagnostic purposes.

- When you manually create a watch in the Oracle WebLogic Server Administration Console, you must follow the naming conventions in Table 14-27. The prefix for Oracle SOA Suite-related watches is SOA-message_ID.

- When you enable the preconfigured watches, the names are automatically created for you.

Table 14-27 Message Prefixes

Scenario

Message-ID

Dumps Executed

Watch Preconfigured?

Memory

SOA-900000

- soa.env

- soa.config

- java.sysprops

Yes, see Enabling Preconfigured Rules and Watches

Deployment hang

SOA-900001

- soa.env

- soa.config

Yes, see Enabling Preconfigured Rules and Watches

Data source

SOA-900002

- soa.env

- soa.config

- soa.db

No, see Manually Creating Oracle SOA Suite Watches and Notifications for creation instructions

Elapsed time of web service calls

SOA-900003

- soa.env

- soa.config

- soa.wsdl

Yes, see Enabling Preconfigured Rules and Watches

Resequencer groups pending

MED-900000

- mediator.resequencer

No, see Manually Creating Oracle SOA Suite Watches and Notifications for creation instructions

You can also link a WLDF notification to the watch. If you link the out-of-the-box Oracle Fusion Middleware Diagnostic Framework notification (named FMWDFW notification), then a set of SOA-specific dumps are executed. These dumps provide runtime information about the situation and environment. The list of dumps to execute is determined by predefined XML incident rules files.

Other notifications (like email) can also be linked to the watch.

14.5.1 Enabling Preconfigured Rules and Watches

The following preconfigured Diagnostic Framework rules are automatically installed with Oracle SOA Suite:

- Log detection condition rule for creating an incident when an OWS-04086 error is encountered.

- Condition rule that checks for the presence of the SOA composite application name in the DMS execution context (EC) and adds the soa.wsdl and soa.composite.trail diagnostic dumps to the list of dumps executed.

To enable these rules for use and generate the following watches, you must run the sca_createWatches WLST command after domain creation.

- Deployment watch (with a threshold of 5 minutes)

- Memory watch (heap free percent with a threshold of 25 percent)

- Elapsed time of web service calls watch (with a threshold of 5 minutes)

To enable the preconfigured watches:

1. Connect using WLST to the Oracle WebLogic Server instance and start an editing session. For information about connecting and starting an editing session, see Chapter "WLST Command and Variable Reference" of WLST Command Reference for WebLogic Server.

2. Execute the following WLST command to enable the preconfigured watches.

wls:/soainfra/serverConfig> sca_createWatches()

The watches are enabled and displayed along with any watches you manually create at the bottom of the Settings for Module_Name page in Oracle WebLogic Server Administration Console.

For information about executing WLST commands in Oracle SOA Suite, see WLST Command Reference for SOA Suite.

14.5.2 Manually Creating Oracle SOA Suite Watches and Notifications

To manually create Oracle SOA Suite watches and notifications:

1. Log in to Oracle WebLogic Server Administration Console.

http://host:port/console

2. In the Domain Structure, expand Diagnostics, and select Diagnostic Modules.

The Summary of Diagnostic Modules page appears.

You configure a diagnostic system module to monitor an aspect of a server or server resource. You can configure multiple system modules to monitor different aspects of a server, but only one such module can be active on a server.

3. In the Diagnostic System Modules section, click Module-[Module_Name] (for example, Module-FMWDFW).

4. On the Settings for Module_Name page, select Watches and Notifications > Watches.

5. In the Watches section, click New.

The Create a Diagnostic Watch page is displayed.

6. Enter the following details to create a watch, and click Next.

Field

Description

Watch Name

Enter a name for the watch (for this example, SOA-900000#soa-infra#MemoryWatch is entered).

The name of the watch must conform to the following pattern:

message-id#soa-infra#some_other_text

For example, SOA-900000#soa-infra#MemoryWatch.

This is necessary because the watch name coordinates the Diagnostic Framework incident processing actions when watch conditions evaluate to true. Not following this pattern results in Oracle SOA Suite dumps not getting triggered when Oracle SOA Suite incidents are created.

For additional information, see Table 14-27.

If the watch is set up with the FMWDFW notification, the notification handler creates an incident that corresponds to the message-id specified in the watch name.

Watch Type

Select an option:

- Collected Metrics: Sets a watch based on metrics collected from MBean attributes. It is recommended that you select this option because it works for the scenarios described in Table 14-1.

- Server Log: Sets a watch based on data written to server logs. This type is only useful for extending an existing log watch such as StuckThread to include Oracle SOA Suite dumps.

- Event Data: This option is not applicable because Oracle SOA Suite is not using any WLDF-based instrumentation.

Enable Watch

Select to enable a watch.

The Configure Watch Rule Expressions page for adding an expression to the watch is displayed.

7. Click Add Expressions.

The Add Expression wizard is displayed.

8. In the MBean Server location list, select the Oracle WebLogic Server MBean server for the expression you want to configure (for example, ServerRuntime).

9. Click Next.

10. Click the Select an MBean Type from the following list button.

11. In the MBean Type list, select the MBean to use for collecting diagnostic information (for this example, Oracle WebLogic Server MBean weblogic.management.runtime.JRockitRuntimeMBean is selected).

Note:

If you want to create an automatic notification when a composite state is set to off, select oracle.fabric.management.composite.mbean.Composite from the MBean Type list.

12. Click Next.

The Select Instances page is displayed.

13. From the Instance list, select the instance name or specify an instance name pattern to use to identify the metric for the expression.

14. Click Next.

15. Enter the following details to create a watch rule expression, and click Finish.

Field

Description

Message Attribute

Select a message attribute (for this example, HeapFreePercent is selected).

The attributes that are displayed for selection are part of the MBean that you selected in Step 11. For example, if you selected:

oracle.dms.name=/soainfra/engines/bpel/request/system.type=soa_infra_bpel_requests

You see assigned attributes such as active_count, active_maxValue, active_minValue, scheduled_count, and others.

Operator

Select an operator (for this example, < is selected).

Value

Enter a value (for this example, 100 is specified).

The Configure Watch Rule Expressions page is displayed with the watch rule expression you created.

16. Click Next.

The Config Watch Alarm page is displayed.

17. Optionally specify an alarm and the alarm's reset value for the watch.

18. Click Next.

The Configure Watch Notifications page is displayed.

19. In the Available table, select a notification to assign to the watch and click >.

When a watch rule expression evaluates to true, a notification is triggered. This notification is handled by the Diagnostic Framework if the FMWDFW notification is selected, which links it to the watch. The FMWDFW notification is automatically shipped with Oracle SOA Suite. Oracle recommends that you select this notification because it creates the Oracle SOA Suite dumps described in Executing Oracle SOA Suite Diagnostic Dumps.

The notification handler creates a problem incident package that contains appropriate Oracle SOA Suite dumps in the ADR. The incident package name corresponds to the message ID specified in the watch name. The incident package dumps can be viewed later using standard ADR tools. This feature enables you to take corrective actions for the problem scenario.

20. Click Finish.

The watch you created is displayed at the bottom of the Settings for Module_Name page. In addition, three WLDF watches that are automatically shipped with Oracle WebLogic Server (Deadlock, StuckThread, and UncheckedException) are also displayed.

21. In the Name column, click the specific watch name to display configuration details about the watch.

14.5.3 Creating a Watch to Identify the Elapsed Time of Web Service Binding Calls

You can create a watch that keeps track of the time it takes for web service binding calls from a composite to an external references to complete. When the specified time threshold is exceeded, an incident can be created or an alert can be triggered. This watch is useful for the following scenarios:

- Identify scenarios in which an invoked external reference is operating too slowly, which causes messages to collect while waiting for processing by this reference

- Have strict service level agreements (SLAs) and want to be notified if the SLAs are being violated from the invoked services

To create a watch to identify the elapsed time of web service binding calls:

Follow the steps described in Manually Creating Oracle SOA Suite Watches and Notifications and use these guidelines to create a watch:

- Set the CreateWSCallTrackingMBean property to true under the More SOA Infra Advanced Configuration Properties section of the SOA Infrastructure Common Properties page. This property controls the creation of MBeans for tracking the elapsed time of web service binding calls, and applies globally to all SOA composite applications in the SOA Infrastructure. For each web service binding call to an external reference, a new MBean is registered to keep track of the time, and then unregistered. This property is set to false by default. Do not set this property to true until you see problems in your system.
For more information about accessing the SOA Infrastructure Common Properties page, see Configuring SOA Infrastructure Properties.

- Specify SOA-900003#soa-infra#WSExtElapsedTimeWatch as the watch name.

- Select Collected Metrics from the Watch Type list.

- Specify CreateWSCallTrackingMBean in the Custom MBean Types field. This MBean is not available for selection from the MBean Type field.

- Specify an expression rule for tracking the elapsed time it takes in milliseconds for web service binding calls from a SOA composite application to an external references to complete (in minutes). For example, this expression creates an incident when the watch is triggered.

(${ServerRuntime//[oracle.fabric.management.wldf.mbean.WSExternalBindingWatchMXBeanImpl]//ElapsedTime} > 2

- An incident is created in the Oracle SOA Suite ADR directory when the watch is triggered. A readme file in the directory displays information about the incident. For example:

WatchDomainName:      soainfra
Watch Data:
ServerRuntime//[oracle.fabric.management.wldf.mbean.WSExternalBindingWatch
MXBeanImpl]//ElapsedTime : oracle.soa.config:Application=soa-infra.j2eeType=
CompositeReferenceWatch.name=bpel#20004/soainfra/AdminServer/soainfra/default/
ExceptionHandler/1.0/soa.2075e8a1-5c69-4e5o-a679-c0ba2f6ae6/REFERENCEs/
CommsUtilityS/PORTs/CommsUtilityPort//ElapsedTime:244013

You can also create this watch automatically with the sca_createWatches WLST command. For information, see Enabling Preconfigured Rules and Watches.

14.5.4 Creating a Watch to Identify if Processing Delays Exceed a Specified Time Limit

You can create a watch that alerts you if the counts of message wait times or processing delays exceed a certain limit.

This watch is controlled by the DispatcherStatsMap attribute of the CubeDispatcher System MBean Browser property. You can access this setting as follows:

1. Right-click soa-infra, and select Administration > System MBean Browser.

2. Expand Application Defined MBeans > oracle.as.soainfra.bpm > Server : server_name > bpel > CubeDispatcher.

3. Click CubeDispatcher.

Follow the steps described in Manually Creating Oracle SOA Suite Watches and Notifications and use these guidelines to create a watch in the Add Expressions section of the Create Watch wizard:

- Select ServerRuntime, and click Next.

- Specify com.collaxa.cube.engine.dispatch.DispatcherMXBeanAdapter in the Custom MBean Types field, and click Next. This MBean is not available for selection from the MBean Type field.

- Specify oracle.as.soainfra.bpm:Application=soa-infra,name=CubeDispatcher,type=bpel in the Custom Instance field, and click Next.

- Specify DispatcherStatsMap(invokeSet)(invoke)(scheduled) in the Attribute Expression field.

- Complete the remaining fields on this page, and click Next.

14.5.5 Creating Resequencer Watches and Notifications

You can create a watch that tracks how long it takes for resequencer groups to process messages. When the time threshold you specify is exceeded, a notification can be generated.

To create resequencer watches and notifications:

Follow the steps described in Manually Creating Oracle SOA Suite Watches and Notifications using the following guidelines:

- Create the watch and notification in the Module-FMWDFW module.

- On the Create a Diagnostic Watch page, the name of the watch must conform to the following pattern:

MED-900000#soa-infra#some_other_text

For example, MED-900000#soa-infra#PendingGroups.

- When you create the expression, select the following MBean type:

oracle.tip.mediator.dfw.MediatorDiagnostic

There is only once choice for the instance in the expression:

oracle.mediator:name=MediatorDiagnostic,type=MediatorDiagnostic

- For the Message Attribute field, select ResequencerMaxUnprocessTime. For the value, enter the number of minutes a group can be pending before triggering a notification.

- For the operator, select the greater than symbol (>).

The completed expression should look similar to the following:

(${ServerRuntime//[oracle.tip.mediator.dwf.MediatorDiagnostic]oracle.mediator:name
=MediatorDiagnostic,type=MediatorDiagnostic//resequencerMaxUnprocessTime} > '15')

To create a sample custom rules file:

The watch rules expression is not provided in the dump context, so the criteria specified when generating a dump are not available. You can use a custom file, custom-rule.xml, to register the dump generation rules. For more information, see Predefined Incident Processing Rules.

1. Create a watch, as described above.

2. Create a file named custom-rules.xml in one of the following locations:

- Server level configuration: FMW_HOME/user_projects/domains/domain_name/config/fmwconfig/servers/server_name/dfw

- Domain level configuration: FMW_HOME/user_projects/domains/domain_name/config/fmwconfig/dfw

3. Define the rules in the new file. Example 14-1 provides a resequencer sample file.

4. Restart the domain or load the file dynamically. For information about dynamic loading, see Predefined Incident Processing Rules.

The WLDF generates the dump.

Example 14-1 Sample Custom Rules File for Resequencer Dumps

<?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules
xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules"
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
<processingRules>
<rule name="memory diagnosis rule">
<ruleCondition>
<condition name="MESSAGE_ID" value="MED-900000"
operator="EQ"/>
</ruleCondition>
<ruleActions>
<dumpAction name="mediator.resequencer">
<argument name="resequencerMaxUnprocessTime" value="10"
valueType="literal"/>
</dumpAction>
</ruleActions>
</rule>
</processingRules>
</diagnosticRules>

Example 14-1 shows a sample custom rules file that generates a diagnostic dump when the length of time a group stops processing messages reaches 10 minutes.

14.6 Manually Triggering and Executing Dumps

You can manually execute existing dumps with the WLST command executeDump and create incidents when one has not been automatically created.

To manually trigger and execute dumps:

1. Specify the executeDump command to place dump contents in a file (for this example, soa.config is the dump executed). This creates the following output:

wls:/soainfra/serverConfig> executeDump(name='soa.config',outputFile='path',
appName='soa-infra')

Start Dumping deployedCompositesCatalog from MDS
URI:deployed-composites/deployed-composites.xml to: /myhome/fmwhome/user_
projects/domains/mydomain/servers/myserver/adr/diag/ofm/mydomain/
myserver/incident/incdir_9/deployedCompositesCatalog

Finished dumping specified MDS metadata to : /myhome/fmwhome/user_
projects/domains/mydomain/servers/myserver/adr/diag/ofm/mydomain/myserver/incid
ent/incdir_9/deployedCompositesCatalog

Start Dumping soaServiceEnginesConfigurations from MDS
URI:soa/configuration/default to: /myhome/fmwhome/user_projects/
domains/mydomain/servers/myserver/AdminServer/adr/diag/ofm/mydomain/
myserver/incident/incdir_9/soaServiceEnginesConfigurations

Finished dumping specified MDS metadata to : /myhome/fmwhome/user_projects/
domains/mydomain/servers/myserver/AdminServer/adr/diag/ofm/mydomain/
myserver/incident/incdir_9/soaServiceEnginesConfigurations

2. Specify the executeDump command to display dump contents to the screen.

executeDump(name='soa.edn', appName='soa-infra')

Type:oracle.integration.platform.blocks.event.saq.SAQBusinessEventBus
Configuration:null
Status: running=true started=true
ThreadCount:3
RetryCount:3
In Global: Tx:false
Cluster Info:oracle.integration.platform.blocks.cluster.CoherenceCluster
Interface1mpt@163bd717
SharedEDN:false
OOAO Queue Name:edn_ooao_queue
Java Subscriber Name:edn java subscriber
Subscription Info:
No namespace subscription...
QName subscriptions:
=============================================================
qname={http://schemas.oracle.com/events/edl/ActionOccur}ADEvent
subscriptions=
id=default/WSInMedPubBpelSubFileOut!1.0*soa_7a055d6a-8402-49c2-ac56-5f85cbf3d7f/
BpelSub, consistencyLevel=ONE_AND_ONLY_ONE, filter=XPath Filter: starts-with(/
be:business-event/be:content/ns0:ActionOccurrence/ns0:ParentEntityType/@value,
'A'), runAsRoles=[$publisher]
id=partition_1/WSInMedPubBpelSubFileOut!1.0*soa_80a169ab1-395a-4b87-9986-9fa2742a8bd3/
BpelSub, consistencyLevel=ONE_AND_ONLY_ONE, filter=XPath Filter: starts-with(/
be:business-event/be:content/ns0:ActionOccurrence/ns0:ParentEntityType/@value,
'A'), runAsRoles=[$publisher]
EventThreadContextInfo:
EventTargets:
Event:partition_1/WSInMedPubBpelSubFileOut!1.0*soa0a169ab1-395a-4b87-9986-9fa2742a9bd3/
BpelSub:::oracle.fabric.BPELServiceEngine@163bd6b5
Event:default/WSInMedPubBpelSubFileOut!1.0*soa7a055d6a-8402-49c2-ac56-5f85cbf3
d7f/BpelSub:::oracle.fabric.BPELServiceEngine@163bd6b5
EDN DB Log enabled:false

You can also manually create incidents when one has not been automatically created. For example, this is useful when you notice performance issues and want to create an incident to send to Oracle Support Services. The incident can include SOA dumps, according to the SOA message ID mapping.

This can be performed with the following WLST command:

createIncident(messageId="SOA-90000", appName="soa-infra")

This has the same effect as WLDF watch notification execution, in which the watch has the message ID of SOA-90000 and application name of soa-infra.

For more information about executeDump, see Chapter "Diagnostic Framework Custom WLST Commands" of WLST Command Reference for WebLogic Server.

14.7 Viewing Incident Packages with ADR Tools

ADRCI is a command-line utility that enables you to investigate problems and package and upload first-failure diagnostic data to Oracle Support Services. ADRCI also enables you to view the names of dump files in the ADR, and to view the alert log with XML tags stripped, with and without content filtering.

ADRCI is installed in the following directory:

MW_HOME/wlserver_10.3/server/adr

For more information about ADRCI, see Chapter "ADRCI: ADR Command Interpreter" of Oracle Database Utilities.

For information about other tools, see Chapter "Managing Diagnostic Data" of Oracle Database Administrator's Guide

14.8 Querying Problems and Incidents

The Diagnostic Framework provides WLST commands that you can use to view information about problems and incidents, including the following:

- Querying problems across Oracle WebLogic Servers

- Querying incidents across Oracle WebLogic Servers

- Viewing dump files associated with an incident on an Oracle WebLogic Server

For more information about these WLST commands, see Section "Understanding the Diagnostic Framework" of Administering Oracle Fusion Middleware and WLST Command Reference for WebLogic Server.

Part V Administering BPEL Process Service Components and Engines

This part describes how to administer BPEL process service components and engines.

This part includes the following chapters:

- Configuring BPEL Process Service Components and Engines

- Monitoring BPEL Process Service Components and Engines

- Managing BPEL Process Service Components and Engines

15 Configuring BPEL Process Service Components and Engines

This chapter describes how to configure BPEL process service components and service engines, including configuring properties such as audit level and audit trail threshold, automatic recovery for BPEL processes, master node recovery scheduling, automatic recovery attempts for invoke and callback messages, and callback message order preservation.

This chapter includes the following topics:

- Configuring BPEL Process Service Engine Properties

- Configuring Automatic Recovery for Oracle BPEL Process Manager

- Configuring Master Node Recovery Scheduling

- Configuring Automatic Recovery Attempts for Invoke and Callback Messages

- Preserving the Order of Callback Messages

- Setting the Audit Level at the BPEL Process Service Component Level

For more information about Oracle SOA Suite and Oracle BPEL process tuning and performance properties, see Tuning Performance.

15.1 Configuring BPEL Process Service Engine Properties

You can configure BPEL process service engine properties, which are used by the BPEL process service engine during processing of BPEL process service components.

To configure BPEL process service engine properties:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > BPEL Properties.

a. Right-click soa-infra.

b. Select SOA Administration > BPEL Properties.

The BPEL Service Engine Properties page displays properties for setting the audit level, audit trail and large document thresholds, payload schema, and BPEL monitors and sensors.

2. Make changes to the service engine properties that are appropriate to your environment.

Property

Description

Audit Level

Select one of the following options:

- Off: Business flow instance tracking and payload tracking information is not collected.

- Inherit: Logging equals the SOA Infrastructure audit level. This setting enables the BPEL process audit level to automatically change when the global setting is changed. Setting a different audit level tracking on this page overrides the tracking set at the SOA Infrastructure level.

- Minimal: The BPEL process service engine does not capture any audit details. Therefore, they are not available in the flow audit trails. All other events are logged.

- Production: The BPEL process service engine does not capture the payload. The payload details are not available in the flow audit trails. Payload details for other BPEL activities are collected, except for assign activities. This level is optimal for most standard operations and testing.

- Development: Allows both business flow instance tracking and payload tracking. All events are logged. However, it may have an impact on performance. This level is intended for debugging and can impact system performance.

Audit Trail Threshold

Enter the maximum size in bytes of an instance audit trail before it is chunked and saved in a dehydration store table separate from the audit trail. If the threshold is exceeded, the View XML link is shown in the audit trail instead of the payload.

Large Document Threshold

Enter the maximum size for a BPEL variable before its contents are stored in a separate location from the rest of the instance scope data.

Payload Validation

Select to enable validation of inbound and outbound messages. Nonschema-compliant payload data is intercepted and displayed as a fault.

Note: This setting is independent of the SOA composite application and SOA Infrastructure payload validation level settings. If payload validation is enabled at both the service engine and SOA Infrastructure levels, data is checked twice: once when it enters the SOA Infrastructure, and again when it enters the service engine.

Disable BPEL Monitors and Sensors

Select this checkbox to disable all BPEL monitors and sensors defined for all BPEL components across all deployed SOA composite applications.

3. Click Apply.

4. If you want to configure advanced BPEL properties in the System MBean Browser, click More BPEL Configuration Properties. Properties that display include, but are not limited to, the following. Descriptions are provided for each property.

- AsyncAuditBatchSize: Stores multiple audit trail messages (across instances) in a single transaction on Oracle Exalogic platforms. For more information, see Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms.

- BpelcClasspath: The extra BPEL class path to include when compiling BPEL-generated Java sources. For more information, see Section "How to Add Custom Classes and JAR Files" of Developing SOA Applications with Oracle SOA Suite.

- DisableAsserts: Disables the execution of assertions in BPEL, including the bpelx:assert activity. For more information, see Section "How to Disable Assertions" of Developing SOA Applications with Oracle SOA Suite.

- DisableSensors: Disables all calls to sensors.

- DispatcherNonBlockInvokeThreads: The total number of threads allocated to process nonblocking invocation dispatcher messages. If your system has many nonblocking invokes, the value of this property can be incremented. The default value is 2. Any value less than 1 is automatically changed to the default value.

- ExecuteCallbacksInOrder: Preserves BPEL process callbacks in the order of received time of the callback inside the BPEL process service engine (when set to true). For more information, see Preserving the Order of Callback Messages.

- ExpirationMaxRetry: The maximum number of times a failed expiration call (wait/onAlarm) is retried before failing.

- ExpirationRetryDelay: The delay between expiration retries.

- InstanceKeyBlockSize: The size of the block of instance IDs to allocate from the dehydration store during each fetch.

- MaximumNumberOfInvokeMessagesInCache: The number of invoke messages stored in the in-memory cache.

- MaxRecoverAttempt: The number of automatic recovery attempts to submit in the same recoverable instance. For more information, see Configuring Automatic Recovery Attempts for Invoke and Callback Messages.

- MinBPELWait: The minimum time duration for a BPEL process to perform a real wait that involves a dehydration. For more information, see Section "Creating a Wait Activity to Set an Expiration Time" of Developing SOA Applications with Oracle SOA Suite.

- OneWayDeliveryPolicy: Changes whether one-way invocation messages are delivered.

- QualityOfService: Enables or disables Oracle Coherence cache for the BPEL process service engine. For more information, see Configuring Oracle Coherence Caching.

- RecoveryConfig: Configures automatic recovery of activities and configures clustered environments to use master node recovery scheduling. For more information, see Configuring Automatic Recovery for and Configuring Master Node Recovery Scheduling.

- StatsLastN: The size of the most recently processed request list. Change this value to a value such as 1000. This enables you to view low level statistics in the Statistics page. For more information, see Monitoring BPEL Process Service Engine Request and Thread Performance Statistics.

- SyncMaxWaitTime: The maximum time a request and response operation takes before timing out. For more information about this property, see Section "Specifying Transaction Timeout Values in Durable Synchronous Processes" of Developing SOA Applications with Oracle SOA Suite.

5. Make changes appropriate to your environment.

For more information about Oracle BPEL process tuning and performance parameters, see Tuning Performance.

15.2 Configuring Automatic Recovery for Oracle BPEL Process Manager

Oracle SOA Suite provides an automatic recovery feature in Oracle Enterprise Manager Fusion Middleware Control that enables you to configure and recover:

- All activities (for example, wait activities and OnAlarm branches of pick activities) that have an associated expiration date and are scheduled with the SOA Infrastructure to be rescheduled

- All activities that are not complete over a provided threshold time

- All invoke and callback messages that are unresolved

To configure automatic recovery:

1. In the navigator, right-click soa-infra and select SOA Administration > BPEL Properties.

2. Click More BPEL Configuration Properties.

3. In the Name column, click RecoveryConfig.

4. Expand RecurringScheduleConfig.

This section enables you to configure recurring recovery attempts.

5. Set the following properties to values appropriate to your environment, and click Apply.

Property

Description

maxMessageRaiseSize

The maximum number of messages to submit for each recurring recovery attempt. Use this property to limit the impact of recovery on the server. This value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.

The default value is 50. A 0 value causes no messages to be selected from the database (effectively disabling recovery).

Warning: Specifying a negative value causes all messages selected from the database to be submitted for recovery. This value can potentially overload your system. Do not specify this value.

startWindowTime

The start time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:00-9:00).

The default value is midnight (00:00). Any invalid parsed time value is defaulted to midnight.

stopWindowTime

The stop time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:00-9:00).

If you do not want daily recovery, set the start and stop window times to be the same value. If the stop window time is earlier than the start window time, both the start and stop window times are changed to their respective default values.

The default value is (04:00), effectively setting recurring recovery to run until 04:00.

Any invalid parsed time values default to 00:00.

subsequentTriggerDelay

The number of seconds between recovery attempts during daily recurring startup recovery periods. If the next recovery trigger falls outside of the current recovery period, that trigger is not scheduled until the next recurring recovery period (tomorrow).

The default value is 300 (five minutes). A negative value causes the default to be selected.

threshHoldTimeInMinutes

This is the threshold time in minutes to ignore for automatic recovery processing. For automatic invoke and callback recovery, this value is used for picking messages with a received date less than the threshold time.

For automatic activities recovery, this value is used for picking activities with a modification date less than the threshold time.

This property prevents the message contention scenario in which a BPEL process service engine picks up a message for recovery while another thread on the service engine is in the middle of processing the message. This property ensures that the recovery part of the service engine only attempts recovery on messages older than the value for threshHoldTimeInMinutes.

The default value is 10 minutes. A negative value causes the default to be selected.

6. Expand StartupScheduleConfig.

This section enables you to configure server startup recovery attempts.

7. Set the following properties to values appropriate to your environment, and click Apply.

Property

Description

maxMessageRaiseSize

The maximum number of messages to submit for each startup recovery attempt. Use this property to limit the impact of recovery on the server. This value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.

The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A zero value causes no messages to be selected from the database (effectively disabling recovery).

startupRecoveryDuration

Specifies the number of seconds that the startup recovery period lasts. After the server starts, it goes into a startup recovery period. During this period, pending activities and undelivered callback and invocation messages are resubmitted for processing.

The default value is 600 (ten minutes). A negative or zero value disables startup recovery.

subsequentTriggerDelay

The number of seconds between recovery attempts during the server startup recovery period. If the next recovery trigger falls outside the server startup period, that trigger is not scheduled and the server moves into the recurring recovery period.

The default value is 300 (five minutes). A negative value causes the default to be selected.

Note:

In a cluster, it is possible for different nodes to concurrently attempt an automatic recovery of the same items. The first node to lock the item attempts the recovery, while other nodes may raise an exception that can be safely ignored.

15.3 Configuring Master Node Recovery Scheduling

You can configure a clustered environment to use master node recovery scheduling. In this environment, the master node is dedicated to performing recovery for all nodes in the cluster.

Note:

This feature does not work if you are using a pre-Oracle Fusion Middleware Release 11g (11.1.1.3) database schema.

Master node recovery scheduling enables you to perform the following tasks:

- Recover activities with expiration dates (for example, a wait activity or an OnAlarm branch of a pick activity) that are past due. The master node picks expired work items and reschedules them.

- Recover stranded work items

- Recover callback messages

- Recover invoke messages

- Fail over expired activities: When the master node detects a failed node, it tries to reschedule work items that have an expiration date.

To configure master node recovery scheduling:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. Right-click soa-infra.

3. Select SOA Administration > BPEL Properties.

4. Click More BPEL Configuration Properties.

5. In the Name column, click RecoveryConfig.

6. Expand ClusterConfig. The ClusterConfig properties work in association with the recurring recovery attempt properties and server startup recovery attempt properties that you set for RecurringScheduleConfig and StartupScheduleConfig, respectively.

7. Set the following properties to values appropriate to your environment, and click Apply.

Note:

Once an instance/message becomes recoverable, a recovery is attempted. However, the number of retries is not tracked. If a recovery fails, it continues to pick the same record, retry, and fail again.

Property

Description

clusterDbTimeRefresh

Specifies how often to refresh the local copy of the database time. This takes into account the clock drift on different computers. All nodes in the cluster rely on the database time, regardless of its accuracy.

The default value is 12 hours (specified as 43200 seconds).

heartBeatInterval

Specifies how often a node polls the cluster message table to check for messages published by other nodes in the cluster.

The default value is 5 seconds.

The following tasks are performed each interval:

- Updates the node's last updated time in the cluster_node table.

- Attempts to claim ownership of the master role.

- If the master role is claimed, the recovery manager resumes work.

- Checks for all nodes that have update times not updated for the nodeReapThreshold value, deletes those nodes from the cluster_node table, and reschedules all expiring work items from this node.

masteAliveThreshold

Specifies the number of seconds a master node is considered to be active. Master nodes that have not checked in with the cluster for this number of seconds are considered to be terminated. Whichever node gets an exclusive lock on the cluster_master table after this point can claim the master role.

The default value is 15 minutes (specified as 900 seconds).

nodeReapInterval

Specifies how often the heartbeat thread is borrowed to mark old cluster nodes. Only the master node performs this job.

The default value is 2 hours (specified as 7200 seconds).

nodeReapThreshold

Specifies the number of seconds a node is considered to be active. Nodes that have not checked in with the cluster for this number of seconds are considered to be terminated. During its heartbeat cycle, the master node tries to clean up the cluster_node table.

The default value is 15 minutes (specified as 900 seconds).

15.4 Configuring Automatic Recovery Attempts for Invoke and Callback Messages

You can configure the number of automatic recovery attempts to submit in the same recoverable instance. The value you provide specifies the maximum number of times invoke and callback messages are recovered. If the value is 2 (the default value), two attempts are made to recover each recoverable message. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.

To configure automatic recovery attempts for invoke and callback messages:

1. In the navigator, right-click soa-infra and select SOA Administration > BPEL Properties.

2. Click More BPEL Configuration Properties.

3. Go to MaxRecoverAttempt.

4. In the Value field, enter a value.

The recovery behavior for invoke and callback messages is different when MaxRecoverAttempt is set. For example, assume MaxRecoverAttempt is set to 4.

- Invoke message recovery is retried 4 (N) times before moving the message to the exhausted state.

- Callback message recovery is retried 5 times (N + 1) before moving the message to the exhausted state.

This is the expected behavior. The first attempt is not counted as a recovery attempt. The recovery attempts are incremented by the BPEL process service engine. If MaxRecoverAttempt is set to 1, you see one default resolution process and then one recovery attempt.

5. Click Apply.

For information about recovering invoke and callback messages, see Performing BPEL Process Service Engine Message Recovery.

15.5 Preserving the Order of Callback Messages

You can preserve the order of callback messages in a BPEL process and ensure that they are delivered to the BPEL process instance in the correct order by setting the ExecuteCallbacksInOrder property to true in the System MBean Browser. ExecuteCallbacksInOrder enables callbacks to be picked up in the order in which they were received by the BPEL process service engine for a given business flow instance. This setting impacts all SOA composite applications deployed in the BPEL process service engine.

For information about accessing and configuring the ExecuteCallbacksInOrder property, see Configuring BPEL Process Service Engine Properties.

15.6 Setting the Audit Level at the BPEL Process Service Component Level

You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels. The service component level setting is only available for BPEL processes and is not supported for the Oracle Mediator, human workflow, and business rule service components.

There are two ways to set the audit level for BPEL process service components. Supported values are Off, Minimal, Inherit, Development, and Production.

To set the audit level for BPEL process service components:

- In the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigation tree, expand the SOA folder.

2. Right-click soa-infra, and select Administration > System MBean Browser.

3. Select Application Defined MBeans > oracle.soa.config > Server: server_name > SCAComposite > Composite_Name > SCAComposite.SCAComponent > BPEL_Service_Component > Properties.

4. Click the Add icon.

5. Expand the Element_number folder.

6. From the many list, select false.

7. In the name field, enter bpel.config.auditlevel.

8. In the value field, enter a value.

9. Click Apply.

- In Oracle JDeveloper:
Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project.

<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

For more information about audit levels, see Introduction to the Order of Precedence for Audit Level Settings.

16 Monitoring BPEL Process Service Components and Engines

This chapter describes how to monitor the flow trace of a business flow instance, the time distribution of BPEL process activities and instances and faults throughput metrics, the service engine requests and thread performance statistics, the deployed BPEL process service components, and the statistics about the time a request spends in the service engine.

This chapter includes the following sections:

- Monitoring the Flow Trace of a Business Flow Instance

- Monitoring the Time Distribution of BPEL Process Activities and Instance and Fault Throughput Metrics

- Monitoring BPEL Process Service Engine Request and Thread Performance Statistics

- Monitoring Deployed BPEL Process Service Components in the Service Engine

- Viewing Statistics About the Time a Request Spends in the BPEL Process Service Engine

For conceptual information about service components and service engines, see the following sections:

- Introduction to Service Components

- Introduction to Service Engines

- Tuning Performance

Note:

You see any type of fault on the Flow Instances page (for example, fault policy faults, BPEL message recovery, rejected messages, EDN faults, and so on). All faults are part of the business flow instance details. For information, see Tracking Business Flow Instances at the SOA Infrastructure or Partition Level.

16.1 Monitoring the Flow Trace of a Business Flow Instance

This section describes how to monitor the flow trace of a business flow instance. The flow trace is a runtime trail of the message flow. A business flow instance corresponds to an end-to-end business transaction. Business flows consist of a single SOA composite application or multiple SOA composite applications connected together to fulfill a specific business process. The flow trace of a business flow instance is identified by a unique flow ID value that is displayed in the Search Results table of the Flow Instances page after you invoke a flow instance search.

Note:

This section assumes a business flow instance has been initiated. If not, see Initiating a Test Instance of a Business Flow for instructions.

To monitor the flow trace of a business flow instance:

Access the Flow Trace page through one of the following options:

1. To access business flow instances in all partitions:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Flow Instances tab.

c. Click the Search icon to populate the Search Results table with business flow IDs.

d. In the Flow ID column, click a specific business flow instance number.

a. Expand SOA folder.

b. Right-click soa-infra.

c. Select Home > Flow Instances.

d. Click the Search icon to populate the Search Results table with business flow IDs.

e. In the Flow ID column, click a specific business flow instance number.

2. To access business flow instances in an individual partition:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Manage Partitions.

b. In the SOA Partitions column, click a specific partition.

c. Click the Flow Instances tab.

d. Click the Search icon to populate the Search Results table with business flow IDs.

e. In the Flow ID column, click a specific business flow instance number.

a. Expand SOA > soa-infra.

b. Click a specific partition.

c. Click the Flow Instances tab.

d. Click the Search icon to populate the Search Results table with business flow IDs.

e. In the Flow ID column, click a specific business flow instance number.

The Flow Trace page consists of two sections. Depending on which tab is selected, the top section shows the Faults, Composite Sensor Values, Composites, or Resequencer (if an Oracle Mediator resequencer is included in the composite) tabs of the selected flow trace. The bottom section shows the business flow trace.

The Faults tab of the Flow Trace page displays the following details:

- A Faults table that displays the error message, component that handled the fault, time of the fault, and recovery status (for example, unrecoverable, recovery required, and so on). To display additional columns in the table, select View > Columns. If you change the columns in the Flow Instances page, they are also changed in the Faults table of the Flow Trace page.

- A Trace table that displays the sequence of the message flow through the services, service components, and references that comprise SOA composite applications. Regardless of the tab that you select on the Flow Trace page (Faults, Composite Sensor Values, Composites or Resequencer (if an Oracle Mediator resequencer is included in the composite), the Trace section is always displayed. To display additional columns in the table, select View > Columns. To view the flow trace in XML format, select the Actions list.

If the Audit Level is set to Off, trace details are not captured and the trace table is not displayed. However, instance details for some components are captured. For those components, a flat list of instance details is displayed. This list only has instance details for some components and may not have all components that participated in the flow.

Midprocess receive activities that are triggered by events are displayed in the flow trace. Midprocess receive activities can co-relate multiple flow IDs. The flow trace on the correlating BPEL node can display all the flow IDs that are correlated by that node.

You can perform the following flow trace management tasks:

- Recovering from Faults in the Flow Trace

- Viewing Composite Sensor Values in the Flow Trace

- Viewing the SOA Composite Application in the Flow Trace

- Viewing the Audit Trail and Process Flow in the Flow Trace

- Monitoring Fault_ Activity_ and Variable Sensors in the Flow Trace

- Understanding Additional Flow Trace Behavior Scenarios

16.1.1 Recovering from Faults in the Flow Trace

You can perform fault recovery from the Faults tab of the Flow Trace page. The fault recovery tasks that you perform are the same as those performed from the Faults tab of the Flow Instances page of the SOA Infrastructure or individual partition.

The Faults section shows the faults occurring in the services, service components, and references of the SOA composite application displayed in the Trace section. Selecting a fault highlights one or more rows in the Trace section in which the fault occurred (because multiple rows can correspond to the same fault if they are in the same fault chain). For example, a recoverable fault on a BPEL component can cause failed instances of other components and endpoints downstream. Selecting that BPEL process fault in the Faults table highlights all impacted Trace section nodes.

To recover from faults in the flow trace:

1. Access the Flow Trace page as described in Monitoring the Flow Trace of a Business Flow Instance.

2. Select a fault in the Faults section.

This highlights the row in the Trace section in which the fault occurred.

3. Initiate a fault recovery through one of the following options:

- From the Recover list, select a recovery option (for example, Abort or Retry).

- In the Error Message column, click the error to display a detailed error message and options for performing fault recovery (for example, Abort or Retry).

- In the Recover column, click Recovery Required.

For instructions about recovering from faults, see Step 5 of Recovering from Faults in a Business Flow Instance.

If recovery is successful, the fault is cleared from the Faults section and Trace section of the Flow Trace page.

16.1.2 Viewing Composite Sensor Values in the Flow Trace

You can view details about composite sensors included in the flow trace of the business flow instance. Composite sensors provide a method for implementing trackable fields on messages. Composite sensors can be added to service and reference binding components and service components that have subscribed to business events during design time in Oracle JDeveloper.

To view composite sensor values in the flow trace:

1. Access the Flow Trace page as described in Monitoring the Flow Trace of a Business Flow Instance.

2. Click the Composite Sensor Values tab to display composite sensors in the business flow instance.

This highlights the row in the Trace section in which the composite sensor data was collected. Closing the sensor clears the selection in the Trace section.

16.1.3 Viewing the SOA Composite Application in the Flow Trace

You can view the initiating and participating SOA composite applications included in the flow trace of the business flow instance.

To view the SOA composite application in the flow trace:

1. Access the Flow Trace page as described in Monitoring the Flow Trace of a Business Flow Instance.

2. Click the Composites tab.

The initiating and participating composites in the flow trace of the business flow instance are displayed. If you set a value for the business flow instance title during design time in Oracle JDeveloper, it is displayed in the Name column.

For information about setting the business flow instance name, see Section "How to Set the Flow Instance Name or Composite Instance Name at Design Time" of Developing SOA Applications with Oracle SOA Suite.

16.1.4 Viewing the Audit Trail and Process Flow in the Flow Trace

You can view the audit trail and process flow in the flow trace of the business flow instance. The audit trail and flow trace provide a graphical representation of the audit trail data. The audit trail displays execution details about the activities in the BPEL process. The process flow displays the flow of the payload through the process.

To view the audit trail and process flow in the flow trace:

1. Access the Flow Trace page as described in Monitoring the Flow Trace of a Business Flow Instance.

The Trace section displays the sequence of the message flow through the services, service components, and references that comprise the SOA composite application. For this example, the service binding component, service components, and reference binding component involved in the flow have successfully received and processed messages.

2. In the Instance column of the Trace section, click a specific BPEL process service component. Service components can be accessed from the Flow Trace page; services and references cannot be accessed.

The audit trail for the selected service component is displayed.

3. Select the Highlight Faults checkbox to highlight any faults in the audit trail.

4. From the View list, select Audit trail XML to view the XML output of the audit trail. You can save the XML output as a file.

5. Scroll through the audit trail to check for errors and click the View Payload links to view their contents at a given point in the flow.

Note:

- Canceled onMessage branches of pick or scope activities that did not execute are displayed in the audit trail. However, the flow diagram does not show these same canceled onMessage branches. This is the expected behavior.

- The following error message appears when a transaction is displayed as rolled back in the Audit Trail page:

The transaction was rolled back. The work performed for bpel
instance "instance_ number" was rolled back to the previous
dehydration point,  but the audit trail has been saved.
You can recover the instance from the recovery console by
resubmitting the callback message or activity for execution

This message does not specifically state whether recovery should happen on either the activity or the callback. This is the intended behavior. Oracle recommends that you do not recover each instance through the audit messages. Instead, set up automatic recovery to recover these instances.

6. Click the Flow tab.

A flow diagram of the activities in the BPEL process is displayed. Any faults in the flow diagram are highlighted.

7. Click an activity to view the flow of the payload through the process.

Note:

If using Microsoft Internet Explorer, you can click Copy details to clipboard to copy the activity details to the clipboard. If using Mozilla Firefox, this link does not appear. Instead, you must manually select the text, and copy and paste it to a file.

8. Scroll through the flow diagram to check for errors.

9. Click a highlighted activity to view error messages.

10. Close the message.

16.1.5 Monitoring Fault, Activity, and Variable Sensors in the Flow Trace

You can view the fault, activity, and variable sensor data in a BPEL process service component. You design sensors in BPEL processes in Oracle JDeveloper. Sensors enable you to monitor BPEL process activities, variables, and faults during runtime.

To monitor fault, activity, and variable sensor data in BPEL processes:

1. Access the Flow Trace page as described in Monitoring the Flow Trace of a Business Flow Instance.

2. Click a specific BPEL process service component in the Instance column of the Trace section.

3. Click the Sensor tab.

4. Expand a sensor type to view details.

If you created JMS sensors in your BPEL process, JMS sensor values are not displayed in Oracle Enterprise Manager Fusion Middleware Control. Only sensor values in which the sensor action stores the values in the database are displayed (for example, database sensor values).

For more information about sensors, see Chapter "Using Oracle BPEL Process Manager Sensors and Analytics" of Developing SOA Applications with Oracle SOA Suite.

For more information about fault recovery, see Recovering from Faults in a Business Flow Instance and Performing BPEL Process Service Engine Message Recovery.

16.1.6 Understanding Additional Flow Trace Behavior Scenarios

This section describes additional flow trace behavior scenarios.

16.1.6.1 Behavior of Activity Sensors in Compensate and CompensateScope Activities in BPEL 2.0

Assume you have an activity sensor in a BPEL 2.0 compensateScope activity with the evaluation time set to completion and have also configured the activity's variable sensor to point to a variable. You may expect that when the sensor is triggered, the compensation activity completes and the variable shows the state that it is in at the completion of the compensation activities.

However, note that the compensateScope activity (and also a compensate activity) ends immediately after passing control to the compensation activities. As a result, the activity's variable sensor shows the state that it is in at the beginning of the compensation activities, rather than at the end.

This is the expected behavior.

As a workaround for obtaining the variable state upon completion of compensation, add an empty activity after the compensate or compensateScope activity and set the activity sensor on the empty activity with an evaluation time set to activation.

16.2 Monitoring the Time Distribution of BPEL Process Activities and Instance and Fault Throughput Metrics

You can monitor the time distribution of BPEL process activities and a graphical view of instance and fault throughput metrics for the BPEL process service component.

To monitor the time distribution of BPEL process activities and instance and fault throughput metrics:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

The Dashboard page is displayed.

2. In the Components section, select the BPEL process service component.
The Dashboard page displays the following details:

- Details about the time distribution for activities, including the activity name, the total number of activities for all instances, and the average execution time.

- A graphical representation of the number of successful, faulted, and incoming (pending) instances of the BPEL process service component over a specific time range.

3. Click Table View to display throughput details for the last five minutes in tabular form, including the throughput for successful instances, the total faults throughput, and the instance throughput.

For more information, see Introduction to Business Flow Instances and Administering Oracle Fusion Middleware for details about viewing and searching log files.

16.3 Monitoring BPEL Process Service Engine Request and Thread Performance Statistics

You can monitor request and thread performance statistics for all BPEL process service components running in the service engine.

To monitor BPEL process service engine request and thread performance statistics:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > BPEL.

a. Right-click soa-infra.

b. Select Service Engines > BPEL.

2. Click Statistics.
The Pending Requests and Active Requests sections of the Statistics page display the following details. Click the Help icon for additional information.

- Pending requests in the service engine

- Active requests in the service engine

The Thread Statistics and Request Breakdown parts of the Statistics page display details about the number of active threads and the count and minimum, maximum, and average request processing times in the service engine.

For more information about BPEL process tuning and performance, see Tuning Performance.

16.3.1 Viewing Low Level Request Breakdown Table Details

You can configure the Request Breakdown part of the Statistics page to display lower level details about the time a request spends in various service engine layers during processing. You may need to scroll down the Statistics page to view this part.

Configure the StatsLastN property under the More BPEL Configuration Properties link on the BPEL Service Engine Properties page. By default, this property is set to -1. You can set this property to a more appropriate value (for example, 1000). This property provides information that helps you analyze and isolate areas that may become potential trouble spots.

For information about accessing and configuring this property, see Configuring BPEL Process Service Engine Properties.

The information that is displayed on the Request Breakdown part of the Statistics page after configuring the StatsLastN property is also displayed with the following System MBean Browser properties:

- AsyncProcessStats: Provides low level asynchronous process statistics.

- SyncProcessStats: Provides low level synchronous process statistics.

- RequestStats: Provides a low level request breakdown.

For information about accessing these properties, see Viewing Statistics About the Time a Request Spends in the BPEL Process Service Engine.

16.4 Monitoring Deployed BPEL Process Service Components in the Service Engine

You can monitor all deployed SOA composite applications with BPEL process service components running in the service engine.

To monitor deployed BPEL processes in service engines:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > BPEL.

a. Right-click soa-infra.

b. Select Service Engines > BPEL.

The Deployed Components page displays the following details:

- A utility for searching for a specific deployed SOA composite application by specifying criteria and clicking Search. This search is case sensitive. You must enter the exact name of the component and the exact name of the composite, without the revision portion. To view an unfiltered list of all components after searching, click Reset.

- Details about deployed SOA composite applications with BPEL process service components running in this service engine, including the service component name, the SOA composite application, and the current status (up or down).

2. In the Name column, click a specific service component to access its home page.

3. In the Composite column, click a specific SOA composite application to access its home page.

16.5 Viewing Statistics About the Time a Request Spends in the BPEL Process Service Engine

You can display lower level details about the time a request spends in various service engine layers during processing with several System MBean Browser properties.

1. In the navigation tree, expand the SOA folder.

2. Right-click soa-infra, and select Administration > System MBean Browser.

3. Select Application Defined MBeans > EMDomain > Server: server_name > Application: soa-infra > EMIntegration > soa-infra.

The following properties can be configured.

- AsyncProcessStats: Asynchronous process statistics

- RequestStats: Request breakdown statistics

- SyncProcessStats: Synchronous process statistics

4. View the content of the AsyncProcessStats property.

5. View the content of the RequestStats property.

6. View the content of the SyncProcessStats property.

For information on configuring this information with the StatsLastN property on the BPEL Service Engine Properties page, see Configuring BPEL Process Service Engine Properties.

17 Managing BPEL Process Service Components and Engines

This chapter describes how to manage BPEL process service components and service engines, including managing service component policies, performing BPEL process message recovery of undelivered invoke and callback messages, and storing instance and message data in Oracle Coherence distributed cache on Oracle Exalogic Platforms.

This chapter includes the following topics:

- Managing BPEL Process Service Component Policies

- Performing BPEL Process Service Engine Message Recovery

- Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms

For conceptual information about service components and service engines, see the following sections:

- Introduction to Service Components

- Introduction to Service Engines

17.1 Managing BPEL Process Service Component Policies

You can attach and detach policies to and from BPEL process service components in currently deployed SOA composite applications. Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services.

Note:

Before attaching policies, see Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use in your environment.

To manage BPEL process service component policies:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

2. Select the BPEL process service component in the Components section.

3. Click Policies.
The Policies page enables you to attach and detach policies to and from BPEL process service components. The Policies table displays the attached policy name, the policy reference status (enabled or disabled) that you can toggle, the category (such as Management, Reliable Messaging, MTOM Attachment, Security, or WS-Addressing), the violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

4. Click Attach/Detach.
If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

5. Select the service or component to which to attach or detach a policy.
This invokes a dialog for attaching or detaching policies.

Policies currently attached appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

6. Select to attach policies appropriate to your environment.

7. Click Attach.

8. When you are finished attaching policies, click Validate.

9. If an error message appears, make the necessary corrections until you no longer have any validation errors.

10. Click OK.
The attached policy is displayed in the Policies table.

For more information, see the following documentation:

- Introduction to Policies

- Managing SOA Composite Application Policies for the dialogs that are displayed during policy attachment

- Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use for your environment

17.2 Performing BPEL Process Service Engine Message Recovery

In Release 12.1.3, issues with business flow instances, including BPEL process message recovery, are reported as faults. Therefore, you can perform message recovery from the Recovery page of the BPEL process service engine or from the Error Hospital page.

You can perform a manual recovery of undelivered invoke or callback messages due to a transaction rollback in the business flow instance. Recovery of invoke messages applies to asynchronous BPEL processes only. Synchronous BPEL processes return an error to the calling client and are not recoverable from the Recovery page. Recoverable activities are activities that failed and can be recovered. For example, if you are using the file adapter to initiate an asynchronous BPEL process and your system fails while the business flow instance is processing, you can manually perform recovery when the server restarts to ensure that all message records are recovered.

You can also manage messages that have failed automatic recovery attempts by the BPEL process service engine. To ensure that automatic recovery of these messages is not attempted multiple times, these messages are placed in the exhausted state. You can then perform one of the following actions on these messages:

- Return them to the automatic recovery queue

- Never attempt a recovery on them again

- Attempt to recover them immediately

For example, assume you have a BPEL process that writes to a database adapter. If the database is down, these messages are sent to a recovery queue. Automatic recovery of these messages fails while the database is down. Such messages are marked with the exhausted state so that automatic recovery is not attempted on them again. When the database begins running again, you can reset these messages (return them to the automatic recovery queue) so that an automatic recovery is attempted on them again.

To perform BPEL process service engine message recovery:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > BPEL.

a. Right-click soa-infra.

b. Select Service Engines > BPEL.

2. Click Recovery.
The Recovery page displays the following details:

- A Refresh Alarm Table button for resynchronizing lost, in-memory, Quartz-scheduled jobs in the database. For example, assume a timer on a wait activity or an onAlarm branch of a pick activity was initiated, but the transaction was rolled back. You can resynchronize these jobs with the business flow instances residing in the wait activity/onAlarm branch in the database.

- A utility for searching for a specific message failure by specifying criteria and clicking Search. Click the Help icon for details.

- Message failures in the service engine, including the conversation ID, whether you can recover from the message failure, the service component and composite application in which the failure occurred, and the time at which the fault occurred. Depending on the state, you can recover these messages immediately, cancel these messages, or reset these messages for automatic recovery.

Note:

- You can recover callback messages in resolved and undelivered states. These messages can be displayed for recovery when you execute search criteria in which you select Callback from the Type list and either Resolved or Undelivered from the Message State list. When a callback message first enters the BPEL process service engine, its state is undelivered. When this message is resolved to the target business flow instance either through matching a conversation ID or a correlation, the state is switched to resolved. In both of these states, the messages have not yet been consumed. Messages in these two states can be recovered (redelivered into the BPEL process service engine for consumption). In other situations, the callback messages can become stranded in both of these states. Messages in these states can also be recovered. However, there is no guarantee that stranded callback messages always remain in an undelivered state.

- The Message States list is applicable to the callback and invoke message type recovery, and the activity message type recovery for the undelivered, cancelled, and exhausted states. The delivered and resolved message states are not applicable to activity messages in Release 12c.

3. Select a fault in the table.

4. Select one of the following options:

Action

Description

Recover

Retries the message in which the fault occurred.

If you select messages in the exhausted state and click this button, an attempt is made to recover them immediately. Should this recovery attempt also fail, the message is returned to the exhausted state. You must then select the message and click Reset to return the message to the automatic recovery queue.

If an asynchronous BPEL process encounters a transaction rollback scenario because of any underlying exception error, it rolls back to the last dehydration activity. If this is a new instance, and a receive activity was the first dehydration activity, the BPEL process service engine creates a recoverable invoke. When you click Recover to recover the invoke, the service engine creates a new instance. This instance may run to completion with no exception error. However, you continue to see the older instance identified as faulted.

Abort

Select to display a confirmation message that enables you to terminate the entire flow in which the message marked as cancelled is included, and update the instance state. Message cancellation is executed in the context of the flow ID. If instances are linked using this flow ID, all instances are terminated. A flow ID enables you to track a message flow that crosses different composite applications.

If you select messages in the exhausted state and click this button, recovery is never attempted on them.

Reset

Select to reset exhausted messages to the undelivered state. This returns the message to the automatic recovery queue. The messages that are displayed in the exhausted state disappear from the messages table. If you select Undelivered from the Message State list and click Search, these messages are displayed. Callback messages in the exhausted state can also be reset to the resolved state and still remain recoverable.

Once a message is submitted for recovery, the BPEL process service engine may take time to complete the action. This typically takes less than several seconds. During this time, the message remains visible in the Recovery page. Duplicate attempts to recover the same message in that period are ignored. Refresh the page every few seconds to receive the latest recovery status.

Note:

If you define a fault policy in a BPEL process with an ora-retry action and a fault occurs, the BPEL process attempts to recover from the fault the number of times you specified with the retryCount parameter. After this period, the process continues to be in a running state. The status of an activity in the process that has not completed (such as an invoke or receive) shows as pending a manual recovery. This is the expected behavior.

For information about fault recovery in the Error Hospital, see Recovering From Faults in the Error Hospital.

For information about configuring the maximum number of times to attempt an invoke and callback message recovery, see Configuring Automatic Recovery Attempts for Invoke and Callback Messages.

For information about designing a fault policy, see Section "Handling Faults with the Fault Management Framework" of Developing SOA Applications with Oracle SOA Suite.

17.3 Storing Instance and Message Data in Oracle Coherence Distributed Cache on Oracle Exalogic Platforms

With BPEL processes, a potential performance issue is the number of database interactions required per instance. This factor is the main reason for synchronous transient flows outperforming asynchronous durable flows. You can design around this issue by utilizing synchronous transient flows in situations where low response times are required. However, you may be unable to design this type of flow for business reasons.

If you are running Oracle SOA Suite on an Oracle Exalogic platform, you can use the distributed cache feature of Oracle Coherence to store instance and message data from BPEL processes. This eliminates database reads, thereby reducing the number of database interactions.

Oracle Coherence is a component of Oracle Fusion Middleware that enables organizations to scale mission-critical applications by providing access to frequently used data. Oracle Coherence includes a distributed cache feature that provides scalability for both read and write access. Data is automatically, dynamically, and transparently partitioned across nodes. The distribution algorithm minimizes network traffic and avoids service pauses by incrementally shifting data.

Oracle Exalogic is an integrated hardware and software system designed to provide a platform for a range of application types and varied workloads. Oracle Exalogic is intended for large-scale, performance-sensitive, mission-critical application deployments.

Note:

If your environment is not using Oracle Exalogic, Oracle Coherence distributed cache is not available.

The potential performance gains of using a distributed cache for BPEL processes are as follows:

- Eliminates the read operation required for messages (invoke and callback) from the database after initial delivery

- Eliminates the read operation required for cube instances after a dehydration point

For more information about Oracle Coherence, see the Oracle Coherence Getting Started Guide and Developing Applications with Oracle Coherence.

17.3.1 Introduction to the Oracle Coherence Caching Architecture

During dehydration, instance objects are stored in the database using the Java Persistence API (JPA) in a container-managed Enterprise JavaBeans (EJB) transaction. The BPEL process service engine registers the transaction afterCompletion listener for post-transaction processing. Instance objects modified during a transaction are tracked and made available to the afterCompletion listener, which updates the cache. Figure 17-1 provides details about the dehydration process.

Figure 17-1 Dehydration Process

During rehydration, instance objects are read from cache. Implementations do not provide XA guarantees for transaction completion notification, and cache eviction may delete the object from cache. Implementations account for these two scenarios and address the issues of cache not returning an object or returning an older version of the object.

Cache lookup usually provides a valid object. In this scenario, performance gain for dehydration and rehydration using cache over direct writes (the default) equals the following:

(database read time + relational to object mapping) minus (Object serialization +
reading from serialized form + Coherence network overhead + query to
database for reading CACHE_VERSION)

It also reduces activity on the database server.

If Oracle Coherence cache is not available due to a network issue, the BPEL process service engine continues to work. If there are no errors, business process instances continue to progress.

17.3.2 Running with Default SOA Cluster Nodes and Coherence Cache Grid Nodes

BPEL process caches are not created on an Oracle SOA Suite cluster node. You must start the BPEL cache servers, which host the BPEL caches, by following the instructions in Starting the BPEL Process Cache Servers. Start at least four servers to observe an increase in performance.There is no requirement for ordering of an Oracle SOA Suite cluster and BPEL cache servers. The BPEL process service engine continues to function without BPEL cache servers, even when the QualityOfService property is set to CacheEnabled in Oracle Enterprise Manager Fusion Middleware Control.

For more information about Oracle Coherence, see the Oracle Coherence Getting Started Guide and Developing Applications with Oracle Coherence.

17.3.3 Configuring Oracle Coherence Caching

The System MBean Browser property QualityOfService enables you to configure Oracle Coherence for dehydration. You can configure this property on one of the nodes in the SOA cluster.

To configure Oracle Coherence caching for dehydration:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > BPEL Properties.

a. Right-click soa-infra.

b. Select SOA Administration > BPEL Properties.

The BPEL Service Engine Properties page is displayed.

2. Click More BPEL Configuration Properties.

3. In the Attributes tab, click QualityOfService.

4. In the Value field, enter a value appropriate to your environment. This change does not require a SOA Infrastructure restart.

Table 17-1 QualityOfService Values

Value

Description

DirectWrite

No cache is used for dehydration and rehydration. Read and write operations are done to the database. This is the default setting.

CacheEnabled

During dehydration, the instance data is stored in the database using an XA data source connection; the placement of objects into cache is part of post-transaction processing.

During rehydration, data is fetched from the cache. If the data is not found (for example, the BPEL process cache servers are not available) or the version is aborted, data is read from the database.

5. Click Apply.

17.3.4 Configuring the Storage of the Audit Trail to Oracle Coherence Cache

You can store the audit trail in Oracle Coherence cache by setting the following System MBean Browser properties to these values in Oracle Enterprise Manager Fusion Middleware Control:

- AuditStorePolicy is set to async. This property is now set from the AuditConfig attribute at the SOA Infrastructure level.

- QualityOfServiceOneWayDeliveryPolicyUseDistributedCache is set to true. This property is set under BPEL Service Engine Properties.

- QualityOfService is set to CacheEnabled. This property is set under BPEL Service Engine Properties. For instructions, see Configuring Oracle Coherence Caching.

These settings enable the following to occur:

- Oracle Coherence cache acts as a queue and writes the audit trail to the database.

- The SOA server node heap and threads do not process the audit trail.

If one of these properties is set to a different value, the heap and dispatcher threads are used for writing to the database.

To configure the storage of the audit trail into Oracle Coherence cache:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > BPEL Properties.

a. Right-click soa-infra.

b. Select SOA Administration > BPEL Properties.

The BPEL Service Engine Properties page is displayed.

2. Click More BPEL Configuration Properties.

3. In the Attributes tab, click AuditStorePolicy .

4. In the Value field, enter async.

Note:

If the server crashes (the SOA/BPEL cache server), some audit trail messages are not persisted to the database. This results in loss of the audit log. Failover is not supported. This is true for both Oracle Coherence and memory/heap caches.

5. Click Apply.

6. Click Return.

7. In the Attributes tab, click QualityOfService.AuditStorePolicy.UseDistributedCache.

8. From the Value list, select true.

9. Click Apply.

17.3.5 Configuring the Storage of Invocation Messages to Oracle Coherence Cache

You can store invocation messages in Oracle Coherence cache by setting the following System MBean Browser properties to these values in Oracle Enterprise Manager Fusion Middleware Control:

- OneWayDeliveryPolicy is set to async.cache.

- QualityOfServiceOneWayDeliveryPolicyUseDistributedCache is set to true.

- QualityOfService is set to CacheEnabled. For instructions, see Configuring Oracle Coherence Caching.

If one of these properties is set to a different value, local memory is used for cache, and not Oracle Coherence cache.

Note:

Invocation messages in the middle of execution at the time of a server crash (both SOA and BPEL process cache servers) can be lost or duplicated. Failover is not supported. This is true for both Oracle Coherence and memory/heap caches.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > BPEL Properties.

a. Right-click soa-infra.

b. Select SOA Administration > BPEL Properties.

The BPEL Service Engine Properties page is displayed.

2. Click More BPEL Configuration Properties.

3. In the Attributes tab, click OneWayDeliveryPolicy .

4. In the Value field, enter async.cache.

5. Click Apply.

6. Click Return.

7. In the Attributes tab, click QualityOfServiceOneWayDeliveryPolicyUseDistributedCache.

8. From the Value list, select true.

9. Click Apply.

17.3.6 Starting the BPEL Process Cache Servers

Run the start-bpel-cache.sh script to start the BPEL process cache servers on UNIX machines on which Oracle SOA Suite is installed.

The only requirement is network connectivity. The Oracle SOA Suite nodes must be reachable from the host on which the BPEL process cache servers are installed.

This script joins an Oracle SOA Suite cluster with a multicast, default address and port. These values match with the corresponding values in the $FMW_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh file.

If you choose multicast for a cluster, but use a different address and port, you can override it in the bpelCacheEnv.sh file by using an environment variable or setting a shell variable. Use the same values for SOA managed servers (in setDomainEnv.sh).

The default cache configuration for the Oracle SOA Suite cluster must be unicast, and not multicast. For more information about this recommended cache configuration for Oracle SOA Suite clusters for Oracle Coherence, see the High Availability Guide or Enterprise Deployment Guide for Oracle SOA Suite for details.

To start the BPEL process cache servers:

1. Go to the $FMW_HOME/SOA_ORACLE_HOME/bin directory.

2. Open the start-bpel-cache.sh file.

3. Follow the instructions inside the start-bpel-cache.sh file to create the bpelCacheEnv.sh file and configure various environment variables.

Environment/shell variable names and value formats are described in the initial notes section of the start-bpel-cache.sh file.

4. Ensure that you first set the QualityOfService property to CacheEnabled in Oracle Enterprise Manager Fusion Middleware Control, as described in Configuring Oracle Coherence Caching.

5. Run the following script:

start-bpel-cache.sh

Part VI Administering Oracle Mediator Service Components and Engines

This part describes how to administer Oracle Mediator service components and engines.

This part includes the following chapters:

- Configuring Service Components and Engines

- Monitoring and Managing Service Components and Engines

- Managing Cross-References

18 Configuring Oracle Mediator Service Components and Engines

This chapter describes how to configure runtime properties for Oracle Mediator service components and service engines using Oracle Enterprise Manager Fusion Middleware Control. You can also configure advanced and custom properties for Mediator.

This chapter includes the following sections:

- Configuring Service Engine Properties

- Configuring Resequenced Messages

For more information about Oracle Mediator tuning and performance properties, see Tuning Performance.

18.1 Configuring Oracle Mediator Service Engine Properties

Mediator service engine properties are used by the Mediator service engine during processing of Mediator service components.

To configure Mediator service engine properties:

1. Access the Mediator Service Engine Properties page using one of the following methods:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > Mediator Properties.

a. Right-click soa-infra.

b. Select SOA Administration > Mediator Properties.

The Mediator Service Engine Properties page displays a list of Mediator properties, as shown in the following figure.

2. Make changes to the service engine properties that are appropriate to your environment.
The properties are described in Table 18-1 below.

Table 18-1 Mediator Service Engine Properties

Property

Description

Audit Level

The Mediator-specific audit level. The value of this property overrides the value of the global SOA Infrastructure audit level property. The possible values of this property are:

- Off: Switches off auditing for Mediator. Business flow instance tracking and payload tracking information are not collected.

- Inherit: The level of audit is the same as the SOA infrastructure. This setting enables the Mediator audit level to automatically change, when the global setting is changed. Setting a different audit level tracking, for this page, overrides the tracking set at the SOA Infrastructure level.

- Production: All events are logged. All audit details, except the details of assign activities, are logged. Instance tracking information is collected, but payload details are not captured and these details are not available in the flow audit trails. This level is optimal for most typical operations and testing.

- Development: All events and all audit details are logged. In addition, payload details are captured and are available in the flow audit trails. This level is useful for debugging purposes, but may impact performance.

The default value of this flag is Inherit.

Notes:

- You do not need to restart the server after changing these properties.

- Audit levels were known as instance tracking levels in the Oracle Application Server 10g releases.

Metrics Level

The Mediator-specific property for configuring the Dynamic Monitoring Service (DMS) metrics level. DMS metrics are used to measure the performance of application components. The possible values of this property are:

- Enabled: Enables DMS metrics tracking

- Disabled: Disables DMS metrics tracking

Parallel Maximum Rows Retrieved

The number of rows retrieved per iteration for parallel processing.

Note: A large value for this property can result in memory exhaustion.

Parallel Locker Thread Sleep (sec)

The idle time between two successive iterations for retrieving rows, when there is no message for parallel processing. The time is measured in seconds.

Parameters

Custom configuration properties. For an example, see Configuring Resequenced Messages.

Container ID Refresh Time (sec)

Container ID Lease Timeout (sec)

Heartbeat infrastructure properties. The heartbeat infrastructure is a part of the Mediator service engine and detects the absence of a Mediator service engine instance due to failure or shutdown of a node. The heartbeat infrastructure creates a unique identifier for each instance of the Mediator service engine and performs the necessary housekeeping tasks, if a Mediator service engine fails. The heartbeat infrastructure consists of a heartbeat thread. The heartbeat thread periodically updates the time stamp associated with each Mediator service engine's unique identifier. By updating the time stamp associated with it, a Mediator service engine announces its presence to the other Mediator service engines. The heartbeat thread also checks if there are unique identifiers that have not been updated for a particular period. You can configure the heartbeat framework by setting the following parameters:

- Container ID Refresh Time (sec): The time interval at which the heartbeat thread periodically updates the time stamp associated with each Mediator service engine's unique identifier.
Notes: The default value is 60 seconds. In case of unplanned outages, you must wait the amount of time specified for this property after restarting the server.

You can set this parameter to a smaller value, like 30 seconds, if you need to ensure more frequent refreshes.

- Container ID Lease Timeout (sec): The time interval at which the heartbeat thread periodically checks if there are unique identifiers that have not been updated for a particular period. A node is considered to be timed out if it has not refreshed itself for a duration longer than the amount of time specified here.
Notes: The default value is 300 seconds. You can set this parameter to a larger value, like 600 seconds, if you find your nodes being timed out because of slow-running SQL statements, for example.

By configuring these parameters, you can specify the period used by the heartbeat thread to detect the failure of a Mediator service engine.

Resequencer Locker Thread Sleep (sec)

The sleep interval for the locker threads in seconds. When the resequencer is unable to find a group with messages that can be processed, the locker thread sleeps for the specified duration. The locker thread does not sleep between each iteration of a database seek, as long as it finds groups with messages that can be processed. The default value is 10.

Resequencer Maximum Groups Locked

The number of groups to be retrieved for processing in a single iteration of a database seek. Once retrieved, the groups are assigned to worker threads for processing. The default value is 4.

Resequencer Worker Threads

The number of worker threads (dispatchers) for processing resequencing groups in parallel. Each worker thread is assigned a group, and then processes messages for the group in sequence. When there are a large number of groups waiting for messages to be processed, increasing this parameter can improve performance.The default value is 4.

3. To configure advanced Mediator properties in the System MBean Browser, click More Mediator Configuration Properties.

You can also access Mediator properties in the System MBean Browser through the navigator, as described below.

18.1.1 To Access System MBean Browser Properties:

1. From the SOA Infrastructure menu, point to Administration and then select System MBean Browser.
The System MBean Browser page appears.

2. In the System MBean Browser navigation pane on the left, expand oracle.as.soainfra.config, expand Server: server_name, expand MediatorConfig, and then select mediator.
The properties of the MBean appear in the right pane.

3. To change the value of a property, modify its Value field and then click Apply.

Note:

Not all values can be modified. The System MBean properties generally correspond to the properties listed inTable 18-1, with some additional read-only properties for the MBean. An additional property, ContainerInitRetries, is not listed in Table 18-1. This property indicates the number of attempts that are made to create an Oracle Mediator service engine instance ID.

18.2 Configuring Resequenced Messages

For Mediator service components to resequence messages, you must configure the following:

- The worker thread count

- The maximum number of groups that can be locked by a thread

- The sleep interval

If the Mediator service component is configured to use best effort resequencing and the messages to process in each batch are based on a time window rather than a maximum number of rows, you can also configure the buffer window.

To configure resequenced messages:

1. Access the Mediator Service Engine Properties page or the System MBean Browser using one of the methods described in Configuring Service Engine Properties.

2. Enter a value for the following Mediator properties:

- Resequencer Worker Threads: The number of threads used by resequencers.

- Resequencer Maximum Groups Locked: The maximum number of group rows retrieved for each locking cycle.

- Resequencer Locker Thread Sleep: The length of time in seconds for the resequencer locker to sleep when there are no messages in the database.

Note:

For more information about these properties, see Table 18-1.

3. To configure the buffer window for the time window in best effort resequencing, enter the following for the Parameters property value:

buffer.window=x

Where x is the percentage of the configured time window to add to the buffer. For example, buffer.window=20 means that 20% of the length of the time window is added as a buffer.

4. Click Apply.

19 Monitoring and Managing Oracle Mediator Service Components and Engines

This chapter describes how to monitor and manage Oracle Mediator service components and engines using Oracle Enterprise Manager Fusion Middleware Control.

This chapter includes the following topics:

- Introduction to the Component Dashboard Page

- Monitoring and Managing an Service Component

- Monitoring an Service Engine

- Monitoring Resequencing Groups

For more information, see the following sections:

- Introduction to Service Components

- Introduction to Service Engines

In addition to monitoring Mediator components using Oracle Enterprise Manager Fusion Middleware Control, you can also set up watches and notifications for resequencing groups have stopped processing but still have messages pending. You can also run a diagnostic dump with this information. For more information, see Diagnosing Problems with SOA Composite Applications.

19.1 Introduction to the Oracle Mediator Component Dashboard Page

The Mediator Component Dashboard lets you view information about the current state of the selected Mediator service component. This information includes routing statistics and statistics on successful, failed, and pending instances.

Each section of the dashboard includes links to further information that can help you monitor the status of your environment. The following sections describe the instance information in the different sections of the Dashboard page.

19.1.1 Routing Statistics Section

The Routing Statistics section includes the following information about the routing data of a source operation or subscribed event:

- Number of Successfully Processed Messages: The number of messages successfully processed for the selected route source.

- Number of Faulted Messages: The number of messages that threw faults for the selected route source.

- Number of Incoming Messages: The total number of incoming messages for the selected route source.

- Average Processing Time for Successful Messages: The average time taken to process each successful message for the selected route source.

- Average Processing Time for Faulted Massages -The average time taken to process each faulted message.

The Route Target subsection in the Routing Statistics section displays statistics of the target routes for the Mediator service component. This section provides the following information about an instance:

- Name: The name of the route target of the Mediator service component.

- Error: The number of errors that occurred during routing.

- Average Processing Time: The average processing time for the instances of the Mediator service component. This field has two subfields, Success and Failure. The Success subfield shows the average processing time for the instances of the Mediator service component that were processed successfully. The Failure subfield shows the average processing time for the instances of the specific Mediator service component that failed to process successfully.

- Average Invocation Time: The average invocation time for the instances of the Mediator service component.

19.1.2 Instance Rate Per Min Section

The Instance Rate Per Min section provides information about the execution rate of the Mediator instances per minute. This section displays a graph that shows real-time data for successful, faulted, and incoming instances in the last five minutes.

You can view the instance rate for the last five minutes in tabular form by clicking Table View.

19.2 Monitoring and Managing an Oracle Mediator Service Component

You can perform any of the following component-level monitoring and management tasks from the Mediator Component home page in Oracle Enterprise Manager Fusion Middleware Control:

- Monitoring Service Component Routing Statistics and Instances

- Managing Policies

19.2.1 Monitoring Oracle Mediator Service Component Routing Statistics and Instances

The Mediator Component Dashboard displays routing statistics and instance-related information.

To monitor Mediator service component routing statistics and instances:

1. Access the SOA Composite home Page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Expand soa-infra, and then select a specific SOA composite application.

2. In the Components section, select the Mediator service component.

3. Click the Dashboard tab.

The Dashboard page displays the information described in Introduction to the Component Dashboard Page.

4. Expand the Routing Statistics section and select an operation or event in the Select Route Source field.
View the statistics for the selected operation or event. To view additional information, expand the Route Target section.

5. View the routing statistics for all targets in the Route Target table.
For information about the fields displayed in the Routing Statistics section, see Routing Statistics Section.

6. Expand the Instance Rate per Min (Real-Time Data) section to view a graphical representation of the number of successful, faulted, and incoming (pending) instances of the Mediator service component over a specific time range.
Click Table View to display the same information in a tabular format.

For more information, see Introduction to Business Flow Instances. For information about viewing and searching log files, see Administering Oracle Fusion Middleware.

19.2.2 Managing Oracle Mediator Policies

Oracle Fusion Middleware uses a policy-based model to manage web services. Policies apply behavioral requirements and security to the delivery of messages. You can view, attach, and detach policies for Mediator service components in currently deployed SOA composite applications.

The Policies page of the Mediator Component Home page provides the following information about a Mediator component:

- Policy Name: The name of the policy.

- Policy Reference Status: A toggle button that allows you to enable or disable a policy. Disabling a policy temporarily turns it off without detaching it. If the button says Disable, the policy is enabled; if it says Enable, the policy is disabled.

- Category: The category of the policy. It has the following values: Management, Reliable Messaging, MTOM Attachments, Security, and WS-Addressing.

- Total Violations: The total number of violations since the SOA Infrastructure was restarted.

- Security Violation: The number of violations in each category. Category can have the following values: Authentication, Authorization, Confidentiality, and Integrity.

To manage Mediator policies:

1. Access the SOA Composite home page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, select a specific SOA composite application.

2. Select the Mediator service component in the Components section.

3. Click the Policies tab.

4. View the policies attached to a Mediator component.

5. Click Attach/Detach to attach or detach a policy.

6. If multiple components are available, select the service or component to which you want to attach the policy.
The Attach/Detach Policies page appears with all attached policies displayed in the upper pane and all available policies displayed in the lower pane.

7. To attach a policy, select the policy in the lower pane and then click Attach.

8. To detach a policy, select the policy in the upper pane and then click Detach.

9. When you finish attaching or detaching policies, click Validate.

10. If any validation errors occur, make the necessary corrections and run the validation until no more errors occur.

11. Click OK.
The dialog closes and the attached policies appear in the policies table.

For more information, see the following documentation:

- Introduction to Policies

- Managing SOA Composite Application Policies for the dialogs that are displayed during policy attachment

19.3 Monitoring an Oracle Mediator Service Engine

You can perform the following monitoring tasks at the Mediator service engine level from the Dashboard tab of the Mediator Engine home page in Oracle Enterprise Manager Middleware Control.

- Monitoring Request Breakdown Statistics

- Monitoring Deployed Service Components in the Service Engine

19.3.1 Monitoring Request Breakdown Statistics

You can assess the efficiency level of the Mediator service engine by monitoring the request breakdown statistics.

To monitor the request breakdown statistics of the currently deployed Mediator service components:

1. Access the Mediator Engine home page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > Mediator.

a. Right-click soa-infra.

b. Select Service Engines > Mediator.

The Mediator Engine home page appears.

2. Click the Statistics tab.

3. View the request breakdown statistics.

The Request Breakdown section provides information about the count and the average time taken for processing the following actions:

- Invoke One Way: One-way invocations from the Mediator service engine.

- Transformation: Transforming messages in the Mediator service engine.

- Enqueue: Dehydrating messages for parallel routing rules.

Note:

Dehydrating of messages means storing the incoming messages in the database for parallel routing rules for processing later by worker threads.

- Invoke: Request-response invocations from the Mediator Service Engine.

- Publish: Publishing events from the Mediator service engine.

- Condition Evaluation: Filtering conditions for evaluation by the Mediator service engine.

- Validation: Message validations by the Mediator service engine.

19.3.2 Monitoring Deployed Oracle Mediator Service Components in the Service Engine

You can monitor all deployed SOA composite applications with Mediator service components running in the service engine.

To monitor deployed Mediator components in service engines:

1. Access the Mediator Engine home page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > Mediator.

a. Right-click soa-infra.

b. Select Service Engines > Mediator.

2. Click the Deployed Components tab.
The Deployed Components page includes two sections. The upper section lets you search for the components to view and the lower section displays information about the components returned by the search.

3. In the Name column, click a specific service component to access its home page.

4. In the Composite column, click a specific SOA composite application to access its home page.

19.4 Monitoring Resequencing Groups

You can use the Mediator Resequencing Groups page to view and manage resequencing groups for the Mediator.

Note:

The Mediator Component page or Mediator Engine (service engine) page cannot be used to access, or configure, resequencer related information.

Use the Mediator Resequencing Groups page and the Flow Instances page to manage and monitor all Mediator resequencer groups, and to perform actions like fault recovery.

Resequencing enables the Mediator to have the out-of-sync messages put back into order. See "Resequencing in Oracle Mediator" in Developing SOA Applications with Oracle SOA Suite for details on resequencing.

To monitor resequencing groups:

1. Access the Mediator Resequencing Groups page through one of the following options:

- To monitor resequencing groups at the SOA Infrastructure level:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Resequencing Groups.

a. Right-click soa-infra (server_name).

b. Select Resequencing Groups.

The Mediator Resequencing Groups page appears. shows the Mediator Resequencing Groups page.

- To monitor resequencing groups at the individual partition level:

From the SOA Partition Menu of a Specific Partition...

From the SOA Folder in the Navigator...

a. Select Resequencing Groups.

a. Expand SOA > soa-infra (server_name).

b. Right-click a specific partition.

c. Select Resequencing Groups.

The Mediator Resequencing Groups page appears.

2. Select the time period to find all resequencing groups processed within the specified period.

3. Click Find Resequencing Groups. Details for all resequencing groups processed within the specified period are displayed. The details include the following:

- Group: Displays the resequencing group name. Click on any group name to see details like the last processed sequence ID, next sequence ID, and so on.

- Group Location: Displays the location for the resequencing group. The location comprises of the component name, composite name, and the name of the partition where the composite is deployed.

- Group State: Displays the state of the resequencing group. This can be one of Faulted, TimedOut, or Running.

- Last Processing Time: Displays the timestamp when a message in the group was last processed.

- Backlog Messages: Displays the number of pending messages for the resequencing group.

4. Click a group name to show the group details:

- If you click a Group with a Faulted Group State, the following group details are shown:

- Fault Time

- Failed Sequence ID

- Next Sequence ID to Process

You can click Search for Recoverable Instance to navigate to the Flow Instances tab where you can recover the faulted instance.

- If you click a Timed Out Group, the following group details are shown:

- Last Message Processing Time

- Last Processed Sequence ID

- Next Sequence ID to Process

You can click Skip to unlock the group and start processing the next available sequence ID.

- If you click a Running Group, the following details are shown:

- If the mediator's resequencer type is not Standard, then the following message is displayed:
Now processing the messages

- If the mediator's resequencer type is Standard, then the following details are shown:
* Last Message Process Time

* Last Processed Sequence ID

* Next Sequence ID to Process

You can click Skip to skip to the next available instance.

5. Click Flow Instances on the Mediator Resequencing Groups page to show the business flow instances corresponding to the group. See Tracking Business Flow Instances for details on working with the flow instances page.

6. Click Recoverable Instance to show the recoverable flow instances corresponding to the group. See Recovering from Faults in a Business Flow Instance for details on recovering from faults.

20 Managing Cross-References

This chapter describes how to delete obsolete information from cross reference tables. Cross references are used to associate identifiers for equivalent entities created in different applications.

This chapter includes the following topic:

- Deleting Cross-Reference Values

For more information about cross-references, see Developing SOA Applications with Oracle SOA Suite.

20.1 Deleting Cross-Reference Values

You can use the Cross References page to select tables and columns from which you want to delete the values.

To delete values from cross-reference tables:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > Cross References.

a. Right-click soa-infra.

b. Select SOA Administration > Cross References.

The Cross References page appears.

2. In the Select Tables and Columns section, select one of the following options:

- All tables: To delete values from all tables.

- Select a table and columns: To select either a specific table from which to delete values, or to select one or more columns from a specific table from which to delete values.

3. In the Select Values section, select one of the following options:

- All: To delete all values from the selected table and columns.

- Marked for delete: To delete only the values that have been marked for deletion from the selected table and columns.

- Updated between: To delete values updated between a specific time periods.

4. If you selected the Updated between option in the preceding step, enter a starting date in the From field and an ending date in the To field.

5. Click Delete.

Part VII Administering Decision Service Components and Business Rules Service Engines

This part describes how to administer Decision Service components and Business Rules service engines.

This part includes the following chapter:

- Monitoring Decision Service Service Components and Engine

21 Monitoring Decision Service Service Components and Engine

This chapter describes how to monitor Decision Service service components, including service engine performance statistics and deployed composites; business rule tracing; and log files. Decision Service service components are also called business rules service components in the Oracle Fusion Middleware documentation.

This chapter includes the following topics:

- Monitoring Business Rules Service Engine Performance Statistics

- Monitoring Business Rules Service Engine Deployed Components

- Monitoring Business Rule Tracing

- Monitoring Decision Service Service Component Logs

For information about business rules tuning and performance parameters, see Tuning Performance.

Note:

The business rules service engine does not support any user level configuration.

21.1 Monitoring Business Rules Service Engine Performance Statistics

Using the business rules service engine Statistics page, you can monitor business rules service engine performance and metrics. This page shows service engine-level, not component-level, details. Business rules service components are also called Decision Service service components in the Oracle Fusion Middleware documentation.

To monitor business rules service engine statistics:

1. Access the business rules service engine statistics page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Service Engines > Business Rules.

a. Select soa-infra.

b. Right-click and select Service Engines > Business Rules.

2. Click Statistics.
The Statistics page displays the following:

- Average Request Processing Time: This chart displays the average request processing time of the business rules service engine since server startup. That is, how many requests were processed by the service engine per unit of time.

- Business Rules Cache Statistics: This section provides details about the service engine cache. This section lists the types of caches used by the service engine and the object count in each of the caches. All these metrics are based on the object count since server startup.

- Business Rules Operation Statistics: This section shows the operation statistics. Using the operation statistics, you can determine the number of calls to Oracle Business Rules decision functions since server startup, and determine the total time spent in Decision Functions since server startup.

Note:

When you view business rules operation statistics for composite applications created with Oracle Fusion Middleware 11g Release 1 (11.1.1), the only operation shown is the callFunction operation. In this release, the Decision Service service only calls Oracle Business Rules using decision functions, and this operation is indicated with values for the operation named callFunction (with Count and Average(ms) fields). With composite applications that were migrated from older releases, the Decision Service service performs callFunction operations and the other operations listed in the Business Rules Operation Statistics section. For these migrated projects, you can debug the flow of the request through various important operations within the service engine. Also, you can find any long-running operations and take the necessary actions. These metrics also are since server startup.

For information about business rules tuning and performance parameters, see Tuning Performance.

21.2 Monitoring Business Rules Service Engine Deployed Components

Using the Deployed Components page, you can monitor all Decision Service service components deployed across SOA composite applications. Decision Service service components are also called business rules components in the Oracle Fusion Middleware documentation.

To monitor business rule service engine deployed components:

1. Access the business rules service engine Deployed Components page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Service Engines > Business Rules.

a. Right-click soa-infra.

b. Select Service Engines > Business Rules.

2. Click Deployed Components.
The Deployed Components page displays the following:

- A utility for searching for a specific component by specifying criteria and clicking Search.

- A list of components, including the name, the SOA composite application name, and the status (up or down).

3. In the Name column, click a name to navigate to the Component home page and view component details.

4. In the Composite column, click a specific SOA composite application to access its home page.

For more information, see Introduction to Service Components.

21.3 Monitoring Business Rule Tracing

You can use Oracle Enterprise Manager Fusion Middleware Control to perform rule execution tracing. For more information about accessing and using Fusion Middleware Control, see Getting Started with Administering and Oracle BPM Suite.

A rule execution trace is a mechanism of tracing business rules service engine events that occur during the evaluation of rules. The types of events traced are:

- Fact operations (assert, retract, and modify)

- Rules execution

- Rule activation

- Ruleset stack changes

- Rule compilation

- Reset (required for maintaining state during analysis)

Each trace contains information about the event that it traces. For example, a rule trace entry for an executed rule consists of:

- Rule name (RL name)

- Execution sequence number

- List of fact IDs for the facts that matched this rule

- Timestamp in milliseconds

Rule execution trace audit levels are the same as the audit levels supported in the SOA Infrastructure:

- Off: Rule execution tracing is disabled. The decision component instance is not created at all.

- Development: Full rule execution tracing that contains all the details about facts (listing, operations such as modify and assert), rule activation, pop or push rulesets, and so on. It also provides a list of fact IDs on which the executed rules are matched. See Tracing Rule Execution at the Development Audit Level for an example.

- Production: The executed rules are traced. All the details about facts, rule activation, pop or push ruleset are not available. The trace do not contain a list of the matching facts IDs. See Tracing Rule Execution at the Production Audit Level for an example.

You can set audit levels either at the SOA Infrastructure level or at the composite level. See Configuring SOA Infrastructure Properties for SOA Infrastructure audit level configuration information. See Introduction to the Order of Precedence for Audit Level Settings for a discussion about audit level precedence when set at the SOA Infrastructure level and the composite level.

The following sections discuss setting audit levels at the composite level for the purposes of rule execution tracing.

21.3.1 Tracing Rule Execution at the Development Audit Level

By setting the audit level to Development you can view all the details pertaining to a rule that has been executed.

To perform a development-level rule execution trace:

1. Open the composite application in Oracle Enterprise Manager Fusion Middleware Control.

A list of the recent business flow instances is shown on the composite Dashboard page.

2. Click the Settings list, select Composite Audit Level, > Development to set the trace level as Development at the composite level.

3. Click Yes in the Confirmation dialog.

4. Click Test and then click the name of the service to invoke a test instance of the business flow to view the decision traces corresponding to different input parameters.

5. Enter a value in the Value field in the Input Arguments section on the Test Web Service page and click the Test Web Service button.

Use the Load Payload field to add a payload file. Click Browse to locate the file and then click Save Payload to save the file.

Based on the input Order ID, the service invokes a BPEL process instance containing the details of the Order ID, and the rule that is relevant to the order details is executed.

6. Click Launch Flow Trace under the Response tab to open the Flow Trace page.

7. Click the Decision Service service component instance called RatingRules in the Trace section to view the actual rule execution trace.

Note:

You can also view the values of composite variables before and after invocation of business rule component. You must click the BPEL process component instance in the Flow Trace page, and then click the relevant payload. In this case, the BPEL component name is WlsRulesFaultProcess.

The execution trace for the Decision Service service component called RatingRules is shown.

8. Select the Show rule set stack states in audit trail check box to view further details of the rule execution.

Selecting this check box affects just the trace (the Rule Set Stack panel on the right hand side is not impacted). This check box hides or shows the pushed or popped steps. The default option is Hidden, which displays a more compact rendition of the audit trail.

The development-level trace report displays the fact name, activated rule, and the pushed and popped ruleset names.

The following table lists the entries of the trace report:

Element

Description

Invoked Decision Service Name

Displays the name of the Decision Service service component that is invoked.

Asserted Fact

There can be three types of asserted facts:

- Input fact

- Facts that get asserted as part of initial actions of a decision function

- Facts that get asserted during rule execution

Activated Rule

Displays the name of the rule that is activated, along with the name of the fact that activated the rule.

Pushed ruleset

Displays the name of the ruleset that has been invoked when the fact is asserted.

Fired rules in Ruleset

Displays the name of the ruleset whose rule is executed.

Fired rule

Displays the name of the rule that is executed.

Modified fact

Displays the name of the fact that has been modified because of the rule execution. This modified fact is then passed by the Decision Service service component to the BPEL service.

Popped ruleset

Displays the name of the ruleset for which execution is complete and so, the ruleset is taken out of the execution queue.

Note:

The entry Invoked Decision Service Name appears differently in different scenarios:

- For AS10.1.3.x to AS11 upgraded rules dictionaries with AssertExecuteWatch patterns, the entry appears in the trace report as Invoked Decision Service.

- For AS10.1.3.x to AS11 upgraded rules dictionaries with CallFunction patterns, the entry appears in the trace report as Invoked Decision Function.

- For AS11 created dictionaries, the entry is displayed as Invoked Decision Function.

Click the nodes of the execution trace to see the corresponding engine state in the Business Rules: Engine State section of the page. This section contains the following panels:

Facts in Working Memory: This panel displays the tree of objects that have been asserted and are currently being reasoned on by the service engine. These objects can lead to subsequent rule activations or firings and are the ones that can be modified or retracted as part of rules.

Rule Set Stack: This panel displays which rulesets are currently in the stack and which one of those is at the top of the stack. Once all activated rules within that ruleset are fired, the next ruleset goes to top of stack and the first ready-to-fire rule in that ruleset is fired next.

Rule Activation: This panel displays the list of rules that have fired as well as those that have been activated but not yet fired.

A rule can be activated but not fired if the ruleset that contains the rule is not at the top of the stack or if there is a rule in the same ruleset that is deemed to have a higher priority according to the service engine's conflict resolution semantics.

21.3.2 Tracing Rule Execution at the Production Audit Level

Setting the audit level to Production provides a truncated report on the rule execution trace. It only displays the ruleset and the rules that have been fired and does not display details about facts, rule activation, and so on.

The process of production-level tracing is similar to the development-level tracing. However, for Production-level tracing, you must do the following:

In Fusion Middleware Control, after opening the composite, select Production from the Composite Audit Level of the Settings menu.

Figure 21-1 shows the Flow Trace page that displays the trace report.

Figure 21-1 Flow Trace Audit Trail - Production

The Production-level trace report contains only the name of the ruleset and the rules that were fired. In addition, the Show rule set stack states in audit trail check box that provides a drill-down detailed trace report is unavailable in the Production-level trace report.

21.4 Monitoring Decision Service Service Component Logs

You can monitor Decision Service service component logs. Decision Service service components are also called business rules service components in the Oracle Fusion Middleware documentation.

21.4.1 Viewing Decision Service Service Component Logs

To view Decision Service service component logs:

1. In the navigation tree, select and right-click soa-infra.

2. Select Logs > View Log Messages. This displays the Log Messages page.

The Log Messages page opens. Use this page to select target log files.

21.4.2 Setting the Diagnostic Logging Level with a Log Configuration

Use the Log Configuration page to configure the logging level.

To set the diagnostic logging level with a log configuration:

1. Right-click soa-infra, and select Logs > Log Configuration.

2. To configure the Decision Service service component logging level, expand the oracle.soa.service.rules and the oracle.soa.services.rules.obrtrace loggers and set the notification level.

Part VIII Administering Human Task Service Components and Human Workflow Service Engines

Learn how to administer human task service components and human workflow service engines

- Configuring Human Workflow Service Components and Engines

- Monitoring Human Workflow Service Components and Engines

- Managing Human Workflow Service Components and Engines

22 Configuring Human Workflow Service Components and Engines

Learn how to configure human workflow service components and the human workflow service engine, including how to configure the notification mode for messages and actionable addresses. Also learn how to configure workflow service properties such as the actionable email account name and an alternative authentication provider such as Oracle Internet Directory, Microsoft Active Directory, or Oracle iPlanet.

- Configuring Human Workflow Notification Properties

- Configuring the Notification Service to Send Notifications to a Test Address

- Configuring Human Workflow Task Service Properties

- Configuring Oracle HTTP Server for Task Form Attachments

- Configuring the Pluggable Notification Service

- Globally Disabling the Automatic Release Timers for Tasks

- Configuring the Number of Email Notification Messages

- Configuring Multiple Send Addresses

- Configuring Notification Retries

- Configuring the Identity Service

- Seeding Users_ Groups_ and Application Roles using LDAP Tools

- Enabling Case Agnostic Group Names in Human Tasks

- Configuring Security Policies for Human Workflow Web Services

For information about installing and using the organizational hierarchy of users and groups known as the demo user community, see Installing the Demo User Community in the Database.

For more information about human workflow tuning and performance properties, see Tuning Performance.

22.1 Configuring Human Workflow Notification Properties

You can configure human workflow notification properties, such as setting the notification mode for messages and setting actionable addresses. These properties are used to notify users of changes to the state of a task.

Workflow notifications can use three types of addresses:

- From address: For sending notifications.

- Actionable address: For receiving actionable responses.

- Reply to address: For receiving reply notifications.

Note:

In the following procedures, you must configure your channel drivers before configuring your workflow notification properties. Ensure that you know all necessary driver addresses before beginning (for example, the incoming IMAP and outgoing SMTP email servers).

To configure human workflow notification properties:

1. Access this page using one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > Workflow Properties > Mailer tab.

a. Right-click soa-infra.

b. Select SOA Administration > Workflow Properties > Mailer tab.

The Workflow Notification Properties page appears.

You now configure Oracle User Messaging Service to send and receive notifications. During configuration, you provide the addresses that are used by human workflow.

2. Click Go to the Messaging Driver Page.
The Messaging Drivers page is displayed.

3. Go to the Associated Drivers section.

4. In the Configure Driver column of the Local tab, select the driver to configure. For this example, the User Messaging Email Driver is selected.

This takes you to the Email Driver Properties page for the selected messaging service driver.

5. Click the Create icon.

This takes you to the Create Driver Properties page to configure the selected messaging service driver.

6. See the following section based on the messaging service driver you selected in Step 4.

For This Driver...

See...

Messaging Extension

Section 26.4.1.3, "Configuring the Messaging Extension Driver."

Note: This driver is not selectable from the Local tab, but is available for configuration.

Email

"Configuring the Email Driver" of Administering Oracle User Messaging Service

SMPP

"Configuring the SMPP Driver" of Administering Oracle User Messaging Service

XMPP

"Configuring the XMPP Driver" of Administering Oracle User Messaging Service

VoiceXML

"Configuring the VoiceXML Driver" of Administering Oracle User Messaging Service

Proxy

Section 26.4.1.9, "Configuring the Proxy Driver" of Administering Oracle User Messaging Service

For example, if you selected the email driver, properties such as the following are displayed for you to configure:

- Incoming IMAP and outgoing SMTP email servers.

- Outgoing server user names and passwords.

- List of sender addresses and the default sender address. (The addresses you specify for these properties must match the addresses you specify in the Email: From Address and Email: Actionable Address fields of the Workflow Notification Properties page.)

For handling incorrect email responses, the email driver should be configured to handle incoming mail. This action enables human workflow participants to receive and forward notifications. Messaging drivers support the various messaging transports.

Note:

- The hostname and IP address of the email server with which you configure must also be added to the /etc/hosts file of the server on which Oracle SOA Suite is running. For example, if the hostname is xyz.example.com and the IP address is aa.bb.cc.dd, then add this information to the /etc/hosts file.

- After you configure the inbound (IMAP) email server, the outbound (SMTP) email server, or both, you must restart the managed Oracle WebLogic Server on which the SOA Infrastructure is configured for these setting to take effect.

7. Click Apply when driver configuration is complete.

8. Return to the Workflow Notification Properties page.

9. Specify the mode of the notification service. The values are:

- ALL: The email, short message service (SMS), instant message (IM), and voice channels are configured and notification is sent through any channel that you use.

- EMAIL: Only the email channel is configured for sending notification messages.

- NONE: No channel is configured for sending notification messages. This is the default setting.

10. Specify notification channel values:

Field

Description

Example

Email: From Address

Enter the outgoing email address from which end users receive notifications.

The address you specify must match the sender addresses and the default sender address that you specify on the Email Driver Properties page of the Oracle User Messaging Service.

Note: You can only receive error messages when the outgoing email address is also configured to receive incoming messages. This ensures that error messages from incorrect or nonexistent email addresses are captured by the server. Even if you configure a separate incoming account in the Email: Reply To Address field, error messages do not appear in the server logs.

It is best practice to have From Address pointing to outgoing email address in the Email Driver Properties page.

workflow.notifications@mycompany.com

Email: Actionable Address

Enter the incoming email address for performing task actions. The actionable email account is the account in which task action-related emails are received and processed by human workflow.

The address you specify must match the receiver addresses that you specify on the Email Driver Properties page of the Oracle User Messaging Service.

workflow.actions@mycompany.com

Email: Reply To Address

Enter the address to display in emails sent out from Oracle SOA Suite. It can be a dummy address such as no.reply@mycompany.com or a valid address. If a valid address is provided, and configured in the Messaging Driver page, then if a user replies to actionable email address, human workflow sends an automated email indicating the correct usage. This is another incoming email account.

It is best practice to have this email account set to something other than Actionable email address on the Email Driver Properties page. (If it is set same as Actionable email address then auto reply or any reply to email notifications will be processed by workflow engine and at times will be responded back to as unsolicited email).

workflow.no.reply@mycompany.com

11. Click Apply.

12. To configure advanced notification properties in the System MBean Browser, click More Workflow Notification Configuration Properties. Properties that are displayed include, but are not limited to, the following. Descriptions are provided for each property.

- ASNSDriverIMAddress: The address at which to receive incoming instant messages (IMs).

- CustomNSDriverPropertyNames: Returns custom notification services property names.

- FaxCoverPageCount: The return number of configured fax cover pages.

- RetryNotificationMessageThrottle: The number of email notification messages that can be processed during notification retry cycles. For more information, see Configuring the Number of Email Notification Messages.

13. Make changes appropriate to your environment.

Note:

If your IM message contains content that appears to be actionable, then acting upon the task from within the message does not cause any action to be taken. For example, acting upon the task in the following IM message does not cause any action to occur.

Help desk request for wfaulk  Task Help desk request for  wfaulk
requires your attention.  NOTE: You can act on the task by
copy-pasting one of following  lines as your response.

RESOLVED : [[NID]] :
Pt12uRUu9H+Xem4NYS2o7dKDtqNLs42d4YIs8ySO8Gn0ZVYFsb1SQVenRukRE+
IcE7c4XDb+tPazvP v9T2iA0qylDg0bTaVxX13HhsrCYAg= : [[NID]]
UNRESOLVED : [[NID]] :
xT9l06rbaGRAey+BtgQyJIXk62mkFtCe7ocKxwNLIsPzyE5/7AnGwXlBodEgQxr6
jorvsw2F54k/C1 r5mvyAJpAp4I4IekOHi4qhQ3eSbBHdzET1IL4F3qV/KZ/BAUsq :
[[NID]]

For information about managing incoming and outgoing notifications through email in human workflow, including testing that outgoing messages are arriving at the correct destination, see Managing Outgoing Notifications and Incoming Email Notifications.

For more information about notifications and the User Messaging Service, see the following documentation:

- Administering Oracle User Messaging Service

- Developing Applications with Oracle User Messaging Service

22.2 Configuring the Notification Service to Send Notifications to a Test Address

You can configure the Oracle Human Workflow Notification Service to send all notifications to a test address instead of to a production address.

Use the System MBean Browser in Oracle Enterprise Manager to configure.

To configure the Notification Service to send notifications to a test address:

1. Navigate to the System MBean Browser in Oracle Enterprise Manager. From the SOA Infrastructure Menu select Administration > System MBean Browser. Or
From the SOA Folder in the Navigator, right-click soa-infra, Select Administration > System MBean Browser.

2. Search for the HWFMailerConfig Mbean. To do this click the Find icon in the System MBean Browser navigator pane. From the Find list, select MBean Name, and, in the text box to the right of the list, enter HWFMailerConfig. Click the Find arrow.
The corresponding information appears in the right pane.

3. Select the Operations page. To set a test address:

a. In the Operations page, select addTestNotificationAddress. The Operation: addTestNotificationAddress page appears.

b. In the Parameters table, in the Channel row, in the Value column, specify the channel through which to send notifications, for example, Email, SMS, FAX, IM, Voice, Pager.

c. In the Parameters table, in the testNotificationAddress row, in the Value column, enter the address of the test recipient, for example, testAddress@yourDomain.com.

d. Click Invoke.

e. Shut down and restart the SOA server in order for the change to take effect.

Note that in the Enterprise Manager notification management screen, the original email address is still displayed as the To address.

The test user can respond to any actionable emails. Ensure that the test email address belongs to a user in the Identity store so that it is verified as part of response email processing.

When the notification service is initialized with a test address and the recipient address is switched with the test address, a Warning is written to the log. This can be useful to identify an incorrect configuration of the test notification address.

22.2.1 How to Remove a Test Address

To remove a test address:

1. In the Operations page, select removeTestNotificationAddress. The Operation: removeTestNotificationAddress page appears in the right pane.

2. In the Parameters table, in the Channel row, in the Value column, specify the channel you want to remove for the notification, for example, Email, SMS, FAX, IM, Voice, Pager.

3. Click Invoke.

22.3 Configuring Human Workflow Task Service Properties

You can assign the actionable email account name, specify workflow session timeout and custom class path URL properties values, configure dynamic assignment and task escalation functions of the assignment service, and set additional human workflow properties.

Dynamic assignment functions select a particular user, group, or application role from a group or application role, or a list of users, groups, or application roles. The selection is made according to criteria specific to the particular dynamic assignment function.

To configure human workflow task service properties:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > Workflow Properties > Task tab.

a. Right-click soa-infra.

b. Select SOA Administration > Workflow Properties > Task tab.

The upper part of the Workflow Task Service Properties page displays the field for the actionable email account and the pre-defined dynamic assignment functions.

2. Enter the following details.

Function

Description

Actionable Email Account

Enter the incoming, actionable email account to use.

The default account name is Default, which is the account configured in Configuring Human Workflow Notification Properties. If a different account name is specified in this field, then create and configure the account as described in Configuring Multiple Send Addresses.

Workflow Service Session Timeout (in minutes)

Enter the length of time that users logged in to Oracle BPM Worklist can remain inactive before their session expires, and they are required to log in again. This also applies to authenticated sessions created through one of the TaskQueryService authentication methods.

Workflow Custom Classpath URL

Enter the URL class path. This is the class path used by workflow services to look up classes implementing custom dynamic assignment and task escalation functions, custom callbacks, and customized instances of the system resource bundle, WorkflowLabels.properties.

This can be any valid URL (either a local file path or remote URL). The class path can specify either a directory or a JAR file. The URL must include the protocol; for a class path on the local filesystem, the file protocol must be specified, such as 'file:///example/directory/'.If the URL specifies a directory, it must include a trailing slash ('/') character.

The classpath can consist of more than one URL; each URL in the classpath can be delimited with a comma character (',').

3. Go to the Dynamic Assignment and Task Escalation Functions section.
The dynamic assignment functions are defined in the following table. You can also create your own functions and register them with the workflow service.

Function

Type

Description

MANAGERS_MANAGER

Task escalation

This function picks the manager's manager for the task.

ROUND_ROBIN

Dynamic assignment

This function picks each user, group, or application role in turn. This function uses the initialization parameter MAX_MAP_SIZE. This parameter specifies the maximum number of sets of users, groups, or roles for which the function can maintain ROUND_ROBIN counts. The dynamic assignment function holds a list of participants in memory for each group, role (or list of users, groups or roles) on which it is asked to execute the ROUND_ROBIN function.

LEAST_BUSY

Dynamic assignment

This function picks the user, group or role with the least number of tasks currently assigned to it.

MOST_PRODUCTIVE

Dynamic assignment

This function picks the user, group, or role that has completed the most tasks over a certain time period (by default, the last seven days). This function uses the initialization parameter DEFAULT_TIME_PERIOD. This parameter specifies the length of time (in days) over which to calculate the productivity. This value can be overridden when calling the MOST_PRODUCTIVE dynamic assignment function.

4. Click a function to display its parameters and values in the Parameters section.

5. Click Add to add a function. You are prompted to specify the following:

- Function name

- Class path

- Function parameter name

- Function parameter value

6. Click OK.

7. To update the value of a parameter in a function, select the function in the Dynamic Assignment and Task Escalation Functions table.
The parameter value is displayed for editing.

8. Update the value.

9. Expand the Advanced section.
The Advanced section displays the following properties:

These properties are defined in the following table.

Properties

Description

Worklist Application URL

In the emails that are sent for tasks, the link to Oracle BPM Worklist is read from this property.

This element identifies the URL. Configuring this is useful if the custom Oracle BPM Worklist is built. The tag PC_HW_TASK_ID_TAG in this URL is replaced with the task ID when constructing the URL for the email.

Pushback Assignee

A task can be pushed back to the previous approver or previous initial assignees. The original assignees may not be the approver because they may have reassigned the task, escalated the task, and so on. The possible values for this element are INITIAL_ASSIGNEES and APPROVER.

Portal Realm Mapping

This property is used when authenticating a user from an HTTP servlet request through the task query service method createContext (for example, when Oracle BPM Worklist runs in a single sign-on (SSO) environment). The HTTP servlet request does not carry information about the identity service realm to which the remote user belongs; this parameter is used to configure which realm to use to authenticate the user in an HTTP servlet request remote user.

Note: This property is no longer used and therefore, must not be altered.

Task Auto Release Configuration

When a task is assigned to a group, application role, or multiple users, a user must first acquire the task before working on it. After the task is acquired, other users cannot work on the task. If a user acquires a task, but does not act on it, the task is eventually automatically released, allowing other users to acquire the task. This prevents a user from acquiring tasks, then forgetting to work on them. This prevents others from working on them. Task automatic release enables you to configure the time period that elapses after a user acquires a task and before the system automatically releases the task and makes it available again to other users. The automatic release durations can be configured as a default duration and as a percentage of the expiration duration of a given task. The automatic release durations can also be configured differently for tasks of different priority.

For example, assume the task automatic release duration for priority 2 tasks is set to 50%, with a default duration of 12 hours. If a priority 2 task is set to expire in two days, the task is automatically released after one day (which is 50% of the expiration duration). If no expiration date is set for the task, then the task is automatically released after 12 hours (which is the default automatic release duration).

10. Make changes appropriate to your environment.

11. Click Apply.

12. To configure advanced task service properties in the System MBean Browser, click More Workflow Taskservice Configuration Properties. See Step 12 of Configuring Human Workflow Notification Properties for a list of some advanced properties that are displayed.

13. Make changes appropriate to your environment.

For more information about the task service and assignment service, see Developing SOA Applications with Oracle SOA Suite.

22.4 Configuring Oracle HTTP Server for Task Form Attachments

When adding an attachment to the task form through Oracle HTTP Server (OHS), include the location, /ADFAttachmenthelper, in the OHS configuration.

For example, add the following to the mod_wl_ohs.config file of OHS, under instance_home/config/OHS/ohs_instance:

<Location /ADFAttachmentHelper>
SetHandler weblogic-handler
PathTrim /weblogic
ErrorPage  http:/WEBLOGIC_HOME:WEBLOGIC_PORT/
</Location>

22.5 Configuring Oracle Advanced Queuing for Oracle Human Workflow Notifications

Understand how to configure Oracle Advanced Queuing for Oracle Human Workflow Notifications.

To configure Oracle Advanced Queuing for Oracle Human Workflow notifications, set the managed bean property UseAQ under the HWFMailer configuration in Oracle Enterprise Manager Fusion Middleware Control to TRUE. Restart the SOA server.

After the server restarts, new notification messages are enqueued onto Oracle Advanced Queuing. Pending messages in the JMS queue are enqueued onto Oracle Advanced Queuing by the notification retry thread.

22.6 Configuring the Pluggable Notification Service

You can plug in and use custom notification service implementations instead of the default notification service providers.

You can plug in a custom notification service for all channels or selectively for specific channels. For example, the notification service provides the ability to plug in an existing SMS implementation instead of the default SMS notification service.

22.6.1 Pluggable Notification Service Implementation

To plug in a notification service, perform one of the following tasks:

- Implement interface oracle.bpel.services.notification.ICustomNotificationService

- Extend the abstract class oracle.bpel.services.notification.AbstractCustomNotificationServiceImpl.

This interface has methods for the following channels:

- Email

- Voice

- SMS

- IM

The plugged-in notification service can override the default providers for one or more channels. When the custom notification service is overriding the default implementation for a subset of channels, the methods corresponding to the other channels (channels that are not overridden) are not called by the notification service. Those methods can just return a null value. Alternatively, the implementation can extend the following abstract class:

oracle.bpel.services.notification.AbstractCustomNotificationServiceImpl

This class provides empty implementations for each of the channels. In that case, the implementation can just extend the methods for the appropriate channels.

The implementation and its dependent classes must be available in the class path of Oracle WebLogic Server.

22.6.2 Pluggable Notification Service Registration

After the implementation is available, you register it in the System MBean Browser.

To register the pluggable notification service:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. In the navigator, expand the SOA folder.

3. Right-click soa-infra, and select Administration > System Mbean Browser.

The System MBean Browser is displayed on the right side of the page.

4. Expand Application Defined MBeans > oracle.as.soainfra.config > Server: server_name > HWFMailerConfig > human-workflow.

5. Click the CustomNSDriverPropertyNames property on the right side of the page.

6. Record the values displayed by CustomNSDriverPropertyNames for the All, Voice, Email, Fax, Pager, SMS, and IM properties.

7. Click Return.

8. Click the Operations tab.

9. Click setCustomNSDriverPropertyValue.

10. In the Value field for propertyName, enter one of the values you noted down for the All, Voice, Email, Fax, Pager, SMS, and IM properties on the CustomNSDriverPropertyNames page. Note the following details:

- If you are overriding the default implementation for only the email channel, use the Email value in the Value field for propertyName and the complete class name of your implementation in the Value field for propertyValue.

- The override for other channels is configured the same way as the email channel.

- Using the value of the All property in the Value field for propertyName refers to an implementation for all specified channels.

11. In the Value field for propertyValue, provide the complete class name of your implementation.

12. Click Invoke.

13. Restart Oracle WebLogic Server.

22.7 Globally Disabling the Automatic Release Timers for Oracle BPM Worklist Tasks

If automatic release timers are enabled for all Oracle BPM Worklist tasks and this is creating overhead for the database and JVM, you can globally disable the timers.

To globally disable the automatic release timers for Oracle BPM Worklist tasks:

1. Right-click soa-infra, and select Administration > System Mbean Browser.

The System MBean Browser is displayed on the right side of the page.

2. Expand Application Defined MBeans > oracle.as.soainfra.config > Server: server_name > WorkflowConfig > human-workflow > WorkflowConfig.TaskAutoReleaseConfiguration.

3. Select the task priority to modify. Each task instance has a priority.

- Priority[1]

- Priority[2]

- Priority[3]

- Priority[4]

- Priority[5]

4. In the Attributes tab, click DefaultDuration.

5. In the Value field, enter P0D to indicate zero days. The default value is P1D (one day).

6. Click Apply.

7. Perform Steps 3 through 6 for any remaining priorities for which you want to disable automatic release.

When complete, the automatic release timers for newly created task instances with the priority you modified are disabled.

22.8 Configuring the Number of Email Notification Messages

You can control the number of email notification messages that can be processed during notification retry cycles with the System MBean Browser RetryNotificationMessageThrottle property. This property prevents the overloading of messages in the queue and reduces the memory size of the notification message payload.

To configure the number of email notification messages:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > Workflow Properties

a. Right-click soa-infra.

b. Select SOA Administration > Workflow Properties

2. Click More Workflow Notification Configuration Properties.

3. Click RetryNotificationMessageThrottle.

4. In the Value field, enter a value. The default is 200000 messages.

5. Click Apply.

22.9 Configuring Multiple Send Addresses

It may be necessary in some processes to distinguish email notification based on the from address of the email. For example, a human resources BPEL process sends emails with the from address set as HR@yourcompany.com, while a finance BPEL process sends emails with the from address set as finance@yourcompany.com.

To configure multiple send addresses:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. In the navigator, expand the SOA folder.

3. Right-click soa-infra, and select Administration > System Mbean Browser.

The System MBean Browser is displayed on the right side of the page.

4. Expand Application Defined MBeans > oracle.as.soainfra.config > Server: server_name > HWFMailerConfig > human-workflow.

5. Under the Attributes tab, record the value of the ASNSDrivers attribute. By default, only the Default value is available.

6. Click Return.

7. Click the Operations tab.

8. Click setASNSDriver.

9. For propertyName, enter a value (for this example, EmailFromAddress).

10. For propertyValue, enter a value (for this example, HR@yourcompany.com).

11. For driverName, enter a value (for this example, HR).

12. Click Invoke.

13. Add as many accounts as the number of from addresses needed:

- For propertyName, enter a value (for this example, EmailFromAddress).

- For propertyValue, enter a value (for this example, finance@yourdomain.com).

- For driverName, enter a value (for this example, Finance).

14. Click Invoke.

The ASNSDriver attribute now shows all the accounts created in the previous steps and the getASNSDriverAddresses operation now shows the addresses being used for each of the drivers. For more information, see Section "Configuring Oracle User Messaging Service" of Administering Oracle User Messaging Service.

15. Using Oracle WebLogic Server Administration Console, install multiple Oracle User Messaging Service email drivers, one for each from address.

16. Configure the email drivers to use the required from address for sending outgoing emails.

17. In Oracle JDeveloper during design time, use HR as the account name to configure an email activity for an HR BPEL process and Finance as the account name to configure an email activity for the finance BPEL process.

22.10 Configuring Notification Retries

Oracle SOA Suite provides support for reliable notifications.

The outbound notification creates a notification message with a unique notification ID and stores the message and unique ID in the dehydration store. It then enqueues this unique ID in the JMS queue and commits the transaction.

A message-driven bean (MDB) listening on this queue dequeues the message and sends a notification to the user. If there is any notification failure, the notification retries three times. If the retries all fail, it marks this notification as being in error.

22.11 Configuring the Identity Service

By default, the identity service uses the embedded LDAP server in Oracle WebLogic Server as the default authentication provider. You can, however, configure Oracle WebLogic to use an alternative authentication provider, such as Oracle Internet Directory, Microsoft Active Directory, or Oracle iPlanet, along with the default authenticator.

Note:

For more information on configuring and using Oracle Virtual Directory plug-ins, see Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory, "Understanding Oracle Virtual Directory Plug-Ins".

Learn how to add an authentication provider and create users and groups in the authentication provider using either Oracle WebLogic Administration Console or Oracle Directory Services Manager.

For more information on configuring multiple LDAP authentication providers, see Securing Applications with Oracle Platform Security Services, "Configuring the Identity Store Service"

- Adding an Authentication Provider

- Creating Users and Groups in the Authentication Provider

- Configuring the Directory Service

For information about installing and using the organizational hierarchy of users and groups known as the demo user community, see Installing the Demo User Community in the Database.

Note:

Oracle Fusion Middleware supports providers that enable the User and Role API to interact with custom identity stores.

For more information, see Chapter "Developing with the User and Role API" of the Securing Applications with Oracle Platform Security Services.

22.11.1 Adding an Authentication Provider

You can add an authentication provider to a security realm using the Oracle WebLogic Server Administration Console.

To add an authentication provider:

1. Log in to the Oracle WebLogic Server Administration Console.

2. Click Security Realms in the Domain Structure pane, and click the name of a realm in the list (myrealm, for example).

3. Click Providers, Authentication.

The Authentication Providers page appears.

4. Click New to add a new authentication provider.

The Create a New Authentication Provider page appears.

5. In the Name field, type a name for the provider, choose the authenticator type using the Type drop-down list, and click OK.

For example, you can type OIDAuthenticator as the name and choose OracleInternetDirectoryAuthenticator as the type for a provider that authenticates users using the Oracle Internet Directory.

Similarly, you can type a name and choose ActiveDirectoryAuthenticator, iPlanetAuthenticator, openLDAPAuthenticator, or NovellAuthenticator from the list to specify the corresponding authenticator.

Note:

When using Oracle Internet Directory as the authentication provider, you must set the orclsslinteropmode attribute to 0 (zero) using Oracle Directory Services Manager. See Configuring the Directory Service for more information.

6. On the Providers > Authentication page, click the authenticator that you just created.

The settings for the authentication provider appears.

7. From the Control Flag drop-down list, choose SUFFICIENT, and click Save.

This specifies that if a user is authenticated successfully using this authenticator, WebLogic should accept the authentication and not continue to invoke any additional authenticators. If the authentication fails, Oracle WebLogic Server attempts to authenticate the user using the next authenticator in the list.

If you set the Control Flag to SUFFICIENT, ensure that all subsequent authenticators also have the Control Flag set to SUFFICIENT. Likewise, ensure that the Control Flag of the default authenticator is set to SUFFICIENT as well.

8. Click Provider Specific to enter the details for the authenticator server.

9. Enter the provider-specific information about the authentication provider, check the Use Retrieved User Name as Principal check box, and click Save.

You must specify the following information. Use the default setting for the rest of the fields.

Field

Description

Host

The hostname or IP address on which the authenticator server is running.

Port

The port number on which the authenticator server is running.

Principal

The Distinguished Name (DN) of the authenticator server user that Oracle WebLogic Server should use when connecting to the server.

Credential

The credential (usually a password) used to connect to the authenticator server.

User Base DN

The base Distinguished Name (DN) of the tree in the LDAP directory that contains users.

Group Base DN

The base Distinguished Name (DN) of the tree in the LDAP directory that contains groups.

Use Retrieved User Name as Principal

Specifies whether to use the user name retrieved from the LDAP server as the principal in the subject.

User Name Attribute

The attribute of an LDAP user object class that specifies the name of the user (for example, UID, CN, MAIL).

Note:

The same user name attribute must be used for the fields: All User Filter, User from Name Filter and User Name Attribute.

10. Click Security Realms > Providers > Authentication to return to the list of authentication providers.

11. Click Reorder.

The Reorder Authentication Providers page appears.

12. Select the new authentication provider, click the Up arrow to move the provider to the top of the list, and click OK.

After reordering, the DefaultAuthenticator should appear at the bottom of the list. This action enables the system to handle logins as weblogic that are not typically in an LDAP directory, but still must be authenticated to start the server.

If multiple authentication providers are configured, authentication falls through the list of authenticators according to the control flags set. But the Java Portlet Specification (JPS) provides authorization against only the first entry in the list of providers.

22.11.1.1 Updating the User Attribute

You can modify the settings of the authentication provider in Oracle WebLogic Server Administration Console to use your email address as your login user (user attribute). You must perform the following steps:

1. Log in to Oracle WebLogic Server Administration Console

2. Under the Domain Structure pane, select Security Realms. The Summary of Security Realms page appears with a list of available realms.

3. From the list, click the name of the realm you want to modify. The Settings tab for that realm appears

4. Select Providers, Authentication

5. In the Authentication tab, select the Authentication Provider you want to modify. The Settings tab for that Authentication Provider appears

6. Select Configuration, Provider Specific and update the following fields:

- All Users Filter: set value to (&(mail=)(objectclass=person)

- User From Name Filter: set value to (&(mail=%u)(objectclass=person))

- User Name Attribute: set value to mail

Note:

Note: The same user name attribute must be used for the fields: All User Filter, User from Name Filter and User Name Attribute.

7. Click Save.

22.11.1.2 Configuring Multiple Authentication Providers

Starting with 11.1.1.4, you can authorize users and groups from multiple authenticators. Add the following property to the idstore instance in the $DOMAIN_HOME/config/fmwconfig/jps-config.xml file:

<serviceInstance name="idstore.ldap"
provider="idstore.ldap.provider">
............................
<property name="virtualize" value="true"/>
..............................
</serviceInstance>

22.11.2 Creating Users and Groups in the Authentication Provider

You can create users and groups in the authentication provider using either Oracle WebLogic Server Administration Console or Oracle Directory Services Manager.

22.11.2.1 Creating Users Using WebLogic Console

You can create users for a specific provider, and define user membership, using the Oracle WebLogic Server Administration Console.

To create a user using WebLogic Console:

1. Log in to the Oracle WebLogic Console.

2. Click Security Realms in the Domain Structure pane, and click the name of a realm in the list (myrealm, for example).

3. Click Users and Groups > Users.

The Users page appears.

4. Click New to add a new user. The Create a New User page appears.

5. Enter the required information about the user, and click OK.

You must specify the following information.

Field

Description

Name

(Required) The name of the new user.

Description

A description of the new user.

Provider

The provider for the user.

Password

The password associated with the login name for the new user.

Confirm Password

Confirmation of the password.

The system creates the new user in the specified provider and shows the Users page. You can configure group membership for the user, as required.

6. To specify group membership for the user, click the newly-created user in the list. The settings for the new user page appear.

7. Click Groups to specify group membership for the user.

8. Select a group in the Available list and click the right arrow to move it to the Chosen list.

You can press Ctrl-Click to select multiple groups to move.

9. Click Save.

22.11.2.2 Creating Groups Using WebLogic Console

You can create groups for a specific provider, and define group membership, using the Oracle WebLogic Server Administration Console.

To create a group using WebLogic Console:

1. Click Users and Groups > Groups.

The Groups page appears.

2. Click New to add a new group. The Create a New Group page appears.

3. Enter the required information about the group, and click OK.

You must specify the following information.

Field

Description

Name

(Required) The name of the new group.

Description

A description of the new group.

Provider

The provider for the group.

The system creates the new group in the specified provider and shows the Groups page. You can configure group membership for the group, as required.

4. To specify group membership for the group (specify parent groups), click the newly-created group in the list. The settings for the new group page appear.

5. Click Membership to add the group to other groups.

6. Select a parent group in the Available list and click the right arrow to move it to the Chosen list.

You can press Ctrl-Click to select multiple groups to move.

7. Click Save.

22.11.2.3 Creating Users and Groups Using Oracle Internet Directory

You can create users and groups using Oracle Internet Directory through the Oracle Directory Services Manager.

To connect to Oracle Internet Directory from the Oracle Directory Services Manager:

1. Launch the Oracle Directory Services Manager by navigating to the following URL using a web browser:

http://host_name:port/odsm/faces/odsm.jspx

where host_name and port are the hostname and the managed server port number on which Oracle Internet Directory is running.

2. Click the Connect to a directory link and choose Create a New Connection in the drop-down menu. The New Connection dialog appears.

3. Select OID as the directory type, enter values in the required fields, and click Connect.

You can specify the following information.

Field

Description

Name

The name of the connection.

Server

(Required) The hostname or IP address of the system on which Oracle Internet Directory is running.

Port

(Required) The port number on the system on which Oracle Internet Directory is running.

SSL Enabled

Select to enable Secure Sockets Layer (SSL) communication.

User Name

(Required) The user name used to log in to Oracle Internet Directory.

Password

(Required) The password associated with the user name.

Start Page

The start page after logging into Oracle Internet Directory.

The Oracle Directory Services Manager Home page appears.

4. Click the Data Browser tab. You can use this page to create and remove entries.

22.11.2.3.1 How to Create a Domain

To create a domain:

1. Click the Create a new entry button in the Data Tree pane. The Entry Properties page of the Create New Entry wizard appears.

2. Click the Add button to add the required object class for the domain. The Add Object Class dialog appears.

3. Enter the name of the object class. When the correct object class appears in the Name list, select it, and click OK.

4. Repeat Steps 2 and 3 to add all the required object classes for the domain. Generally, top, domain, and orclContainer are the object classes required for a domain.

Note:

LDAP operations from Oracle SOA Suite can take a long time to complete if you do not index the correct LDAP attributes. The recommended searchable attribute list for indexing is cn, sn, givenName, uid, manager, title, mail, and telephoneNumber.

5. Click Browse to choose the parent of the domain. The Select Distinguished Name (DN) Path dialog appears.

6. Select the parent of the domain and click Select. You can create a hierarchy of entries by selecting the appropriate parent domains.

7. Click Next in the Create New Entry dialog. The Mandatory Properties page of the Create New Entry wizard appears.

8. Enter and select values for the required fields, and click Next.

You can specify the following information.

Field

Description

dc

(Required) The domain component.

Relative Distinguished Name

(Required) The relative distinguished name of the user.

The Status page of the Create New Entry wizard appears.

9. Verify the status of the new domain, and click Finish to create the new domain.

22.11.2.3.2 How to Create a User

To create a user:

1. Click the Create a new entry button in the Data Tree pane. The Entry Properties page of the Create New Entry wizard appears.

2. Click the Add button to add the required object class for the user. The Add Object Class dialog appears.

3. Enter the name of the object class. When the correct object class appears in the Name list, select it, and click OK.

4. Repeat Steps 2 and 3 to add all the required object classes for the user. Generally, top, person, inetorgperson, organizationalPerson, and orcluser are the object classes required for a user.

5. Click Browse to choose the parent of the user. The Select Distinguished Name (DN) Path dialog appears.

6. Select the parent of the user and click Select.

7. Click Next in the Create New Entry dialog. The Mandatory Properties page of the Create New Entry wizard appears.

8. Enter and select values for the required fields, and click Next.

Specify the following information.

Field

Description

cn

(Required) The common name.

sn

(Required) The surname (last name).

Relative Distinguished Name

(Required) The relative distinguished name of the user.

The Status page of the Create New Entry wizard appears.

9. Verify the status of the new user, and click Finish to create the new user.

10. Click the entry for the newly-created user in the Data Tree pane. The Person page for the user appears.

11. Enter details about the user, and click Apply.

22.11.2.3.3 How to Create a Group

To create a group:

1. Click the Create a new entry button in the Data Tree pane. The Entry Properties page of the Create New Entry wizard appears.

2. Click the Add button to add the required object class for the group. The Add Object Class dialog appears.

3. Enter the name of the object class. When the correct object class appears in the Name list, select it, and click OK.

4. Repeat Steps 2 and 3 to add all the required object classes for the group. Generally, top, groupOfUniqueNames, and orclGroup are the object classes required for a group.

5. Click Browse to choose the parent of the group. The Select Distinguished Name (DN) Path dialog appears.

6. Select the parent of the group and click Select.

7. Click Next in the Create New Entry dialog. The Mandatory Properties page of the Create New Entry wizard appears.

8. Enter and select values for the required fields, and click Next.

Specify the following information.

Field

Description

cn

(Required) The common name.

Relative Distinguished Name

(Required) The relative distinguished name of the group.

The Status page of the Create New Entry wizard appears.

9. Verify the status of the new group, and click Finish to create the new group.

10. Click the entry for the newly-created group in the Data Tree pane. The Group page for the group appears.

11. Specify details about the group, and click Apply.

22.11.2.3.4 How to Delete an Entry

To delete an entry:

1. Select an entry in the Data Tree pane.

2. Click the Delete this entry button in the Data Tree pane.

22.11.3 Configuring the Directory Service

When using Oracle Internet Directory as the authentication provider, you must set the orclsslinteropmode attribute to 0 (zero) using Oracle Directory Services Manager.

Note:

If the GUID attribute in the LDAP server is set to a binary value, which cannot be properly handled in the identity service, you must map it to a unique attribute that exists in both the user and group object classes and cannot have a binary value. For example, if the cn attribute is unique, it can be used because it satisfies both of these requirements.

You map GUID to cn in the jps-config.xml file:

<property value="GUID=cn" name="PROPERTY_ATTRIBUTE_MAPPING"/>

For more information about identity store attribute mapping, see Chapter "Developing with the User and Role API" of the Securing Applications with Oracle Platform Security Services.

To configure the directory service:

1. Launch Oracle Directory Services Manager and choose an Oracle Internet Directory connection using the drop-down list.

2. Click the Data Browser tab.

3. Expand the cn=subconfigsubentry > cn=osdldapd > cn=oid1 nodes.

4. In the Attributes page, set the orclsslinteropmode attribute to 0.

5. Click the Apply button.

22.11.4 Customizing the Identity Provider

To customize the identity provider (for example, to handle user and role information stored in home grown solutions), visit the following URL:

http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.html

22.12 Seeding Users, Groups, and Application Roles using LDAP Tools

Get an overview of the procedures required for seeding users, groups, and application roles with LDAP tools.

When you create a task, you assign humans to participate in and act upon the task. Participants can perform actions upon tasks during runtime from Oracle BPM Worklist, such as approving a vacation request, rejecting a purchase order, providing feedback on a help desk request, or some other action. There are three types of participants:

- Users

- Groups

- Application roles

For more information, see Developing SOA Applications with Oracle SOA Suite.

22.12.1 Changing the Default Password in the Embedded LDAP Server

The password credential is accessible from the Oracle WebLogic Server Administration Console by selecting Security > Embedded LDAP for your domain.

For instructions on changing the default password credential, see Chapter 9, "Managing the Embedded LDAP Server" of Administering Security for Oracle WebLogic Server.

22.12.2 Seeding Users or Groups through the LDAP Browser

To seed users or groups through the LDAP browser:

1. Start an LDAP browser (for example, openLdap browser, ldapbrowser, jXplorer, and so on). See the documentation for your browser for instructions.

2. Connect to the LDAP server by providing the hostname, port number on which the server is running, and the administration user credentials with which to log in.
For Embedded LDAP

a. The default managed server port number is 7001.

b. The administration credential username is cn=admin.

c. The administration credential password is what you set in Changing the Default Password in the Embedded LDAP Server.

For OIDm

a. The default port number is 3060.

b. The administration username is cn=orcladmin.

c. The administration password is the password for the LDAP server.

3. Seed a user or group through the browser by performing the following steps:

a. Select a parent under which to add a user or group.

b. Select the Edit menu and choose an appropriate option to add a new entry.

c. Enter all required attribute values for the entry.

4. Seed users or groups through the LDIF file by performing the following steps:

a. Select the domain under which to seed the users or groups.

b. Select the LDIF menu and choose to import an LDIF file.

c. In the Import LDIF File dialog, browse for and select the LDIF file and click Import.
Similarly, the users or groups seeded on the LDAP server can be exported to an LDIF file by selecting the Export option from the LDIF menu.

5. Add attributes to the users or groups by performing the following steps:

a. Select an entry for which to add a new attribute.

b. Right-click and choose the option to add a new attribute.

c. In the Add Attribute dialog, provide the name and value of the attribute.
You can only add attributes that are defined in the LDAP server schema.

6. Delete attributes for users or groups by performing the following steps:

a. Select an entry for which to delete a new attribute.

b. Select an attribute from the list of attributes and delete it.

22.12.3 Seeding Application Roles using WLST Scripts

For instructions on using the WebLogic Scripting Tool (WLST) to seed application roles, see Chapter 4, "Infrastructure Security Custom WLST Commands" of WLST Command Reference for WebLogic Server.

22.12.4 Managing Application Roles in Oracle Enterprise Manager Fusion Middleware Control

This section describes how to manage application roles in Oracle Enterprise Manager Fusion Middleware Control.

Note:

Follow these steps to provide nonadministrators with access to Oracle SOA Composer. This is accomplished by assigning the SOADesigner role to users or groups on the Edit Application Role page. The users must exist in the Oracle WebLogic Server realm.

To manage application roles in Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigator, select the appropriate Oracle WebLogic Server under WebLogic Domain > Farm_Domain_name.

2. Right-click the domain name, and select Security > Application Roles.

3. Create an application role by performing the following steps:

a. In the Application list, select the application name (server_name/soa-infra) under which to create a role.

b. Select the Create option in the Application Roles page.
The Create Application Role page appears.

c. Enter the role name, display name, and description for the application role.

d. Add members by selecting Add Role in the Roles section and Add User in the Users section.

e. Click OK to create the application role.

4. Edit application roles by performing the following steps:

a. In the Select Application Name to Search list of the Search section of the Application Roles page, select an appropriate application (for example, soa_server1/soa-infra).

b. To the right of the Role Name list, click the Search icon.
This action lists all the application roles created for that application.

c. Select the application role to edit (for example, select SOADesigner).

d. Click Edit.
The Edit Application Role page appears.

e. Add application roles and groups in the Roles section and users in the Users section (for example, assign SOADesigner to a user to which to provide access to Oracle SOA Composer). The user must be defined in the Oracle WebLogic Server realm.

f. Click OK.

5. Delete application roles by performing the following steps:

a. In the Select Application Name to Search list of the Search section of the Application Roles page, select an appropriate application.

b. To the right of the Role Name list, click the Search icon.
This action lists all the application roles created for that application.

c. Select the application role to delete.

d. Click the Delete button to delete the application role.

e. Click Yes in the Confirmation dialog.

22.13 Enabling Case Agnostic Group Names in Human Tasks

By default, only user names in human tasks are case agnostic (case insensitive). This behavior is controlled by the value of the caseSensitive property in the System MBeans Browser for users, which is set to false by default. Group names in human tasks must be identical to what is seeded in the user directory. However, if you also want group names in human tasks to be case agnostic, you must set the caseSensitiveGroups property to false.

To enable case agnostic behavior for group names in human tasks:

1. Right-click soa-infra, and select Administration > System Mbean Browser.

The System MBean Browser is displayed on the right side of the page.

2. Expand Application Defined MBeans > oracle.as.soainfra.config > Server: server_name > WorkflowIdentityConfig > human-workflow > WorkflowIdentityConfig.PropertyType > caseSensitiveGroups.

3. Click Value.

4. In the Value field, enter false.

5. Click Apply.

22.14 Configuring Security Policies for Human Workflow Web Services

A policy set, which can contain multiple policy references, enables you to attach policies globally to a range of endpoints of the same type.

Attaching policies globally using policy sets enables you to ensure that all subjects are secured in situations in which multiple users, such as a developer, assembler, or deployer, did not explicitly specify the policies to attach. Policies that are attached using a policy set are considered externally attached.

For example, if the developer did not specify policies in annotations or include policy references in deployment descriptors, then the deployer must attach them or risk a potential security risk. By attaching policies globally to a set of subjects by type, the administrator can ensure that all subjects are secured by default independent of, and even before, deployment. For example, the administrator can define a policy set that attaches a security policy to all web service endpoints in a domain. In this case, any new services added to the domain automatically inherit the security configuration defined in the policy set.

For more information about attaching policies globally using policy sets, see Administering Web Services.

22.15 Enabling Lookup of Tasks Assigned to Groups not Part of the Configured Provider

Tasks that are assigned to the groups which are part of non configured provider do not appear in Human Workflow.

To enable the lookup of such tasks where the groups are not part of the configured provider, set the Mbean propertygroupsFromNonConfiguredProvider in WorkflowIdentityConfig Mbean to true.

23 Monitoring Human Workflow Service Components and Engines

Learn how to monitor human workflow service engine active requests and operation performance statistics, and how to monitor deployed human workflows in the service engine.

- Monitoring Human Workflow Service Engine Active Requests and Operation Performance Statistics

- Monitoring Deployed Human Workflows in the Service Engine

For more information, see the following sections

- Introduction to Service Engines

23.1 Monitoring Human Workflow Service Engine Active Requests and Operation Performance Statistics

You can view details about active requests in the human workflow service engine and operational statistics. such as service used, operations performed, and active and completed requests.

To monitor human workflow service engine active requests and operation statistics:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > Human Workflow.

a. Right-click soa-infra.

b. Select Service Engines > Human Workflow.

2. Click Statistics.
The Statistics page displays the following details.

- Active requests in the service engine. Use this graph to get an idea of the current service engine load. Only under extreme load conditions is there data shown in the graph. This is because most requests are processed instantaneously by the service engine. The data is collected by a Dynamic Monitoring Service (DMS) state sensor. After the requests are processed by the service engine, the count goes to zero. This action enables you to know the current load on the service engine (for example, if it is too high).

- Average request message processing time in the service engine since the last startup of the SOA Infrastructure. Use this graph to check service engine performance. While the processing time is calculated based on the last startup of the SOA Infrastructure, the data that is displayed in the graph is gathered only from the time at which you first accessed this page. The graph does not continue calculating and displaying data if you have not accessed this page. The DMS phase event sensor calculates the average request processing time and provides the processing time data.

- Operation statistics about human workflow services used in the service engine, including the human workflow service used, the operation performed by the service, the number of active and completed requests, the count, and the average processing time.

- Users with the highest backlog provides a snapshot of the workload assigned to various users, groups, or roles. Using this table you can identify assignees with a large number of pending human workflow service tasks as well as the average time it takes for each assignee to complete their tasks.

For more information, see the following documentation:

- Introduction to Service Components

- Developing SOA Applications with Oracle SOA Suite for details about human workflow services and operations

- Tuning Performance for more details about human workflow tuning and performance properties

23.2 Monitoring Deployed Human Workflows in the Service Engine

You can monitor all deployed SOA composite applications with human workflow service components running in the service engine.

To monitor deployed human workflows in service engines:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > Human Workflow.

a. Right-click soa-infra.

b. Select Service Engines > Human Workflow.

2. The Deployed Components tab is displayed.
The Deployed Components page displays the following details:

- A utility for searching for a specific deployed SOA composite application by specifying the full name and clicking Search.

- Details about deployed human workflow service components running in this service engine, including the service component name, the SOA composite application, the current status, and the number of total, faulted, and running instances.

3. In the Name column, click a specific service component to access its home page.

4. In the Composite column, click a specific SOA composite application to access its home page.

24 Managing Human Workflow Service Components and Engines

Learn how to manage human workflow service components and the human workflow service engine, including managing policies, recovering from workflow faults, managing the task details application URI, managing outgoing and incoming email notifications, and moving workflow data from test to production environments.

- Managing Human Workflow Service Component Policies

- Managing the URI of the Human Workflow Service Component Task Details Application

- Managing Outgoing Notifications and Incoming Email Notifications

- Moving Human Workflow Data from a Test to a Production Environment

Note:

Human workflow service components are also known as human task service components in Oracle Enterprise Manager Fusion Middleware Control.

For more information, see the following sections:

- Introduction to Service Components

- Introduction to Service Engines

24.1 Managing Human Workflow Service Component Policies

You can attach and detach security policies to and from human workflow service components of currently deployed SOA composite applications. Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services.

Note:

Human tasks have a port that is protected by default using the SAML policy oracle/wss10_saml_token_service_policy. Oracle recommends that you not use this policy in a production environment.

To manage human workflow service component policies:

1. Access the human workflow service component's home page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Service Engines > Human Workflow.

a. Select soa-infra.

b. Right-click and select Service Engines > Human Workflow.

2. Go to the Composites column of the View table and select a specific SOA composite application to access its home page.

3. Click Policies.
The Policies page enables you to attach and detach security policies to and from a human workflow service component. The policies table displays the attached policy name, the policy reference status (enabled or disabled) that you can toggle, the category (Management, Reliable Messaging, MTOM Attachment, Security, or WS Addressing), the total violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

4. Click Attach/Detach From.
If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

5. Select the service or component to which to attach or detach a policy.
This invokes a dialog for attaching or detaching policies.

Policies currently attached appear in the Globally Attached Policies or Directly Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

6. Select to attach policies appropriate to your environment.

7. Click Attach.

8. When you are finished attaching policies, click Validate.

9. If an error message appears, make the necessary corrections until you no longer have any validation errors.

10. Click OK.
The attached policy is displayed in the policies table.

For more information, see the following documentation:

- Introduction to Policies

- Managing SOA Composite Application Policies for the dialogs that are displayed during policy attachment

24.2 Managing the URI of the Human Workflow Service Component Task Details Application

You can add or remove the URIs of the task details application used in human workflow.

To manage the URIs of the human workflow service component task details application:

1. Access this page using one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Service Engines > Human Workflow.

a. Select soa-infra.

b. Right-click and select Service Engines > Human Workflow.

2. Go to the Composites column of the View table and select a specific SOA composite application to access its home page.

3. Select a component from the list of components.

4. Click Administration.
The Administration page shows the URI for the task details application.

Note:

If the SOA server is SSL enabled or disabled, then you must manually enable or disable SSL for any already deployed workflow task detail applications. Change the workflow task display URL to use the correct protocol and port number. To enable the use of the SSL (HTTPS) URL, ensure that the HTTP port setting is left blank.

5. Click the Add icon to specify the following details for the URI:

- Application name

- Hostname

- HTTP port

- HTTPS port (optional)

- URI

6. Click OK and then click Apply.

24.3 Managing Outgoing Notifications and Incoming Email Notifications

You can manage incoming and outgoing notifications through email in human workflow, including testing messages, resending messages, and identifying messages as spam.

Incoming and outgoing notifications are sent to and from human workflow. Incoming notifications are responses to actionable notifications. For example, an outgoing notification is sent to the manager of an employee requesting vacation leave. The manager approves the request by clicking the Approve link in the actionable notification email. This action sends an incoming notification to human workflow for possible additional processing.

To manage outgoing notifications and incoming email notifications:

1. Access this page using one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > Human Workflow.

a. Right-click soa-infra.

b. Select Service Engines > Human Workflow.

2. Click Notification Management.
The upper part of the Notification Management page displays the following details:

- A utility for searching for a specific message by specifying criteria and clicking Search. You must expand the Search icon to display this utility.

- Outgoing notifications, including the source ID, the source type (for example, if a notification is sent by a BPEL service component, the type is BPEL), the channel used (for example, email, SMS, instant messenger, or voice), the address of the message recipient, the message status (for example, error, send, retry, sent), and the time at which the message was sent.

The lower part of the Notification Management page displays the following details:

- A utility for searching for a specific message by specifying criteria and clicking Search. You must expand the Search icon to display this utility.

- Incoming notifications, including the message ID, the channel used (same types as for outgoing notifications), the address of the message sender, the address of the message recipient, the message status (replied email notification, unsolicited email, unknown email content, response not processed, and response processed), a link to the content of the message, and the time at which the message was received.

3. Perform the following actions on outgoing notifications.

Action

Description

Send Test Notification

Test that outgoing messages are arriving at the correct destination. This ensures that the destination is reachable and messages are arriving. Selecting this option invokes a dialog for specifying the following destination details:

- Destination address

- Delivery channel (for example, email)

- Message subject and content

Note: You cannot send test notification messages with the messaging extension driver because it requires the following:

- Specific data to be manually entered into the test page (such as the URI of the task details)

- URI-specific headers (such as time, user, and so on)

Resend

Select specific outgoing notification messages in the table and click Resend to resend. Use this option if you believe that messages are not arriving at their correct destination. For example, you may have incorrectly configured a recipient address. After correcting the address, click Resend to test the delivery.

Resend All Similar Notifications

Resend all error notification messages having the same recipient address as the selected one.

View Bad Addresses

Click to display a list of bad or invalid addresses. The addresses are automatically removed from the bad address list after one hour. If you do not want to wait an hour, you can explicitly select and delete them.

Delete icon

Click to delete a selected message.

If outgoing notifications are sent to an incorrect address of a message recipient, they are displayed as errors in the Recipient column. You can correct the recipient's address and resend the notification.

4. In the Recipient column, click the email address and correct the address.

5. Perform the following actions on incoming notifications.

Action

Description

Mark as Spam

Mark the message sender's address of the selected notification as spam. This action prevents incoming notifications from the same sender address from being delivered again.

No Spam

Mark incoming messages as not being spam. This action enables new messages from the sender's address to be delivered again.

Delete icon

Click to delete a selected message.

For more information about notifications, see Developing SOA Applications with Oracle SOA Suite.

24.4 Moving Human Workflow Data from a Test to a Production Environment

You can migrate Human Workflow user metadata, such as views, mapped attribute (previously known as flex field) mappings, and vacation rules, from a test environment to a production environment using the Human Workflow User Config Data Migrator.

The Data Migrator is available as an ant target that can be executed at the command line. You specify the input parameters for the migration of data in a properties file, migration.properties.

For example, assume you have two SOA servers installed:

- SOAServer_A
A test server that includes human workflow user-configurable data (user views, standard views, user rules, group rules, attribute labels, and task payload mapped attribute mappings).

- SOAServer_B
A production server to which you want to move the data on SOAServer_A.

Since you have a significant amount of data on SOAServer_A, it can be time consuming to manually migrate all of the data to SOAServer_B.You can use the Data Migrator to move the data from the test server to the production server. You run the ant target at the command line of SOAServer_A to migrate data to SOAServer_B.Migration is always performed through an XML file. The Data Migrator supports the following operations:

- Export operation: Stores all the human workflow user-configurable data from the source SOA server to the XML file.

- Import operation: Creates all the human workflow user-configurable data in the target SOA server by reading from the XML file.

The Data Migrator consists of the following files:

- migration.properties: Contains all required input properties in terms of key-value pairs for migration operations.

- build.xml: Contains the ant target runHwfMigrator that executes the Data Migrator.

24.4.1 Moving Human Workflow Data from Test to Production Environments

Perform the following steps to move data from a test to a production environment.

To move human workflow data from test to production environments:

1. Ensure that the PATH environment variable contains the JAVA_HOME and ANT_HOME environment variables and that they point to the locations within the Oracle SOA Suite installation.

2. Create a migration.properties file in any location to export user metadata for the worklist application (for example, group rules, views, mapped attribute mappings, and vacation rules) from the test environment. See Migration Property File Examples for instructions on how to specify properties.

Note the following:

- You can export mapped attribute mappings.

- You can export attribute labels.

- You can only export one type of data at a time.

- When you export data for a particular user or group, you must export each in separate operations.

- You must export attribute labels before you export mapped attribute mappings.
To export attribute labels, use the following values in the migration.properties file:

objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
migrateAttributeLabel = true

To export mapped attribute mappings, use the following values in the migration.properties file:

objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
migrateAttributeLabel = false

3. Export the data with the ant script. The following example shows how to invoke the command and specify the parameters:

ant -f ant-t2p-worklist.xml
-Dbea.home=/scratch/oracle/MW_HOME
-Dsoa.home=/scratch/oracle/MW_HOME/AS11gR1SOA
-Dmigration.properties.file=migration.properties
-Dsoa.hostname=hostname -Dsoa.rmi.port=7001
-Dsoa.admin.user=weblogic
-Drealm=jazn.com
-Dmigration.file=/tmp/export_all_userRules.xml
-Dmap.file=/tmp/export_all_userRules_mapper.xml

Note:

After specifying the Admin user name, enter the password when prompted.

See ant Script Data Migration Syntax for instructions on specifying ant properties.

4. Ensure that the application is deployed to the production system.

Note:

Human workflow artifacts such as task mapped attribute mappings, rules, views, and approval groups are defined based on namespace. The Data Migrator migrates human workflow artifacts based on namespace. Therefore, it is not possible to migrate human workflow artifacts based on a partition.

5. Create the migration.properties file to import user metadata for the worklist application to the production environment.

Note the following:

- You can only import one type of data at a time.

- When you import data for a particular user or group, you must import it in separate operations.

- You must import attribute labels before you import mapped attribute mappings.
To import attribute labels, use the following values in the migration.properties file:

objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
migrateAttributeLabel = true

To import mapped attribute mappings, use the following values in the migration.properties file:

objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
migrateAttributeLabel = false

6. Import the data to the production environment from the file export_all_userRules.xml, which you created with the map.file property in Step 3. The following example shows how to invoke the command and specify the properties:

ant -f ant-t2p-worklist.xml
-Dbea.home=/scratch/oracle/MW_HOME
-Dsoa.home=/scratch/oracle/MW_HOME/AS11gR1SOA
-Dmigration.properties.file=migration.properties
-Dsoa.hostname=hostname
-Dsoa.rmi.port=7001
-Dsoa.admin.user=weblogic
-Dsoa.admin.password=password
-Drealm=jazn.com
-Dmigration.file=/tmp/export_all_userRules.xml
-Dmap.file=/tmp/export_all_userRules_mapper.xml

If the data, such as rules and views, are attached to the user, then the user must be an available user in the production SOA server.

7. Deploy J2EE human task forms, as you would deploy any .ear file.

8. If necessary, update the workflow notification configuration with production mail server and inbound and outbound email accounts. See Configuring Human Workflow Notification Properties.

24.4.2 migration.properties File Syntax

The migration.properties file specifies the input parameters for data migration. The template for this file is located in the following directory:

The migration.properties file contains the following input parameters:

operationType = {EXPORT | IMPORT}
objectType = {VIEW | RULE | TASK_PAYLOAD_FLEX_FIELD_MAPPING}
name = name of VIEW or TASK_PAYLOAD_FLEX_FIELD_MAPPING
user = username of VIEW or RULE
group = groupname for RULE
grantPermission = {true | false}
migrateAttributeLabel = {true | false}
override = {true | false}
skip = {true | false}
migrateToActiveVersion = {true | false}

Argument

Definition

operationType

Specify to perform one of the following actions:

- EXPORT: Data is migrated from a SOA server instance into an XML file.

- IMPORT: Data is migrated from the XML file into the SOA server instance.

objectType

Specify the type of object to migrate:

- VIEW: Migrates views.

- RULE: Migrates vacation rules.

- TASK_PAYLOAD_FLEX_FIELD_MAPPING: Migrates mapped attribute mappings.

name

Specify the object name if you specified VIEW or TASK_PAYLOAD_FLEX_FIELD_MAPPING values for the objectType. This property refers to the following:

- viewName for VIEW

- taskDefinitionId for TASK_PAYLOAD_FLEX_FIELD_MAPPING

Specify ALL to identify all objects of this type.

user

Specify the user name only if you specified the VIEW or RULE value for the objectType property. If a user is not specified for VIEW, it implies STANDARD_VIEW.

group

Specify this property only if you specified the RULE value of the objectType property. It identifies the group name (for example, LoanAgentGroup).

grantPermission

Specify this property only if you specified the VIEW value of the objectType property.

- true: Migrates view definitions and grants.

- false: Migrates only view definitions.

migrateAttributeLabel

Specify one of the following values:

- true: Migrates only attribute labels. Payload mappings are not migrated.

- false: Does not migrate attribute labels. Migrates only payload mappings.

override

Specify whether to override the data on the target SOA server:

- true: Overrides the existing workflow user-configurable data on the target SOA server.

- false: Does not override the target SOA server instance that has the workflow user-configurable data.

skip

Specify error handling details.

- true: Errors are skipped and the migration utility continues processing.

- false: Any encountered error halts the migration.

migrateToActiveVersion

Specify a value for mapping task definition IDs.

- true: Maps task definition IDs to the active version in the target SOA server instance.

- false: Does not map task definitions.

24.4.2.1 Migration Property File Examples

This section provides examples how to configure the migration.properties file.

24.4.2.1.1 Exporting All Attribute Labels

The following example exports all attribute labels.

operationType = EXPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = true
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.2 Importing All Attribute Labels

The following example imports all attribute labels.

operationType = IMPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = true
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.3 Exporting Specific Attribute Labels

The following example exports specific attribute labels.

operationType = EXPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = cb801c91-4605-4e96-a234-aeb8441f0388
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = true
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.4 Importing Specific Attribute Labels

The following example imports specific attribute labels.

operationType = IMPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = cb801c91-4605-4e96-a234-aeb8441f0388
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = true
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.5 Exporting Task Payload Mapped Attribute Mappings for All Task Definition IDs

The following example exports task payload mapped attribute mappings for all task definition IDs.

operationType = EXPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.6 Importing Task Payload Mapped Attribute Mappings for All Task Definition IDs

The following example imports task payload mapped attribute mappings for all task definition IDs. Task payload mapped attribute mappings use attribute labels. As a prerequisite, find out the attribute labels involved in the task payload mapped attribute mappings to import. These attribute labels must be available in the target SOA server before the import of task payload mapped attribute mappings into the target SOA server.

The recommended steps are as follows:

- Import the attribute labels into the target SOA server.

- Import the task payload mapped attribute mappings into the target SOA server.

operationType = IMPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.7 Exporting Task Payload Mapped Attribute Mappings for a Specific Task Definition ID

The following example exports task payload mapped attribute mappings for a specific task definition ID.

operationType = EXPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = default/HelpDeskRequestComposite!1.0*c9856b8b-bc9e-46a4-8aef-698e539ba1d7/HelpDesk
RequestHumanTask
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.8 Importing Task Payload Mapped Attribute Mappings for a Specific Task Definition ID

The following example imports task payload mapped attribute mappings for a specific task definition ID. Task payload mapped attribute mappings make use of attribute labels. As a prerequisite, find out the attribute labels that are involved in the task payload mapped attribute mappings to import. These attribute labels must be available in the target SOA server before the import of task payload mapped attribute mappings into the target SOA server.

The recommended steps are as follows:

- Import the attribute labels into the target SOA server.

- Import the task payload mapped attribute mappings into the target SOA server.

operationType = IMPORT
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING
name = default/HelpDeskRequestComposite!1.0*c9856b8b-bc9e-46a4-8aef-698e539ba1d7/HelpDesk
RequestHumanTask
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = true

24.4.2.1.9 Exporting All Rules for a Specific User

This example exports all rules for a specific user. The group property is left blank when you export rules for a specific user.

operationType = EXPORT
objectType = RULE
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.10 Importing All Rules for a Specific User

This example imports all rules for a specific user. The group property is left blank when you import rules for a specific user.

operationType = IMPORT
objectType = RULE
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.11 Exporting All Rules for a Specific Group

This example exports all rules for a specific group. The user property is left blank when you export rules for a specific group.

operationType = EXPORT
objectType = RULE
name = ALL
user =
group = LoanAgentGroup
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.12 Importing All Rules for a Specific Group

This example imports all rules for a specific group. The user property is left blank when you import rules for a specific group.

operationType = IMPORT
objectType = RULE
name = ALL
user =
group = LoanAgentGroup
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.13 Exporting All User Views

This example exports all user views.

operationType = EXPORT
objectType = VIEW
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.14 Importing All User Views

This example imports all user views.

operationType = IMPORT
objectType = VIEW
name = ALL
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.15 Exporting a Specific User View

This example exports a specific user view.

operationType = EXPORT
objectType = VIEW
name = jcooperUserView1
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.16 Importing a Specific User View

This example imports a specific user view.

operationType = IMPORT
objectType = VIEW
name = jcooperUserView1
user = jcooper
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.17 Export All Standard Views

This example exports all standard views.

operationType = EXPORT
objectType = VIEW
name = ALL
user =
group = LoanAgentGroup
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.18 Importing All Standard Views

This example imports all standard views.

operationType = IMPORT
objectType = VIEW
name = ALL
user =
group = LoanAgentGroup
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.19 Exporting a Specific Standard View

This example exports a specific standard view.

operationType = EXPORT
objectType = VIEW
name = MyStandardView1
user =
group = LoanAgentGroup
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.2.1.20 Importing a Specific Standard View

This example imports a specific standard view.

operationType = IMPORT
objectType = VIEW
name = MyStandardView1
user =
group = LoanAgentGroup
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false

24.4.3 ant Script Data Migration Syntax

Use the ant script for data migration. The script is located in the following directory:

ORACLE_HOME/bin/ant-t2p-worklist.xml

The script uses the following format to migrate human workflow configurable data from one SOA server to another:

ant -f ant-t2p-worklist.xml
-Dbea.home=BEA_HOME
-Dsoa.home=SOA_HOME
-Dmigration.properties.file=MIGRATION_PROPERTY_FILE_PATH
-Dsoa.hostname=SOA_HOSTNAME
-Dsoa.rmi.port=SOA_RMI_PORT
-Dsoa.admin.user=SOA_ADMIN_USER
-Dsoa.admin.password=SOA_ADMIN_PASSWORD
-Drealm=REALM -Dmigration.file=MIGRATION_FILE
-Dmigration.file=<MIGRATION_FILE>
-Dmap.file=MAP_FILE
-Dhwf.t2p.config.file=

Argument

Definition

bea.home

The absolute path of the installation directory for Oracle WebLogic Server.

soa.home

The absolute path of the Oracle SOA Suite home directory.

migration.properties.file

The absolute path to the migration.properties file.

soa.hostname

The hostname of the SOA server instance.

Note: You must specify the complete domain name, such as myhost.us.example.com, instead of myhost.

soa.rmi.port

The remote method invocation (RMI) port of the SOA server instance.

soa.admin.user

The Admin user name to connect to the SOA server instance.

soa.admin.password

The Admin user password to connect to the SOA server instance.

realm

The realm of the SOA server instance.

migration.file

The complete path location of the migration file in which all user-configurable data from the SOA server is exported to or imported from.

map.file

The full path location of the map file in which all the TaskDefinitionId mappings in the target SOA server are provided. This file enables you to customize the mapping.

hwf.t2p.config.file

The location of the configuration file.

Note:

The configuration file specified must be of type .properties (for example, config.properties) and include an entry for soa.admin.password (for example, soa.admin.password=****).

When calling ant-t2p-worklist.xml, set the argument soa.admin.password to the correct password, or to an empty value. For example:

-Dsoa.admin.password=*** or -Dsoa.admin.password=

If soa.admin.password is set to an empty value, provide the password configuration file location by setting the hwf.t2p.config.file argument to the file location. If both hwf.t2p.config.file and soa.admin.password are set, the soa.admin.password value is read from the configuration file.

For example:

ant -f ant-t2p-worklist.xml
-Dbea.home=/net/myhost/jsmith/fmwhome
-Dsoa.home=/net/myhost/jsmith/fmwhome/AS11gR1SOA
-Dmigration.properties.file=migration.properties
-Dsoa.hostname=myhost.us.example.com -Dsoa.rmi.port=7001
-Dsoa.admin.user=weblogic
-Drealm=jazn.com
-Dmigration.file=/tmp/export_all_userRules.xml
-Dmap.file=/tmp/export_all_userRules_mapper.xml
-Dhwf.t2p.config.file=

Part IX Administering Oracle JCA Adapters

Learn how to administer Oracle JCA Adapters.

- Configuring Oracle JCA Adapters

- Monitoring Oracle JCA Adapters

25 Configuring Oracle JCA Adapters

Learn how to configure inbound and outbound endpoint properties during runtime for Oracle JCA adapters.

- Configuring the Endpoint Properties for an Inbound Adapter

- Configuring the Endpoint Properties for an Outbound Adapter

For more information about adapter tuning and performance properties, see Tuning Performance.

Note:

All adapter properties visible in Oracle Enterprise Manager Fusion Middleware Control can be updated on a live basis. Some properties may cause the endpoint to recycle (for example, QueueName), others do not (for example, jca.retry.count). Generally, properties originating from an activation or interaction spec cause the endpoint to recycle. All other (binding / endpoint) properties do not cause it to recycle.

Also, you can add any properties that you want to use and that are specified in the Properties Appendix of the Understanding Technology Adapters book, However, because there is no validation when you add properties within Oracle Enterprise Manager Fusion Middleware Control, this practice is not recommended.

25.1 Configuring the Endpoint Properties for an Inbound Adapter

Learn how to configure the endpoint properties for an inbound adapter.

- Editing a Predefined Property for an Inbound Adapter

- Adding Predefined Properties for an Inbound Adapter

- Creating a New Property for an Inbound Adapter

- Deleting a Property for an Inbound Adapter

- Reverting a Property Value for an Inbound Adapter

25.1.1 Editing a Predefined Property for an Inbound Adapter

The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, you can edit the predefined properties at a later stage using Oracle Enterprise Manager Fusion Middleware Control.

To edit a predefined property for an inbound adapter, navigate to the adapter by using either of the following options:

1. From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click either Services or References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Service or Reference. The Home Page for the adapter is displayed.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.1.1.1 Edit a Predefined Property:

1. Click Properties to see a list of the currently defined binding properties.

2. Select the property you want to edit.

3. Edit the value in the Value text box, and then click Apply.
You have edited a predefined property for an inbound adapter.

25.1.2 Adding Predefined Properties for an Inbound Adapter

The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, you can add properties at a later stage using Oracle Enterprise Manager Fusion Middleware Control.

Note:

Though the Properties page list both endpoint and the binding properties, you can only add endpoint properties.

To add a predefined property for an inbound adapter:

1. Navigate to the adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click either Services or References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Service or Reference. The Home Page for the Adapter is displayed.

2. Add a predefined property:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Click the Add button.
A new empty row is appended to the existing list of properties.

c. Click the Select Values icon in the Name field of the new row.
The Properties dialog is displayed.

d. Select a property that is valid for the particular adapter from the list of properties, and then click OK.

e. Click Apply.
You have added a predefined property for an inbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.1.3 Creating a New Property for an Inbound Adapter

The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, it is possible to add new properties at a later stage using Oracle Enterprise Manager Fusion Middleware Control.

To create a new property for an inbound adapter:

1. Navigate to the adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click Services.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Service. The Home Page for the Adapter is displayed.

2. Create a new property:

a. Click the Properties tab to see the list of the currently defined binding properties.

b. Click the Add button.
A new empty row is appended to the existing list of properties.

c. Specify the property name and value in the Name and the Value fields of the new row.

d. Click Save.
You have created a new property for an inbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.1.4 Deleting a Property for an Inbound Adapter

You can delete only properties that you added from the predefined list of properties or the ones that you newly created.

To delete a property for an inbound adapter:

1. Navigate to the adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click Services.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Service. The Home Page for the Adapter is displayed.

2. Delete a property:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Select the property you want to delete, and then click Delete.
A message asking you to confirm your action is displayed.

c. Click Yes to confirm.

d. Click Apply.
You have deleted a property for an inbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.1.5 Reverting a Property Value for an Inbound Adapter

You can only revert the properties that you have changed. Also note that you can perform the revert operation only on the existing property values and not on those that you added from the predefined list of properties or the ones that you created.

To revert a property value for an inbound adapter:

1. Navigate to the Adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click Services.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Service. The Home Page for the Adapter is displayed.

2. Revert a property value for an inbound adapter:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Select the property you want to revert, and then click Revert.
A message asking you to confirm your action is displayed.

c. Click Yes to confirm.

d. Click Save.
You have reverted a property value for an inbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.2 Configuring the Endpoint Properties for an Outbound Adapter

Learn how to configure the endpoint properties for an outbound adapter.

- Editing a Predefined Property for an Outbound Adapter

- Adding a Predefined Property for an Outbound Adapter

- Creating a New Property for an Outbound Adapter

- Deleting a Property for an Outbound Adapter

- Reverting a Property Value for an Outbound Adapter

25.2.1 Editing a Predefined Property for an Outbound Adapter

The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, it is possible to edit the predefined properties at a later stage using Oracle Enterprise Manager Fusion Middleware Control.

To edit a predefined property for an outbound adapter:

1. Navigate to a SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Reference. The Home Page for the Adapter is displayed.

2. Edit a predefined property:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Select the property you want to edit.

c. Edit the value in the Value text box. You can click Apply to apply the change.
You have edited a predefined property for an outbound adapter.

Note:

For Oracle MQ Series Adapter in an asynchronous outbound request/reply scenario, properties are differentiated by an (Enqueue) or (Dequeue) label. For example, QueueName(Enqueue) is used for putting a message and QueueName(Dequeue) is used for dequeuing the reply.

When editing Oracle MQ Series Adapter properties in this scenario, note the following:

- If you change the ReplyToQueueName(Enqueue) property, you must also change the QueueName(Dequeue) property to the same value.

- If you change the MessageId(Dequeue) property, you must also change the MessageId(Enqueue) property to the same value.

- If you change the CorrelationId(Dequeue) property, you must also change the CorrelationId(Enqueue) property to the same value.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.2.2 Adding a Predefined Property for an Outbound Adapter

The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, you can add predefined properties at a later stage using Oracle Enterprise Manager Fusion Middleware Control.

To add a predefined property for an outbound adapter:

1. Navigate to the Adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Reference. The Home Page for the Adapter is displayed.

2. Add a predefined property:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Click the Add button.
A new empty row is appended to the existing list of properties.

c. Click the Select Value icon in the Name field of the new row.
The Properties dialog is displayed.

d. Select a property that is valid for the particular adapter from the list of properties, and then click OK.

e. Click Save.
You have added a predefined property for an outbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.2.3 Creating a New Property for an Outbound Adapter

The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, you can add new properties at a later stage using Oracle Enterprise Manager Fusion Middleware Control.

To create a new property for an outbound adapter:

1. Navigate to the Adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Reference. The Home Page for the Adapter is displayed.

2. Create a new property:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Click the Add button.
A new empty row is appended to the existing list of properties.

c. Specify the property name and value in the Name and the Value fields of the new row.

d. Click Apply to apply the changes.
You have created a new property for an outbound adapter.

For more information about configuring adapters, seeConfiguring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.2.4 Deleting a Property for an Outbound Adapter

You can delete only properties that you added from the predefined list of properties or the ones that you newly created.

To delete a property for an outbound adapter:

1. Navigate to the Adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Reference. The Home Page for the Adapter is displayed.

2. Delete a property for an outbound adapter:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Select the property you want to delete, and then click Delete.
A message asking you to confirm your action is displayed.

c. Click OK to confirm.

d. Click Apply to apply the changes.
You have deleted a property for an outbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

25.2.5 Reverting a Property Value for an Outbound Adapter

You can revert changes made, if any, only for the already existing property values and not those that you added from the predefined list of properties or the ones that you newly created.

To revert a property value for an inbound adapter:

1. Navigate to the Adapter by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Right-click soa-infra in the target menu.

b. Click Services and References.
The SOA-Infra page is displayed with Services and References.

c. Click References.
The Home page for the Adapter is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. From the Composite Target menu, select Service/Reference Properties. Select the Reference. The Home Page for the Adapter is displayed.

2. Revert a property value for an outbound adapter:

a. Click the Properties tab to see a list of the currently defined binding properties.

b. Select the property you want to revert, and then click Revert.
A message asking you to confirm your action is displayed.

c. Click OK to confirm, and click Apply.
You have reverted a property value for an outbound adapter.

For more information about configuring adapters, see Configuring Service and Reference Binding Component Properties and Understanding Technology Adapters.

26 Monitoring Oracle JCA Adapters

Learn how to monitor inbound and outbound Oracle JCA adapters, including monitoring instances and faults, recent faults and rejected messages, adapter properties, and adapter logs.

- Monitoring Instances and Faults for an Inbound Adapter

- Monitoring Recent Faults and Rejected Messages for an Inbound Adapter

- Monitoring Faults for an Inbound Adapter

- Monitoring Properties for an Inbound Adapter

- Monitoring Instances and Faults for an Outbound Adapter

- Monitoring Faults for an Outbound Adapter

- Monitoring Properties for an Outbound Adapter

- Monitoring Adapter Logs

- Adapter Configuration Reports

- Scheduling JCA Adapter Endpoint Activation and Deactivation using Oracle Enterprise Scheduler

26.1 Monitoring Instances and Faults for an Inbound Adapter

An invocation to a service from a composite may result in an error. This error is captured as a fault in the service. You can view the details of the instances and faults of the inbound adapter in the Instances and Faults section of the Dashboard page.

To monitor instances and faults for an inbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite home page is displayed.

d. Click the inbound adapter (service) from the Services and References section in the right panel.
The Service Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite Home page is displayed.

b. Click the inbound adapter (Service) from the Services and References section in the right panel.

2. Monitor the instances and faults for an inbound adapter:

a. The Dashboard page is, by default, selected once you select the composite under soa-infra.

b. Select the Flow instance tab. Under that the Instances with Faults Section is displayed. You can view the instances and faults within the Instances and Faults section.
The details of the fault is displayed in a line chart in the Instances and Faults section, which you can search within to find recent faults. This line chart shows the total number of outgoing messages since the start of the server, and the total number of faults since the start of the server.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.2 Monitoring Recent Faults and Rejected Messages for an Inbound Adapter

You can view the details of the recent faults and rejected messages of the inbound adapter under the Flow Instances tab of the Dashboard page.

To monitor the recent rejected messages for an inbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite home page is displayed.

d. Click the inbound adapter (Service) from the Services and References section in the right panel.
The Service Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. Click the inbound adapter (service) from the Services and References section in the right panel.
The Service Home page is displayed.

2. Monitor the recent faults and rejected messages for an inbound adapter:

a. Click Dashboard.
The Dashboard page is displayed.

b. View the recent faults and rejected messages listed in Instances and Faults section within the Flow Instances tab.
A list of recently rejected faults and messages with details such as error message, fault time, and the business flow instance ID is displayed.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.3 Monitoring Faults for an Inbound Adapter

You can view the details of the faults and rejected messages of an inbound adapter in the Flow Instances page.

To monitor the rejected messages for an inbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite Home page is displayed.

2. To monitor the faults and rejected messages for an inbound adapter:

a. View the recent faults and rejected messages listed in Instances and Faults section within the Flow Instances tab.
A list of faults and rejected messages with details such as error message, fault time, and business flow instance ID is displayed.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.3.1 Searching for Rejected Messages for an Inbound Adapter

Use the Search feature to search for faults and rejected messages for an inbound adapter.

To search for faults and rejected messages for an inbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composite applications is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite Home page is displayed.

2. Select the Flow instance tab to obtain the Instances with Faults section.

3. Enter any or all of the following search options:

- Instances within a Time Range
Enter any part of the error message text.

- Time
Enter the ID of the fault.

- Composite
Select Initiating or Participating from the toggle.

- State
Select Active, which can be one of All Active, Recovery, Running, Suspended, or Inactive, which can be one of All Inactive, Completed, Failed or Aborted

- Fault
Select a type from the list of faults available. These include: All Faults, Recovery Required, Nonrecoverable, Recovered, System Auto Retries

- You can also choose to search for only Recent Instances, Instances with Faults, Recoverable Instances.

4. Click Search to start the search operation.
The fault or rejected message matching the criteria you specified is displayed.

5. Click Reset to reset the search criteria.

For more information about configuring adapters, see Understanding Technology Adapters.

26.3.2 Deleting Rejected Messages for an Inbound Adapter

You can directly delete rejected messages from the database by specifying a search criteria.

To delete rejected messages for an inbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composite applications is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

2. Select the Flow instance tab to obtain the Instances with Faults section.

3. Click the Delete Selected Flow Instances icon
The Delete Selected Flow Instances dialog is displayed.

4. Click Delete.

To delete a fault, you must delete the associated business flow instance from the Instances page.

For more information about configuring adapters, see Understanding Technology Adapters.

26.4 Monitoring Properties for an Inbound Adapter

You can view the details of the properties of an inbound adapter in the Properties page.

To monitor the properties for an inbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite home page is displayed.

d. Click the inbound adapter (service) from the Services and References section in the right panel.
The Service Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. Click the inbound adapter (service) from the Services and References section in the right panel.
The Service Home page is displayed.

2. Monitor the properties for an inbound adapter:

a. Click Properties.
The Properties page is displayed for that adapter.

A list of properties with details such as name and value is displayed.

Note:

For any adapter that has an inbound asynchronous request-reply scenario (the Get Message operation preceding the Send Reply operation), only details about the activation specification are displayed; details about the interaction specification are not displayed.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.5 Monitoring Instances and Faults for an Outbound Adapter

An invocation to a reference from a composite may result in an error. This error is captured as a fault in the reference. The details of the instances and faults of the outbound adapter can be viewed in the Instances and Faults section of the Dashboard page.

To monitor instances and faults for an outbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite home page is displayed.

d. Click the outbound adapter (reference) from the Services and References section in the right panel.
The Service Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. Click the outbound adapter (reference) from the Services and References section in the right panel.
The Service Home page is displayed.

2. Monitor the instances and faults for an outbound adapter:

a. Click Dashboard.
The Dashboard page is displayed.

b. View the instances and faults listed in the Instances and Faults section, after clicking on the Flow Instances tab.
The details of the fault is displayed in a line chart in the Instances and Faults section. This line chart shows the total number of outgoing messages since the start of the server, and the total number of faults since the start of the server.

c. Select Table View to see an expanded table view listing to see total number of messages since server start or total number of faults since server start, which you can sort by ascending, or descending order, or you can sort by more advanced criteria by choosing advanced.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.6 Monitoring Faults for an Outbound Adapter

The details of the instances and faults of the outbound adapter can be viewed in the Faults page.

To monitor faults for an outbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite Home page is displayed.

2. To monitor the faults for an outbound adapter:

a. Select the Flow instance tab to obtain the Instances with Faults section.

b. Select Table View to see a listing of faults, total number of incoming messages since server start and total number of faults., and to sort the displayed data according to your preference.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.6.1 Searching for Faults for an Outbound Adapter

Use the Search feature to search for faults for an outbound adapter.

To search for faults for an outbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composite applications is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite Home page is displayed.

2. Select the Flow instance tab to obtain the Instances with Faults section.

3. Click the Search icon at the right to execute any saved Searches.

4. In the Search Options section, enter any or all of the following search criteria:

- Select the Reset icon to reset the search criteria.

- Select the Disk icon to save the custom search.

- Select the Bookmark icon to generate a bookmarkable link.

- Select the Funnel icon on the right to customize (that is, add or remove) filters.

- On the Add/Remove Filters link t you can set Filters by you can add or remove Filters by Time, Composite, Resequencer, Flow Instance, State, Fault, or User.

- Using Search Options, you can set Recent Instances, Instances with Faults, Recoverable Instances, All Saved Searches.

- You can either select Customize Time Period, or Last number of hours, minutes, days or weeks.

- Choose Participating or a Composite.

- Choose State, which can be All Active, Recovery, Suspended, Running.

- Chose Fault, which can be any one of All Faults, Recovery Required, Nonrecoverable, Recovered, System Auto Retries.

5. Click Search to start the search operation.
The fault matching the criteria you specified is displayed.

For more information about configuring adapters, see Understanding Technology Adapters.

26.7 Monitoring Properties for an Outbound Adapter

The details of the properties of the outbound adapter can be viewed on the Properties page.

To monitor properties for an outbound adapter:

1. Navigate to the SOA composite application by using either of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Click Home.
The SOA Infrastructure page is displayed.

b. Click the Deployed Composites tab.
The list of deployed composites is displayed.

c. In the Composite section, click a specific SOA composite application.
The SOA Composite home page is displayed.

d. Click the outbound adapter (reference) from the Services and References section in the right panel.
The Service Home page is displayed.

a. Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.

b. Click the outbound adapter (reference) from the Services and References section in the right panel.
The Service Home page is displayed.

2. Monitor the properties for an outbound adapter:

a. Click the Properties tab.
The Properties page is displayed.

b. Click View.
A list of properties with details such as name and value is displayed.

Note:

Where an adapter has an outbound asynchronous request-reply scenario (the Send Message operation preceding the Get Response operation), only details about the interaction specification are displayed, and details about the activation specification are not displayed.

For more information about monitoring adapters, see Understanding Technology Adapters.

26.8 Monitoring Adapter Logs

Oracle Fusion Middleware components generate log files containing messages that record all types of events, including startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information. There is only one logger for all Oracle JCA Adapters, and the logger is called oracle.soa.adapter.

To monitor the File adapter logs:

1. Navigate to your SOA composite dashboard for the selected composite application.

2. Select the logs for your composite application from the Selected Links link to the right of the SOA composite dashboard.

3. Supply a date and time range for the logs you want to examine.

4. In addition to date and time range, you can also provide other criteria to delimit the list of logs you will find. These include the following:

- Message contains | is | is not | does not contain | starts with | does not start with | ends with | does not end with | matches | does not match

- Composite name is | is not | contains | does not contain | starts with | does not start with | ends with | does not end with | matches | does not match

- Fault id is | is not |contains | does not contain | starts with | does not start with | ends with | does not end with | matches | does not match

- Flow correlation is | is not |contains | does not contain | starts with | does not start with | ends with | does not end with | matches | does not match

- Flow id is | is not |contains | does not contain | starts with | does not start with | ends with | does not end with | matches | does not match

5. Oracle Enterprise Manager Fusion Middleware Control displays a list of logs meeting the criteria you have supplied. Select a server log from the list of logs and download to view it in an editor.

6. You could have alternatively navigated from Target-Navigation-Domain and right-clicked on the domain where the composite resides to select View Log Messages. This brings up a list of log messages directly.

7. Information about SOA adapter logs can be found in the logger.

For information about configuring logs, see Configuring Log Files. For information about diagnostics related to logs, see Diagnosing Problems with SOA Composite Applications.

26.9 Adapter Configuration Reports

Oracle Adapter Configuration reports provide information on how you have configured Adapters. They provide diagnostics information in addition to Snapshot reports and Monitoring reports. Without this the support, one has to go through multiple consoles and logs for diagnosis. There are many more Adapter properties than those reported on in the diagnostic reports; however, the reports provide information from the most relevant properties.

The configuration report provides information on the service endpoints; each of these reports correlate and provide you with information that would otherwise require you to do a large amount of moving between different reports to find information related to Adapter configuration.

Adapter Configuration reports capture:

- Connection Factory properties

- Service Definition Properties (Activation Properties and other specs related to a service endpoint).

- Service Tuning Properties - Service endpoint properties used to tune the service to alter performance items such as throughput and throttling.

- Reference Definition Properties (Interaction Properties and other types of specs involved in Reference endpoint).

- Reference Tuning Properties - Reference endpoint properties used to tune the service to alter performance factor such as throughput and throttling.

The Reports do not provide information on Adapter-specific properties that are not part of Connection Factory properties. For example, the reports do not provide information on LDAP RootDSE properties.

26.9.1 Enabling Display of Adapter Reports

You can enable the following Adapter reports to display in Oracle Enterprise Manager Fusion Middleware Control:

- Monitoring Report

- Configuration Reports

- Snapshot Reports

You can enable reports by checking the box at the top of the Monitoring Reports page. Another way to enable reports to add corresponding property on the Properties tab.

26.9.1.1 Monitoring Report

Within a Monitoring report, showing real-time monitoring statistics, the activation spec provides configuration-related information, including:

- EIS connection configurations, displayed as connection factory properties.

- Resources that are being accessed. These include Managed Connections and the Most Recent Timestamp for such connections.

- Additional tuning information, such as Currently Free Connections and Maximum Pool Size for Connections.

Figure 26-1 shows the appearance of the Monitoring report in the context of the Diagnosability and Snapshot reports. This report shows a information related to a service endpoint.

Figure 26-1 Monitoring Report Showing Statistics for a Service Endpoint

See Figure 26-1 for a description of the elements in the Monitoring Report.

Table 26-1 Adapter Monitoring Report Elements

Element

Description

Server Name

The name of the server where the endpoint is deployed.

EIS Connection Status

Indicates if the EIS is connected to the Endpoint. You can click status icon to obtain stack trace if status is Not connected.

Managed Connections

Connection pool statistics for the managed connections for this Adapter to Enterprise Information System (EIS) systems.

Currently Free

The pool size of this Connector connection pool.

Average Number Used

The running average usage of created connections that are active in the Connector Pool since the pool was last shrunk.

Currently Free

The current total free connections.

Maximum Pool Size

The maximum capacity configured for this Connector connection pool.

Most Recent Time Stamp

The most recent time stamp for last message publication and last service activation.

Last Message Publication

Last message published to the fabric for a service endpoint; last message published to the EIS for a reference endpoint.

Last Service Activation

Last time the service endpoint was activated. Only for a service endpoint.

Last Reference Interaction

Last time the reference endpoint was activated. Only for a reference endpoint.

26.9.1.2 Configuration Reports

The Configuration report within the Diagnosability Report from the Oracle Enterprise Manager Fusion Middleware Control dashboard shows a summary of connection factory, binding and activation properties for a specific service endpoint.

Figure 26-2 shows an Adapter Configuration Report for a Service Endpoint, showing Deployment Configuration Type, and information about EIS Connectivity and Service Properties, including definition properties and Tuning Properties, in this case properties that are specific to a File Adapter.

Figure 26-2 Adapter Configuration Reports

See Table 26-2 for a description of the elements in the Adapter Configuration Report.

Note that you need to select Related Links (at the top right of the page) to initiate the process of configuring a connection factory within the WebLogic Server Console.

Table 26-2 Adapter Configuration Reports Elements

Element

Description

Deployment Configuration Type

Indicates if the endpoint is part of an active-active or active-passive configuration. This is only displayed for a service endpoint.

EIS Connectivity

Provides information about connection factory properties related to this endpoint and its connection to the Enterprise Information System.

Service Properties

Lists Definition Properties, used to define services specific to this endpoint, and Tuning Properties, used to tune services specific to this endpoint. For Reference Endpoints, there are Reference Properties which include Definition Properties and Tuning Properties.

See the User's Guide to Technology Adapters appendix for the complete list and definitions of the properties.

26.9.1.3 Snapshot Reports

The Snapshot Reports section of the Service or Reference Adapter Reports Page provides connection downtime and message statistics over a specified period.

Snapshot reports aggregate historical data over a selected period of time.

The default for snapshot data persistence is 15 minutes, which is the period of time collection over which the captured data persists when Write to database is checked. You can configure the snapshot interval from the snapshotInterval property in the Properties tab. Because the default value of some properties on the Properties tab is not shown explicitly, you might need to add snapshotInterval property from the properties page and then modify it as you require. You can select Write to Database on a Report Screen to have the data persisted.

Similarly, you can add or modify enableSnapshots (enables Write to Database) and select the Enables Reports checkbox (enables Reports).

Note that you must understand each Snapshot report in the context of the functioning of the specific adapter; for example, for the Database Adapter, the payload size that is reported and displayed is the size of XML produced by the Adapter, never the size of XML consumed by the Adapter.

Where an adapter has no output, the size is reported as 0.

For the same service endpoint, you can correlate information from the Snapshot report and the Monitoring Report.

Figure 26-3 shows an example Snapshot Report, with the Message Statistics tab selected. The Report shows:

- Data will be retrieved over the last 24 hours

- The name of the server for which information is being collected

- Average Message Size, in bytes

- Maximum Message Size, in bytes

- Minimum Message Size, in bytes

- Total Message Size, in bytes

- Number of Messages

- Data Location, specifying Persisted or In-Memory, as indicated by an icon and tooltip

- Write to Database-enables data persistence. By default, the data is not persisted. Note that when enabled, persistence is enabled concurrently for both EIS Connection statistics and Message statistics at once. Once you enable persistence, the value for writes to the database is displayed (for example, "every 15 minutes".)

Figure 26-3 Snapshot Report, with Message Statistics Tab Selected

Figure 26-4 shows an example Snapshot Report, with EIS Connection Downtime, or the down shown. The Report shows:

- Server Name

- The Start EIS Downtime-when the connection downtime began

- The End EIS Downtime-when the connection downtime ended

- Error Summary-A summary of the errors that might be related to the downtime.

- Total EIS Connection Downtime.

- Data Location, specifying Persisted or In-Memory, as indicated by an icon and tooltip

- Show XML button, which when clicked on provides XML data for the information that is displayed.

Figure 26-4 Snapshot Report with EIS Connection Downtime Tab Selected

26.9.1.3.1 Snapshot Reporting Persistence and Intervals

The snapshot persistence period can provide historical data over the period the data is persisted; this period is different than the global refresh period for the Oracle Enterprise Manager Fusion Middleware Control.

You must also distinguish the Snapshot Interval (default is 15 minutes) versus the Retrieve Data period, which is defaulted to one day.

Persisted and In-memory data is shown per query criteria (that is, EIS connection downtime falls within the time range used for searching or message publication time is within the time range used for searching).

The persistence setting provides a way to guard saved data from crashes and downtime. However, there is a performance cost to retaining saved data.

A Data Location column in the reports contains either or both of two icons which signify the place of origin of the data in the reports in the appropriate row: either from persistent data or from in-memory data.

Also note that data is not persisted in the following circumstances.

For non-persisted (in-memory) data, when the following occur:

- Write to database is unchecked

- The adapter's composite application is shutdown or retired

- Composite is un-deployed

- The Adapter endpoint is de-activated (for service endpoints)

- The SOA server is bounced

- Auto purge occurred

For persisted data, data is not persisted when the following occur:

- Auto purge occurred

You can search and retrieve past data. Therefore, the Retrieve Data search control is always available for data that persists. The search feature is specific to Enterprise Information System (EIS) Connection statistics and is distinct from Message statistics.

Table 26-3 provides information about the different elements found in the Snapshot Adapter Reports and their meaning.

Table 26-3 Snapshot Adapter Report Elements

Element

Description

EIS Connection Downtime

(Only shown for the service downtime.)

Select a Time Range

The time range filter delimits the statistics displayed in the snapshot reports to a specified number of minutes, hours, days, or weeks.

Show XML

Shows the EIS connection downtime in an XML format.

Server Name

The name of the server connected to this Adapter for which messages are being displayed.

End EIS Connection Downtime

Time at which the EIS connection is restored.

Start EIS Downtime

The time at which the EIS connection is lost.

Error Summary

Select Error Summary to provide stack trace.

Message statistics

Server Name

The name of the server where this endpoint is displayed.

Average Message Size

Average message size processed for the filtered snapshot interval.

Maximum Message Size

Maximum message size processed for the filtered snapshot interval.

Minimum Message Size

Minimum message size processed for the filtered snapshot interval.

Total Message Size (Bytes)

Sum total of all the messages processed for the filtered snapshot interval.

Number of Messages

Number of messages processed for the filtered snapshot interval.

Data Location

Specifies Persisted or In-Memory, as indicated by an icon and tooltip.

Write to Database

Select this checkbox to enable persistence. The value (for example, every 15 minutes) shows how often that write to the database happens, when enabled. By default the check box is not selected. Persistence is enabled for both EIS Connection starts and Message statistics at the same time. The screen indicates the following: “Select to persist the data. Persisted data remains available in case of downtimes or crashes, or if you disable the reports; but it impacts performance.

Persistence operations involve a snapshot scheduler and repetitive I/O (disk read and write) operations. Persistent operations are different from in-memory operations because I/O operations from memory are faster than Database operations.

26.9.2 Configuration Report Categories and Adapter Properties Reported

The following tables show, for each Adapter type, the configuration report category, the available property name, and a description of each property. Although adapter configuration properties can be set at service/reference Mbean and Adapter binding Mbean, the Adapter configuration report shows only properties from the Adapter binding Mbean.

Table 26-4 MSMQ Adapter Connection Factory Properties

Property Name

Description

QueueManagerName

MQ Series Queue Manager Name

PortNumber

Port on which the Queue Manager is listening

HostName

Host on which Queue Manager is running

ChannelName

MQ Series Server Connection Channel name

CCDTurl

The url to the MQ Series CCDT file.

XATransaction

Flag which enables participation in JTA transaction

SSLEnable

Flag which enables SSL.

Table 26-5 MSMQ Adapter Service Definition Properties

Property Name

Description

QueueName

Queue on which the MQSeries Adapter is polling.

BackoutQueueName

The configured Backout Queue Name (if any).

MessageSelector

MessageSelector to filter inbound messages.

Table 26-6 MSMQ Adapter Service Tuning Properties

Property Name

Description

jca.retry.count

JCA retry count before the message is rejected.

jca.retry.interval

Time interval between the JCA retries.

payloadSizeThreshold

Decides the size of the payload that the adapter can process.

InboundThreadCount

Number of inbound polling threads to dequeue messages

Table 26-7 MSMQ Adapter Reference Definition Properties

Property Name

Description

QueueName (Enqueue)

Queue to which messages are published

QueueName (Dequeue)

Queue from which messages are dequeued

SegmentIfRequired

Flag telling whether large message should be segmented.

Table 26-8 MSMQ Adapter Reference Tuning Properties

Property Name

Description

jca.retry.count

JCA retry count before the message is rejected

jca.retry.interval

Time interval between the JCA retries

payloadSizeThreshold

This value decides the size of the payload that the adapter can process.

Table 26-9 File Adapter Connection Factory Properties

Property Name

Description

ControlDir

The directory used by the Adapter for storing book-keeping information.

InboundDataSource

Set to the datasource name to enable High availability in the inbound adapter.

OutboundLockTypeForWrite

Set to either oracle, database or coherence to enable HA on the outbound adapter.

IsTransacted

Set to true for LRC (Last Resource Commit). This applies only if you choose LocalTransaction for the transaction-supports attribute

Table 26-10 File Adapter Service Definition Properties

Property Name

Description

PhysicalDirectory

Directory to be polled by the File Adapter.

Recursive

If set to true, the File/Ftp Adapter processes files recursively in sub-directories.

DeleteFile

If set to true, the File/Ftp Adapter deletes the file after it has been processed.

PollingFrequency

This parameter specifies how often does the File/Ftp Adapter wake up in order to look for files in the inbound directory. It is specified in seconds.

MinimumAge

This parameter specifies the time interval after which a file should be picked up for processing. For example, this enables a large file to be completely copied into the directory before it is retrieved for processing. The age is determined by the last modified time. If a file is detected in the input directory and its modification time is less than 5 minutes older than the current time, the file is not retrieved because it is still potentially being written to.

PublishSize

This parameter indicates that a file contains multiple messages and specifies how many messages should be processed at one time. For example, if a certain file has 11 records and this parameter is set to 2, then the file will be processed 2 records at a time and the final record will be processed in the 6th iteration.

jca.message.encoding

This parameter is used to override the encoding specified in the NXSD schema for the inbound File/Ftp adapter.

Table 26-11 File Adapter Service Tuning Properties

Property Name

Description

ThreadCount

If this parameter is available, the adapter creates it's own processor threads rather than depending on the global thread pool processor threads (by default 4 of them). In other words, this parameter partitions the in-memory queue and each composite app gets its own in-memory queue. If the ThreadCount is set to 0, it behaves in the same manner as the SingleThreadModel. If the ThreadCount is set to -1, it begins using the global thread pool. The maximum value for this property is 40.

SingleThreadModel

If the value is true, the File/FTP Adapter poller processes files in the same thread. That is, it does not use the global in-memory queue for processing.

MaxRaiseSize

This parameter specifies the maximum number of files that the File/Ftp Adapter will submit for processing in each polling cycle. For example, if the inbound directory has 1000 files and this parameter is set to 100 and the polling frequency is one minute, then the File/FTP Adapter will submit 100 files every minute.

Table 26-12 File Adapter Reference Definition Properties

Property Name

Description

PhysicalDirectory

Directory path for outbound file write.

NumberMessages

This parameter is used for outbound batching. The outgoing file is created when the number of messages condition is met. The parameter is of type String and is not mandatory. The default value is 1.

FileNamingConvention

This parameter is for the naming convention for the outbound write operation file

Append

Setting this parameter to true. causes the File/Ftp Adapter to append to a file on the outbound. If the file does not exist, a new file is created.

ChunkSize

Set it to the Chunk Size for the chunked interaction operation.

Table 26-13 File Adapter Reference Tuning Properties

Property Name

Description

ConcurrentThreshold

The maximum number of translation activities that can be allowed to execute in parallel for a particular outbound scenario. The translation step during the outbound operation is CPU intensive and hence needs to be guarded as it might cause other applications/threads to starve. The maximum is 100 (same value as the maximum for dspMaxThreads in BPEL.)

UseStaging

If  true, then the outbound File/Ftp Adapter writes translated data to a staging file and then it streams the staging file to the target file. If  false, the outbound File/FTP Adapter does not use an intermediate staging file.

inMemoryTranslation

This parameter is applicable only if UseStaging is false If set to true, the translation step occurs in-memory i.e. an in-memory byte array is created. If set to false, then the adapter creates an output stream to the target file and allows the translator to translate and write directly to the stream.

serializeTranslation

If set to true, the translation step is serialized using a semaphore. The number of permits for semaphore (guarding the translation step) comes from ConcurrentThreshold parameter (above). If false, then the translation step occurs outside the semaphore.

Table 26-14 FTP Adapter Specific Connection Factory Properties (Properties in addition to those for file adapter)

Property Name

Description

Host

FTP server host name

Port

FTP server port

Username

FTP server user name

Password

FTP server password

DefaultDateFormat

This parameter specifies the default date format value. On the FTP server, this is the value for files that are older. The default value for this parameter is MMM d yyyy as most UNIX-type FTP servers return the last modified time stamp for older files in the MMM d yyyy format. For example, Jan 31 2012.

RecentDateFormat

This parameter specifies the recent date format value. On the FTP server, this is the value for files that were recently created.

ListParserKey

Directs the Oracle FTP Adapter how it should parse the response from the LIST command. The default value is UNIX, in which case the Oracle FTP Adapter uses a generic parser for UNIX-like FTP servers. Apart from UNIX, the other supported values are WIN /WINDOWS for Microsoft Windows NT FTP server and MVS for ftp severs running on MVS systems.

ConnectionMode

Indicates if the FTP Adapter uses the active/passive mode to connect to FTP server

UseFtps

Set to true for FTP over SSL

UseSftp

Set to true for SFTP.

Table 26-15 FTP Adapter Specific Service Definition Properties (Properties in addition to those for file adapter)

Property Name

Description

timestampOffset

This parameter is used by the FTP Adapter to address timezone issues, typically to convert the time difference between the FTP server and the system on which the FTP Adapter is running to milliseconds.

UseNlst

Set this parameter to true if you need the FTP Adapter to use the NLST FTP command rather than the LIST command that the Adapter uses by default

Table 26-16 FTP Adapter Specific Service Tuning Properties (Properties in addition to those for file adapter)

Property Name

Description

control.read.timeout

Timeout on the control socket in milliseconds.

Table 26-17 Socket Adapter Connection Factory Properties

Property Name

Description

Host

Host on which ServerSocket is running.

Port

Port on which ServerSocket is listening.

BacklogQueue

Queue length for incoming connection.

SSLEnable

Flag which enables SSL

KeepAlive

Flag to enable pooling of connection

Table 26-18 Socket Adapter Service Definition Properties

Property Name

Description

Host

Host on which ServerSocket is running

Port

Port on which ServerSocket is listening.

TransMode

Translation mode of Adapter.

Encoding

Encoding of data.

ByteOrder

ByteOrder of the data.

Table 26-19 Socket Adapter Service Tuning Properties

Property Name

Description

NIOProcessorThreadCount

Number of threads processing messages in inbound (only in NIO mode).

Table 26-20 Socket Adapter Reference Definition Properties

Property Name

Description

Host

Host on which ServerSocket is running

Port

Port on which ServerSocket is listening

TransMode

Translation mode of adapter

Encoding

Encoding of data

ByteOrder

ByteOrder of the data.

Table 26-21 UMS Adapter Connection Factory Properties

Property Name

Description

XATransaction

Specify it with value false to disable XA Transaction support on inbound. Default value is true.

Table 26-22 UMS AdapterService Definition Properties

Property Name

Description

DeliveryType

Specify the message channel to receive/send messages. Email, SMS, IM in case of receiving.

To

Address from which to receive incoming messages. One or more comma separated device addresses; for instance email addresses or mobile phone numbers.

ConsumeMode

Specifies how the adapter will receive messages from UMS. Set to poller for polling mode; set to listener for listener mode.

JavaCalloutImpl

Name of the Java class that defines custom logic for a message filtering or any other check, after message is accepted from UMS. It is a concrete implementation of ICustomCallout interface.

MessageFilters

Specify one or more message filters. A single filter would comprise of a Java Pattern String to match against incoming message's content/metadata, along with the metadata field type and the action (Accept or reject) to be taken.

Table 26-23 UMS Adapter Service Tuning Properties

Property Name

Description

InboundThreadCount

Specify the number of inbound poller or listener threads.

PollingInterval

Polling interval in seconds for poller consume mode.

Table 26-24 UMS Adapter Reference Definition Properties

Property Name

Description

DeliveryType

Specify the message channel through which to send messages. Email, SMS, IM, Voice for sending

Table 26-25 UMS Adapter Outgoing Message Properties

Property Name

Description

SendEmailAsAttachment

True to send email as an attachment.

Table 26-26 LDAP Adapter Connection Factory Properties

Property Name

Description

inboundDataSource

Jndi string location pointing to a valid XA  data source.

hostName

Host name of the directory server.

port

Port where the LDAP service is running.

bindDN

dn of the entry that will be used to bind to the LDAP service.

operationTimeout

Client-side timeout defined at the connection level. If the response is not received by the DS in the timeout period, the operation will be abandoned and an exception will be raised.

useStartTLS

Use start TLS extended operation to secure communication with a directory server over a non-encrypted channel. Port in this case is listening for clear-text LDAP Connections.

useSSL

Indicates that LDAP adapter should use SSL to secure communication with the directory server. The server must be configured to listen in SSL mode and the value for the port argument must be one where the server is listening for SSL based connections.

Table 26-27 LDAP Adapter Service Definition Properties

Property Name

Description

NotificationStrategy

How are notifications going to be polled and published. Based on the Timestamp of the changeLog and if changelog, which changeLog mechanism.

EventType

If all is selected, all the events will be published. Otherwise, a comma separated list of events type to publish will be sent.

BaseDN

Valid DN under which events should be reported.

EventScope

Scope of event source under the configured base dn.

SearchFilter

Advanced filter condition. Events that satisfy the given filter condition only will be published by the Adapter. Value should be a valid string representation of LDAP filter.

TypesOnly

When set to true, only the attribute names will be returned. Otherwise, both attribute names and values will be returned.

ReturnAttributes

A list of all the attributes to return as part of the event.

ReturnAttributesDelimiter

String regex. A delimiting regular expression.

Table 26-28 LDAP Adapter Service Tuning Properties

Property Name

Description

PollingInterval

Polling interval before conducting a subsequent search for new events.

payloadSizeThreshold

Integer value representing the byte count threshold limit of the message to be published.

SizeLimit

Maximum number of entries returned as part of a search operation. This can be configured on the DS side as well. Lower of the two values will take effect. SizeLimit is enforced within a single page.

TimeLimit

Maximum time the server should wait before returning the results.

PageSize

Max number of events that should be published in a page.

Table 26-29 LDAP Adapter Reference Definition Properties

Property Name

Description

RequestControls

The Adapter constructs the appropriate control objects from this interaction spec property and passes them along with the request message.

Table 26-30 LDAP Adapter Reference Tuning Properties

Property Name

Description

SizeLimit

Maximum number of entries returned as part of a search operation. This value can be configured on the Directory Server side as well. If so, the lower of the two values takes effect.

TimeLimit

Maximum time in seconds the server should wait before returning the results.

FollowReferrals

Referral chase strategy.

HopLimit

Maximum number of permissible hops while chasing referrals.

AliasDereferencing

Behavior for handling alias entries while processing the search.

MaxDSMLRequestSize

DSML contains a batch request. This batch request can potentially contain millions of LDAP operation requests.This property is used to control the maximum number of permissible operation requests that can be passed to the LDAP adapter through a single DSML batch request.

Table 26-31 DB Adapter Service Definition Properties

Property Name

Description

PollingStrategy

Indicates how to poll for records and what to do with them after they have been read so they are only processed once.

DescriptorName

A name generated from the root table name.

Table 26-32 DB Adapter Service Tuning Properties

Property Name

Description

PollingInterval

How often to poll for new records

MaxTransactionSize

How many records to fetch at a time and process in a single transaction (not per polling interval.)

MaxRaiseSize

How many top-level records to bundle into a single XML document and hence a single process instance.

NumberOfThreads

How many threads concurrently poll for and process records.

Table 26-33 DB Adapter Reference Definition Properties

Property Name

Description

SchemaName

The schema to which the stored procedure belongs.

PackageName

The package to which the stored procedure belongs.

ProcedureName

The name of the stored procedure being executed.

SqlString

The SQL to execute

DescriptorName

A name generated from the root table name.

QueryName

The name of the EclipseLink query being executed

IsQueryByExample

If queryName not set, SQL is built from an input XML example record

DmlType

Indicates merge, insert, update or delete.

Table 26-34 JMS Adapter Connection Factory Properties

Property Name

Description

ConnectionFactoryLocation

JMS provider connection factory.

FactoryProperties

Enables parameters that establish context for remote lookup.

IsTopic

Flag that enables you to select the connection factory based on the JMS destination (topic/queue)

IsTransacted

Flag that enables you to specify if the adapter participates in local or XA transaction.

Table 26-35 JMS Adapter Service Definition Properties

Property Name

Description

DestinationName

The name of the queue or topic.

MessageSelector

A string expression (based on a subset of the SQL92 conditional expression) specifying the messages the Adapter is interested in.

DurableSubscriber

Name used to identify a durable subscription.

PayloadType

Specifies the type of JMS message.

Table 26-36 JMS Adapter Service Tuning Properties

Property Name

Description

adapter.jms.receive. threads

Poller threads created when an endpoint is activated.

adapter.jms.receive. timeout

Timeout value used for the synchronous receive call.

adapter.jms.retry. interval

The time for which the Oracle JMS Adapter waits before trying to re-create a connection after a connection is lost.

Table 26-37 JMS Adapter Reference Definition Properties

Property Name

Description

DestinationName

Name of the queue or topic

TimeToLive

Represents the message's lifetime (in milliseconds)

Priority

Represents the priority for the message.

PayloadType

Specifies the type of JMS message

DeliveryMode

Represents the delivery mode to use.

Table 26-38 JMS Adapter Reference Tuning Properties

Property Name

Description

adapter.jms.receive. timeout

Timeout value used for the synchronous receive call.

adapter.jms.retry. interval

The time for which the Oracle JMS Adapter waits before trying to re-create a connection after a connection is lost.

Table 26-39 AQ Adapter Connection Factory Properties

Property Name

Description

XADataSourceName

datasource name for xa transactions

DataSourceName

datasource name for local transactions

Table 26-40 AQ Adapter Service Definition Properties

Property Name

Description

QueueName

The name of the AQ Queue.

DatabaseSchema

The schema where the queue resides

Consumer

Dequeue message for a given consumer

ObjectFieldName

Identifies the field containing the business payload if the queue is an ADT queue.

PayloadHeaderRequired

Ensures all non- payload attributes of ADT are available for processing.

Correlation

Dequeues messages that match the value specified

DequeueCondition

Expression to allow dequeue of message based on a specific condition.

Table 26-41 AQ Adapter Service Tuning Properties

Property Name

Description

DequeueTimeOut

The interval after which the dequeue() API times out if no message is received on the inbound queue.

adapter.aq.dequeue. threads

Specifies the number of poller threads that are created when an endpoint is activated.

Table 26-42 AQ Adapter Reference Definition Properties

Property Name

Description

QueueName

The name of the AQ Queue

DatabaseSchema

The schema where the queue resides.

ObjectFieldName

Identify the field containing the business payload if the queue is an ADT queue.

PayloadHeaderRequired

Ensures all non- payload attributes of ADT are available for processing.

RecipientList

Specify the consumer name or names that are the intended recipients for the messages enqueued by the Adapter.

Table 26-43 Coherence Adapter Connection Factory Properties

Property Name

Description

CacheConfigLocation

Location of cache configuration file that defines the cache and extend client settings.

ServiceName

Name of the cache service to be associated with the connection

Table 26-44 Coherence Adapter Reference Definition Properties

Property Name

Description

CacheName

Identifies a particular Coherence cache

CacheOperation

The operation to be carried out on the Cache identified by CacheName.

Filter

Used to specify the subset of cache to which the operation should be applied.

ValueType

Fully qualified class name that identifies the object stored to/retrieved from cache.

ReturnCacheKeysOnly

Boolean that allows for only Cache identifiers (keys) to be returned

Key

Identifier for a Cache Entry

KeyType

Identifies the java type of the value to be used as the key.

Table 26-45 Coherence Adapter Reference Tuning Properties

Property Name

Description

payloadSizeThreshold

PayloadSizeThreshold decides the size of the payload that Adapter can process

Table 26-46 MSMQ Adapter Connection Factory Properties

Property Name

Description

Host

Name of the MSMQ host.

Domain

Windows Domain name of the MSMQ host.

AccessMode

Identifies if the connection factory will allow for native access or not.

TransactionMode

Identifies if the connection will participate in a transaction when sending and receiving a message.

Table 26-47 MSMQ Adapter Service Definition Properties

Property Name

Description

DestinationType

Identifies the type of queue

DestinationName

Name of the MSMQ queue.

DestinationPath

The actual string that identifies a DistributionList or Public queue as represented in ActiveDirectory

UseActiveDirectoryPath

Boolean that allows for Active Directory Path to be used to identify a public queue instead of queue name.

UseDirectFormatName

Boolean that allows for Direct Format name to be used for public and private queues.

Correlation

Correlation identifier.

Table 26-48 MSMQ Adapter Service Tuning Properties

Property Name

Description

adapter.msmq.receive.timeout

The time (in milliseconds) that Message Queuing will wait for a message to arrive before starting

Table 26-49 MSMQ Adapter Another Poll-Cycle

Property Name

Description

adapter.msmq. dequeue.threads

Number of poller threads that will be initialized when endpoint activation occurs.

Table 26-50 MSMQ Adapter Reference Definition Properties

Property Name

Description

DestinationType

Identifies the type of queue

DestinationName

Name of the MSMQ queue.

DestinationPath

The actual string that identifies a DistributionList or Public queue as represented in ActiveDirectory.

UseActiveDirectoryPath

Boolean that enables the Active Directory Path to be used to identify a public queue instead of queue name.

UseDirectFormatName

Boolean that enables the Direct Format name to be used for public and private queues.

Priority

Message priority

TimeToLive

The property specifies a time limit (in seconds) for the message to be retrieved from the target queue.

Delivery

The property is used to specify express (non-persistent) or recoverable (persistent) messaging.

Table 26-51 SAP Adapter Connection Factory Properties

Property Name

Description

ServerDataProvider_JCO_gwhost

Gateway host

ServerDataProvider_JCO_gwserv

Gateway service

ServerDataProvider_JCO_progid

Program ID of the server.

ServerDataProvider_JCO_trace

Enable/disable RFC trace.

ServerDataProvider_JCO_params

Arbitrary parameters for RFC library

ServerDataProvider_JCO_snc_myname

SNC name.

ServerDataProvider_JCO_snc_qop

SNC level of security.

ServerDataProvider_JCO_snc_lib

Path to the SNC library.

ServerDataProvider_JCO_unicode

Flags whether to connect in unicode mode.

ServerDataProvider_JCO_max_startup_delay

Maximum server startup delay time in seconds.

ServerDataProvider_JCO_connection_count

Maximum server connection threads allowed.

ServerDataProvider_JCO_dsr

Enable/Disable dsr support.

DestinationDataProvider_JCO_client

SAP client

DestinationDataProvider_JCO_user

Logon user

DestinationDataProvider_JCO_alias_user

Logon user alias

DestinationDataProvider_JCO_passwd

Logon password

DestinationDataProvider_JCO_lang

Logon language

DestinationDataProvider_JCO_saprouter

SAP router string to use for a system prot.ected by a firewall

DestinationDataProvider_JCO_sysnr

SAP system number.

DestinationDataProvider_JCO_ashost

SAP application server

DestinationDataProvider_JCO_mshost

SAP message server

DestinationDataProvider_JCO_msserv

Optional: SAP message server port to use instead of the default sapms sid

DestinationDataProvider_JCO_gwhost

Gateway host

DestinationDataProvider_JCO_gwserv

Gateway service

DestinationDataProvider_JCO_r3name

System ID of the SAP system

DestinationDataProvider_JCO_group

Group of SAP application servers

DestinationDataProvider_JCO_tpname

Program ID of external server program

DestinationDataProvider_JCO_tphost

Host of external server program

DestinationDataProvider_JCO_type

Type of remote host

DestinationDataProvider_JCO_trace

Enable/disable RFC trace

DestinationDataProvider_JCO_cpic_trace

Enable/disable CPIC trace

DestinationDataProvider_JCO_use_sapgui

Start a SAP GUI and associate with the connection

DestinationDataProvider_JCO_codepage

Initial codepage in SAP notation

DestinationDataProvider_JCO_getsso2

Get/Don't get a SSO ticket after logon

DestinationDataProvider_JCO_mysapsso2

Use the specified SAP Cookie Version 2 as logon ticket

DestinationDataProvider_JCO_x509cert

Use the specified X509 certificate as logon ticket

DestinationDataProvider_JCO_lcheck

Enable/Disable logon check at open time

DestinationDataProvider_JCO_snc_mode

Secure network connection mode

DestinationDataProvider_JCO_snc_partnername

SNC partner

DestinationDataProvider_JCO_snc_qop

SNC level of security

DestinationDataProvider_JCO_snc_myname

SNC name. Overrides default SNC partner

DestinationDataProvider_JCO_snc_lib

Path to library which provides SNC service

DestinationDataProvider_JCO_dsr

Enable/Disable dsr support

DestinationDataProvider_JCO_peak_limit

Maximum number of active connections that can be created for a destination simultaneously

DestinationDataProvider_JCO_pool_capacity

Maximum number of idle connections kept open by the destination. A value of 0 has the effect that there is no connection pooling.

DestinationDataProvider_JCO_expiration_time

Time in ms after that the connections hold by the destination can be closed.

DestinationDataProvider_JCO_expiration_check_period

Period in ms after that the destination checks the released connections for expiration.

DestinationDataProvider_JCO_max_get_client_time

Max time in ms to wait for a connection, if the max allowed number of connections is allocated by the application.

DestinationDataProvider_JCO_repository_destination

Specifies which destination should be used as repository, i.e. use this destination's repository.

DestinationDataProvider_JCO_repository.user

If repository destination is not set, and this property is set, it will be used as user for repository calls. This allows using a different user for repository lookups.

DestinationDataProvider_JCO_repository.passwd

The password for a repository user. Mandatory, if a repository user should be used.

DestinationDataProvider_JCO_repository.snc_mode

If SNC is used for this destination, it is possible to turn it off for repository connections, if this property is set to 0. Defaults to the value of DestinationDataProvider_JCO_snc_mode,

Table 26-52 SAP Adapter Service Definition Properties

Property Name

Description

Type

SAP object type

BAPIName

Name of BAPI object

RFCName

Name of RFC object

IDOCName

Name of IDOC object

ProgramID

Program ID registered at SAP

AutoSYSTAT01

Auto SYSTAT01 acknowledgment IDOC

EncodeIDOC

Encode IDOC in flat file format

Migration

Migration support for older SAP adapter

Table 26-53 SAP Adapter Reference Definition Properties

Property Name

Description

Type

SAP object type

BAPIName

Name of BAPI object

RFCName

Name of RFC object

IDOCName

Name of IDOC object

QueueName

Name of SAP inbound queue to send

Interaction

Stateful or stateless interaction

Migration

Migration support for older SAP adapter

Table 26-54 Oracle E-Business Suite Adapter Connection Factory Properties

Property Name

Description

XADataSourceName

datasource name for xa transaction

DataSourceName

datasource name for local transactions

Table 26-55 Oracle E-Business Suite Adapter Service Definition Properties

Property Name

Description

IRepInternalName

Internal name of the EBS interface from Integration Repository

PollingStrategy

How to poll for records and what to do with them after they have been read so they are only processed once.

DescriptorName

A name generated from the root table name.

QueueName

The name of the AQ Queue.

DatabaseSchema

The schema where the queue resides.

Consumer

Dequeue message for a given consumer.

Correlation

Dequeues messages that match the value specified.

DequeueCondition

Expression to allow dequeue of message based on a specific condition.

AppsEventSchema

Custom schema for business events payload.

Table 26-56 Oracle E-Business Suite Adapter Service Tuning Properties

Property Name

Description

PollingInterval

How often to poll for new records.

MaxTransactionSize

How many records to fetch at a time and process in a single transaction (not per polling interval)

MaxRaiseSize

How many top-level records to bundle into a single XML document and hence a single process instance

NumberOfThreads

How many threads concurrently poll for and process records

DequeueTimeOut

Interval after which the dequeue() API times out if no message is received on the inbound queue

adapter.aq.dequeue.threads

Specifies the number of poller threads that are created when an endpoint is activated.

Table 26-57 Oracle E-Business Suite Adapter Reference Definition Properties

Property Name

Description

IRepInternalName

Internal name of the EBS interface from Integration Repository

SchemaName

The schema to which the stored procedure belongs.

PackageName

The package to which the stored procedure belongs

ProcedureName

The name of the stored procedure being executed.

SqlString

The SQL to execute

DescriptorName

A name generated from the root table name.

QueryName

The name of the EclipseLink query being executed.

IsQueryByExample

If queryName not set, SQL is built from an input XML example record.

DmlType

Indicates merge, insert, update or delete.

DataSecurityCheck

Enables EBS function security check

APIErrorHandler

To retrieve error messages from FND_MSG_PUB message stack

QueueName

The name of the EBS Queue

DatabaseSchema

The schema where the queue resides

IRepOverloadSequence

Overload sequence from Integration Repository.

AppsFlexConfigFile

flexfield mapping configuration file name.

26.10 Scheduling JCA Adapter Endpoint Activation and Deactivation using Oracle Enterprise Scheduler

You can schedule activation and deactivation of the SOA composite JCA Adapter Services from Oracle Enterprise Manager Fusion Middleware Control.

Using Oracle Enterprise Scheduler schedule metadata you provide, you can:

- Schedule a request for composite JCA Adapter service activation.

- Schedule a request for composite JCA Adapter service deactivation.

Oracle Enterprise Manager Fusion Middleware Control also displays the current state of an Adapter endpoint (composite service), which can be either active or inactive.

You can also edit existing metadata to alter your schedule, and you can remove schedules for Adapters.

Note:

Because the Oracle Enterprise Scheduler installation is optional, this feature is not be available if the Oracle Enterprise Scheduler is not installed.

Follow these steps to schedule activation and deactivation of the SOA composite JCA Adapter Services:

- Create the Schedule Metadata

- Use the Created Schedule Metadata to Schedule the Deactivation and Activation of a SOA Composite JCA Adapter

- Editing Oracle Enterprise Scheduler Schedule Metadata

- Removing Schedules from an Adapter Endpoint

26.10.1 Create the Schedule Metadata

To create the schedule metadata, you fill in a form by selecting Define Schedules. The form populates the metadata.

1. In Oracle Enterprise Manager Fusion Middleware Control, login to the Scheduling Services page, and navigate to the SOA Infrastructure menu -> Define Schedules page by using the Scheduling Services menu.

2. The next Oracle Enterprise Scheduler page lists schedules for submitting jobs.

3. On this page, select the Create button to launch the page that helps create the schedule metadata.

4. Define the schedule metadata on this page. Provide a name for the schedule, a display name, a description, frequency of activation and deactivation and start date of the schedule. Ensure you create the schedule metadata in the /oracle/apps/ess/custom/soa package.

26.10.2 Use the Created Schedule Metadata to Schedule the Deactivation and Activation of a SOA Composite JCA Adapter

You next use the metadata you have created to schedule the deactivation and activation of an Adapter.

1. Once the schedule is created, navigate back to the SOA Composite home page, and then to the Services and References page of the Composite Application or the SOA Infra page (to see Services and References across Composites).

2. In the Service home page, select a JCA Adapter. Select the icon provided in the top-right of the page to launch the popup to schedule the deactivation. The icon is shown in on the right side. This button activates or deactivates the endpoint when selected. It provides a manual way to activate or deactivate the schedule.

3. The popup has two sections: Deactivate and Activate. Each section has a drop-down that displays the saved schedule. Select an activation and a deactivation schedule, and select the Apply Schedules button to enable automated activation for this adapter or to refresh already applied schedules. (Both sections are mandatory.)

The Adapter endpoint status is shown with an icon on the service home page.

Select Remove Schedules to stop automated activation/deactivation for this adapter

If the Adapter already has activate/deactivate schedules set, you have the option to cancel them and to add a new schedule, or simply to cancel the schedule.

When a drop-down list appears blank, this indicates that the endpoint is no longer associated with a schedule.

26.10.3 Editing Oracle Enterprise Scheduler Schedule Metadata

You can edit existing metadata you have created using the Oracle Enterprise Scheduler/Oracle Enterprise Manager Fusion Middleware Control page. To do so:

1. Navigate to the Scheduling Services -> Job Requests -> Define Schedules page by using the Scheduling Services menu.

2. The existing schedules will be listed in the table. Select the one you want to modify and to select the Edit button on the table's toolbar.

3. The Edit Schedule metadata screen opens and displays the current state of the Schedule. Click the Change Frequency button.

4. Click Yes on the warning popup that is displayed.

5. The Schedule opens up in a editable mode, and you can make necessary modifications. If you change the schedule, it does not automatically apply to adapter activate/deactivate requests that have already been issued with that schedule. You have to reissue the activate/deactivate requests.

26.10.4 Removing Schedules from an Adapter Endpoint

You can remove schedules from an Adapter Endpoint. To do so:

1. After deactivation and activation schedules have been attached to the Adapter endpoint, the icon reflects the state accordingly. Select this icon to display the popup with schedules associated with this Adapter pre-selected.

2. Select the Remove Schedules button to remove the schedules from this Adapter endpoint.

3. A confirmation dialog appears. Click Ok to remove the schedules.

26.11 Monitoring Adapter Resiliency

Resiliency deals with downstream service outages or connectivity issues that cause failures to build up within SOA. Within the context of JCA Technology Adapters, this means dealing with downstream service outages related to Adapters.

If a downstream endpoint is down or behaving sporadically, a large number of instances are forwarded to the error hospital and have to be recovered. If the endpoint is down, machine resources are wasted, as they partially process instances which are not going to complete anyway. The solution is to suspend upstream inbound adapters. With failure resiliency in place, messages wait in a queue or a topic until the endpoint is resumed.

To use resiliency, the first step is to enable it. You can enable it globally: each downstream endpoint inherits the failure resiliency configuration but you can override this resiliency for that one endpoint.

Once the upstream endpoint is suspended, periodically, one or a few messages are let into the flow. If the downstream endpoint is detected as clear, the upstream endpoint automatically resumes.

The Resiliency feature determines when a downstream endpoint is down based on system errors based on error rate heuristics (that is, M failures in N minutes.)

It then disables/suspends upstream endpoints where messages originated and leaves incoming messages in the natives system rather than erring out in SOA (Adapters, WebServices)

EDN events are still queued up in the system but not read by the subscriber.

The Resiliency feature supports JMS, AQ, DB, File and FTP Adapters.

WebService requests will be rejected.

The Resiliency feature monitors downstream endpoints and determine when the endpoints come back up by periodically processing inbound requests and re-enabling upstream endpoints if there is success in enabling a message to go through.

Resiliency provides Fusion Middleware Control dashboard notification and history for disabled endpoints; re-enabled status of upstream endpoints and enables upstream endpoints to be resumed from Fusion Middleware Control.

For complete information, see the section on resiliency in this guide.

26.11.1 Adapter Properties for Resiliency

You can define adapter properties in Fusion Middleware Control (in Adapter properties screen) and by using JDeveloper, the WebService properties are set using MBeans in Fusion Middleware Control and the same way as Adapters in JDev (composite bindings). Note that EDN subscribers cannot override resiliency properties.

Part X Administering Oracle B2B and Oracle Healthcare

This part describes how to administer Oracle B2B and Oracle Healthcare.

This part includes the following chapters:

- Configuring Oracle B2B

- Monitoring Oracle B2B

- Monitoring Oracle Healthcare

27 Configuring Oracle B2B

This chapter describes how to configure Oracle B2B to view data on B2B Bindings and configure Oracle B2B operations and attributes.

This chapter includes the following topics:

- Configuring Oracle B2B Server Properties

- Configuring Oracle B2B Operations

- Configuring Oracle B2B Attributes

- Configuring Oracle B2B Logging Mode

For more information about Oracle B2B tuning and performance properties, see Tuning Performance.

27.1 Configuring Oracle B2B Server Properties

You can configure the Enable Metrics property on the B2B Server Properties page of Oracle Enterprise Manager Fusion Middleware Control.

The metrics are enabled by default, and include data on the top five recently active document types, top five recently active trading partners, and inbound and outbound endpoints.

Note:

You do not need to restart the server after changing this property.

To configure Oracle B2B server properties:

1. From the SOA Infrastructure menu, select SOA Administration > B2B Server Properties.

2. Select Enable Metrics to view data on the B2B Bindings and SOA composite pages.

For information about using Oracle B2B, which enables the secure and reliable exchange of business documents between an enterprise and its trading partners, see User's Guide for Oracle B2B.

27.2 Configuring Oracle B2B Operations

You can configure the properties of Oracle B2B operations by setting values using the System MBean Browser.

Note:

Restarting the SOA server is required after updating the following MBean properties:

- b2b.inboundThreadCount

- b2b.outboundThreadCount

To specify Oracle B2B operation properties:

Note:

To access the Application Defined MBeans for Oracle B2B, you can also click the More B2B Configuration Properties link on the B2B Server Properties page.

1. Expand the SOA node and select the soa-infra node.

Note:

You can also use Search and search for B2BConfig.

2. From the SOA Infrastructure menu, choose Administration > System MBean Browser.

The System MBean Browser page is displayed.

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

4. Expand the manage server name node.

5. Expand the B2BConfig node.

6. Click the b2b MBean.

The properties of the MBean are displayed in the right pane.

7. Click the Operations tab.

8. Click an operation in the list.

9. Provide the needed information (key, value, and an optional comment) and click Invoke.

See Appendix "Setting Oracle B2B Configuration Properties in Fusion Middleware Control" in User's Guide for Oracle B2B for a list of property names and valid values, including properties for turning off validation during deployment, setting the MDS cache size, setting thread count and thread sleep time, specifying how functional acknowledgments are handled, setting payload obfuscation, and more.

27.3 Configuring Oracle B2B Attributes

You can configure Oracle B2B attributes by setting values using the System MBean Browser.

To specify Oracle B2B attribute properties:

1. Expand the SOA node and select the soa-infra node.

2. From the SOA Infrastructure menu, choose AdministrationSystem MBean Browser.

3. Click the Attributes tab.

4. Click Properties.

5. Expand Property_0, Element_1, and so on to find the property you want to change.

6. Note the property name and value, and click Return.

For example, under Element_3, you see the b2b.payloadObfuscation property with the default value false.

7. Click the Operations tab.

8. Click setProperty.

9. Enter values for the key, value, and optional comments.

For example, to enable payload obfuscation, set b2b.payloadObfuscation to true.

10. Click Invoke.

11. Click Return.

27.4 Configuring Oracle B2B Logging Mode

You can configure the logging mode for Oracle B2B by using Oracle Enterprise Manager Fusion Middleware Control.

For example, to set the log mode to TRACE mode (DEBUG):

1. Expand the SOA node and select the soa-infra node.

2. From the SOA Infrastructure menu, select Logs, and then Log Configuration.

3. In the Log Configuration page, expand oracle.soa.

4. Use the Oracle Diagnostic Logging Level (Java Level) list to select TRACE:32 (FINEST) for oracle.soa.b2b.

5. Click Apply.

Note:

For more information about log files and the level and type of logging information to write to a log file, see Oracle Fusion Middleware Administrator's Guide.

28 Monitoring Oracle B2B

This chapter describes how to monitor Oracle B2B, including monitoring the Oracle B2B infrastructure, viewing Oracle B2B binding component message flow, viewing services and references, and accessing Oracle B2B reports from the Oracle B2B composite flow trace page.

This chapter includes the following topics:

- Monitoring the Oracle B2B Infrastructure

- Accessing Oracle B2B from the B2B Infrastructure Page

- Viewing the Message Flow of an Oracle B2B Binding Component

- Viewing Services and References

- Accessing Oracle B2B Reports from the Oracle B2B Composite Flow Trace Page

28.1 Monitoring the Oracle B2B Infrastructure

To monitor the Oracle B2B infrastructure, metrics must be enabled (the default) on the B2B Server Properties page. Use the B2B Server Properties link under Related Links on the B2B Infrastructure (SOA Binding) page to change the setting.

See Configuring Oracle B2B Server Properties, for more information on enabling metrics.

Table 28-1 describes the information displayed on the B2B Infrastructure (SOA Binding) page.

Table 28-1 B2B Infrastructure (SOA Binding)

Section/Column

Description

Top 5 Recently Active Document Types

Shows the active document types with the maximum number of messages exchanged (inbound and outbound combined) during the current session of the server.

The document types listed in this section are from Oracle DMS metrics, triggered by runtime sensors. This data is not persisted. Therefore, if Oracle B2B is restarted, then new data based on Oracle B2B activity appears here.

Number of Messages Processed

Shows the number of document messages exchanged between the host and trading partners. Outbound indicates messages sent from the host to the trading partner and Inbound indicates messages sent from the trading partner to the host.

Average Message Processing Time (sec)

Shows the average document processing time, in seconds, for both outbound and inbound messages.

Average Message Size (kb)

Shows the average document size, in kilobytes, for both outbound and inbound messages.

Errors

Shows the document error count.

Top 5 Recently Active Trading Partners

Shows the active trading partners with the maximum number of messages exchanged (from and to combined) during the current session of the server.

The trading partners listed here are from Oracle DMS metrics, triggered by runtime sensors. This data is not persisted. Therefore, if Oracle B2B is restarted, then new data based on Oracle B2B activity appears here.

Number of Messages Processed

Shows the number of messages sent and received between the host and trading partners. From indicates messages sent from this partner to its trading partner. To indicates messages received by this partner from the trading partner.

Average Message Processing Time (sec)

Shows the average document processing time, in seconds, for exchanged messages.

Average Message Size (kb)

Shows the average document size, in kilobytes, for exchanged messages.

Errors

Shows the document error count.

Inbound Endpoints

Shows the status of the listening endpoints at the time the connection was attempted (not for a later point in time). For example, in an EDI transaction using Generic File transport, when Oracle B2B reads from a directory, that directory is the inbound endpoint.

Protocol

Shows the type of transport protocol used in the exchange, for example, File, AQ, and FTP, among others.

Endpoint

Shows the location from which messages are received. The endpoint can be a URL, folders, or path, among others.

Status

Shows the status (up or down) of the endpoint (protocol) the last time a connection was attempted.

Outbound Endpoints

Shows the status of the delivery endpoints at the time the delivery was attempted (not for a later point in time). For example, in an EDI transaction using Generic File transport, when Oracle B2B writes to a directory, that directory is the outbound endpoint.

Protocol

Shows the type of transport protocol used in the exchange, for example, File, AQ, and FTP, among others.

Endpoint

Shows the location to which messages are sent. The endpoint can be a URL, folders, or path, among others.

Status

Shows the status (up or down) of the endpoint (protocol) the last time a delivery was attempted.

To monitor the Oracle B2B infrastructure using Oracle Enterprise Manager Fusion Middleware Control:

1. Expand the SOA node.

2. Select the SOA Infrastructure, for example, soa-infra (soa_server1).

3. From the SOA Infrastructure menu, select Bindings > B2B.
See Table 28-1 for a description of the information displayed.

Information displayed in Fusion Middleware Control is based on DMS metrics, including inbound and outbound endpoints. Therefore, changes to Oracle B2B runtime data are not necessarily or immediately reflected in Fusion Middleware Control.

For example, if you purge runtime data or make Oracle B2B configuration changes in the Oracle B2B interface, the changes do not affect DMS metrics. To view current runtime data, use the Oracle B2B interface. Fusion Middleware Control data shows Oracle B2B message traffic from the time that the Oracle B2B (SOA) server starts.

28.2 Accessing Oracle B2B from the B2B Infrastructure Page

Use the B2B Console link under Related Linksto log in to Oracle B2B.

Figure 28-1 Accessing Oracle B2B from Oracle Enterprise Manager Fusion Middleware Control

See User's Guide for Oracle B2B for information on using the Oracle B2B interface.

28.3 Viewing the Message Flow of an Oracle B2B Binding Component

Use these instructions to view the message flow of an Oracle B2B binding component in a business flow instance.

1. Select a SOA composite application with an Oracle B2B binding component.

A list of the recent instances is displayed in the Dashboard page.

2. To see all instances of this SOA composite application, click the Instances tab.

Note:

You can see details of a specific message by searching on the instance ID on the Reports page of the Oracle B2B interface.

3. Click a specific instance in the Instance ID list to see faults and the flow trace.

The Flow Trace page displays the following details:

- The Faults section shows the faults occurring and sensor information collected in the services, service components, and references that comprise the SOA composite application.

- The Trace section shows the sequence of the message flow through the services, service components, and references that comprise the SOA composite application.

28.4 Viewing Services and References

When Oracle B2B is used as a service (inbound), it receives messages from trading partners and delivers them to SOA composite applications. When Oracle B2B is used as a reference (outbound), it sends messages from the SOA composite application to partners.

The Dashboard page for a composite application lists the services and references used in the composite.

Details of the Oracle B2B reference shown in Figure 28-2, B2B_Send_ebMS_PO, are displayed on the Reference home page.

Figure 28-2 The Oracle B2B Reference, B2B_Send_ebMS_PO

The Instances and Faults section shows the number of outgoing messages and the number of faults since the server was started. See Table 28-1 for a description of the Top 5 Recently Active Trading Partners section.

The Recent Faults section lists the faults, including details such as the error message, time of the fault, and the associated business flow instance ID. Faults can be on the incoming messages processed by a service binding component or on the outgoing messages processed by a reference binding component.

While all errors appear in the Oracle B2B console, only a subset of faults appears in Oracle Enterprise Manager Fusion Middleware Control. This subset includes all inbound messages containing an error after trading partner identification in Oracle B2B.

See Monitoring the ,and Monitoring Service and Reference Binding Components for more information.

28.5 Accessing Oracle B2B Reports from the Oracle B2B Composite Flow Trace Page

The Oracle B2B composite Flow Trace page displays Oracle B2B faults and traces. Click an instance to open the Oracle B2B console and view a report.

29 Monitoring Oracle Healthcare

This chapter describes how to enable and configure an audit trail of user activity for healthcare integration components and applications. Oracle SOA Suite for healthcare integration uses Oracle's Common Audit Framework to log user activity against healthcare integration components.

This chapter includes the following sections:

- Introduction to the Audit Trail

- Configuring the Healthcare Integration Audit Trail

- Viewing User Audit Logs

29.1 Introduction to the Audit Trail

The Oracle auditing framework collects and stores information about events affecting configured components, providing an audit log of activity for those components to help support your compliance requirements. Auditing for each SOA Suite component is defined by an audit policy that defines which components and which activities are captured in the audit log.

You can configure the audit policy to only capture the information you need and ignore the rest. This is done on the Audit Policy page of Oracle Enterprise Manager. See "Managing Audit Policies" in the Oracle Fusion Middleware Application Security Guide for more information.

The set of auditable events for each application and component is defined by the audit policy and differs between each application. When you expand the list of events for a component, only those events that can be audited for that component appear in the list. For each event, you can further specify whether to only log successful attempts or failed attempts (currently Oracle SOA Suite for healthcare integration only logs successful attempts).

When you configure auditing, you can select from the following audit levels:

- Low: This option selects a subset of events from all auditable components in the audit policy list, including a subset of Oracle SOA Suite for healthcare integration events. It does not allow custom filters to be created.

- Medium: This option selects a larger subset of events from all auditable components in the audit policy list, including all Oracle SOA Suite for healthcare integration events. It does not allow custom filters to be created.

- Custom: This options lets you select only those components, events, and conditions that you want to audit. This is the recommended level for Oracle SOA Suite for healthcare integration. You need to select this level in the Oracle Enterprise Manager console to enable Oracle Healthcare auditing.

You can also specify a list of users whose activity is audited regardless of the actions performed or the component used. Auditing occurs for these users no matter what audit level or filters are defined.

For more information about audit policies, see Configuring and Managing Auditing in the Oracle Fusion Middleware Application Security Guide.

29.1.1 Oracle SOA Suite for Healthcare Integration Auditing Options

The components and events available for auditing are listed on the Audit Policy page of Oracle Enterprise Manager (Weblogic domain > Security > Audit Policy). To configure the these options, select Oracle SOA Suite for Healthcare from the Audit Component Name list, Custom from the Audit Level list, and click the check boxes adjacent to the events as displayed in Figure 29-1.

Figure 29-1 Healthcare Integration Components on the Audit Policy Page

Note:

Currently only the SUCCESS events are audited. You should not select FAILURE events.

Currently, the following components and events are supported for audit in Oracle SOA Suite for healthcare integration (note that additional events appear in the list, but they are not currently logged):

- User Session

- User Login

- User Logout

- Endpoint Management

- Create Endpoint

- Enable Endpoint

- Disable Endpoint

- Delete Endpoint

- Document Management

- Create Document Definition

- Update Document Definition

- Delete Document Definition

- Resubmit Message

- Purge Message

- Resubmit Message

- Purge Message

- Read Payload

- Configuration

- Import

- Export

- Create Internal Delivery Channel

- Delete Internal Delivery Channel

- Create Mapset

- Delete Mapset

29.1.2 Oracle B2B Auditing Options

The Oracle B2B components and events available for auditing are listed on the Audit Policy page of Oracle Enterprise Manager. To view or configure the Oracle B2B options, expand the nodes under SOA_B2B.

The available components and events for audit in Oracle B2B include the following:

- User Session

- User Login

- User Logout

- Document Management

- Create Document Definition

- Update Document Definition

- Delete Document Definition

- Resubmit Message

- Purge Message

- Read Payload

- Configuration

- Import

- Export

- Create Batch

- Delete Batch

- Update Batch

- Create Schedule Downtime

- Delete Schedule Downtime

- Create Mapset

- Delete Mapset

- Partner Management

- Create Trading Partner

- Delete Trading Partner

- Agreement Management

- Create Agreement

- Delete Agreement

- Edit Agreement

- Deploy Agreement

- Activate Agreement

- Inactivate Agreement

- Retire Agreement

- Purge Agreement

- Channel Management

- Create Delivery Channel

- Delete Delivery Channel

- Create Internal Delivery Channel

- Delete Internal delivery Channel

- Create Listening Channel

- Edit Listening Channel

- Delete Listening Channel

- User Management

- Add user Roles

- Remove User Roles

- Add Supported Document Definition

- Remove Supported Document Definition

29.1.3 Using Filter Conditions for Auditing

For each event, you can define filters for the success condition. Filters use rule-based expressions that are based on the attributes of the event. For most Oracle SOA Suite for healthcare integration user access auditing, you can use the following attributes in your filter expressions:

- Host ID

- Host Network Address

- Initiator

- Client IP Address

- Resource

- Domain Name

Expressions can include AND and OR operators, as well as a variety of comparison functions, such as equals, starts with, contains, does not equal, and so on.

29.2 Configuring the Healthcare Integration Audit Trail

You configure audit policies in Oracle Enterprise Manager by selecting the events or components to include in the audit log. Currently, Oracle B2B components and events are not included in the audit trail.

There are two default configurations, Low and Medium audit levels, that select a predefined subset of components or events. These are not recommended for Oracle SOA Suite for healthcare integration because they affect all auditable components, not just the components of Oracle SOA Suite for healthcare integration. Selecting either of these options can result in extraneous audit entries and unnecessarily large audit logs. Additionally, these two options do not allow you to define any filters.

The following instructions apply to custom-level audit policy configuration.

To configure auditing for healthcare integration

1. Login to Oracle Enterprise Manager.

2. In the navigation panel on the left, expand WebLogic Domain and then right-click the name of the domain for which you want to enable user auditing.

3. In the context menu that appears, point to Security and then select Audit Policy.

4. In the Audit Level field, select Custom.

Check boxes appear in the Select for Audit column so you can select which healthcare integration components and events to audit.

5. Click event categories such as User Session to display the list of events pertaining to that category below.

6. Do any of the following:

- To enable auditing for all Oracle SOA Suite for healthcare integration components and events, click the Audit All Events button.

- To enable auditing for all events for a specific component, click the check box in the Select for Audit column next to the component name.
For example, to audit all actions taken against endpoints, select the check box for Endpoint Management.

- To enable auditing of a specific event for a component, expand the component and select the check box in the Enable Audit column next to the event name under that component.

7. To define a filter for a success condition, select Enable Audit for the success condition, and then click its Edit Filter icon. Define the filter on the dialog that appears, and then click OK.

For more information about filters, see Using Filter Conditions for Auditing and the online help available from the Edit Filter dialog. Note that filters can only be defined for success conditions at this time.

8. To specify a list of users whose activity is always audited regardless of the component configuration, enter a list of user accounts in the Users to Always Audit section. Separate the account names with commas.

9. When you are done configuring auditing, click Apply.

10. Restart the server in order for the changes to take effect.

29.3 Viewing User Audit Logs

When an event triggers an audit log entry, the event information is written to the audit log file. The audit log captures the information listed here.

Depending on the type of event that triggered the entry, several of these fields might be empty.

- Date and time

- Initiator of the event

- Event type

- Event status

- Message text (indicating what occurred)

- ECID

- RID

- Context fields

- Session ID

- Target component type

- Application name

- Event category

- Thread ID

- Failure code

- Remote IP address

- Target

- Resource

- Roles

- Authentication method

- Reason

You can view the audit log file directly. It is written to the following location:

fmw_home/user_projects/domains/domain_name/servers/managed_server_name/logs/auditlogs/healthcare/audit_1_0.log

Part XI Administering Binding Components

This part describes how to administer binding components.

This part includes the following chapters:

- Configuring Service and Reference Binding Components

- Monitoring Service and Reference Binding Components

- Managing Service and Reference Binding Components

30 Configuring Service and Reference Binding Components

This chapter describes how to configure runtime properties for web service, REST, and JCA adapter binding components in SOA composite applications. Binding components are network protocols and services that connect the SOA platform with the outside world.

This chapter includes the following topic:

- Configuring Service and Reference Binding Component Properties

For more information about binding components, see the following documentation:

- Introduction to Binding Components

- Developing SOA Applications with Oracle SOA Suite

Note:

- You cannot configure message header properties for direct binding components that invoke a SOA composite application through a remote RMI call. For this reason, the Properties tab does not display for direct binding components.

- You cannot change the httpBinding property for the HTTP binding component.

- Support is provided for adding MTOM attachments to web services. For more information, see Developing SOA Applications with Oracle SOA Suite.

30.1 Configuring Service and Reference Binding Component Properties

You can configure message header properties for the service and reference binding components included in a deployed SOA composite application.

To configure service and reference binding component properties:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

From the SOA Composite Menu...

a. Select Services and References.

b. Select a specific service or reference.

c. Click the Properties tab.

a. Right-click soa-infra.

b. Select Services and References.

c. Select a specific service or reference.

d. Click the Properties tab.

a. Select Services/Reference Properties.

b. Select a specific service or reference.

c. Click the Properties tab.

The following binding component properties appear for a web service.

The following binding component properties appear for a file adapter. Depending upon your selection of JCA adapter, different properties display for configuring.

The following binding component properties appear for a REST reference binding component.

2. Change properties based on your selection of binding component:

- Configuring Properties for Web Services

- Configuring Properties for REST Adapters

- Configuring Properties for Oracle JCA Adapters

Note:

To see adapter header properties and their values on this page, ensure that you change the value of the Audit Level property from Production (the default) to Development on the SOA Infrastructure Common Properties page. If this property is set to Production, the properties and their values do not display. For more information, see Configuring SOA Infrastructure Properties.

30.1.1 Configuring Properties for Web Services

Table 30-1 describes the properties available for a web service binding component.

Table 30-1 Web Service Properties

Service, Reference, or Endpoint

Property Name

Description

Service

REST Enabled

Enable or disable the web services port to accept messages in REST format.

Service

WSDL Enabled

Enable or disable the WSDL of the web service.

Service

Metadata Exchange Enabled

Enable or disable a metadata exchange of the web service.

Service

Endpoint Test Enabled

Enable or disable an endpoint test of the web service.

Service

Schema Validation

Enable or disable schema validation.

Service

Atomic Transaction Flow Option

Select the transaction participation value:

- Never
No transaction context is imported (for services) or exported (for references).

- Supports
If a transaction exists, a transaction context is imported (for services) or exported (for references). This information is added to the composite.xml file.

- Mandatory
A transaction context is imported (for services) or exported (for references). For exports, a web service exception message is thrown if there is no active transaction. For imports, a fault is returned to the client if there is no transaction context in the request.

For more information, see Section "WS-AtomicTransaction Support" of Developing SOA Applications with Oracle SOA Suite.

Service

Atomic Transaction Version

Select the WS-AtomicTransaction (WS-AT) supported version (1.0, 1,1, 1,2, or default).

30.1.2 Configuring Properties for REST Adapters

Table 30-2 describes the properties available for a REST binding component.

Table 30-2 REST Adapter Properties

Property Type

Binding Component Type

Description

Endpoint Address

Reference

Endpoint URL to which the client sends the request.

Stop Chunking

Reference

Flag that specifies whether chunking is enabled for client requests.

Chunking Size (bytes)

Reference

Size of the request chunk in bytes.

HTTP Read Timeout (ms)

Reference

Length of the request read timeout in milliseconds.

HTTP Connection Timeout (ms)

Reference

Length of the request connection timeout in milliseconds.

30.1.3 Configuring Properties for Oracle JCA Adapters

If you manually add a nonregistered JCA binding level property in the composite.xml file, then you cannot subsequently edit that property or any other registered properties for that service or reference through Oracle Enterprise Manager Fusion Middleware Control. Table 30-3 describes the JCA adapter property types.

Table 30-3 Types of JCA Adapters

Property Type

Description

Restrictions

Activation specification and interaction specification

Activation specification properties operate as services and interaction specification properties operate as references in a SOA composite application.

Do not add or remove these properties. You can only change their values.

These properties require the adapter endpoint to be recycled. These types of properties are also dependent upon other properties. If you attempt to add one of these properties, you have no way of knowing which dependent properties must also be added.

Endpoint

These are tuning-related properties that are not exposed through the activation or interaction specification properties, such as specifying timeouts, thresholds, maximum intervals, and so on.

There are no restrictions on adding, removing, or changing endpoint properties. The adapter is notified when these properties are added, removed, or changed, but it does not require redeployment.

You cannot add or remove jca.retry.* endpoint properties without redeploying the composite. However, you can change these properties by using Oracle Enterprise Manager Fusion Middleware Control without redeploying the composite.

For information on available JCA adapter configuration properties, see Appendix "Oracle JCA Adapter Properties" of Understanding Technology Adapters.

31 Monitoring Service and Reference Binding Components

This chapter describes how to monitor service and reference binding component messages and faults in SOA composite applications. If Oracle Enterprise Scheduler is deployed with Oracle SOA Suite, you can also access a page for scheduling the activation and deactivation of JCA adapter services.

This chapter includes the following topic:

- Monitoring Binding Component Messages and Faults

For more information, see the following documentation:

- Introduction to Binding Components for conceptual details about binding components

- Administering Oracle B2B and Oracle Healthcare

- Developing SOA Applications with Oracle SOA Suite

31.1 Monitoring Binding Component Messages and Faults

You can monitor messages and faults for all binding components included in SOA composite applications.

To monitor binding component messages and faults:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home. > Deployed Composites.

b. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

2. Click Dashboard (if it is not selected).

3. In the Services and References section, select a specific service or reference.

4. If you select a service binding component that is a JCA adapter, web service, or REST service, the Dashboard page displays a graphic representation of the total number of incoming messages and faults since server startup:

5. If you select a service that invokes a SOA composite application through a remote method invocation (RMI) call (known as direct binding), the Dashboard page displays similar details as described in Step 4. Direct binding enables SOA composite applications to be invoked through an API that supports transaction and security propagation across JVMs.
The word Direct is displayed in the header to indicate that this is a direct binding component. However, no Polices and Properties tabs are available for direct binding components.

6. If you select a reference binding component, the Dashboard page displays a graphic representation of the total number of outgoing messages and faults since server startup. Reference binding components are only available for JCA adapters, web services, and REST services.

If Oracle Enterprise Scheduler is deployed with Oracle SOA Suite, the Adapter Schedules icon is displayed to the left of the Related Links list. This enables you to schedule the activation and deactivation of JCA adapter services.

7. Click the Adapter Schedules icon to invoke the Adapter Schedules dialog for selecting an activation and deactivation schedule to enable automated activation of this adapter.

For more information, see Scheduling JCA Adapter Endpoint Activation and Deactivation using Oracle Enterprise Scheduler.

32 Managing Service and Reference Binding Components

This chapter describes how to manage policies for web service and JCA adapter service and reference binding components in SOA composite applications, publish service binding components to the Universal Description, Discovery, and Integration (UDDI) registry from a registered UDDI source, and perform additional Oracle Service Registry tasks.

This chapter includes the following topics:

- Managing Binding Component Policies

- Publishing Web Services to the UDDI Registry

- Changing the Endpoint Reference and Service Key for Oracle Service Registry Integration

- Publishing and Browsing the Oracle Service Registry

Note:

Oracle SOA Suite does not support multiple bindings for service or reference binding components (for example, specifying both SOAP 1.1 and SOAP 1.2 in the composite.xml file). Support is only provided for a single web service binding per service or reference. If you specify multiple bindings, remove all but one and redeploy your SOA composite application.

For more information, see the following documentation:

- Introduction to Binding Components for conceptual details about binding components

- Developing SOA Applications with Oracle SOA Suite

32.1 Managing Binding Component Policies

You can attach and detach security policies to and from binding components included in a currently deployed SOA composite application (for example, web services and JCA adapters). Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services.

Note:

Before attaching policies, see Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use in your environment.

To manage binding component policies:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home.

b. Select the Deployed Composites tab.

c. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, expand the partition.

b. Select a specific SOA composite application.

The Dashboard page for the selected SOA composite application appears. The Services and References section of this page displays the binding components being used in the application.

2. In the Services and References section, select a service or reference.

3. Click Policies.
The Policies page enables you to view the globally-attached and directly-attached policies, and to attach or detach security policies to and from a service or reference binding component:

- The Globally Attached Policies table displays the globally-attached policy name, the policy set, the category (such as Management, Reliable Messaging, MTOM Attachment, Security, or WS Addressing), the violations since the SOA Infrastructure was last restarted, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.
Policy sets provide a means to attach policies globally to a range of endpoints of the same type. Attaching policies globally using policy sets enables an administrator to ensure that all subjects are secured in situations in which the developer, assembler, or deployer did not explicitly specify the policies to attach. Policies that are attached using a policy set are considered externally attached. For information about creating and managing policy sets, see Securing Web Services and Managing Policies with Oracle Web Services Manager.

- The Directly Attached Policies table displays the directly-attached policy name, the policy reference status (enabled or disabled), the category, the violations since the SOA Infrastructure was last restarted, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

5. In the Directly Attached Policies section, click Attach/Detach.
If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

Note:

If you attach a policy to a service binding component (client) and initiate an instance of the SOA composite application in the Test Web Service page, and the policy attachment fails, an Oracle Web Services Manager (OSWM) policy error is not generated and viewable in Oracle Enterprise Manager Fusion Middleware Control.

If the same business flow instance is initiated externally, a policy error is generated and viewable in Oracle Enterprise Manager Fusion Middleware Control.

For service components (such as a BPEL process) or reference binding components, the policy error is always generated and viewable, regardless of whether the business flow instance was initiated externally or internally through the Test Web Service page.

6. Select the service or component to which to attach or detach a policy.
This invokes a dialog for attaching or detaching policies.

Policies currently attached appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

7. Select policies to attach that are appropriate to your environment.

8. Click Attach.

9. When you are finished attaching policies, click Validate.

10. If an error message appears, make the necessary corrections until you no longer have any validation errors.
The attached policy is displayed in the policies table.

11. Click OK.

For more information, see the following documentation:

- Introduction to Policies

- Managing SOA Composite Application Policies for the dialogs that are displayed during policy attachment

- Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use for your environment

32.1.1 Override Policy Configuration Property Values

Your environment may include multiple servers with the same policies. However, each server may have their own specific policy requirements. To satisfy your runtime requirements, you can override the property values for some management and security policies attached to service and reference binding components.

1. Follow the instructions in Managing Binding Component Policies to attach a policy to a service or reference binding component.

2. Select the attached policy in the table.

3. Click Override Policy Configuration.

The Security Configuration Details dialog is displayed.

4. In the Value field, enter a value to override the default value in the Original Value column.

5. Click Apply.

For more information on overriding policy values, see Securing Web Services and Managing Policies with Oracle Web Services Manager.

32.2 Publishing Web Services to the UDDI Registry

You can publish service binding components to the UDDI registry from a registered UDDI source.

Note:

- You cannot publish a reference binding component to the UDDI registry.

- You can only publish web services to the UDDI registry. For example, you cannot publish a JCA adapter.

For more information about publishing web services to the UDDI registry, see Administering Web Services.

32.2.1 Publishing a Web Service to the UDDI Registry

Note:

You can publish web services to default Oracle Service Registry businesses from Oracle Enterprise Manager Fusion Middleware Control. To publish to nondefault businesses, use the publish option in Oracle Service Registry.

For more information about Oracle Service Registry, including documentation, visit the following URL:

http://www.oracle.com/technetwork/middleware/registry/overview/index.html

To publish a web service to the UDDI registry:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Services and References.

a. Right-click soa-infra.

b. Select Services and References.

The Services page displays details about the names and types of the services, the SOA composite applications in which the services are used, the partition in which the composite is deployed, the total number of messages processed, the average processing time, and the number of faults occurring in the services.

2. In the Service table, select a service to publish to the UDDI registry.

3. From the Actions list, select Publish To UDDI.

The Publish Service to UDDI dialog appears.

4. Enter the following information:

Field

Description

Service Name

Displays the name of the selected service.

Service Description

Enter an optional description of the selected service.

System Definition Location

Displays the WSDL URL to publish to the UDDI registry. For example:

http://myhost.mycompany.com:7001/soa-infra/services/default/HelloWorld/client?WSDL

UDDI Source

Select the UDDI publishing source from which to register the service.

Business Name

Select a business to publish the service. This is the name of the data structure in the UDDI registry. It is assumed that the business has already been registered in the UDDI registry.

When complete, the Publish Service to UDDI dialog looks similar to the following:

5. Click OK.

32.3 Changing the Endpoint Reference and Service Key for Oracle Service Registry Integration

If a reference binding component of the SOA composite application is integrated with Oracle Service Registry (OSR), you can change the endpoint reference and service key in the General section of this page.

The UDDI ServiceKey field automatically displays the value of binding.ws property="oracle.soa.uddi.serviceKey" from the composite.xml file if you selected to use UDDI for runtime resolution of the endpoint.

You can edit the UDDI ServiceKey field after the SOA composite application has been deployed to either:

- Change the value as needed.

- Add it to a composite that did not use UDDI for runtime endpoint resolution.

The Endpoint Address field represents the endpoint location as defined with the ws.binding endpointURI property in the composite.xml file. The Endpoint Address field is not filled in after the SOA composite application has been deployed, but can override the endpoint location in the concrete WSDL.

The endpoint location order of precedence is as follows:

- Dynamically set the binding oracle.soa.uddi.serviceKey at runtime in the UDDI ServiceKey field.

- Dynamically set the binding property endpointURI at runtime in the Endpoint Address field.

- Use the binding property value for oracle.soa.uddi.serviceKey in the composite.xml file (viewable and editable in Oracle Enterprise Manager Fusion Middleware Control).

- Use the binding property value for endpointURI in the composite.xml file (viewable and editable in Oracle Enterprise Manager Fusion Middleware Control).

- Use the location specified in the concrete WSDL.

Figure 32-1 shows both fields.

Figure 32-1 Endpoint Reference and Service Key Properties

To change the endpoint reference and service key for OSR integration:

1. In the UDDI ServiceKey field, change the service key to use during runtime.

2. In the Endpoint Address field, enter the endpoint address to use during runtime.

You can edit both fields. The value for one field is selected and used based on what you selected in the UDDI Deployment Options dialog during design time. The changes to these fields are persisted in the composite.xml file during runtime.

For information about design-time tasks such as how to publish a business service, create a connection to the UDDI registry, and configure a SOA project to invoke a service from the registry, see Developing SOA Applications with Oracle SOA Suite.

For information about how to set the inquiry URL during runtime, see Configuring SOA Infrastructure Properties.

32.3.1 Configuring Caching of WSDL URLs

Caching of endpoint WSDL URLs occurs by default during runtime. If an endpoint WSDL URL is resolved using the orauddi protocol, subsequent invocations retrieve the WSDL URLs from cache, and not from OSR. You can increase the amount of time that the endpoint WSDL URL is available in cache for inquiry by the service key with the UddiCacheLifetime property. This property invalidates the cache at specified time intervals. The default value is 86400 seconds. The minimum value is 300 seconds.

To configure endpoint caching of WSDL URLs:

1. From the SOA Infrastructure menu, select Administration > System MBean Browser.

2. Select Application Defined MBeans > oracle.as.soainfra.config > Server: soa_server1 > SoaInfraConfig > soa-infra > Attributes.

3. Click the UddiCacheLifetime property on the right side of the page.

4. Enter a value.

5. Click Apply.

32.4 Publishing and Browsing the Oracle Service Registry

The Oracle Service Registry (OSR) provides a common standard for publishing and discovering information about web services. This section describes how to configure OSR against a separately installed Oracle SOA Suite environment.

You can use Oracle SOA Suite with the following versions of OSR:

- OSR 11g

- OSR 10.3 (with Oracle WebLogic Server 10.3)

- OSR 10.1.3

For more information about OSR, visit the following URL:

http://www.oracle.com/technetwork/middleware/registry/overview/index.html

Note:

- This section does not describe how to configure OSR against the embedded Oracle WebLogic Server in Oracle JDeveloper.

- OSR 10.3 deploys to the 10.3.0.0 version of Oracle WebLogic Server.

- OSR 10.3 does not support the 10.3.1.0 version of Oracle WebLogic Server.

32.4.1 Publishing a Business Service

This section provides an overview of how to publish a business service. For specific instructions, see the documentation at the following URL:

http://www.oracle.com/technetwork/middleware/registry/overview/index.html

You can also access the documentation by clicking the Registry Documentation link.

To publish a business service:

1. Go to the Registry Control:

http://hostname:port/registry/uddi/web

2. Click Publish > WSDL.

3. Log in when prompted.

4. Complete the fields on this page to specify the access point URL and publish the WSDL for the business service.

Note:

If you later change your endpoint location, you must also update the WSDL location in the Registry Control. Otherwise, UDDI invocation fails during runtime. See section Changing Endpoint Locations in the Registry Control.

32.4.2 Creating a Connection to the Registry

To create a connection to the registry:

1. Go to Oracle JDeveloper.

2. Select File > New > Connections > UDDI Registry Connection to create a UDDI connection.

3. Enter a connection name.

4. Enter an inquiry endpoint URL. For example:

http://myhost.us.example.com:7001/registry/uddi/inquiry

5. Ensure that the Business View option is selected.

6. Click Next.

7. Click Test Connection.

8. If successful, click Finish. Otherwise, click the Back button and correct your errors.

Note:

When you right-click a web service of a SOA composite application under IDE Connections > Application Server in the Resources window in Oracle JDeveloper, the Publish WSDL To UDDI option is disabled.

32.4.3 Configuring a SOA Project to Invoke a Service from the Registry

To configure a SOA project to invoke a service from the registry:

1. Open the SOA project in which to create a reference to the business service.

2. Drag a Web Service icon into the External References swimlane.

The Create Web Service dialog appears.

3. To the right of the WSDL URL field, click the icon to select a WSDL.

4. From the list at the top, select Resource Palette.

5. Expand the navigational tree.

6. Expand UDDI Registry > Business Services.

7. Select the published business service, and click OK.

The UDDI Deployment Options dialog appears.

8. Select one of the following deployment options:

- Dynamically resolve the SOAP endpoint location at runtime

- Dynamically resolve the concrete WSDL location at runtime

9. Click OK.

You are returned to the Create Web Service dialog.

10. See the following section based on your selection in the UDDI Deployment Options dialog.

- Dynamically Resolving the SOAP Endpoint Location

- Dynamically Resolving the WSDL Endpoint Location

32.4.3.1 Dynamically Resolving the SOAP Endpoint Location

To dynamically resolve the SOAP endpoint location:

1. Complete the remaining fields in the Create Web Service dialog, and click OK.
The Create Web Service dialog looks as follows.

2. Wire the reference with the appropriate service component.

3. In the SOA Composite Editor, click Source.
The composite.xml file shows the serviceKey. The property dynamically resolves the endpoint binding location at runtime.

<property name="oracle.soa.uddi.servicekey" type="xs:string" many="false">uddi:
d3611b59-1c79-478e-9ae5-874007eb20c4">

4. If you want, you can also resolve the SOAP endpoint location by explicitly adding the oracle.soa.uddi.servicekey property in the Property Inspector. This action dynamically resolves the SOAP endpoint location at runtime for any external reference to a web service.

a. Highlight the reference binding component in the External References swimlane.

b. In the Property Inspector, expand the Properties section.

c. Click the Add icon.

d. In the Name list, select oracle.soa.uddi.servicekey.

e. In the Value field, specify the value for oracle.soa.uddi.servicekey from the composite.xml file.

32.4.3.2 Dynamically Resolving the WSDL Endpoint Location

To dynamically resolve the WSDL endpoint location:

1. Complete the remaining fields in the Create Web Service dialog, and click OK.

2. Wire the reference with the appropriate service component.

3. In the SOA Composite Editor, click Source.

The composite.xml file shows that the WSDL location is an abstract URL of orauddi:/uddi_service_key instead of a concrete URL (such as a HTTP URL). The orauddi protocol dynamically resolves the WSDL location at runtime.

<location="orauddi:/uddi:d3689250-6ff5-11de-af2b-76279200af27">

32.4.3.3 Resolving Endpoints

Oracle SOA Suite invokes a service for resolving an endpoint. Examples and descriptions are shown in Table 32-1.

Table 32-1 Resolving Endpoints

Endpoint Resolutions

Description

Example

Normalized message UDDI serviceKey

The OSR UDDI serviceKey is specified in the normalized message property within an Oracle Mediator or an Oracle BPEL Process Manager assign activity (serviceKey).

For example, with Oracle Mediator:

<copy target="$out.property.oracle.soa.uddi.serviceKey"
value="uddi:10a55fa0-99e8-11df-9edf-7d5e3ef09eda"/>

Normalized message endpointURI

The normalized message endpointURI property is specified within an Oracle Mediator or an Oracle BPEL Process Manager assign activity (endpointURI).

For example, with Oracle Mediator:

<copy target="$out.property.endpointURI"
value="http://hostname:8001/soa-infra/services
/partition/Project/endpoint_ep"/>

composite.xml UDDI serviceKey

The OSR UDDI serviceKey property (oracle.soa.uddi.serviceKey) is specified in the binding component section of composite.xml.

Note: This can be overwritten in Oracle Enterprise Manager Fusion Middleware Control.

<binding.ws
port="http://xmlns.oracle.com/UDDIPublishApplication
/Proj/BPELProcess1#wsdl.endpoint(bpelprocess1_client
_ep/BPELProcess1_pt)"
. . .>
<property name="oracle.soa.uddi.serviceKey"
type="xs:string"
many="false">uddi:31040650-9ce7-11df-9ee1-7d5e3e
f09eda</property>
</binding.ws>

composite.xml endpointURI

The endpointURI property is specified within the binding component section of composite.xml.

Note: This can be overwritten in Oracle Enterprise Manager Fusion Middleware Control.

<binding.ws
port="http://xmlns.oracle.com/UDDIPublishApplica
tion/Project/BPELProcess1#wsdl.endpoint(bpelproc
ess1_client_ep/BPELProcess1_pt)"
. . . >
<property name="oracle.soa.uddi.endpointURI"
value="http://hostname:8001/soa-infra/services/
Partition/Project/bpelprocess1_client_ep"</property>
</binding.ws>

composite.xml concrete WSDL endpoint location

The endpoint location is specified in the concrete WSDL in the binding component section of composite.xml.

<binding.ws
port="http://xmlns.oracle.com/UDDIPublishApplication
/Project/BPELProcess1#wsdl.endpoint(bpelprocess1_
client_ep/BPELProcess1_pt)"
location="http://hostname:8001/soa-infra/services
/Partition/Project/bpelprocess1_client_ep?wsdl"
soapVersion="1.1">

The failover scenario for resolving endpoints is as follows.

- Normalized message UDDI serviceKey

- Any error on the endpoint access

- Log a severe error

- Return an error to the user

- Normalized message endpointURI

- Any error on the endpoint access

- Log a severe error

- Return an error to the user

- composite.xml UDDI serviceKey

- Error on an OSR connection

- Log a severe error

- Use the composite.xml endpointURI if it is coded

- Else, return an error to the user

- Error for an invalid serviceKey in the connection

- Log a severe error

- Use the composite.xml endpointURI if it is coded

- Else, return an error to the user

- Error on the endpoint access

- Log a warning error

- Use a second (or third) binding template if it exists.

- Else, fail over to the composite.xml endpointURI

- composite.xml endpointURI

- Error on the endpoint access

- Log a warning error

- Fail over to the composite.xml concrete WSDL endpoint location

- composite.xml concrete WSDL endpoint location

- Error on the endpoint access

- Log a severe error

- Return an error to the user

32.4.4 Configuring the Inquiry URL, UDDI Service Key, and Endpoint Address for Runtime

You can set the inquiry URL, UDDI service key, and endpoint address during runtime in Oracle Enterprise Manager Fusion Middleware Control.

To configure the inquiry URL, UDDI service key, and endpoint reference for runtime:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. Specify values for the following properties:

- In the SOA Infrastructure Common Properties page, specify the same UDDI inquiry URL that you specified in the Create UDDI Registry Connection wizard. For information, see Configuring UDDI Registry Properties.

- In the Properties page of the reference binding component, you can change the endpoint reference and service key values created during design time. For information, see Configuring Service and Reference Binding Component Properties.

3. Restart the SOA Infrastructure.

4. Exit Oracle Enterprise Manager Fusion Middleware Control.

5. To see endpoint statistics, return to the Registry Control.

6. Go to the Manage page and check statistics to see the increase in the number of invocations when not cached (the first time).

Caching of WSDL URLs occurs by default during runtime. If a WSDL URL is resolved using the orauddi protocol, subsequent invocations retrieve the WSDL URLs from cache, and not from OSR. When an endpoint WSDL obtained from cache is no longer reachable, the cache is refreshed and OSR is contacted to retrieve the new endpoint WSDL location. As a best practice, Oracle recommends that you undeploy services that are no longer required in Oracle Enterprise Manager Fusion Middleware Control and used by the SOA Infrastructure. Endpoint services that are shut down or retired (but not undeployed) are still reachable. Therefore, the cache is not refreshed.

If you move the business service WSDL from one host to another, ensure that you change the location in the Registry Control. No change is required in Oracle JDeveloper or Oracle Enterprise Manager Fusion Middleware Control.

You can optionally increase the amount of time that the WSDL URL is available in cache for inquiry by the service key. For more information, see Configuring Service and Reference Binding Component Properties.

Note:

In 11g, caching occurs automatically. If you are using Oracle SOA Suite 10.1.3, caching is supported by setting the CacheRegistryWSDL property to true in bpel.xml. Setting this property to false disables caching.

32.4.4.1 Changing Endpoint Locations in the Registry Control

The Registry Control provides an option for changing the endpoint location. This is a two-step process. The following steps provide an overview. For more specific details, see the Oracle Service Registry documentation:

http://www.oracle.com/technetwork/middleware/registry/overview/index.html

To update WSDL bindings:

1. Log in to Registry Control.

2. Click Search > Business.

3. Click Add Name.

4. In the Name field, enter a search criteria.

5. Click Find.

6. In the search results, click the business name that is displayed.

7. On the right side, click the Services tab.

8. From the list of services, click the service name.

9. At the bottom, click the Edit button.

10. On the right side, click the Bindings tab.

11. In the list of bindings, select the notepad icon next to the description column.

Oracle Service Registry is now in edit mode for bindings.

12. In the Access Point field, change the required URL, and save your changes.

32.4.4.1.1 To Update WSDL Binding Overview Documentation:

1. Within the Registry Control, click Search.

2. In the tModel name field, enter the name and click Find tModel.

3. In the name column, click the name with the description wsdl:type representing portType.

4. Ensure that WSDL details are shown correctly.

5. Click the Edit button.

6. On the right side, click the Overview doc tab.

7. Under the Add description button, click the Edit icon.

8. Enter the new URL.

9. Click Update and save the changes.

10. To verify, navigate to the service and ensure that the WSDL URL is pointing to a new location.

32.4.4.2 Publishing WSDLs from Multiple SOA Partitions

Follow these steps to publish WSDLs from multiple SOA partitions using the Registry Control, and access them using a separate serviceKey and bindings.

To publish WSDLs from multiple SOA partitions:

1. Log in to Registry Control.

http://host:port/registry/uddi/web

2. Publish the WSDL from the first partition.

3. Publish the WSDL from the second partition.

a. Click Publish > WSDL.

b. Enter values in the Business key and WSDL location (URI) fields.

c. Select the Advanced Mode checkbox.

d. Click Publish.

e. In the navigation tree in the left pane, select the endpoint, bindings, and port type, and ensure that the "new" mode option is selected.

f. Click Publish.

32.4.5 How to Publish WSDLs to UDDI for Multiple Partitions

The following limitations exist for publishing WSDL services from Oracle Enterprise Manager Fusion Middleware Control.

- You cannot publish the same service with the same target namespace from different SOA partitions or from different hosts.

- There is no option for entering your own service key.

Instead, use the Registry Console to publish the same WSDL service deployed to different partitions to OSR.

To publish WSDLs to UDDI for multiple partitions:

1. Log in to the Registry Console.

2. Publish the WSDL of the first partition.

3. Rename the above-mentioned service name to a unique name.

4. Publish the WSDL of the second partition.

This creates two separate services in OSR.

Part XII Administering Business Events

This part describes how to administer business events.

This part includes the following chapter:

- Managing Business Events

33 Managing Business Events

This chapter describes how to manage business events and the Event Delivery Network (EDN), including mapping the flow of different business events through different JMS destinations, testing the publishing of business events, viewing the event definition language (EDL) file of the business event, viewing service components subscribed to business events, changing the JMS type, and configuring the inbound poller thread number. Business events consist of message data sent as the result of an occurrence in a business environment. When a business event is published, other service components can subscribe to it.

This chapter includes the following topics:

- Introduction to the Event Delivery Network and JMS Provider Types

- Mapping Business Events to JMS Topic Destinations

- Testing the Publishing of Business Events and Viewing the EDL File

- Viewing Business Event Subscribers

- Resolving Duplicate Messages for Subscribers in Clustered Environments

- Changing the JMS Type

- Configuring the Inbound Poller Thread Number

For information about troubleshooting business event issues, see Business Events and Event Delivery Network Troubleshooting.

For information about creating business events in Oracle JDeveloper, see Chapter "Using Business Events and the Event Delivery Network" of Developing SOA Applications with Oracle SOA Suite.

33.1 Introduction to the Event Delivery Network and JMS Provider Types

You create business events in Oracle JDeveloper and include them in SOA composite applications that you deploy to Oracle Enterprise Manager Fusion Middleware Control. Service components can subscribe to business events. When a business event is published, the entity subscribed to that event receives it.

EDN is the subsystem of Oracle SOA Suite that accepts published business events and delivers them to the subscribers. EDN uses a JMS topic as a back-end store. EDN provides two JMS-based types:

- Oracle WebLogic Server JMS
EDN uses a default Oracle WebLogic Server JMS topic as the underlying JMS store for all event types. Figure 33-1 provides details.

Figure 33-1 JMS Topic of Oracle WebLogic Server JMS

The following JMS adapter connection factories are supported:

- eis/wls/EDNxaDurableTopic (supports XA, durable topic with ClientID=edn_wljms_xa_client)

- eis/wls/EDNxaTopic (supports XA)

- eis/wls/EDNLocalTxDurableTopic (supports local transaction, durable topic with ClientID=edn_wljms_localtx_client)

- eis/wls/EDNLocalTxTopic (supports a local transaction)

You can change the default JMS type. For information, see Changing the JMS Type. You can also create custom JMS topics and specify certain event types of interest to map to the custom topics.

- Oracle Advanced Queueing (AQ) JMS
AQ JMS topics can also be created and used. EDN provides a preprovisioned AQ JMS topic out of the box. Figure 33-2 provides details.

Figure 33-2 JMS Topic of Oracle AQ JMS

AQ JMS is exposed through a foreign server.

The following JMS adapter connection factories are supported:

- eis/aqjms/EDNxaDurableTopic (supports XA, durable topic with ClientID=edn_aqjms_xa_client)

- eis/aqjms/EDNxaTopic (supports XA)

- eis/aqjms/EDNLocalTxDurableTopic (supports local transaction, durable topic with ClientID=edn_aqjms_localtx_client)

- eis/aqjms/EDNLocalTxTopic (supports a local transaction)

The following JDBC data sources are supported:

- jdbc/EDNDataSource (supports XA)

- jdbc/EDNLocalTxDataSource (supports local transaction)

The following foreign servers are supported:

- EDNAQjmsForeignServer (supports XA)

- EDNAQjmsLocalTxForeignServer (supports local transaction)

Table 33-1 describes the benefits of both JMS provider types.

Table 33-1 Comparison Between JMS Provider Types

Oracle WebLogic Server JMS

AQ JMS

- A file-based (file store) and file cached database backed (JDBC store) implementation.

- When you have an application that runs in the same process space as the JMS server, it is always faster than AQ JMS. This is because AQ JMS always requires database round trips.

- Does not provide SQL visibility of messages, so there is no language conversion cost.

- In most low to medium scale and some high end (concurrency, throughput) JMS use cases, Oracle WebLogic Server JMS outperforms AQ JMS. This is because you usually compare different qualities of services when looking beyond what is expected from standard JMS (for example, crash recoverability, SQL visibility, full ordering, and disaster recovery).

- Usually wins on a price and performance basis for most cases if you evaluate total cost.

- Oracle database access is inherently multithreaded through the use of multiple database connections (whereas Oracle WebLogic Server JMS storage is single threaded). If you have enough database connections to spare, AQ JMS does well at high concurrencies when compared to Oracle WebLogic Server JMS arriving at the same destination both in clustered (RAC in the AQ JMS' case) and nonclustered cases.

- AQ JMS can short-circuit 2-PCs when Oracle database operations are involved in the XA transaction. Therefore, in cases in which the messaging cost is much lower when compared to the 2-PC cost required for using XA, AQ JMS does well.

- AQ JMS does better than Oracle WebLogic Server JMS when large message sizes are involved, when there are large message backlogs, or when there are complex selectors. This is because the database offers indexing, LOB streaming, embedded rules engines, and lock management that are much better than what Oracle WebLogic Server JMS offers.

- AQ JMS does well in an Exadata-Exalogic pairing because it makes better use of Exadata capabilities. Oracle WebLogic Server JMS becomes bottle necked because of the lower end storage nodes in Exalogic.

Durable subscriptions are supported. This means that events are retained even if the subscriber is not up and running. Durable subscriptions continue to accumulate events. Table 33-2 describes how nondurable and durable subscriptions are handled in the various life cycle states of the SOA composite application.

Table 33-2 Business Events and Composite Life Cycle States

The Composite Is...

Effect on Nondurable Subscribers

Effect on Durable Subscribers

Deployed

The subscriber is created and starts receiving events.

The subscriber is created, a durable subscription is registered, and the subscriber starts receiving events.

Undeployed

The subscriber is removed and stops receiving events.

The subscriber is removed, a durable subscription is unregistered, and the subscriber stops receiving events.

Redeployed

The durable subscription and subscriber are recreated.

The durable subscription and its subscriber are recreated.

Shut down

The subscriber stops receiving events.

The subscriber stops receiving events, but events continue to be queued (are not dropped) through durable subscriptions.

Started up

The subscriber starts receiving events.

The subscriber receives events, including those queued up prior to startup.

Retired

The subscriber stops receiving events.

The subscriber stops receiving events and events are not queued (are dropped).

Activated

The subscriber starts receiving events.

The subscriber start receiving events.

33.2 Mapping Business Events to JMS Topic Destinations

You can map the flow of different business events through different JMS destinations in Oracle Enterprise Manager Fusion Middleware Control. This mapping can reduce business event bottlenecks caused by mapping all business events through a single destination. After installation, all business events are mapped by default to a single, local Oracle WebLogic Server JMS topic. You can manually create additional JMS topics and map business events to the topics appropriate to your performance needs.

Note the following best practices when mapping business events to JMS topics other than the default.

- Perform the mapping before messages flow into JMS topic destinations. This prevents existing events from flowing into old JMS topic destinations for which there are no subscribers.

- Restart the subscribing SOA composite applications or the SOA server after completing the mapping. This enables subscribers to be associated with the new JMS topic destination.

- Ensure that the JMS topic is configured in the Oracle WebLogic Server Administration Console. See Creating an JMS Topic .

- Ensure that all JMS adapter connection factories are configured in the Oracle WebLogic Server Administration Console. See Optionally Creating JMS Adapter Connection Factories for JMS.

33.2.1 Creating an Oracle WebLogic Server JMS Topic

To create an Oracle WebLogic Server JMS topic:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure, go to Services > Messaging > JMS Modules.

3. In the Name column, click SOAJMSModule.

4. Click New.

5. Create a new topic.

6. Target it to SOAJMSServer.

33.2.2 Optionally Creating JMS Adapter Connection Factories for Oracle WebLogic Server JMS

It is typically unnecessary to create JMS Adapter connection factories because you can reuse the ones included with EDN installation. If you need to create connection factories (for example, for a separate management purpose), follow these steps.

To create JMS adapter connection factories for Oracle WebLogic Server JMS:

1. Log in to Oracle WebLogic Server Administration Console.

2. From the Domain Structure, select soainfra > Environment > Deployments > JMS Adapter > Configuration > Outbound Connection Pools.

3. Click New.

4. Provide the JNDI name (for example, eis/wls/MyEdnWLjmsTopic).

5. Save the new deployment plan.

6. Return to JMS Adapter > Configuration > Outbound Connection Pools, and click the newly created connection factory.

7. Provide values appropriate to your connection factory:

Property Name

Property Value

AcknowledgeMode

Leave as AUTO_ACKNOWLEDGE.

ConnectionFactoryLocation

For XA, use weblogic.jms.XAConnectionFactory.For a local transaction, use weblogic.jms.ConnectionFactory.

FactoryProperties

For a durable topic, specify ClientID=your_client_ID.For a nondurable topic, leave this field blank.

IsTopic

Always true.

IsTransacted

For XA, use false.

For a local transaction, use true. However, if the Oracle WebLogic Server JMS server is running in a local JVM (same JVM as the EDN/JMS adapter), set IsTransacted to false.

Password

Leave blank.

Username

Leave blank.

Transaction Support (in the Transaction tab)

Leave as XA Transaction.

33.2.3 Creating an AQ JMS Topic

Open the Database Navigator (in Oracle JDeveloper) or SQL Developer as the soainfra user, and run the following script to create an AQ JMS topic:

define edn_user=soainfra_schema_user_here
define topic=your_custom_aqjms_topic_name_here (for example, EDN_AQJMS_TOPIC_2)
define topic_table=your_custom_aqjms_topic_table_here (EDN_AQJMS_TOPIC_
TABLE_2)

begin
DBMS_AQADM.stop_queue(queue_name => '&edn_user..&topic');
DBMS_AQADM.drop_queue(queue_name => '&edn_user..&topic');
DBMS_AQADM.drop_queue_table(queue_table => '&edn_user..&topic_table');
end;
/
begin
dbms_aqadm.create_queue_table(queue_table => '&edn_user..&topic_table',
queue_payload_type => 'SYS.AQ$_JMS_MESSAGE',
multiple_consumers => true);
dbms_aqadm.create_queue(queue_name => '&edn_user..&topic',
queue_table => '&edn_user..&topic_table',
max_retries => 256);
dbms_aqadm.start_queue(queue_name    =>    '&edn_user..&topic');
end;
/
commit;

The queue and queue table are created.

33.2.4 Exposing an AQ JMS Topic

If you created an AQ JMS topic in Creating an AQ JMS Topic , you must expose the topic to Oracle WebLogic Server applications, including Oracle SOA Suite applications. Use Oracle WebLogic Server Administration Console to either create a new foreign server or update the existing foreign server EDNAQjmsForeignServer to add AQ JMS topic mapping:

To expose an AQ JMS topic:

1. Optionally create a new foreign service:

a. Log in to Oracle WebLogic Server Administration Console.

b. In the Domain Structure, go to Services > Messaging > JMS Modules > SOAJMSModule.

c. Click New, and select Foreign Server.

d. Name the foreign server, target it to the SOA server, and click Finish.

e. Open the new foreign server, and go to Configuration > General.

f. Set the following properties.

Property

Value

JNDI Initial Context Factory

oracle.jms.AQjmsInitialContextFactory

JNDI Properties

For an EDN XA JDBC data source (for example, datasource=jdbc/EDNDataSource).

For an EDN non-XA JDBC data source (for example, datasource=jdbc/EDNLocalTxDataSource).

2. If you also create your custom JMS adapter connection factories for AQ JMS, then you must create a connection factory mapping:

a. Go to the Configuration > Connection Factories tab of this foreign server, and click New.

b. Provide the local JNDI name (which matches the value configured in the adapter's ConnectionFactoryLocation) and remote JNDI name, which is XATopicConnectionFactory for XA support.

c. If you must create another foreign server that uses a non-XA JDBC data source, set the remote JNDI name to TopicConnectionFactory for non-XA support.

3. Add mapping to the AQ JMS topic

a. Click New to create a new destination mapping in one of the newly created foreign servers or the existing foreign server EDNAQjmsForeignServer.

b. Map a local JNDI name to a remote JNDI name convention of Topics/custom_aqjms_topic_name.

33.2.5 Optionally Creating JMS Adapter Connection Factories for AQ JMS

It is typically unnecessary to create JMS adapter connection factories because you can reuse the ones included with EDN installation. If you must create connection factories (for example, for a separate management purpose), follow these steps.

To create JMS adapter connection factories for AQ JMS:

1. Log in to Oracle WebLogic Server Administration Console.

2. From the Domain Structure, select soainfra > Environment > Deployments > JMS Adapter > Configuration > Outbound Connection Pools.

3. Click New.

4. Provide the JNDI name (for example, eis/wls/MyEdnAQjmsTopic).

5. Save this new deployment plan.

6. Return to JMS Adapter > Configuration > Outbound Connection Pools, and click the newly created connection factory.

7. Provide values appropriate to your connection factory:

Property Name

Property Value

AcknowledgeMode

Leave as AUTO_ACKNOWLEDGE.

ConnectionFactoryLocation

For XA, the value must match the local JNDI name of the connection factory that is mapped to XATopicConnectionFactory in the foreign server of EDNAQjmsForeignServer or your custom foreign server supporting XA.

For a local transaction, the value must match the local JNDI name of the connection factory that is mapped to TopicConnectionFactory in the foreign server of EDNAQjmsLocalTxForeignServer or your custom foreign server supporting a local transaction.

FactoryProperties

For a durable topic, specify ClientID=your_client_ID.For a nondurable topic, leave this field blank.

IsTopic

Always true.

IsTransacted

For XA, use false.

For a local transaction, use true.

Password

Leave blank.

Username

Leave blank.

Transaction Support (in the Transaction tab)

Leave as XA Transaction.

33.2.6 Enabling a Remote Client to Interact with an AQ JMS-Based Topic

If an event type is mapped to the default EDN AQ JMS topic or a custom AQ JMS topic, EDN enables Oracle SOA Suite publishers and subscribers to interact with this event type through the AQ JMS topic. However, EDN does not enable remote publishers or subscribers to interact by default.

To enable remote publishers, subscribers, or both, the EDN foreign servers (either the one installed by EDN or the custom foreign servers) must have their JNDI properties and credential updated, as shown in Table 33-3.

Table 33-3 JNDI Properties and Credentials

Property Name

Property Value

JNDI Properties

Add: db_url=jdbc:oracle:thin:@host:port:service.

java.naming.security.principal=soainfra_schema_user.

JNDI Properties Credential

Enter the password for oainfra_schema_user.

Figure 33-3 provides details.

Figure 33-3 Enable a Remote Client to Interact with an AQ- MS-Based Topic

33.2.7 Mapping Business Events to JMS Topic Destinations on the Business Events Page

You can map business events to JMS topic destinations on the Business Events page in Oracle Enterprise Manager Fusion Middleware Control.

To map business events to JMS topic destinations on the Business Events page:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Business Events.

Right-click soa-infra and select Business Events.

The Business Events page displays the following details:

- A utility for searching for a specific business event by specifying a full or partial name and clicking the Search icon. Click Help > Help For This Page under the weblogic menu for details.

- Business events, including the namespace, event name, JMS type and mapping, number of subscriptions to each event, and number of failed event deliveries. Business events are contained within their namespace.

2. In the JMS Mapping column, view the supported JMS topic mapping for the event:

- Default: Indicates that the business event is using the default JMS topic destination mapping. The default configuration consists of a single, local JMS topic destination that uses Oracle WebLogic Server JMS as the underlying provider.

- Modified: Indicates that the business event is not using the default JMS topic destination mapping.

3. Click the JMS topic mapping type in the column. For example, if Default is selected, the following details are displayed. The connection factory settings that are initially displayed are automatically set during installation.

4. Enter values appropriate to your environment:

Element

Description

Oracle Enterprise Messaging System (OEMS)

Select the underlying JMS provider:

- Oracle WebLogic Server JMS (default provider)

- Oracle Advanced Queueing JMS

JNDI Connection Factory

Specify connection factory details for the JMS adapter. EDN uses the JMS adapter to interact with JMS.

For Oracle WebLogic Server JMS:

- eis/wls/EDNxaDurableTopic (supports XA, durable topic with ClientID=edn_wljms_xa_client)

- eis/wls/EDNxaTopic (supports XA)

- eis/wls/EDNLocalTxDurableTopic (supports local transaction, durable topic with ClientID=edn_wljms_localtx_client)

- eis/wls/EDNLocalTxTopic (supports local transaction)

For Oracle AQ JMS:

- eis/aqjms/EDNxaDurableTopic (supports XA, durable topic with ClientID=edn_aqjms_xa_client)

- eis/aqjms/EDNxaTopic (supports XA)

- eis/aqjms/EDNLocalTxDurableTopic (supports local transaction, durable topic with ClientID=edn_aqjms_localtx_client)

- eis/aqjms/EDNLocalTxTopic (supports local transaction)

JMS Topic Name

Specify the JNDI name of the JMS topic.

Use Default JMS Topic

Select to reset all configuration fields to values to use the default JMS topic destinations provided during installation. The default configuration consists of a single, local JMS topic destination that uses Oracle WebLogic Server JMS as the underlying provider.

However, if the default JMS type is changed to AQ JMS instead of Oracle WebLogic Server JMS, then the default configuration consists of a single, local JMS topic that uses Oracle AQ as the underlying provider.

5. Click Apply to close the dialog and display your selection in the JMS Mapping column.

6. Shut down and start up either of the following:

- The impacted SOA composite applications on the Deployed Composites page of the SOA Infrastructure

- The Oracle SOA Suite managed server

For more information, see the following documentation:

- Introduction to the Contents of SOA Composite Applications

- Chapter "Using Business Events and the Event Delivery Network" of Developing SOA Applications with Oracle SOA Suite for details about business events

33.3 Testing the Publishing of Business Events and Viewing the EDL File

You can test the publishing of business events and view the EDL file contents. The business event is defined using EDL. EDL is a schema used to build business event definitions.

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Business Events.

Right-click soa-infra and select Business Events.

The Business Events page displays the following details:

- A utility for searching for a specific business event by specifying a full or partial name and clicking the Search icon. Click Help > Help for This Page under the weblogic menu for details.

- Business events, including the namespace, the event name, the JMS type, the mapping between the business event and the JMS topic destination, the number of subscriptions to each event, and the number of failed event deliveries. Business events are contained within their namespace.

2. In the Namespaces and Events column, select a specific event to test.

a. Click Test to test the selected event. This action enables you to publish a test event that subscribers can act upon.
The Test Event dialog appears.

b. Specify the XML payload to use in the test.

c. Click Publish.
If publishing is successful, the following message is displayed.

The Event published successfully

3. In the Namespaces and Events column, select a specific event for which to display the EDL file.

a. Click Show Event Definition to display the EDL file for the selected event.

b. Click OK to close the message.

33.4 Viewing Business Event Subscribers

When business events are published, service components can subscribe to them. You can view the service components that have subscribed to business events. Service component subscriptions are created in Oracle JDeveloper during design time and cannot be modified in Oracle Enterprise Manager Fusion Middleware Control.

All business events are applicable to the entire Oracle SOA Suite domain instead of the individual partitions of the publishers and subscribers. Business events are also displayed as separate entries in the flow trace of the business flow instance.

Note:

- If your SOA composite application includes a business event subscription, and you deploy different revisions of the composite, all event subscriptions from all revisions of the composite are active and receive messages. To receive the event with the latest revision of the composite only, it is recommended that you retire all previous revisions of the composite.

- A BPEL component in a retired SOA composite application cannot receive a business event, even if the event is associated with a noninitiating receive activity of the BPEL process.

To view business event subscribers:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Business Events.

a. Right-click soa-infra.

b. Select Business Events.

2. Click Subscriptions.
The Subscriptions page displays the following details:

- A utility for searching for a specific subscription by specifying criteria and clicking Search. You can search based on the namespace or event name. Click Help > Help for This Page under the weblogic menu for details.

- The component subscriptions, including the event name, the namespace, the service component subscribing to the event, the SOA composite application, any optionally defined XPath filters, the consistency level (Guaranteed or OneAndOnlyOne), and the number of business events that failed to be delivered.

3. In the Subscription Component column, click a service component to access its home page.

4. In the Composite column, click a SOA composite application to access its home page.

For more information about creating business events in Oracle JDeveloper, see Chapter "Using Business Events and the Event Delivery Network" of Developing SOA Applications with Oracle SOA Suite.

Note:

Enforcement of policies for event subscriptions is not supported in this release. You can attach or detach a policy to or from a service component that subscribes to a business event (such as Oracle Mediator) without being warned. This action does not result in any errors; policy enforcement simply does not occur.

33.5 Resolving Duplicate Messages for Subscribers in Clustered Environments

SOA composite subscribers can receive duplicate events in a multiple-node cluster. This occurs when EDN uses the default JMS type and topic (that is, Oracle WebLogic Server JMS). This occurs because the template used by Oracle SOA Suite installation defaults to a Uniform Distributed WebLogic JMS topic with a replicated (instead of partitioned) forwarding policy and does not support configuration of the forwarding policy.

To automatically configure an EDN JMS topic to be a partition-distributed topic in a clustered environment, change the EDN JMS topic from replicated to partitioned.

To change to the partitioned policy:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure, select soainfra > Services > Messaging > JMS Modules > SOAJMSModule.

3. Click the distributed EDN topic (dist_EDNTopic_auto).

4. Go to Configuration > General tab.

5. In the dropdown list, change Forwarding Policy from Replicated to Partitioned.

When set to Partitioned, the physical member receiving the message is the only member of the uniform distributed topic that is aware of the message. When a message is published to the logical name of a partitioned uniform-distributed topic, it only arrives at one specific, physical topic member. Once a message arrives at a physical topic member, the following occurs:

- The message is not forwarded to the rest of the members of the uniform distributed destination.

- Subscribers at other physical topic members do not receive a copy of the message.

33.6 Changing the JMS Type

You can change the default JMS provider type from Oracle WebLogic Server JMS to AQ JMS. or vice versa.

1. From the SOA Infrastructure menu, select Administration > System MBean Browser.

2. Click the Search icon, enter EDNConfig, and click Find.

3. Click JmsType.

4. Specify a value.

- WLJMS (Oracle WebLogic Server JMS)

- AQJMS (Oracle Advanced Queuing JMS)

5. Click Apply.

6. Restart the SOA server.

Note that you can only change the default JMS type mapped from an event type that does not have mapping to a custom JMS topic. Custom mapping (where an event type is mapped to a user-defined JMS topic) is not altered by this change.

33.7 Configuring the Inbound Poller Thread Number

For each subscriber, EDN spawns poller threads (defaults to one worker thread) for the underlying JMS consumer. You can change the number of inbound poller threads is either of two ways:

- Updating the Global Inbound Poller Thread Number in the System MBean Browser

- Updating the Local Inbound Poller Thread Number Value at the Service Component Level

33.7.1 Updating the Global Inbound Poller Thread Number in the System MBean Browser

You can update the inbound poller thread number at the SOA Infrastructure level with the (global) attribute value of ThreadsPerSubscriber.

To update the inbound poller thread number in the System MBean Browser:

1. From the SOA Infrastructure menu, select Administration > System MBean Browser.

2. Click the Search icon, enter EDNConfig, and click Find.

3. Click the ThreadsPerSubscriber attribute. Change the value from the default of 1 to an appropriate integer, and click Apply.

A confirmation message indicating that the ThreadsPerSubscriber attribute have been updated successfully is displayed. No restart of the SOA server or redeployment of SOA composite applications is necessary.

33.7.2 Updating the Local Inbound Poller Thread Number Value at the Service Component Level

You can update the local inbound poller thread number at the service component level with a System MBean property corresponding to the composite containing the event subscribing component (Oracle Mediator or BPEL process).

1. From the SOA Infrastructure menu, select Administration > System MBean Browser.

2. Select Application Defined MBeans > oracle.soa.config > Server: Server_name > SCAComposite > composite_name > SCAComposite.SCAComponent > component_name.

3. Expand the Events attribute.

4. Update the numberOfPollerThreads value. The default value is -1, which means that the global SOA Infrastructure level EDNConfig MBean's ThreadsPerSubscriber value takes effect for initializing EDN inbound poller threads for the subscriber. The updated numberOfPollerThreads value that you specify takes precedence over the global value.

5. Click Apply.

6. When the Confirmation message appears, click Return.

7. Switch to the Operations tab, and click save.

8. On the operation: save page, click Invoke.

A Confirmation message is displayed.

9. Restart the SOA composite application of interest, or restart the SOA server for the numberOfPollerThreads to take effect.

Part XIII Administering Oracle BPMN Process Service Components and Engines

Learn how to administer Oracle BPMN Process Service Components and Engines.

- Configuring Oracle BPMN Process Service Components and Engines

- Monitoring BPMN Process Service Components and Engines

- Managing Oracle BPMN Service Components and Engines

34 Configuring Oracle BPMN Process Service Components and Engines

Learn how to configure the BPMN process service engine, including configuring properties used by the engine during processing of BPMN service components.

- Configuring BPMN Process Service Engine Properties

- Integrating Oracle BPM with Oracle BAM 12c

- Integrating with Oracle BAM 11g

For more information about BPMN process tuning and performance properties, see Tuning Performance.

34.1 Configuring BPMN Process Service Engine Properties

Learn how to configure BPMN Process Service Engine properties.

To configure BPMN process service engine properties:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select SOA Administration > BPMN Properties.

a. Right-click soa-infra.

b. Select SOA Administration > BPMN Properties.

The BPMN Service Engine Properties page displays properties for setting audit trail and large document thresholds, validating payload schema, and setting the audit trail level.

2. Make changes to the service engine properties that are appropriate to your environment.

Property

Description

Audit Level

Select one of the following options:

- Off: No logging is performed. Business flow instance tracking and payload tracking information are not collected. If measurement is enabled, then this level is overridden to Minimal.

- Inherit (default): Logging equals the SOA Infrastructure audit level. This allows the BPMN audit level to automatically change when the global setting is changed. Setting a different audit level tracking in this page overrides the tracking set at the SOA Infrastructure level.

- Minimal: Instance tracking information is collected, but not payload details; no payload details are available in the flow audit trails.

- Production: Instance tracking information is collected, payload details are collected only for out data associations for asynchronous activities. This level is optimal for most normal operations and testing.

- Development: Allows both the business flow instance tracking and payload tracking. However it may impact the performance. This level is useful mostly for debugging purposes.

Note: If you do not want audit entries to be displayed, then you must turn off both the audit level and the metrics. If metrics are enabled, then audit entries are displayed even if the audit level is set to Off.

Audit Trail Threshold

Enter the maximum size in bytes of an instance audit trail before it is chunked and saved in a dehydration store table separate from the audit trail. If the threshold is exceeded, the View XML link is shown in the audit trail instead of the payload.

Large Document Threshold

Enter the maximum size of a generated document within a BPMN process component instance before it is stored in a separate table in the dehydration store.

Payload Validation

Select to enable validation of inbound and outbound messages. Nonschema-compliant payload data is intercepted and displayed as a fault.

Note: This setting is independent of the SOA composite application and SOA Infrastructure payload validation level settings. If payload validation is enabled at both the service engine and SOA Infrastructure levels, data is checked twice: once when it enters the SOA Infrastructure, and again when it enters the service engine.

Disable BPMN Monitors and Sensors

Select this checkbox to disable all BPMN monitors and sensors defined for all BPMN components across all deployed SOA composite applications.

3. Click Apply.

4. If you want to configure advanced BPMN properties in the System MBean Browser, click More BPMN Configuration Properties. Properties that display include the following. Descriptions are provided for each property.

- AuditDetailThreshold: The maximum size (in bytes) an audit trail details string can be before it is stored separately from the audit trail.

- AuditLevel: Controls the amount of audit events logged by a process; currently supported logging levels are: off: absolutely no logging performed whatsoever; may result in a slight performance boost for processing instances.

- AuditKeyExtents: The extent size for the BPMN Audit Query ID generation. This value specifies the amount by which the BPMN Audit Query sequence will increase each time a new set of IDs are requested.

- AuditUpdateBatchSize: The batch size used when marking BPMN process audit information as aborted during undeployment.

- BpelcClasspath: The extra class path must be included when compiling BPMN generated java sources.

- ConfigMBean: If true, it indicates that this MBean is a Config MBean.

- cleanupCompletedTask: If set to false, Me and my group assignment filter and Completed status, get completed tasks . Default is cleanupCompletedTask=true, which cleans up table to show the completed tasks with Me(previous) assignment filter and Completed status at improved performance.

- DebugIgnore: Lists BPMN activities (localName only) that are ignored by the debugger agent. The BPMN activity names are separated by , or ; or white-space.

- DisableProcessBroker: If set to false the process broker service is enabled. The default value is true.

- DisableProcessTracking: If set to true, the audit disables process tracking. The default value is false.

- DisableSensors: If set to true, the service engine disables all calls to sensors. The default value is false.

- DispatcherEngineThreads: The total number of threads that are allocated to process engine dispatcher messages.

- DispatcherInvokeThreads: The total number of threads that are allocated to process invocation dispatcher messages.

- DispatcherMaxRequestDepth: Maximum number of internal messages the service engine processes. If this number is exceeded, new messages are not dispatched. The default value is 600.

- DispatcherSystemThreads: The total number of threads that are allocated to process system dispatcher messages.

- eventProvider: If set to true, indicates that this MBean is an event provider as defined by JSR-77.

- eventTypes: All the event's types emitted by this MBean.

- ExpirationMaxRetry: The maximum number of times a failed expiration call (wait/onAlarm) is retried before failing.

- ExpirationRetryDelay: The delay between the expiration retries. The default value is 120 seconds.

- InstanceKeyBlockSize: The size of the block of instance IDs to allocate from the dehydration store during each fetch.

- LargeDocumentThreshold: The maximum size (in bytes) a BPMN variable can be before it is stored in a separate location from the rest of the instance scope data.

- MaximumNumberOfInvokeMessagesInCache: Specify the number of invoke messages that can be kept in the in-memory cache, once the service engine reaches this limit, it pushes the message to dispatcher in-memory cache, instead it saves the message in the database, and these saved messages can be recovered using recovery job. Use value -1 to disable this property.

- MaxOptimizationDataToFetch: Maximum depth of data to fetch from database for optimization features.

- objectName: The MBean's unique JMX name.

- OERCredentialMapName: Set the OER Credential map name here.

- OERPublisherCsfKeyName: Set the OER Credential map name to use when publishing the Business Architecture Project to OER.

- OERServerURL: The URL of the OER server including the port name. This server name is used for publishing assets to the OER.

- OneWayDeliveryPolicy: Changes whether the one-way invocation messages are delivered.

- OptimizationDataUpdateInterval: Attribute exposed for management.

- OptimizationDisabledProcesses: List of processes for which optimization features are disabled.

- OptimizationEnabled: Globally enable or disable the process optimization features. This must be set to true to enable the Process Monitor dashboard in Oracle Business Process Management Workspace.

- PeopleQueryTimeout: Specify quartz cron expression People Query. People Query in Logical People Group is reevaluated based on this cron expression.

- QualityOfService: Flag to enable or disable Oracle Coherence cache for BPMN service engine. Use CacheEnabled for enabling Oracle Coherence.

- ReadOnly: If set to true, indicates that this MBean is a read only MBean.

- RecoveryConfig: Set recovery configuration values.

- RepositoryType: Set the repository type to use for Business Architecture Reports. Possible values are RDFRepository or OERRepository. OER specific parameters are used only when OERRepository type is specified.

- RestartNeeded: Indicates whether a restart is needed.

- StatsLastN: The size of the most recently processed request list.

- SystemMBean: If set to true, indicates that this MBean is a System MBean.

- TimeEstimationToBamUpdateInterval: The time interval in seconds in which the process instances estimated completion times are populated in BAM.

- UserInitiateProcessCleanupAction: The action to be performed for the cleanup procedure: OFF (default), ABORT or DELETE. OFF will disable the cleanup process on the next scheduled activation of the process.

- UserInitiateProcessCleanupCronExpression: The cron type expression indicates when and how often the cleanup procedure should take place. Any changes to the schedule will take effect on the next scheduled activation of the cleanup process.

- UserInitiateProcessCleanupRetentionDays: Only the user-initiated processes older than number of days old will be processed. Zero is not allowed. Fractions of a day can be specified as a decimal.

- UserInitiateProcessCleanupTaskStates: The task states to be considered during the cleanup procedure.

Note:

The UserInitiateProcessCleanup properties support the cleanup of properties created using the initiator task.

- ValidateXML: If set to true, the service engine applies schema validation for incoming and outgoing XML documents. The default value false.

- Version: Version of the configuration file.

- Visible: If set to true, this MBean is visible to the current user.

34.1.1 Configuring the BPMN Service Engine for Process Monitoring

Process monitor dashboards in Oracle Business Process Management Workspace allow you to monitor and optimize process execution by identifying bottlenecks and other performance problems.

To configure support for process monitor dashboards:

1. Access BPMN Service Engine Properties as described above, click More BPMN Configuration Properties... and set the OptimizationEnabled property to true.

2. Locate the AnalyticsConfig:analytics mbean. In the System MBean Browser click Filter (View and configure the filters applied to the mbean browser).

3. In the Filtering Settings dialog, specify the MBean Pattern Filter as oracle.as.soainfra.config:name=analytics,*.

4. Set DisableAnalytics to false.

5. Set DisableProcessMetrics to false.

6. Click Apply.

34.2 Integrating Oracle BPM with Oracle BAM 12c

When a BPM composite with enabled measurements (either standard or user-defined) is created, composite specific derived physical and logical data objects are created in Oracle Business Activity Monitoring (Oracle BAM) 12c.

These data objects have the columns for standard metrics and user-defined metrics.

34.2.1 Physical Data Objects

Composite specific process physical derived data object

Name: ORACLE_PROCESSANALYTICS_<COMPOSITE>_PROCESS

Display Name: oracle/processanalytics/<COMPOSITE>/Process (physical)

Composite specific activity physical derived data object

Name: ORACLE_PROCESSANALYTICS_<COMPOSITE>_ACTIVITY

Display Name: oracle/processanalytics/<COMPOSITE>/Activity (physical)

34.2.2 Logical Data Objects

Composite specific process logical data object

Name: ORACLE_PROCESSANALYTICS_<COMPOSITE>_BPM_PROCESS

Display Name: oracle/processanalytics/<COMPOSITE>/Process

Composite specific activity logical data object

Name: ORACLE_PROCESSANALYTICS_<COMPOSITE>_BPM_ACTIVITY

Display Name: oracle/processanalytics/<COMPOSITE>/Activity

34.2.3 Process Star Schema Database Views

In a BPM composite, if the user has defined Analytics View Identifier for the composite, then synonyms to composite specific physical data object views are generated. These views are used to get SQL access to process analytics data. The naming convention of the view synonyms are:

BPM_PV_PRCS_<IDENTIFIER>_V - composite specific process fact

BPM_PV_ACTV_<IDENTIFIER>_V - composite specific activity fact

where <IDENTIFIER> is the Analytics View Identifier defined in the composite.

In addition to the creation of composite specific fact data objects in Oracle BAM 12c, the standard dimension data objects, such as COMPOSITE_DEFINITION, ACTIVITY_DEFINITION, PROCESS_DEFINITION, TASK_DEFINITION, ROLE_DEFINITION, and so on, are also populated with appropriate metadata information from the composite.

34.2.4 Task 1: Enable Oracle BPM Data Publish to Oracle BAM 12c

To do this task, you use the Oracle Enterprise Manager Fusion Middleware Control.

To enable Oracle BPM Data Publish to Oracle BAM 12c:

1. In Oracle Fusion Middleware Control, under WebLogic Domain, select your domain and server.

2. Go to System MBean Browser.

3. Select oracle.as.soainfra.config > Server > BPMNConfig > bpmn.

4. Click Analytics.

To the right, set disableProcessMetrics to false. (Default is true.)

Note:

The ProcessMetrics target can be enabled only if an Oracle BAM 12c server is detected.

5. Click Save and Submit.

Note:

If a new BPM composite configured with measurement is deployed before enabling ProcessMetrics, or when the Oracle BAM 12c server is down; then all data publishing to Oracle BAM 12c Process Star Schema from such composites is permanently disabled (even if Oracle BAM 12c comes up later). This is because some mandatory artifacts, required for allowing runtime analytics population, could not be created in Oracle BAM 12c during composite deployment time. In order to allow such composites to publish data to Oracle BAM 12c Process star schema, they must be redeployed when Oracle BAM 12c is up.

34.3 Integrating Oracle BPM with Oracle BAM 11g

Learn how to integrate Oracle BPM with Oracle BAM 11g.

When a BPMN composite application is deployed, the following Oracle BAM data objects are generated automatically:

- Data object for the following business indicator:
TEMPLATE_BI_Partition_Composite_Process

Once this is imported, you should rename it to:

BI_DEFAULT_Compositename_ProcessName

This is created in the target folder. If the data object already exists, new columns are added to it, assuming the old columns match data types. Otherwise, an error is thrown.

- COMPONENT, INTERVAL, COUNTER data objects if they are not present in the target folder.

The target Oracle BAM Server is specified by JNDI name parameter.

Note:

Data objects can be created only automatically at deployment. You cannot create them manually.

To configure Oracle BPM for use with Oracle BAM 11g, you perform these tasks:

- Task 1: Configure the Oracle BAM Adapter on Server

- Task 2: Enable Oracle BPM Data Publish to Oracle BAM 11g Monitor Express

34.3.1 Task 1: Configure the Oracle BAM Adapter on Oracle BPM Server

You must configure the Oracle BAM Adapter to use either SOAP or RMI for communicating with Oracle BAM.

To configure the Oracle BAM adapter on Oracle BPM server:

1. In the Oracle WebLogic Server Administration Console, under Domain Structure, click Deployments.

2. Click OracleBAMAdapter > Configuration > Outbound Connection Pools.

3. Expand oracle.bam.adapter.adc.soap.SOAPConnectionFactory.

4. Click either eis/bam/soap or eis/bam/rmi.

The JNDI name used to configure the Oracle BAM adapter is used. For example, if you configured the Oracle BAM adapter to use SOAP, then the default JNDI name is eis/bam/soap. Similarly, if you configure the Oracle BAM adapter to use RMI, then the default JNDI name is eis/bam/rmi.

5. Modify properties to match Oracle BAM Server. (Remember to press Enter after text entry).

6. Click Save.

7. Select the location for the deployment plan—for example, bam/Plan.xml, then complete the dialogs.

8. Return to Deployments.

9. Select OracleBAMAdapter.

10. Click Update and complete the dialogs.

For more information about integrating Oracle BAM with Oracle SOA Suite composite applications, see Developing SOA Applications with Oracle SOA Suite.

34.3.2 Task 2: Enable Oracle BPM Data Publish to Oracle BAM 11g Monitor Express

To do this task, you use the Oracle Enterprise Manager Fusion Middleware Control.

To enable Oracle BPM data publish to Oracle BAM 11g Monitor Express:

1. In Oracle Fusion Middleware Control, under WebLogic Domain, select your domain and server.

2. Go to System MBean Browser.

3. Select oracle.as.soainfra.config > Server > BPMNConfig > bpmn.

4. Click Analytics.

To the right, set disableMonitorExpress to false. (Default is true.)

5. Click Save and Submit.

35 Monitoring BPMN Process Service Components and Engines

Learn how to monitor BPMN process service components and service engines, including viewing the audit trail and process flow, monitoring request and thread performance statistics, and monitoring deployed BPMN processes.

- Viewing the Audit Trail and Process Flow of a BPMN Process Service Component

- Monitoring BPMN Process Service Engine Performance Statistics

- Monitoring Deployed BPMN Processes in the Service Engine

For more information, see the following sections:

- Introduction to Service Components

- Introduction to Service Engines

35.1 Viewing the Audit Trail and Process Flow of a BPMN Process Service Component

Learn how to view the audit trail and process flow of a BPMN process service component in a business flow instance.

Note:

- This section assumes a business flow instance has been initiated. If not, see Initiating a Test Instance of a Business Flow for instructions.

- When several messages are thrown in a short interval, they are not processed in the same order as they were sent. This can be apparent when you are examining the audit trail of a process instance.

To view the audit trail and process flow of a BPMN process service component:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Home > Deployed Composites

b. In the Composite section, select a specific SOA composite application.

a. Under soa-infra, select a specific SOA composite application.

The Dashboard page for the selected composite application appears.

2. Click the Flow Instances tab.
Use one of the following methods to select an instance of the application:

- For recent instances of this application, click the Recent Instances link.

- For instances with faults, click the Instances With Faults link.

- For recoverable instances, click the Recoverable Instances link.

A Search page appears.

Enter your search criteria and click Search to display a list of instances.

3. Highlight the required instance and click Show Details to display additional information about the instance in a table containing the following tabs:

- The Faults tab shows the faults occurring in the services, service components, and references that comprise the SOA composite application. Information includes, Error Name, Fault Name, Fault Owner, Fault Time, Recovery, and so on. Use the View option to select the columns to display.

- The Composite Sensor Values tab displays details about composite sensors included in the service and reference binding components of the SOA composite application. Composite sensors can be added to service and reference binding components during design time in Oracle JDeveloper. You cannot add composite sensors to service components.

- The Composites tab shows the sequence of the composites through the flow.

4. Click the Flow ID of the selected instance to display the Flow Trace page.

The flow trace is a runtime trail of a message flow identified by a Flow ID that is displayed in the upper right corner of the page. The Flow ID enables you to track a message flow that crosses instances of different composites. The flow trace lists all services, references, components across composites participating in the flow.

For the flow example in the Trace section, the service binding component and reference binding component involved in the flow have successfully received and processed messages.

5. Select a fault in the Faults section.
This highlights the row in the Trace section in which the fault occurred.

6. Close the fault to clear the selection in the Trace section.

7. Expand the Composite Sensor Values tab to display composite sensors.

8. Select a sensor in the Composite Sensor Values tab.
This highlights the row in the Trace section in which the composite sensor data was collected.

9. In the Instance column of the Trace section, click a specific BPMN process service component instance. Service component instances can be accessed from this section; services and references cannot be accessed.
The Instance page appears.

Use these pages to view the audit trail, flow and faults of a BPMN process service component instance. The following links provide additional details about the instance:

- Flow Trace link: Click the breadcrumbs in the upper left corner of the page to access the flow trace for the business flow instance that contains this BPMN component instance.

- Information icon: Click the information icon to the right of the name of the BPMN component (in the page title) to see biographical information about this BPMN instance. This information includes a summary of the instance, including instance ID, instance startup time or last modification time, instance state (for example, running), and number of faults.
This icon is displayed only on the Audit Trail pages of BPMN processes and Oracle Mediators, and not on the pages of human tasks and business rules.

When you first open the Instance page, the Audit Trail process instance details are displayed in a table by default. It provides execution details about the activities in the BPMN process. You can use the drop down to view the details as a list, tree, or graphical view. If you choose to view by list, you can also choose the types of processes to view. You can select All, Human Activities, Service Activities, Business Rules Activities, Sub-processes, Events, Gateways, Script Activities and Other Activities.

The List table includes the following information:

Column

Description

Activity

Lists all the BPM constructs available in a process in the order they are executed. These include:

- Events: start, end, signal, throw, catch message.

- Activities: user task, business rules task, service task, call activity, subprocess.

- Gateways: inclusive, exclusive, parallel, event based, and complex.

Status

Displays the status of the activity, such as Instance Suspended, Instance Fault, Activity Fault, Activity Completed, and so on.

Start

Time stamp showing when the activity started.

End

Time stamp showing when the activity ended.

Location

Shows the location of the activity.

You can also view Audit Trail in Tree View. When you view Audit Trail in a tree view, both interrupting and non-interrupting timers appear in the tree structure. If it is an interrupting timer, the due date appears on the node that is going to be interrupted at expiration.

Timer Scheduling Type

Non-Interrupting

Interrupting

Event Sub-process

Timer scheduling node appears at the process or sub process level that this timer could be trigger.

Due Date is set to the node that can be closed if that timer is fired.

Boundary Timer

Timer scheduling node appears at the activity or sub process level that this timer is bounded to.

Due Date is propagated to the node that can be closed, cancelled if this timer is fired.

Intermediate Timer

FLOW_NODE_IN event represents scheduling and FLOW_NODE_OUT finishing.

No due date is propagated.

35.2 Monitoring BPMN Process Service Engine Performance Statistics

You can monitor pending and active requests as well as thread performance statistics for all BPMN process service components running in the service engine.

To monitor BPMN process service engine requests and thread statistics:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > BPMN.

a. Right-click soa-infra.

b. Select Service Engines > BPMN.

2. Click the Statistics tab.
The Statistics page displays the following details.

- Pending requests in the service engine. Use this graph to view backlogged requests waiting to be fulfilled.

- Active requests in the service engine. Use this graph to get an idea of the current service engine load. Most requests are processed instantaneously so only under extreme load conditions should there be data shown in the graph.

- Thread statistics for the service engine. Use this table to view details about thread performance in the BPMN process service engine. Details include the number of threads used for the performance category (for example, number of active threads, highest number of active threads, and so on).

For more information about BPMN process tuning and performance properties, see Tuning Performance.

35.3 Monitoring Deployed BPMN Processes in the Service Engine

You can monitor all deployed SOA composite applications with BPMN process service components running in the service engine.

Note:

Subtasks are not listed in the Oracle Enterprise Manager Fusion Middleware Control.

To monitor deployed BPMN processes in service engines:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > BPMN.

a. Right-click soa-infra.

b. Select Service Engines > BPMN.

2. Click the Deployed Components tab.

The Deployed Components page displays the following details:

- A utility for searching for a specific deployed SOA composite application by specifying criteria and clicking Search.

- Details about deployed SOA composite applications with BPMN process service components running in this service engine, including the service component name, the SOA composite application, and the current status.

To access the home page of a specific service component, click the specific service component in the Name column.

To access the home page of a specific SOA composite application, click the specific SOA composite application in the Composite column.

36 Managing Oracle BPMN Service Components and Engines

Learn how to manage BPMN process service components and service engines.

- Managing BPMN Process Service Component Policies

- Performing BPMN Process Service Engine Message Recovery

- Migrating Instances Between Different Composite Application Revisions

36.1 Managing BPMN Process Service Component Policies

You can attach and detach policies to and from BPMN process service components in currently deployed SOA composite applications. Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services.

Note:

Before attaching policies, see Administering Web Services for definitions of available policies and details about which ones to use in your environment.

To manage BPMN process service component policies:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

Select Service Engines > BPMN.

a. Select soa-infra.

b. Right-click and select Service Engines > BPMN.

2. Go to the Composites column of the View table and select a specific SOA composite application to access its Dashboard page.

3. Click Policies.
The Policies page enables you to attach and detach policies to and from BPMN process service components. The policies table displays the attached policy name, the policy reference status (enabled or disabled) that you can toggle, the category (Management, Reliable Messaging, MTOM Attachment, Security, or WS Addressing), the violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

4. Click Attach/Detach.
If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

5. Select the service or component to which to attach or detach a policy.
This invokes a dialog for attaching or detaching policies.

Policies currently attached appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

6. Select to attach policies appropriate to your environment.

7. Click Attach.

8. When you are finished attaching policies, click Validate.

9. If an error message appears, make the necessary corrections until you no longer have any validation errors.

10. Click OK.
The attached policy is displayed in the policies table.

For more information, see the following documentation:

- Introduction to Policies

- Managing SOA Composite Application Policies for the dialogs that display during policy attachment.

- Administering Web Services for definitions of available policies and details about which ones to use for your environment.

36.2 Performing BPMN Process Service Engine Message Recovery

You can perform a manual recovery of undelivered invoke or callback messages due to a transaction rollback in the process instance. Recovery of invoke messages applies to asynchronous BPMN processes only. Synchronous BPMN processes return an error to the calling client and are not recoverable from this page.

Recoverable activities are activities that failed and can be recovered. For example, if you are using the file adapter to initiate an asynchronous BPMN process and your system crashes while the instance is processing, you can manually perform recovery when the server restarts to ensure that all message records are recovered.

Note:

If you encounter the error message ORA-01000: maximum open cursors exceeded, then do the following:

1. Shut down the Oracle database.

2. Increase the value of OPEN_CURSORS to 1500.

3. Restart the Oracle database.

To perform BPMN process service engine message recovery:

1. Access this page through one of the following options:

From the SOA Infrastructure Menu...

From the SOA Folder in the Navigator...

a. Select Service Engines > BPMN.

a. Right-click soa-infra.

b. Select Service Engines > BPMN.

2. Click Recovery.
The Recovery page displays the following details:

- A utility for searching for a specific message failure by specifying criteria and clicking Search. Click the Help icon for details.

- Message failure in the service engine, including the conversation ID, whether you can recover from the message failure, the service component and composite application in which the failure occurred, and the time at which the fault occurred.

3. Select a fault in the table.

4. Select one of the following options:

Action

Description

Recover

Retries the message in which the fault occurred.

If an asynchronous BPMN process encounters a transaction rollback scenario because of any underlying exception error, it rolls back to the last dehydration activity. If this is a new instance, and a receive activity was the first dehydration activity, the BPMN process service engine creates a recoverable invoke. When you click Recover to recover the invoke, the service engine creates a new instance. This instance may run to completion with no exception error. However, you continue to see the older instance identified as faulted.

Mark Cancelled

Marks the message so it is never delivered.

Once a message is submitted for recovery, the BPMN process service engine may take time to complete the action. This typically takes less than several seconds. During this time, the message remains visible in the Recovery page. Duplicate attempts to recover the same message in that period are ignored. Refresh the page every few seconds to receive the latest recovery status.

36.3 Migrating Instances Between Different Composite Application Revisions

Instance migration between revisions is based on flow instances instead of composite instances. For a set of flow instances and a composite type, all instances of the composite in each flow are migrated. A flow migration first obtains the component instances for the flow instance and composite type from each of the composite's associated service engines. The service engine is then requested to migrate each of those component instances, one at a time.

Note:

This feature is only applicable to Oracle BPMN projects that do not include asynchronous BPEL processes.

The reasons for migrating flow instances include the following:

- Design or implementation errors are discovered in the initial revision of the process or potentially invalid data provided by external services has placed the process in a bad state.

- Processes are taking too long to complete. For example, you may have flow instances that run for months or years. Because of this:

- Changes may need to be applied while the flow instances are in-flight.

- Changes are unknown beforehand so they cannot always be modeled as rules or short-lived subprocesses.

- Regulation or policy changes (applying new or modified enforcement of policies) require additional steps to be added to all processes.

The following restrictions apply to flow instance migration:

- Both composite revisions must be deployed.

- Only running flow instances can be migrated. You cannot migrate completed, suspended, or faulted flow instances, except for Oracle Mediator, which can be in a faulted state and still successfully migrated.

- Only compatible flow instances can be successfully migrated. Compatibility depends upon the compatibility of the associated service component in the composite. Nontrivial changes cannot be migrated.

- There is a transaction boundary per flow instance. You typically operate on batches of flow instances related to a specific composite. Each flow instance is bound to a single transaction. Migration of one or more flow instances can fail without failing the entire batch.

Two migration methods are supported:

- Automatic migration: For trivial changes between revisions. Each flow instance is bound to a single transaction. You can migrate a batch of flow instances.

- Manual migration using a migration plan (Oracle BPM only): This is for nontrivial changes between revisions. The migration plan describes how to perform the migration.

36.3.1 Migration Compatibility

Composite migration compatibility depends on the service components defined inside the application. If changes to any service component are not compatible, then the entire flow instance is not eligible for migration. The SOA composite application flow instance is only migrated if the associated service component flow instances can be migrated.

The following service components are eligible for migration:

- Nondurable BPEL processes

- Oracle Mediator

- Human workflow

- Business rules

- Oracle BPMN

The participating service engines are coordinated to migrate their respective flow instances. Flow instance tracking data is migrated to the new revision.

The flow instance must have at least one active component instance of the following states:

- Running

- Recovery required

- Suspended

Table 36-1 describes how the following service component flow instances are migrated to a new flow instance. If not compatible, the overall flow instance migration is reported as incompatible, and you cannot migrate it.

Table 36-1 Service Component Flow Instance Migration Details

Service Component

Supported Migration Types

Migration Restrictions

BPEL process

Automatic migration of BPEL process flow instances to a new revision

- Only nondurable BPEL processes are supported (processes without checkpoint or breakpoint activities). Durable processes include asynchronous processes or synchronous processes with timers or activities that dehydrate before completing.

- Only completed component flow instances are migrated.

Oracle Mediator

Automatic migration of Oracle Mediator flow instances to a new revision

Request-only, request-response, and sequential routing rules are the only supported message patterns. This means that only one-way and synchronous Oracle Mediator components are eligible for migration.

Instances must be in one of the following states: completed successfully, faulted, or terminated by user.

Human workflow

Automatic migration of human workflow flow instances to a new revision

None (all running and completed instances are migrated).

Business rules

Automatic migration of business rules to a new revision (there is no concept of rules flow instances)

None.

Oracle BPM

Both manual (through use of a migration plan) and automatic migration of Oracle BPM flow instances to a new revision

You cannot migrate flow instances between incompatible models. Examples of incompatible flow instances include:

- Removing or changing the behavior of a subprocess

- Changing the levels of any activities

- Removing gateways (except exclusive gateways)

- Changing the interface

- Adding or removing a boundary event on any activity

Adding or removing activities means you must manually migrate them with a migration plan.

Note:

Flow instance migration fails for an instance that includes an Oracle Mediator service component with parallel routing rules and an Oracle BPMN service component.

36.3.2 Migrating Instances with the ant Script

You must create an ant script to perform a migration. The script must import the $Middleware_Home/soa/bin/ant-flow-instance-migration.xml script.

You can get help to create your ant script with the following command:

ant -f $Middleware_Home/soa/bin/ant-flow-instance-migration.xml help

The following elements are supported:

- locatorConfig: defines locator configuration

- locatorSession: represents locator session

- flowInstanceFilterDef: filter that selects the flow instances to migrate. This element supports the following attributes:

- id (required)

- compositeDN (required)

- flowId

- pageStart

- pageSize

- tenantId

- maxCreationDate

- minCreationDate

- maxModifyDate

- minModifyDate

- like

- ecid

- conversationId

- compositeName

- domainName

- label

- revision

- title

- generateFlowMigrationReport: synchronously generates flow migration report

- migrateFlowInstances: synchronously migrates flow instances

The code sample below shows an example of the ant-flow-instance-migration.xml script.

<?xml version="1.0" encoding="iso-8859-1"?>
<project name="migration-test1" basedir="." default="test">
<property name="env" environment="env" value="env"/>
<property name="mw.ora.home" value="${env.MW_ORA_HOME}"/>
<import file="${mw.ora.home}/bin/ant-flow-instance-migration.xml"/>
<property name="reports.dir" value="${baseDir}/reports"/>
<locatorConfig id="c1" host="localhost" port="7001" user="weblogic"
password="weblogic1"/>

<target name="test">
<flowInstanceFilterDef
id="f3"
compositeDN="default/SubProcess!1.0"/>
<locatorSession configId="c1">
<generateFlowMigrationReport  filterId="f3"
revision="2.0"
outputFile="${reports.dir}/
migrationReport.html"/>
<migrateFlowInstances  filterId="f3"
revision="2.0"
migrationPlan="${basedir}/
TaskRemovedInSubprocess-plan.xml"
outputFile="${reports.dir}/
migrationResult.html"/>
</locatorSession>
</target>
</project>

36.3.3 Example of Migrating a Revision Instance for Oracle BPM

This section provides an example of migrating a revision instance of the ReviewProcess composite that includes Oracle BPM. Because a human workflow approval task is removed in this example, a migration plan is required.

Figure 36-1 shows the instance flow for revision 1.0 of the composite. There are two human tasks in this revision of the composite, including VeryExpensiveUserReview, which is a time-consuming, user approval task.

Figure 36-1 Oracle BPM Instance Flow for Revision 1.0

Figure 36-2 shows revision 1.0 of the composite in the SOA Composite Editor.

Figure 36-2 Composite Application for Revision 1.0

Figure 36-3 shows the improved instance flow for revision 2.0 of the composite application.

The time-consuming VeryExpensiveUserReview human approval task has been removed. Instead, an automatic review with a service task is used. The service task delegates the review approval to an external web service.

Figure 36-3 Oracle BPM Instance Flow for Revision 2.0

Figure 36-4 shows revision 2.0 of the composite application in the SOA Composite Editor.

Figure 36-4 Composite Application for Revision 2.0

The following tasks occur during migration:

- A new 2.0 revision is deployed, with an improved definition of ReviewProcess.

- The new 2.0 revision runs side-by-side with the old 1.0 revision.

- In-flight instances are migrated from one revision to another, as required.

36.3.3.1 Migrating a Revision Instance

To migrate a revision instance for Oracle BPM:

1. Generate a migration feasibility report that decides:

- Whether the selected instances are feasible to migrate.

- Whether migration is automatic or manual with a migration plan. Since instances running in an activity are being removed, a migration plan is required.

The migration plan specifies:

- A flow update from the VeryExpensiveUserReview task in the old revision to the LegacyReview task in the new component.

- An instance data update with a new value, later used in the LegacyReview task title.

2. Create a migration plan in which the following tasks are performed:

- The data object is updated.

- The instance title value is updated.

- The VeryExpensiveUserReview task flow is replaced with the LegacyReview task flow.

You can place the migration plan in any directory location.

You can use the sample or create your own migration plan based on the XSD. You specify the path to the file when running the build.xml file to migrate the instance.

3. Create a build.xml file for use with ant. For this example, ant is used. You can place the build.xml file anywhere in the directory structure. You must run ant from the same directory or run ant -f and specify the directory path location for build.xml.

<property name="migrationPlanPath" value="${basedir}/migration_plan.xml"/>

locatorConfig id="c1" host="${wls.host}" port=${wls.port}"
user="{wls.user}" password="${wls.password}"/>
compositeInstanceFilterDef id="f1" domainName="default"
compositeName="Project3" compositeInstanceId="40001"/>

<target name="test">
<locatorSession configId="c1">
<generateFlowMigrationReport filterId="f1" revision="2.0">
<migrateReportedCompositeInstances migrationPlanPath=
"${migrationPlanPath}"/>
</generateFlowMigrationReport>
</locatorSession>
</target>

4. Create a business flow instance of revision 1.0 of the SOA composite application. To migrate instances, both revisions 1.0 and 2.0 must be deployed. For more information about creating an instance, see Initiating a Test Instance of a Business Flow.

5. On the Flow Instances page, click the flow ID of revision 1.0 (for this example, 40007).

6. In the Trace table, click the ReviewProcess instance.

7. Click the Flow tab.

Revision 1.0 of the flow is shown. The instance is waiting on the parallel approval of the two instance tasks.

8. Go to the location for the build.xml file.

9. Change the flowId value to migrate to 40007.

10. In the upper right corner, run the ant script.

11. View the ant build report to see that migration was successful.

12. Return to the Flow Instances page in Oracle Enterprise Manager Fusion Middleware Control.

13. Click the Refresh icon, and note that the old instance is no longer displayed. This is because it was migrated to the new instance.

14. In the navigator, click revision 2.0.

15. Note that the migrated instance is displayed for the revision.

16. Click the instance.

17. In the Trace table, click ReviewProcess.

The LegacyReview human workflow component is shown as running and the VeryExpensiveUserReview human workflow component is shown as withdrawn.

18. Click the Flow tab.

19. View the new flow with LegacyReview.

20. Log in to Oracle Business Process Workspace.

21. Click Process Tracking to refresh the page.

22. Note that version ReviewProcess 2.0 is running.

23. Go to the task to approve, and select Approve.

24. Return to the instance in Oracle Enterprise Manager Fusion Middleware Control.

25. Click the Flow tab.

26. Note that the activity is displayed as approved.

Part XIV Appendixes

This part includes the following appendixes:

- Installing the Demo User Community in the Database

- Troubleshooting Oracle SOA Suite and Oracle BPM Suite

A Installing the Demo User Community in the Database

This appendix describes how to install and use the organizational hierarchy of users and groups known as the demo user community in the database. You can assign users and groups in this community to tasks that require approvals or other types of human interactions that advance the task workflow.

This appendix includes the following sections:

- Installing the Demo User Community

- Demo Community Users

- Demo Community Groups

- soa-infra Application Roles

- SOATestDemoApp Application Roles

- Roles Granted to and Owned by Users

- WorkflowPermission Class

A.1 Installing the Demo User Community

The demo user community is an organizational hierarchy of users and groups. After installing Oracle SOA Suite, you must install the demo user community in the database. The demo user community is part of the workflow-001-DemoCommunitySeedApp sample available under the HW link on the Oracle SOA Suite samples site. The README.txt file included with the sample describes both basic and advanced methods for installing the demo user community. The basic method for installing the demo user community is also described in this section.

Note:

You must run the script for seeding the user demo community locally from within a domain, and not remotely.

To install the demo user community:

1. Ensure that you have a local installation of one of the following:

- Oracle JDeveloper

- Oracle BPM server

- ant 1.7

2. Download the workflow-001-DemoCommunitySeedApp sample from the Oracle SOA Suite samples site.

3. Enter the following command to determine the version of Java on the host.

java -version

The host on which to install the demo user community into the database must include Java 1.6 update 17 or higher.

4. Ensure that your environment PATH contains the version of Java that is shipped with Oracle SOA Suite.

5. Select a method for installing the demo user community in the database.

To Use the build.properties File...

To Run the ant Script with Specified Parameters...

a. Edit the build.properties file included in the downloaded sample to match your environment:

# Set the admin server location
admin.url=t3://localhost:7001
server.url=http://localhost:8001

# Set the Fusion Middleware home, also
# called the bea home
# Linux style /scratch/oracle/middleware
# Windows style C:\\Oracle\\Middleware
bea.home=/scratch/oracle/middleware/
home_betaupdate

# Set the authentication
admin.name=weblogic
admin.pwd=password

# Use the managed server for the target or
# if single server configuration use the
# admin server
# e.g. target=soa_server1 or
# target=AdminServer
target=AdminServer

b. Run the following ant command:

$FMW_HOME\modules\org.apache.ant
_1.7.0\bin\ant seedDemoUsers

Where $FMW_HOME is the Oracle Fusion Middleware home directory for Oracle JDeveloper or SOA Server (or, specify the path to the ant 1.7 location).

a. Run the ant script with specified parameters. Note that bea.home and FMW_HOME are the same

ant seedDemoUsers -Dbea.home=FMW_HOME
-Doracle.home=ORACLE_HOME
-Ddomain.home=FMW_HOME/user_projects/
domains/Domain_Name
-Dtarget=Managed_Server_Name
-Dadmin.url=t3://HOST:Admin_Server_Port
-Dserver.url=http://HOST:Managed_Server_Port
-Dadmin.name=Admin_Name
-Dadmin.pwd=Admin_Password

Where FMW_HOME is the absolute path of the installation home directory and ORACLE_HOME is the absolute path of the Oracle home provided during installation.

For example:

ant seedDemoUsers
-Dbea.home=/scratch/wls/as11wls/lt20
-Doracle.home=/scratch/wls/as11wls/lt20/
AS11gR1SOA
-Ddomain.home=/scratch/wls/as11wls/lt20/
user_projects/domains/domain1
-Dtarget=soa_server1
-Dadmin.url=t3://wlserver.example.com:7001
-Dserver.url=http:///wlserver.example.com:
8001
-Dadmin.name=weblogic
-Dadmin.pwd=password

This installs the demo user community and grants permissions to the demo appRoles.

If installation is successful, the following message is displayed:

Build Successful

Note:

You can receive a Build Successful message even though there were connection problems. Watch for those messages.

After the successful seeding of demo users, you can log in with jcooper, jstein, or other users with the password specified in the build.properties file.

If installation is unsuccessful, the following message is displayed:

Build Failed

Installation failure is caused by a configuration or server availability issue. Correct those problems and retry again.

A.2 Demo Community Users

Table A-1 lists the users in the demo community.

Table A-1 Users in the Demo Community

User

User Name

First Name

Last Name

Title

Manager

Email

1

achrist

Agatha

Christie

Loan Consultant

wfaulk

achrist@emailExample.com

5

cdickens

Charles

Dickens

CEO

--

cdickens@emailExample.com

6

cdoyle

Conan

Doyle

Loan Agent 2

rsteven

cdoyle@emailExample.com

3

EHEMING

Ernest

Hemingway

CFO

JVerne

EHEMING@emailExample.com

7

fkafka

Franz

Kafka

Manager 1

ltolstoy

fkafka@emailExample.com

8

istone

Irving

Stone

Loan Agent 2

sfitzger

istone@emailExample.com

9

jausten

Jane

Austen

Loan Consultant

fkafka

jausten@emailExample.com

10

jcooper

James

Cooper

Loan Agent 1

jstein

jcooper@emailExample.com

11

jlondon

Jack

London

Loan Agent 1

sfitzger

jlondon@emailExample.com

12

jstein

John

Steinbeck

Manager 2

wfaulk

jstein@emailExample.com

2

JVerne

Jules

Verne

CIO

cdickens

JVerne@emailExample.com

13

ltolstoy

Leo

Tolstoy

Director

wfaulk

ltolsoy@emailExample.com

14

mmitch

Margaret

Mitchell

Loan Analyst

fkafka

mmitch@emailExample.com

15

mtwain

Mark

Twain

Loan Agent 2

jstein

mtwain@emailExample.com

16

rsteven

Robert

Stevenson

Manager 3

jstein

rsteven@emailExample.com

17

sfitzger

Scott

Fitzgerald

Manager 1

wfaulk

sfitzger@emailExample.com

18

szweig

Stefan

Zweig

Loan Analyst

fkafka

szweig@emailExample.com

4

VHUGO

Victor

Hugo

HR Manager

EHEMING

VHUGO@emailExample.com

19

wfaulk

William

Faulkner

Vice President

cdickens

wfaulk@emailExample.com

20

wshake

William

Shakespeare

Manager 3

rsteven

wshake@emailExample.com

Figure A-1 shows the organizational hierarchy of the demo community.

Figure A-1 Demo Community Organizational Hierarchy

A.3 Demo Community Groups

Table A-2 lists the following:

- Groups in the demo community

- Users and groups that are granted each group role (direct grantees and all grantees)

- Group roles and application roles granted to each group (direct-granted roles and all granted roles)

See Table A-6 for the roles granted to users sorted by user.

Table A-2 Groups in the Demo Community: Grant Relationships

Group

Direct Grantees

All Grantees

Direct-Granted Roles

All Granted Roles

RegionalOffices

CentralRegion, WesternRegion, EasternRegion

szweig, wshake, jcooper, WesternRegion, mmitch, EasternRegion, jlondon, CentralRegion, istone, cdoyle, mtwain, California, fkafka

-

-

EasternRegion

szweig, wshake, mmitch, fkafka

szweig, wshake, mmitch, fkafka

RegionalOffices

RegionalOffices

CentralRegion

jlondon, mtwain

jlondon, mtwain

RegionalOffices

RegionalOffices

WesternRegion

cdoyle, California

jcooper, istone, cdoyle, California

RegionalOffices

RegionalOffices

California

jcooper, istone

jcooper, istone

WesternRegion

RegionalOffices, WesternRegion

LoanAgentGroup

jlondon, wshake, LoanAnalyticGroup, jcooper, istone, cdoyle, mtwain

szweig, jlondon, wshake, LoanAnalyticGroup, jcooper, istone, cdoyle, mtwain, mmitch, fkafka

-

-

LoanAnalyticGroup

szweig, mmitch, fkafka

szweig, mmitch, fkafka

BPMWorkflowCustomize, LoanAgentGroup

BPMWorkflowCustomize, LoanAgentGroup

Supervisor

jcooper, mtwain, rsteven

jcooper, mtwain, rsteven

-

-

Executives

cdickens, JVerne, EHEMING, VHUGO

cdickens, JVerne, EHEMING, VHUGO

-

-

Table A-3 shows information for several groups listed in Table A-2. It lists the following:

- Users and groups (direct owners and all owners) that own each group

- Group roles (direct-owned roles and all owned roles) that each group owns

See Table A-6 for the roles owned by users sorted by user.

Table A-3 Groups in the Demo Community: Ownership Relationships

Group

Direct Owners

All Owners

Direct Owned Roles

All Owned Roles

EasternRegion

jstein

jstein

-

-

WesternRegion

jstein

jstein

-

-

California

fkafka

fkafka

-

-

LoanAgentGroup

jcooper, fkafka

jcooper, fkafka

-

-

LoanAnalyticGroup

jstein

jstein

-

-

Supervisor

jstein

jstein

-

-

A.4 soa-infra Application Roles

Table A-4 lists the following:

- soa-infra application roles

- Users, groups, and roles that are granted each application role (direct grantees and all grantees)

- Roles granted to each application role (direct-granted roles and all granted roles)

See Table A-6 for the application roles granted to users sorted by user.

Table A-4 Application Roles in soa-infra

Application Role

Direct Grantees

All Grantees

Direct-Granted Roles

All Granted Roles

SOAAdmin

Administrators

Administrators

BPMWorkflowAdmin

BPMWorkflowCustomize BPMWorkflowAdmin

BPMWorkflowAdmin

SOAAdmin, demoadmin

SOAAdmin, demoadmin, Administrators

BPMWorkflowCustomize

BPMWorkflowCustomize

BPMWorkflowCustomize

LoanAnalyticGroup, BPMWorkflowAdmin

szweig, LoanAnalyticGroup, SOAAdmin, BPMWorkflowAdmin, mmitch, fkafka, Administrators, demoadmin

-

-

For more information about application roles, see Developing SOA Applications with Oracle SOA Suite.

A.5 SOATestDemoApp Application Roles

Table A-5 lists the roles in the SOATestDemoApp application.

Table A-5 SOATestDemoApp Roles

Application Role

Direct Grantees

All Grantees

Direct-Granted Roles

All Granted Roles

DevTeam

- rsteven

rsteven, mmitch, fkafka, jcooper, istone

QATeam

jlondon, Supervisor

jlondon, jcooper, mtwain, rsteven, mmitch, fkafka, istone

ProductionTeam

mmitch, fkafka, California

mmitch, fkafka, jcooper, istone

DevTeam, QATeam

DevTeam, QATeam

A.6 Roles Granted to and Owned by Users

Table A-6 lists the following:

- Roles granted to each user (direct-granted roles and all granted roles)

- Roles owned by each user (direct-owned roles and all owned roles)

Table A-6 Roles for Each User

User Name

Direct-Granted Roles

All Granted Roles

Direct-Owned Roles

All Owned Roles

achrist

Executives

-

-

-

cdickens

-

-

Executives

-

cdoyle

WesternRegion, LoanAgentGroup

RegionalOffices, WesternRegion, LoanAgentGroup

-

-

EHEMING

Executives

fkafka

LoanAnalyticGroup, EasternRegion, ProductionTeam

BPMWorkflowCustomize, RegionalOffices, LoanAnalyticGroup, LoanAgentGroup, EasternRegion, ProductionTeam, DevTeam, QATeam

LoanAgentGroup, California

LoanAgentGroup, California

istone

LoanAgentGroup, California

RegionalOffices, WesternRegion, LoanAgentGroup, California, DevTeam, QATeam, ProductionTeam

-

-

jausten

-

-

-

-

jcooper

Supervisor, LoanAgentGroup, California

RegionalOffices, WesternRegion, Supervisor, LoanAgentGroup, California, DevTeam, QATeam, ProductionTeam

LoanAgentGroup

LoanAgentGroup

jlondon

CentralRegion, LoanAgentGroup, QATeam

CentralRegion, RegionalOffices, LoanAgentGroup, QATeam

-

-

jstein

-

-

LoanAnalyticGroup WesternRegion, Supervisor, EasternRegion

LoanAnalyticGroup WesternRegion, Supervisor, EasternRegion

JVerne

Executives

ltolstoy

-

-

-

-

mmitch

LoanAnalyticGroup, EasternRegion, ProductionTeam

BPMWorkflowCustomize RegionalOffices, LoanAnalyticGroup, LoanAgentGroup, EasternRegion, DevTeam, QATeam, ProductionTeam

-

-

mtwain

CentralRegion, Supervisor, LoanAgentGroup

CentralRegion, RegionalOffices, Supervisor, LoanAgentGroup, QATeam

-

-

rsteven

Supervisor, DevTeam

Supervisor, DevTeam

-

-

sfitzger

-

-

-

-

szweig

LoanAnalyticGroup, EasternRegion

BPMWorkflowCustomizeDemoApp/FlexFieldRole, RegionalOffices, LoanAnalyticGroup, LoanAgentGroup, EasternRegion

vhugo

Executives

wfaulk

-

-

-

-

wshake

LoanAgentGroup, EasternRegion

RegionalOffices, LoanAgentGroup, EasternRegion

-

-

A.7 WorkflowPermission Class

Table A-7 lists the permissions defined in the WorkflowPermission class and the application roles associated with each permission.

Table A-7 WorkflowPermission Class

Permission

Application Role with Permission

workflow.mapping.publicFlexField

BPMWorkflowAdmin, BPMWorkflowCustomize

workflow.mapping.protectedFlexField

BPMWorkflowAdmin

workflow.admin

BPMWorkflowAdmin

workflow.admin.evidenceStore

BPMWorkflowAdmin

B Troubleshooting Oracle SOA Suite and Oracle BPM Suite

This appendix describes how to troubleshoot issues you can encounter when using Oracle SOA Suite and Oracle BPM Suite, including logging level setup, parallel purge and table partitioning issues, connection and transaction timeout issues, runtime diagnostic issues, human workflow issues, Event Delivery Network (EDN) issues, performance issues, server startup best practices, and browser issues. References to additional troubleshooting information are also provided.

This appendix includes the following sections:

- Setting Logging Levels for Troubleshooting

- Parallel Purging and Table Partitioning Issues

- Connection and Transaction Timeout Troubleshooting

- Runtime Diagnostics Troubleshooting

- Human Workflow Troubleshooting

- Business Events and Event Delivery Network Troubleshooting

- Performance Troubleshooting

- Server Troubleshooting

- Browser Troubleshooting

- Additional Troubleshooting Documentation

B.1 Setting Logging Levels for Troubleshooting

To simplify troubleshooting, it is recommended that you set logging levels to the TRACE:32 FINEST level in Oracle Enterprise Manager Fusion Middleware Control. This section describes loggers to which to set to this level.

To set logging levels for troubleshooting:

1. See Configuring Log Files for instructions on accessing the Log Configuration page.

2. From the Oracle Diagnostic Logging Level (Java Level) list, set the following parent loggers to the TRACE:32 FINEST level:

- oracle.soa

- oracle.fabric

- oracle.integration

- oracle.wsm (Setting this logger to the ERROR level may also be sufficient because this setting logs the required error messages.)

3. If you want finer-grained control over logging, expand the parent loggers and set any of the following loggers:

Component

Runtime Loggers

Human workflow/approval management extensions (AMX)/rules

- oracle.soa.services.common

- oracle.soa.services.identity

- oracle.soa.services.notification

- oracle.soa.services.rules

- oracle.soa.services.rules.obrtrace

- oracle.soa.services.workflow

- oracle.soa.services.workflow.common

- oracle.soa.services.workflow.evidence

- oracle.soa.services.workflow.metadata

- oracle.soa.services.workflow.persistency

- oracle.soa.services.workflow.query

- oracle.soa.services.workflow.report

- oracle.soa.services.workflow.runtimeconfig

- oracle.soa.services.workflow.soa

- oracle.soa.services.workflow.task

- oracle.soa.services.workflow.task.dispatch

- oracle.soa.services.workflow.task.routing

- oracle.soa.services.workflow.user

- oracle.soa.services.workflow.verification

- oracle.soa.services.workflow.performance

- oracle.soa.services.workflow.worklist

SOA Infrastructure

- oracle.fabric.common.wsdl

- oracle.integration.platform.blocks.deploy

- oracle.integration.platform.blocks.soap

- oracle.integration.platform.blocks.local

- oracle.integration.platform.kernel

- oracle.integration.plaform.blocks.mesh

- oracle.integration.platform.common

- oracle.integration.platform.instance

- oracle.integration.platform.instance.activity

- oracle.integration.platform.instance.store

EDN

- oracle.integration.platform.blocks.event

- oracle.integration.platform.blocks.event.saq

- oracle.integration.platform.blocks.event.jms

Deployment

oracle.integration

Oracle Mediator

- oracle.soa.mediator.common

- oracle.soa.mediator.common.cache

- oracle.soa.mediator.common.error

- oracle.soa.mediator.common.error.recovery

- oracle.soa.mediator.common.listener

- oracle.soa.mediator.common.message

- oracle.soa.mediator.common.persistence

- oracle.soa.mediator.dispatch

- oracle.soa.mediator.dispatch.db

- oracle.soa.mediator.dispatch.resequencer.toplink

- oracle.soa.mediator.monitor

- oracle.soa.mediator.resequencer

- oracle.soa.mediator.resequencer.besteffort

- oracle.soa.mediator.resequencer.fifo

- oracle.soa.mediator.resequencer.standard

- oracle.soa.mediator.service

- oracle.soa.mediator.service.common.functions

- oracle.soa.mediator.service.filter

- oracle.soa.mediator.service.transformation

- oracle.soa.mediator.serviceEngine

Oracle BPEL Process Manager

- oracle.soa.bpel

- oracle.soa.bpel.console

- oracle.soa.bpel.engine

- oracle.soa.bpel.engine.activation

- oracle.soa.bpel.engine.agents

- oracle.soa.bpel.engine.bpel

- oracle.soa.bpel.engine.compiler

- oracle.soa.bpel.engine.data

- oracle.soa.bpel.engine.delivery

- oracle.soa.bpel.engine.deployment

- oracle.soa.bpel.engine.dispatch

- oracle.soa.bpel.engine.sensor

- oracle.soa.bpel.engine.translation

- oracle.soa.bpel.engine.ws

- oracle.soa.bpel.engine.xml

- oracle.soa.bpel.entity

- oracle.soa.bpel.jpa

- oracle.soa.bpel.system

Oracle BPM Suite

oracle.bpm.bpmn.engine

Oracle B2B

- oracle.soa.b2b.apptransport

- oracle.soa.b2b.engine

- oracle.soa.b2b.transport

- oracle.soa.b2b.ui

- oracle.soa.b2b.repository

Oracle adapters

oracle.soa.adapter

Oracle Web Services Manager (OWSM)

oracle.wsm

4. From the Oracle Diagnostic Logging Level (Java Level) list, change the logger level to one of the following settings:

- TRACE:1 (FINE)

- TRACE:16 (FINER)

- TRACE:32 (FINEST) - Most verbose level (recommended for troubleshooting)

The change takes effect within several minutes.

B.1.1 Log Files and Thread Dumps from All Managed Servers

Table B-1 describes the log files to view and thread dumps to obtain.

Table B-1 Log Files and Thread Dumps

Output

Description

Server diagnostic log

View the following file:

$DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log

For example, soa_server1-diagnostic.log, if server_name is soa_server1.

This is where the log output is available. By default, only the last 100 MB of the diagnostic logs are retained.

Server log

server_name.log (for example, soa_server1.log, if server_name is soa_server1)

Server console output

<stdout> is also useful, especially for deployment and patching issues.

Server thread dump

Enter the following at the operating system command prompt:

kill -3 managed_server_process_ID

You can also use Oracle WebLogic Server Administration Console.

1. In the navigation tree of Oracle WebLogic Server Administration Console, select Environment > Servers.

2. In the table, select the server.

3. Select the Monitoring tab.

4. Select the Threads tab.

5. Click Dump Thread Stacks.

The output is in the console logs.

OWSM message log

The following log captures all SOAP messages on the wire.

$DOMAIN_HOME/servers/server_name/logs/owsm/msglogging/diagnostic.log

This log is not enabled by default. To enable this log:

1. Go to Fusion Middleware Control > Weblogic Domain > Web Services > Policies.

2. Select the security level for which to enable logging.

3. Edit the policy to enable the log assertion.

B.2 Parallel Purging and Table Partitioning Issues

This section describes how to troubleshoot parallel purge and table partitioning issues. Audit level recommendations are also provided.

You can delete instances and rejected messages with the PL/SQL purge script or from the Auto Purge page in Oracle Enterprise Manager Fusion Middleware Control. For more information, see Managing Database Growth .

B.2.1 Executing the Parallel Purge Script

This section addresses situations in which the Oracle SOA Suite database has not been managed and space must be reclaimed. This section also describes how to identify the appropriate parameter settings for normal, daily execution.

When trying to reclaim space, the purge scripts must be executed frequently to delete substantially more SOA composite applications than are being created. This has implications for host and database resources that must be monitored to avoid lengthy wait queues.

There must be a clear goal on the number of SOA composite applications to delete. Otherwise, the purge script can be configured too aggressively. The following aspects are described:

- Specifying the Degree of Parallel Value

- Parsing SOA Composite Applications to Delete

- Using Parallel Query Slaves

- Debugging and Tracing Purging Operations

B.2.1.1 Specifying the Degree of Parallel Value

When specifying the appropriate degree of parallel (DOP) value, hardware resources must be considered. The DOP identifies the number of jobs scheduled by the database and the number of processes concurrently executed on the host.

The parallel purge jobs are I/O intensive, which means that they are not entirely CPU-bound. However, the following formula is a starting point after which testing and monitoring are required to identify any increases:

DOP <= PARALLEL_THREADS_PER_CPU x CPU_COUNT

While purge jobs are run concurrently, they are actually executed with a 30-second incremental delay to avoid resource contention. The delay is not meant to avoid row contention because the purge jobs must not contend for the same SOA composite applications. This delay has implications for the elapsed time of the purge jobs. As an example, a DOP of 10 means that the tenth purge job sleeps for 270 seconds before starting (that is, (DOP - 1) * 30 sec).

If a high DOP number is specified, then the max_runtime parameter must be set appropriately.

B.2.1.2 Parsing SOA Composite Applications to Delete

The temptation to delete as many SOA composite applications as possible in each execution of the purge script is understandable when trying to reclaim space. However, the script must parse the data for the appropriate SOA composite application, which can monopolize the elapsed time of the purge.

The strategy must be to reduce the data by running the purge script often with modest date and max_count parameter settings. This reduction requires the parallel purge to be scheduled frequently, perhaps twice an hour.

The set of SOA composite applications to parse is identified by the following parameters:

- min_creation_date

- max_creation_date

- retention_date

- max_count

A modest max_count parameter setting is the most effective method for reducing parse elapsed times. Set the max_count parameter low, perhaps to 50K, to begin until an optimal value can be identified. As the tables start to reduce in size, the max_count parameter and date ranges can be increased.

Note:

This method of reduction is not always effective. On occasions, you may need to introduce parallel query to parse larger amounts of data.

B.2.1.3 Using Parallel Query Slaves

The parsing for candidate SOA composite applications to delete is primarily performed by several INSERT ... SELECT statements. The larger the set of SOA composite applications to parse, the more the database cost-based optimizer favors a full table scan. When large portions of a table must be traversed, a full table scan can be faster than index access because it performs multiblock I/O calls.

A parallel query can significantly improve full table scan performance by coordinating and distributing the work over multiple slave processes. Additionally, the PARALLEL hint on the INSERT portion executes in APPEND mode. This further improves performance through direct path inserts.

As with the scheduled purge jobs, the parallel query slaves are I/O intensive and not entirely CPU bound. However, the following formula is a good starting point when selecting a DOP for the PARALLEL hint:

DOP <= PARALLEL_THREADS_PER_CPU x CPU_COUNT

Note:

There is a DOP setting to identify the number of parallel purge jobs and a DOP setting to identify the number of parallel query slaves. These DOP settings both impact the amount of processes executed on the host, but not simultaneously. The INSERT ... SELECT statement executes first to parse the data followed by the scheduling of the parallel purge jobs.

For the INSERT... SELECT statement, the PARALLEL hint can be specified after the INSERT keyword, after the SELECT keyword, or both. Therefore, parallelism of the INSERT and SELECT operations are independent of each other. The appropriate DOP for the entire statement is identified by the following precedence rule:

- PARALLEL hint on INSERT portion of the statement.

- Set at session.

- DOP on INSERT table.

- Maximum DOP set on any table in the statement.

To execute parallel DML, the following statement must be executed within the script:

ALTER SESSION FORCE PARALLEL DML STATEMENT

For example, this statement has a DOP of 2 for the INSERT and 4 for the SELECT. However, given the precedence rules, the DOP for the entire statement is 2:

INSERT /*+ PARALLEL(TBL_INS,2) */ INTO TBL_INS
SELECT /*+ PARALLEL(TBL_SEL,4) */ * FROM TBL_SEL;

Note:

A parallel query can also be applied to the DELETE and SUBSELECT commands in the purge script, if required.

B.2.1.4 Debugging and Tracing Purging Operations

This section describes debugging and tracing issues.

B.2.1.4.1 Debugging Purging Operations

The purge scripts are instrumented with a DEBUG flag that provides detailed, timestamped information on each operation. This information can be evaluated to identify which tables are difficult to delete and may be better managed outside of the purge scripts through table partitioning.To set the DEBUG flag:

1. Create an operating system directory in which to write the debug logs.

mkdir -p /,,/debuglogs

2. Connect to the database with the SYSDBA account to create the database directory.

SQL> CREATE OR REPLACE DIRECTORY SOA_PURGE_DIR AS '/../DEBUGLOGS';

3. Grant privileges to the Oracle SOA Suite schema owner:

SQL> GRANT READ, WRITE ON DIRECTORY SOA_PURGE_DIR TO DEV_SOAINFRA;

4. Connect as the Oracle SOA Suite schema owner and set the DEBUG flag.

cd MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/soa_purge/
SQL> @DEBUG_ON.SQL;

5. Execute the purge script:

SQL> SET SEVEROUT ON
SQL> EXECUTE_PURGE

Note:

As an alternative, use the SQL*Plus SPOOL command to capture debug information.

The Automatic Workload Repository (AWR) reports for the period of the purge can also help to identify the SQL with the longest elapse and execution times.

B.2.1.4.2 Tracing Purging Operations

If SQL tracing is required to diagnose the performance of the parallel purge scripts, then the following is required:

1. Edit procedures soa.delete_instances_in_parallel and soa.delete_insts_in_parallel_job to add the SQL trace (10046):

SQL> EXECUTE IMMEDIATE 'ALTER SESSION SET EVENTS ''10046 TRACE NAME CONTEXT
FOREVER,LEVEL 12''';

Note:

All quotes are single quotes.

This creates a SQL trace for the purge session and the scheduled purge jobs (J000) in the database user dump destination.

SQL> SHOW PARAMETER DUMP

2. Identify the trace for the main database session by searching the trace files for string dbms_scheduler.create_job or delete_instances_in_parallel.

grep -i dbms_scheduler.create_job *

For example:

TESTORA2_ora_3893.trc

The number of scheduled jobs depends on the DOP. For example, a DOP of 4:

- TESTORA2_j000_9585.trc

- TESTORA2_j001_9587.trc

- TESTORA2_j002_9604.trc

- TESTORA2_j003_9606.trc

If parallel query slaves have been customized into the purge script, then there are trace files (P000) for each. The parallel query trace files are less important because the query plans in the other trace file account for their execution. For example:

PSOAORA2_p000_4284.trc

3. Execute TKPROF on the trace files and sort by the elapsed time to identify the most costly SQL:

TKPROF TESTORA2_ORA_3893.TRC ../OUT/ TESTORA2_ORA_3893.OUT WAITS=YES
SYS=YES AGGREGATE=YES SORT=EXEELA

For more information about TKPROF, see Oracle Database Performance Tuning Guide.

B.2.2 Oracle SOA Suite Table Partitioning

Oracle table partitioning addresses many concerns about the maintenance of large tables by decomposing them into smaller, more manageable segments called partitions. The SOA schema has been instrumented with partition keys to take advantage of the Oracle database range partitioning.

For more information about partitioning, see Partitioning Component Tables.

B.2.2.1 Referential Integrity and Equipartitioning

For performance reasons, the Oracle SOA Suite service components (excluding Oracle B2B) have no foreign key constraints to police referential integrity. Without these constraints, the relationship between master and detail tables must be protected to avoid dangling references in the detail tables.

Equipartitioning is a database partitioning feature that partitions master and detailed tables based on their foreign key constraint. This feature creates table partitions that group related master and detail rows in the same date range. This grouping ensures that no dangling references are created when partitions are dropped.

To mimic this feature, Oracle SOA Suite is instrumented to push the creation date of the business flow instances down into the component master tables (Oracle BPEL Process Manager, Oracle Mediator, and human workflow). Because the SOA Infrastructure is the top level component on which all other components depend, this method groups all dependent rows by date range.

For example, the timestamp in the CREATED_TIME column of the SCA_FLOW_INSTANCE table is pushed down into the following tables:

- Oracle BPEL Process Manager master table CUBE_INSTANCE column CPST_INST_CREATED_TIME, which is then pushed down into dependent tables such as CUBE_SCOPE.CI_PARTITON_DATE.

- Oracle Mediator master table MEDIATOR_INSTANCE column COMPOSITE_CREATION_DATE, which is then pushed down into dependent tables.

Note:

- Dependent tables must be partitioned with their master and, in all cases, the top level SOA Infrastructure SCA_FLOW_INSTANCE table must be partitioned.

- To complete equipartitioning, the table partitions must all share the same name and date range.

In summary, equipartitioning means that the associated dependent table rows are in a partition with the same partition key range as their master table rows. Therefore, the state of each detail row in the equipartition can be inferred from its associated master table row.

B.2.2.2 SOA Composite Application Range-Hash Partitions

Range partitions can have their rows hashed into a subpartition to implement SOA composite application range-hash partitioning. Hash subpartitions can benefit in distributing I/O, but it is not currently recommended when partitioning Oracle SOA Suite tables.

Hashing of keys is a method that works well with equality predicates (=, IN), and there are several tables with keys that are good candidates such as the Oracle BPEL Process Manager CIKEY table. However, range-hash partitions alone do not convey the uniqueness of the hash key. For the cost-based optimizer to identify uniqueness, the query must search all partitions of a table (a full table scan). Partition pruning helps by narrowing the range of partitions to search, but Oracle SOA Suite does not use this feature. (See Partition Pruning.) Therefore, to avoid a full table scan when the cost-based optimizer identifies uniqueness, indexes are searched that bypass the hash subpartition.

B.2.2.3 Interval Partitioning

Interval partitioning is an extension of range partitioning that instructs the database to automatically create partitions as required.

The verification scripts currently require the partition name to be the same across all tables in a group. The interval partitioning system generates partition names that differ for each partition. Therefore, this is not supported.

B.2.2.4 Global Hash Indexes

The use of global hash indexes is independent of Oracle SOA Suite table partitioning.

Oracle SOA Suite is constantly inserting rows, and many of the index keys are monotonically increasing. Indexes of a BTREE structure insert these keys and target only a few database blocks that can become very hot across an Oracle Real Application Clusters (Oracle RAC) setup. This is typically seen in the AWR reports as excessive buffer busy waits. To distribute the index keys randomly across many database blocks, use global hash indexes.

B.2.2.5 Partition Pruning

When the range partition keys are used as predicates, the optimizer can prune the number of partitions to search. Oracle SOA Suite and especially Oracle Enterprise Manager Fusion Middleware Control do not presently use partition keys in SQL queries and therefore do not take advantage of this performance feature.

With the requirements of equipartitioning, the partition keys are populated with the SOA composite application creation date that is not the creation date of the components. The components (Oracle BPEL Process Manager, Oracle Mediator, and human workflow) have their own creation dates that are used in the console queries:

Example for Oracle BPEL Process Manager:

- Partition key: Table CUBE_INSTANCE column CPST_INST_CREATED_TIME

- Creation date: Table CUBE_INSTANCE column CREATION_DATE

B.2.2.6 Purging Partitions

Circumstances may arise that require the partitioned tables to be purged, especially if the row migration scripts are used. This defeats the purpose of partitioning the table for maintenance, which can remove data in bulk through the ALTER TABLE ... DROP PARTITION command.

Attempting to purge the partitioned tables most likely causes the parsing performance problem. If partitions must be purged, then also shrink the partitions. For more information, see Understanding Space Management.

B.2.3 Reducing Audit Levels

This section provides tuning information about how to reduce the audit level for SOA composite applications and the data written to the Oracle SOA Suite schema.

B.2.3.1 Setting the Audit Level for Production Environments

The default Audit Level is set to Production at the SOA Infrastructure level. To limit database growth, and for optimal performance, Oracle recommends that you turn Off the setting at the SOA Infrastructure level, and instead turn on auditing at the composite level for composites that require debugging or monitoring. Your compliance requirements might also determine the granularity of your audit requirements.

The following image depicts setting the audit level for a composite from the composite home page:

Note:

You can change the audit level setting at the SOA Infrastructure level using the SOA Infrastructure Common Properties page in Oracle Enterprise Manager Fusion Middleware Control. See Configuring SOA Infrastructure Properties for information about turning off audit at the SOA Infrastructure level.

See Managing the State of an Application from the SOA Composite Application Home Page for more information about setting the audit levels at the composite level.

If you can disable auditing (provided the business requirements allow for it), there are substantial performance improvements. Changing Production to Off can result in improvements (without tuning the individual component audit settings). However, if you cannot disable auditing, Oracle recommends that you consider the following steps to reduce audit levels.

For synchronous BPEL components for which the audit trail is not required, use the following settings:

- inMemoryOptimization = true

- completionPersistPolicy = faulted

With these settings, the synchronous process only appears in the audit trail if the instance faults.

For information about setting inMemoryOptimization and completionPersistPolicy, see "Deployment Descriptor Properties" in Developing SOA Applications with Oracle SOA Suite.

Note:

Use these settings for synchronous BPEL processes and not for asynchronous BPEL processes.

B.3 Connection and Transaction Timeout Troubleshooting

This section describes how to troubleshoot connection and transaction timeout issues.

B.3.1 Resolving Connection Timeouts

You can receive a connection timeout error under circumstances such as the following:

- You run a SOA composite application with a large payload that takes more than 30 seconds to process.

- You are invoking a stress test using a large payload from the Test Web Service page of Oracle Enterprise Manager Fusion Middleware Control.

- You are passing a large number of message files (one million) into a composite with a file adapter service.

To avoid these timeout errors, increase the transaction timeout property as follows:

1. Log into Oracle WebLogic Administration Console.

2. Click JTA.

3. Change the value of Timeout Seconds (the default is 30).

4. Click Save.

5. Restart Oracle WebLogic Server.

B.3.2 Resolving Email Notification Timeouts

You can receive a connection timeout errors when a large number (for example, 200,000) of notification emails are sent.

To avoid these timeout errors:

1. Increase the JTA Timeout Seconds value to 1200.

2. Change the EJB timeout to 1800 for NotificationSender, NotificationServiceBean, and TaskNotificationSender EJBs. See Long Running_ Synchronous Calls To Remote Web Services Error Out or Asynchronous Transactions Return with an Error after a Long Time.

3. Increase the DataSource XA Transaction Timeout value to 1330.

4. In the database, change the Distributed_lock_timeout parameter value to 1400.

Note:
Important point to note here is that the DataSource XA Transaction Timeout has to be greater than the JTA transaction time out and the Distributed_lock_timeout has to be greater than the DataSource XA Transaction timeout value.

5. Restart Oracle WebLogic Server after making these changes.

Note:
You can also increase the timeout values in deployment descriptor file and redploy the deployment descriptor file. For more information, Deployment Descriptor Schema and Document Type Definitions Reference and other deployment related sections in the Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server guide.

B.3.3 Increasing Database Connection Values

You can receive the error message shown below because of slow connections to the database:

090304)): oracle.toplink.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Internal error: Cannot obtain
XAConnection weblogic.common.resourcepool.ResourceDeadException: Pool
SOADataSource has been disabled because of hanging connection tests, cannot
allocate resources to applications.

If this occurs, perform the following steps:

1. Open the $DOMAIN_HOME/bin/setSOADomainEnv.sh file on Linux or the DOMAIN_HOME\bin\setSOADomainEnv.cmd file on Windows.

2. Open the DOMAIN_HOME\bin\setSOADomainEnv.cmd file.

3. Uncomment the lines shown in bold.

# 8331492: Value of weblogic.resourcepool.max_test_wait_secs is 10
# seconds. It can be increased by uncommenting line below if your database
# connections are slow. See SOA documentation for more details.
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Dweblogic.resourcepool.max_test_wait_secs=30"
export EXTRA_JAVA_PROPERTIES

4. Save your changes and restart the managed Oracle WebLogic Server.

B.3.4 Updating the EJB Transaction Timeout Value in the Deployment Archive After SOA Infrastructure Failure

Updating the transaction timeout value for the FacadeFinderBean property in Oracle WebLogic Server Administration Console under Deployments > expanded SOA Infrastructure Application > FacadeFinderBean > Configuration tab can result in the error shown below after restarting the SOA Infrastructure:

java.lang.IllegalArgumentException: Cannot convert value of type [$Proxy223
implementing
oracle.bpel.services.workflow.verification.IVerificationService,org.springframe
work.aop.SpringProxy,org.springframework.aop.framework.Advised]
to required type
[oracle.bpel.services.workflow.verification.IVerificationService] for
property 'verificationService': no matching editors or conversion strategy found
Message icon - Warning Errors were encountered while performing this operation.

The SOA Infrastructure status is also displayed as failed.

This error is not specific to FacadeFinderBean; it also applies to any EJB that is part of the SOA Infrastructure application.

To resolve this error, you must manually modify the transaction timeout setting in your deployment archive.

To update the transaction timeout setting:

1. Open the fabric-ejb.jar file in your deployment archive.

2. Increase the transaction timeout value in the META-INF/weblogic-ejb-jar.xml file to a larger value.

3. Rejar the file.

4. Restart the managed server that includes the SOA Infrastructure by following the instructions in Stopping and Starting the Managed Server and SOA Infrastructure .

Note:

This issue may also occur while updating any EJBs deployed as part of the SOA Infrastructure application. If this issue occurs, you must update the corresponding contained JAR file for those EJBs in a similar fashion.

B.3.5 Long Running, Synchronous Calls To Remote Web Services Error Out or Asynchronous Transactions Return with an Error after a Long Time

You may have long running, synchronous calls to remote web services that end with JTA transaction rolled-back errors. When executing a transaction making an asynchronous call (for example, to the SOA server), the application may return with an error. The server logs show JTA transaction timeouts, which can cause this behavior.

To check the JTA transaction timeout in the Oracle WebLogic Server Administration Console.

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure, select Services > JTA to check the timeout value.
If the transaction is always timing out beyond 30 seconds and is a custom composite synchronous client invocation, then you may need to revisit the design approach. It may be best for the external web service to be invoked as an asynchronous transaction.

Increasing the JTA for supporting long running, synchronous transactions is simply an interim mechanism. For information on changing the JTA transaction timeout setting, see Resolving Connection Timeouts.

3. If synchronous client invocations take a long time, check for any performance issues with the system and try to resolve them.

4. Check for appropriate values for the syncMaxWaitTime property and BPEL's EJB transaction timeout settings in relation to the JTA timeout settings and only then increase the value of the JTA timeout, if needed.
For information on viewing and changing the syncMaxWaitTime property, see Configuring BPEL Process Service Engine Properties.

5. To view and change the BPEL EJB transaction timeout settings, perform the following steps:

a. Log in to Oracle WebLogic Server Administration Console.

b. In the Domain Structure, click Deployments.

c. Expand soa-infra > EJBs.

d. Update the following EJBs:
- BPELActivityManagerBean

- BPELDeliveryBean

- BPELDispatcherBean

- BPELEngineBean

- BPELFinderBean

- BPELInstanceManagerBean

- BPELProcessManagerBean

- BPELSensorValuesBean

- BPELServerManagerBean

e. Click Save.

f. Restart Oracle WebLogic Server.

6. For asynchronous transactions, check the values for both the BPEL EJB transaction timeout and the JTA transaction timeout and adjust, as needed.

B.3.6 Increasing the HTTP POST Timeout Value to Resolve Broken Pipe Errors

If you receive the broken pipe error as shown below, increase the HTTP POST timeout value in Oracle WebLogic Server Administration Console.

<BEA-000000> <got FabricInvocationException, Cikey=73410002, FlowId=10001, Current
Activity Key=73460002-BpInv0-BpSeq0.3-3, Current Activity Label=Invoke_1,
ComponentDN=default/TestClientWSMEDWSBPELFAProj!2.0*soa_
b2e412f3-1167-4a9a-bbe0-73795f0743d4/BPELProcess1
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)

To increase the HTTP POST timeout value:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure, expand Environment > Servers.

3. In the Name column, click the SOA server.

4. At the top of the page, click the Protocols tab.

5. In the Post Timeout field, increase the value to a maximum of 120.

B.3.7 Resolving Exception Errors When Processing Large Documents

If you receive the error shown below when processing large attachments, increase EJB property timeout values.

java.sql.SQLException: Unexpected exception while enlisting XAConnection
java.sql.SQLException: Transaction rolled back: Transaction timed out after 501
seconds

To increase EJB property timeout values:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure, click Deployments.

3. Expand soa-infra > EJBs.

4. At the bottom of the page, expand the EJBs section.

5. Increase the time out value:

- BpelEngineBean

- BpelDeliveryBean

- CompositeMetaDataServiceBean

B.4 Runtime Diagnostics Troubleshooting

This section describes how to troubleshoot runtime issues.

B.4.1 Unavailability of Work Manager Threads for Incoming Processing

The exception message shown below occurs because there are a fixed number of work manager threads allocated for incoming processing, and Oracle SOA Suite has reached the thread limit. Oracle SOA Suite gracefully backs out of processing to prevent a resource bottleneck that may eventually lead to a stuck thread scenario. If you receive this error, you must resubmit your request.

<Mar 11, 2014 2:10:16 PM PDT> <Error> <HTTP> <BEA-101017>
<[ServletContext@207971169[app:soa-infra module:/soa-infra path:null
spec-version:3.0]] Root cause of ServletException.
java.lang.Exception: Unable to acquire the workmanager thread resource in
order to process requests directed at compsoite
default/POProcessing!1.0*soa_7a9c6320-c26e-4df2-b29f-7b80782d3693
at
oracle.integration.platform.blocks.deploy.CompositeLazyLoader.load(CompositeLa
zyLoader.java:112)
at
. . .
. . .

B.4.2 Oracle SOA Suite Runtime Failure with a "Cannot read WSDL" Error

The following error is displayed if either the endpoint is not available for a reference or a composite is deployed with an incorrect deployment plan file.

oracle.fabric.common.FabricException: Cannot read WSDL

To diagnose this issue:

1. Ensure that the endpoint for the reference is up and running.

The WSDL or endpoint is stated in the error. The service can then be looked up from Oracle Enterprise Manager Fusion Middleware Control to check if it is active. Once the service is active and the endpoint is reachable, search for the SOA instance and retry it through the Recovery tab of the BPEL process service engine in Oracle Enterprise Manager Fusion Middleware Control.

2. For extensions/customizations, ensure that the correct URL is updated in the deployment configuration plan.

For information about deployment plans, including examples of using sca_extractPlan to extract plans, see the Section "Customizing Your Application for the Target Environment Before Deployment" of Developing SOA Applications with Oracle SOA Suite.

B.4.3 Automatic Recovery of BPEL Instances is Not Recovering a Specific Instance

BPEL processes have an automatic recovery feature that attempts to automatically recover activities that are recoverable such as unresolved invoke and callback messages, activities not completed over a provided threshold time, and so on. However, the automatic recovery feature only tries to recover a few instances and only retries a fixed number of times. If some instances are not being automatically recovered, they are likely not being picked up because of the configuration of the automatic recovery parameters.

To resolve this issue:

- Set the maximum number of messages to automatically recover.
By default, the automatic recovery feature of Oracle BPEL Process Manager processes 50 messages to submit for each recovery attempt. This is controlled by the maxMessageRaiseSize property.

1. In the navigation pane, right-click soa-infra (SOA_cluster_name).

2. Select SOA Administration > BPEL Properties > More BPEL Configuration Properties > RecoveryConfig.

3. Expand both RecurringScheduleConfig > maxMessageRaiseSize and StartupScheduleConfig > maxMessageRaiseSize.
The default value is 50 for each. A negative value causes all messages selected from the database to be submitted for recovery. A value of 0 causes no messages to be selected from the database (effectively disabling recovery). To recover more than 50 messages, set the property value to that value. Use this property to limit the impact of recovery on the server.

- Set the maximum number of automatic recovery attempts on a given message.
You can also configure the number of automatic recovery attempts to submit in the same recoverable instance. The value you provide specifies the maximum number of times that invoke and callback messages are recovered. If the value is 0 (the default value), it recovers all messages. Once the number of recovery attempts on a message exceeds the specified value, a message is marked as nonrecoverable.

To configure automatic recovery attempts for invoke and callback messages in Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigation pane, right-click soa-infra (SOA_cluster_name).

2. Select SOA Administration > BPEL Properties > More BPEL Configuration Properties.

3. Select MaxRecoverAttempt, and enter a value in the Value field.

4. Click Apply.
It may not be desirable in all cases to use automatic recovery. If services are not idempotent, then corruption can occur. Moreover, the automatic recovery restores the composite to the last save point that can be immediately after an asynchronous invoke, wait, and so on. Therefore, it is important to understand the process behavior and what it does next before performing mass recoveries. Attempt mass automatic recovery only after the root cause of the composite failures is fixed (for example, a service that was unavailable is now available, a database running out of space was fixed, and so on). Automatic recovery can also trigger an unexpected load during failure scenarios. This causes more threads to block on a remote server that can induce hangs in the SOA server in a cascading fashion.

For more information, see Configuring Automatic Recovery for .

B.4.4 Some Composites Are Retried Multiple Times on Failure

When a BPEL process flow errors out, it is retried with all its invocations. This is undesirable in some cases.

The property GlobalTxMaxRetry (default value is 3) specifies how many retries are performed if an error is identified as retriable. For example, after several web service invocations, if dehydration fails due to a data source error, then this is identified as a retriable error and all activities from the prior dehydration state are retried. If the activities being retried are not idempotent (that is, their state can change with each retry and is not guaranteed to give the same behavior), then multiple retries can be problematic.

To rectify this situation, customize the composite by specifically marking the nonidempotent activities with idempotent set to false in the partner link settings section of the composite.xml file to prevent retries.

<property name="bpel.partnerLink.partner_link_name.idempotent">false</property>

You cannot set the idempotent property in Oracle Enterprise Manager Fusion Middleware Control.

You can also set GlobalTxMaxRetry to 0 in the Systems MBean Browser.

To set GlobalTxMaxRetry:

1. Right-click soa-infra (SOA_cluster_name).

2. Select SOA Administration > Common Properties.

3. Click More SOA Infra Advanced Configuration Properties.

4. Click GlobalTxMaxRetry.

5. In the Value field, enter an appropriate value.

6. Click Apply.

For more information about the idempotent property, see "Managing Idempotence at the Partner Link Operation Level" section of Developing SOA Applications with Oracle SOA Suite.

B.4.5 Application Transaction Does Not Complete and the Underlying Composite is Stuck in a Running State

Assume an application transaction is not completing. For example, a purchase order status may remain processing. Checking the business flow instance shows that the composite is stuck in the running state. In this case, the component is probably not running. Instead, it has likely faulted and may need recovery.

Faults may occur for various reasons:

- A BPEL activity faulted with an error (for example, a business error, security authorization error, or some other error).

- A BPEL activity invoked an external web service that was unavailable.

- A BPEL activity has already been terminated by the administrator using Oracle Enterprise Manager Fusion Middleware Control.

- A BPEL activity invoked an asynchronous ADF service and the message is stuck in the AQ JMS queue.

- A BPEL activity invoked an asynchronous ADF service, but because Oracle SOA Suite was unavailable, the callback message did not arrive.

- A BPEL activity invoked a synchronous ADF service, which is taking a long time (or is hanging).

- A network error occurred.

To diagnose this issue:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. In the navigator pane, go to domain_name > SOA.

3. Click soa-infra (SOA_cluster_name).

4. Click the Flow Instances tab.

5. Search for the business flow instance, and click the flow ID.
The Flow Trace page appears.

If the instance is not visible (and the Audit Level is not set to Off on the SOA Infrastructure Common Properties page), this implies that the message is stuck outside of Oracle SOA Suite.

If the message has reached Oracle Mediator, but not instantiated the BPEL flow, the BPEL instance may have been rolled back from the start due to an error.

If the BPEL flow exists, the Faults section of the Flow Trace page typically shows the faulted service that can trace the root cause.

6. In the Trace section, click the BPEL process.

7. Expand the BPEL audit trail to see the exact point at which the service faulted.
This information is also available in the Faults tab of the BPEL flow trace. It also indicates whether the fault can be recovered.

8. Click the View Raw XML link.
The same information is also available through this link, where you can see the error. For example:

...
<message>Faulted while invoking operation "modifyUserRoles" on provider
"UserService". </message><details>
...
<tns:message>JBO-27023: Failed to validate all rows in a
transaction.</tns:message>
<tns:severity>SEVERITY_ERROR</tns:severity>
...
<message>The transaction was rolled back. The work performed for bpel instance
"451042" was rolled back to the previous dehydration point, but the audit
trail has been saved.
You can recover the instance from the recovery console by resubmitting the
callback message or activity for execution.</message

Since the instance was rolled back to its previous dehydration point, the status remains as Running.

9. In the Audit Trail tab, make a note of the following:

- Composite name (for example, POComposite)

- Component (for example, UpdateGuid BPEL process)

- BPEL instance ID (for example, bpel:451042)

This is all used in the recovery of the instance, if it is recoverable. The Audit Trail may mark the error as a nonrecoverable business fault, but the recoverability of the message can be found in the Recovery tab of the BPEL process service engine.

10. To attempt to recover the instance, right-click soa-infra (SOA_cluster_name), and select Service Engines > BPEL.

11. Click the Recovery tab.

12. From the Type list, select Activity.

13. Specify the composite and component names captured in step 9, and click Search.

14. Find the specific BPEL instance ID. You can recover faults marked as Recoverable.

15. Check the other recovery options in the Type list (for example, Invoke and Callback), if they exist.

Note:

You can also search for recoverable messages from the Flow Instances page of the SOA Infrastructure.

16. If the instance is not marked as recoverable, then reinvoking the service is not allowed (most probably because it is not idempotent). In some cases, you may need to provide diagnostic information to Oracle Support Services to resolve issues with nonrecoverable, nonidempotent transactions.

17. If the BPEL activity has invoked an asynchronous ADF service and the message is stuck in the AQ JMS queue, you can view the server.log and server-diagnostic.log files to see the logging of the message metadata logged by the JRF web services infrastructure.
In addition, the ADF diagnostic logs are also available to debug, if needed.

a. Use the ECID field to correlate and track ADF service logging corresponding with the SOA composite application that invoked it.

b. When viewing the log in Oracle Enterprise Manager Fusion Middleware Control, click the Broaden Target Scope dropdown list and select the farm_name/domain_name (Oracle WebLogic domain) to view messages across the domain.

c. In the Selected Targets section of the Log Messages page for the Oracle WebLogic Server domain, ensure that the search includes the ECID field with the value noted in step 17.a.

d. Search and view log records for the execution content ID (ECID) and note any issues.
For a specific ECID, you find several root instances (top level clients). You must drill down to the appropriate instance to find a specific fault.

e. Observe if the components completed successfully or completed with an error. See the "Viewing and Searching Log Files" section in the Administering Oracle Fusion Middleware.

See the following chapters for the various ways to recover transactions and messages:

- Managing SOA Composite Application Business Flow Instances to recover from the SOA composite application page in Oracle Enterprise Manager Fusion Middleware Control.

- Managing BPEL Process Service Components and Engines to recover from the BPEL process service component and BPEL process service engine message recovery pages.

B.4.6 Errors During Analytics Measurement Event Processing

When errors occur during processing of BPMN, Human Workflow, CASE analytics measurement events for any reason like target BAM is down or the database is not available and so on, (i) analytics message processing related errors are seen in the logs and (ii) BPM_MEASUREMENT_ACTION_EXCEPS table also has one or more records of these errors. You can republish these events by using any of the two methods.

Using Measurement Action Service client

Use republishErroredEvents operation to republish errored measurement events of the past 24 hours. This operation is available as part of AnalyticsConfig mbean To republish the error events, perform the following activities. Enter password when prompted..

java    [CLASSPATH]   [PROPERTIES]  oracle.bpm.metrics.action.MeasurementActionRecoveryClient

CLASSPATH:
-classpath $MW_HOME/soa/soa/modules/oracle.bpm.runtime_<version number of instance>/oracle.bpm.analytics.metrics.interface.jar:
$MW_HOME/soa/wlserver/server/lib/weblogic.jar

Enter the following required properties.

-Dhost=<host> (soa server host name)
-Dport=<port> (soa server port)
-Duser=<admin user> (soa server admin user name)
-DcompositeName=<soa composite name> (soa server host name)

Enter the following optional properties depending on your need.

-Drealm = <hostrealm Name>  (default is  jazn.com)
-Dprotocol=<protocol>  (jndi protocol. Default is t3)
-DinitialContextFactory = <jndi initial context factory> (Default is weblogic.jndi.WLInitialContextFactory)
-DmeasurementAction=<action name>  (measurement action name.  Default is ProcessMetrics (BAM 12c))
-DrangeStartDate=mm/dd/yyyy  (Range start date . Default is 24 hours before rangeEndDate )
-DrangeEndDate=mm/dd/yyyy (Range end date. Default is current time)
-Ddebug=true/false (if true, prints the exception stacktraces in case of any error. default is false)

Using Oracle Enterprise Manager AnalyticsConfig MBean - republishErroredEvents operation

republishErroredEvents operation is also available as part of AnalyticsConfig mbean (mbean object name = oracle.as.soainfra.config:name=analytics,type=AnalyticsConfig,Application=soa-infra). Oracle Enterprise Manager administrator can access and republsih errored messages of the last 24 hours.

1. Log into Oracle Enterprise Manager

2. Expand oracle.as.soainfra.config, Server:AdminServer, AnalyticsConfig and select analytics.

3. Open Operations tab in the right pane.

4. Click on republishErroredEvents.

5. Provide the necessary details as described above.

6. Click Invoke.

B.5 Human Workflow Troubleshooting

This section describes how to troubleshoot human workflow issues.

B.5.1 Unavailability of Human Workflow Service Engine

During SOA server startup, you can receive the exception shown below. This exception occurs because the SOA server is still initializing. Wait for SOA server initialization to complete.

ORABPEL-30132

exception.code:30132
exception.type: ERROR
exception.severity: 2
exception.name: Workflow Service Engine not ready. SOA server is still
starting.
exception.description: Could not obtain instance of Workflow Service Engine
as the SOA server is still initializing.
exception.fix: Wait for SOA server to finish starting up, and retry.

For information about monitoring SOA server initialization status in Oracle Enterprise Manager Fusion Middleware Control, see Viewing the Overall Runtime Health of the SOA Infrastructure.

B.5.2 Task Assignment/Routing/Escalation Issues

Table B-2 describes symptoms, possible causes, and possible solutions for task assignment/routing/escalation issues.

Table B-2 Troubleshooting Task Assignment/Routing/Escalation Issues

Symptom

Possible Cause

Possible Solution

The task completes without any assignment occurring.

The most common problem is that task assignees are specified using XPath expressions, and the expression does not evaluate to any nodes. Other problems can include incorrect skip conditions for participants.

1. Correct any issues with the XPath expressions.

2. Ensure that you get some results for the XPath expression for the given data.

3. Check the skip conditions specified with the Specify skip rule checkbox for task participants in the Human Task Editor.

The business rules do not return any list builders.

When participants of a task are specified using business rules, it is expected that business rules return at least one list builder. If business rules determine that no participants are needed, the function ignoreParticipant(...) must be used. If modeled correctly and you still see this error, it is likely that none of the rules fired. See the symptom entitled '"A human workflow task chooses the incorrect user if many rules are defined or it errors with the following message:" in this table.

1. Use the ignoreParticipant(..) function to model your rules.

2. Ensure the rules are modeled correctly so that at least one rule is fired.

The business rules return list builders of different types.

When participants in a task are specified using business rules, it is expected that business rules return list builders of the same type.

Correct your rules.

A human workflow task chooses the incorrect user if many rules are defined or it errors with the following message:

Ruleset returned lists with
different list builder

At runtime, when a human workflow task tries to fetch the list of users, it may error out with the following error:

Ruleset returned lists with different list builder

This error is displayed in the Task Detail comments field. Alternately, the task may select a user or approver, which may not appear to be the correct or expected one. This is primarily caused by having overlapping rules. When the participants of a task are specified using business rules, it is expected that business rules return list builders of the same type.

Moreover, only one rule from a ruleset must be applicable for a transaction. In case many rules are true, the actions associated with the applicable rule with the highest priority get executed. In case multiple applicable rules have the same priority, then the first rule in the list is picked and its actions executed.

Avoid writing overlapping rules. Constraints from different list builders are different and cannot be mixed. If multiple rules get triggered with a different list builder, this error occurs. In addition, only one set of constraints is honored.

Check that all rules in the ruleset have priorities defined so that multiple rules with the same priority are not applicable for the same transaction.

For more details., see Developing Business Processes with Oracle Business Process Management Studio.

Parallel assignees have to approve or reject the task even though the parallel completion criteria is met.

In the Add Participant Type dialog for a parallel participant, you can configure the human task during runtime to wait for all parallel participants to complete or to complete when criteria are met.

Make the correct selection for completion in the Add Participant Type dialog.

The task is assigned to the group/role when the expectation is that it goes to every user in the group/role individually.

When a group or a role is used as a task assignee, the task is assigned to the group or role directly. Task runtime does not assign it separately. One of the users in the group/role has to claim the task and work on it. When used with a parallel or serial participant, often times it is expected that this resolution to users is automatic, which it is not.

To assign separately to the members of the group or role, use the XPath functions ids:getUsersInGroup and ids:getUsersInAppRole.

A task errors out when invoking the decision service for the evaluation of routing rules or rule-based participants.

Payload validation is enabled on the SOA Infrastructure instance.

Deselect the Payload Validation checkbox for the instance. For more information, see Configuring SOA Infrastructure Properties.

B.5.3 Task Action Issues

Table B-3 describes symptoms, possible causes, and possible solutions for task action issues.

Table B-3 Troubleshooting Task Action Issues

Symptom

Possible Cause

Possible Solution

A user is not allowed to perform an action on a task.

The most common problem is that the user does not have permissions to perform that action on that task at that point in time.

Find out if the user can be an assignee, owner, or creator of the task, or if they are an administrator. If the user should have been allowed to perform the action, check the server log file for a detailed log message, which includes information such as the task state, task assignees, user who acquired it, permitted actions, roles played by this user for the given task, and so on.

A task is locked and cannot be updated in Oracle BPM Worklist. An ORA-30279 error is displayed (with an underlying ORA SQL exception of ORA-20001 also displayed).

Two users are trying to update the same task concurrently.

Wait for the other user to finish.

B.5.4 Notification Issues

Table B-4 describes symptoms, possible causes, and possible solutions for notification issues.

Table B-4 Troubleshooting Notifications Issues

Symptom

Possible Cause

Possible Solution

You may receive the following error message:

[2012-07-05T09:13:05.246-04:
00] [soa_server1] [ERROR] []
[oracle.soa.services.workflow
.common] [tid:
[ACTIVE].ExecuteThread: '6'
for queue:
'weblogic.kernel.Default
(self-tuning)'] [userId:
<anonymous>] [ecid:
dc2ff0568380b04f:23824bc7:13
8570a4e67:-8000-000000000000
1716,0] [APP: soa-infra] <.>
[[ORABPEL-0
at
oracle.bpel.services.workflo
w.task.notification.TaskNoti
fications.notifyForTask(Task
Notifications.java:481)
. . .
. . .

Check if you have apostrophes in the body of an email notification message.

<%string('À titre de
responsable fonctionnel, une
demande d'approbation
. . .

Escape each apostrophe by adding double apostrophes in your string. For example, if you have 'd in your message, escape it as follows:

<%string('d'd')%>

to:

<%string('d''d')%>

The email notification is not being sent out.

Incorrect outgoing (SMTP) server settings are used in the email driver configuration.

Check the Simple Mail Transfer Protocol (SMTP) port/SMTP host/user name/password/email values.

Tip: Validate the values by using them in any email client for connecting to the SMTP server.

Perform the following steps to verify the settings in Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigator, right-click User Messaging Service.

2. Select usermessagingdriver-email > Email Driver Properties.

3. Check the settings, in particular the settings for these properties:
- OutgoingMailServer

- OutgoingMailServerPort

The task email notification is not being sent out.

Notification Mode is set to NONE on the Workflow Notification Properties page in Oracle Enterprise Manager Fusion Middleware Control.

Change this setting to Email or All. For information, see Configuring Human Workflow Notification Properties.

Notifications are not being sent because of the following error message:

No matching drivers found for
sender address = <address>

The User Messaging Service driver for the appropriate channel is configured with a specific list of sender addresses, and the message sent by the application has set a nonmatching sender address.

Note: The User Messaging Service server matches the outbound message's sender address, if set, against the available drivers' sender addresses to find a matching driver to use for delivering the message. If a driver has set one or more sender addresses, then the User Messaging Service server only sends messages with the matching sender address to it.

Perform the following tasks:

- Check the following settings for the appropriate driver in Oracle Enterprise Manager Fusion Middleware Control:
SenderAddresses

SenderAddresses format is a comma-delimited list of DeliveryType:Address. For example:

EMAIL:sender@example.com,

EMAIL:sender@example2.com

- Leave this property blank if you want this driver to service outbound messages for all sender addresses for this channel (delivery type).

- If there are multiple driver instances deployed for the same channel (delivery type) with different configurations, use SenderAddresses to differentiate the driver instances. For example, set one instance with a value in SenderAddresses to only service outbound messages with that matching sender address. The other instance can keep the SenderAddresses blank to service all outbound messages that do not specify any sender address or one that does not match the first driver instance.

- SenderAddresses that are configured with incorrect syntax (such as missing DeliveryType:) are ignored by the User Messaging Service server for driver selection.

The notifications are sent, but are not actionable.

The Actionable Address field is not configured on the Workflow Notification Properties page in Oracle Enterprise Manager Fusion Middleware Control.

In Oracle Enterprise Manager Fusion Middleware Control, configure the Actionable Address field with a valid email address. For information, see Configuring Human Workflow Notification Properties.

Ensure that the same email address is used when configuring the incoming server setting in the User Messaging Service email driver. For information, see Configuring Human Workflow Notification Properties.

Notifications are sent, but are not actionable.

The human workflow task is not set to send actionable notifications.

In the Human Task Editor (you can double click the .task file in Oracle JDeveloper to start the editor), expand the Notification section, click the Advanced tab, and select the Make notification actionable checkbox.

Actionable notifications are sent, but no action is taken after responding.

The Actionable Address field is incorrect.

Check the IMAP/POP3 server/port values. Ensure the Actionable Address field is used in the email driver configuration.

Tip: Validate the values by using them in any email client for connecting to the IMAP/POP3 server.

Actionable notifications are sent, but no action is taken after responding.

The nondefault email client is configured for receiving notifications.

When the user clicks the approval link, the default mail client page opens, which may send emails to a different email server. Configure the default email client to receive actionable notifications.

Enter the correct value in the Actionable Email Account field of the Workflow Task Service Properties page as the incoming, actionable email account to use. The default account name is Default.

For information, see Configuring Human Workflow Task Service Properties.

Human workflow actionable notifications are sent, but no action is taken after responding.

Incoming mail server settings for the email driver are incorrect.

Check the following email driver settings in Oracle Enterprise Manager Fusion Middleware Control:

- MailAccessProtocol (IMAP or POP3 in uppercase)

- ReceiveFolder

- IncomingMailServer

- IncomingMailServerPort

- IncomingMailServerSSL

- IncomingUserIDs

- IncomingUserPasswords

- ImapAuthPlainDisable

Actionable notifications are sent but no action is taken after responding.

An email client is configured with the same account used in the email driver.

The mail may be downloaded and marked as read or deleted by the email client before the human workflow notification service can download and process the mail. Remove that account from the email client.

User notifications or human workflow notifications are sent through the correct delivery type (email, SMS, and so on), but to the wrong address.

A self-provisioned messaging channel was created by the user in User Messaging Preferences for use in a BPEL process user notification or human workflow notification.

Note: The User Messaging Preferences user interface enables you to create your own messaging channel for various use cases. However, do not use these channels for BPEL process user notification and human workflow.

Do not use a self-provisioned messaging channel for BPEL process user notification and human workflow use cases (that is, do not set as default channel and do not use in a messaging filter for such use cases). BPEL process user notification and human workflow use User Messaging Preferences only for the delivery type preference. The the actual address is retrieved from the user profile in the identity management system.

Note: Addresses from the user profile in the identity management system are available through User Messaging Preferences using predefined channel names, such as business email, business mobile, business phone, and instant messaging. Use these predefined messaging channels instead for bpel process user notification and human workflow use cases.

The Oracle BPM Worklist link appears in email notifications.

This is the default behavior. By default, email notifications point to Oracle BPM Worklist.

Perform the following steps:

1. In the Notification section of the Human Task Editor, click the Advanced tab.

2. Deselect the Show worklist URL in notifications checkbox.

Performance is slow for group notifications.

The group notification performance depends on the number of members in the group (size of group).

1. Provide an email ID for the group in LDAP. In this case, human workflow sends one email to the group email ID, instead of individual emails to each group member.

2. In the Notification section of the Human Task Editor, click the Advanced tab.

3. If you want to send one email to all group members, select Send one email containing all user addresses from the Group notification configuration list. This action enables all members to see the to list and common content is sent to all members (without considering locale, and so on).

4. If you want to send individual emails, but reuse content between members, select Send individual emails (the default selection) from the Group notification configuration list and unselect Use separate task forms based on locale. This action enables group members to receive individual mails in their locale. Task forms generated for creating notification content are reused between members in the same locale.

B.5.5 Task View Issues

Table B-5 describes symptoms, possible causes, and possible solutions for task view issues.

Table B-5 Troubleshooting Task View Issues

Symptom

Possible Cause

Possible Solution

Showing custom (mapped attribute) columns in a view.

Attribute mappings are created for specific task types. The view must be associated with one or more task types to use mapped attributes.

In Oracle BPM Worklist (view/create/edit UI), specify a task type for the view in the Definition tab. The attribute labels used in the mappings for that task type are now available as columns that can be used in the view in the Display tab.

It is possible to associate a view with multiple task types. Multiple task types can be selected from the Task Type browser. If multiple task types are selected, then the attribute labels for all those task types are available for use in the view.

View grantees can view and edit tasks belonging to the view owner.

The view is shared as data. This type of sharing allows grantees to use the view as if they are the view owner, and can see and act on the view owner's task.

In the Definition tab of Oracle BPM Worklist (view/edit UI), ensure that Share View is set to Definition only, which enables grantees to use the view against their own tasks. Setting Share View to Data enables grantees to use the view against the view owner's data.

Creating a new standard view.

Only users with administration privileges can create standard views.

1. Ensure the logged-in user has administration privileges.

2. Define the view as usual, using Oracle BPM Worklist (create/edit UI).

3. Check the add to standard views checkbox.
The view is created as a standard view.

Internationalizing a standard view name.

The value specified in the name field for standard views can be used as a resource key to look up a display name from the WorkflowLabels resource bundle.

Add a new resource key to the WorkflowLabels resource bundle. The key is the name you used for the view, prefixed by STD_VIEW. (Note the required trailing period.)

Migrating views and standard views you have created on one instance to another SOA server.

You must use the test-to-production utility.

The test-to-production utility enables you to export user views and standard views as an XML file, and to import the views from the XML file into another instance. For information about this utility, see Moving Human Workflow Data from a Test to a Production Environment.

B.5.6 Task Attribute Mapping Issues

Table B-6 describes symptoms, possible causes, and possible solutions for task attribute mapping issues.

Table B-6 Troubleshooting Task Attribute Mapping Issues

Symptom

Possible Cause

Possible Solution

No payload attributes are available for mapping to a public attribute in Oracle BPM Worklist.

Oracle BPM Worklist only supports creation of mappings to simple payload attributes. Only simple attributes from the task payload are displayed for creating mappings in Oracle BPM Worklist.

- Add simple attributes to the payload.

- Create protected mappings at design time. Mappings can be made to be complex payload attributes using XPath expressions for protected attribute mappings at design time in Oracle JDeveloper.

- Use the RuntimeConfigService API to create public mappings using XPath expressions.

You cannot create mappings for the protected attribute label in Oracle BPM Worklist.

Protected mappings can only be created as part of the task definition at design time. Protected mappings cannot be created or updated at runtime using Oracle BPM Worklist, or the RuntimeConfigService API.

- Use a public attribute label for the mapping.

- Create the mapping to the protected attribute label in the task definition at design time.

You cannot see any attribute labels for which to create mappings in Oracle JDeveloper.

Design-time mappings can only be created for protected attribute labels. Ensure that protected attribute labels have been created in the SOA instance to which you are connected.

1. Log in to Oracle BPM Worklist as an administrator.

2. Go to Administration > Protected Flexfields.

3. Check that protected attribute labels exist.

4. Create any protected attribute labels as required.

Internationalizing the name of an attribute label.

You can use the attribute label name as a resource key to look up a display name from the WorkflowLabels resource bundle.

Add a new resource key to the WorkflowLabels resource bundle. The key is the name you used for the label, prefixed by FLEX_LABEL. (note the trailing period).

Migrating attribute labels and mappings from one server to another.

Use the test-to-production utility.

The test-to-production utility enables you to export public attribute labels, public attribute mappings, and protected attribute labels as an XML file, and to import the labels and mappings from the XML file into another instance.

For more information, see Moving Human Workflow Data from a Test to a Production Environment.

B.5.7 Task Report Issues

Table B-7 describes symptoms, possible causes, and possible solutions for task report issues.

Table B-7 Troubleshooting Task Report Issues

Symptom

Possible Cause

Possible Solution

You receive the following error:

Null Pointer Exception when
running Task Productivity
Report

This is caused by an issue with the handling of dates when the worklist client locale and server default locale are different.

The workaround is to change the locale for the worklist client to be the same as the server, or to run a report without specifying dates.

B.5.8 Task History Issues

Table B-8 describes symptoms, possible causes, and possible solutions for task history issues.

Table B-8 Troubleshooting Task History Issues

Symptom

Possible Cause

Possible Solution

The Add Participant button is disabled.

A current or past participant is selected in the history table.

This is designed behavior. Adding adhoc participants is not allowed with the current or past participant. The current participant means the task is with that participant at that point in time.

All the added adhoc participants disappeared after a page refresh.

You may not have saved your modifications to the history table.

Ensure that you save your changes. Otherwise, all changes disappear. If you think you have saved your changes and the changes still disappear, file a bug.

Do not see future approvers in the history table.

The Future Approvers checkbox may not be selected.

Select the Future Approvers checkbox in Oracle BPM Worklist (configuration in the task sequence table).

You see the message in the history table about the correlation ID not being passed or any exception related to the correlation ID.

If the task is uninitiated, the correlation ID may not have been passed.

Ensure that you pass the correlation ID to the uninitiated task.

The edit toolbar is disabled or is not displayed.

The user may not have privileges to edit the participants.

1. In the Assignment tab of the Human Task Editor, click the Task will go from starting to final participant icon in the upper right corner.
The Configure Assignment dialog is displayed.

2. Select the Allow participants to edit new participants and Allow initiator to add participants checkboxes.

You receive the following error:

<Warning>
<oracle.adf.controller.intern
al.metadata.MetadataService>
<BEA-000000><ADFc:
/META-INF/adfc-config.xml: >
<Warning>
<oracle.adf.controller.intern
al.metadata.MetadataService><
ADFC-52024> <ADFc: Duplicate
managed bean definition for
'aleCompBindings' detected.>

Shared library oracle.soa.worklist.webapp is referenced in weblogic.xml and the JAR files adflibWorklistComponents.jar and adflibTasklistTaskflow.jar are packaged in the web application.

These JARs ideally should not be packaged inside the web application. They should only be referenced as a shared library. Do not package these JARs in the web application.

You receive the following error:

<Error> <Deployer>
<BEA-149265> <Failure
occurred in the execution of
deployment request with ID
'1297964056778' for task
'3'. Error is:
'weblogic.management.Deployme
ntException:
[J2EE:160149]Error while
processing library
references. Unresolved
application library
references, defined in
weblogic-application.xml:
[Extension-Name:
oracle.soa.workflow.wc,
exact-match: false].'
weblogic.management.Deploymen
tException:
[J2EE:160149]Error while
processing library
references. Unresolved
application library
references, defined in
weblogic-application.xml:
[Extension-Name:
oracle.soa.workflow.wc,
exact-match: false].

Shared library oracle.soa.workflow.wc is referenced in weblogic.xml, but not available on the server.

Ensure that this shared library is deployed on the server to which you are deploying your application. It may happen that the shared library is deployed, but not targeted, for that server.

You receive the following error:

java.lang.IllegalStateExcepti
on: Attempt to validate an
already invalid RegionSite:

This is a generic exception that sometimes is displayed in the server logs (for example, AdminServer.log).

See the real exception in the diagnostic logs (for example, AdminServer-diagnostic.log) and provide that exception with the bug you file.

You receive the following error:

[AdminServer] [NOTIFICATION]
[J2EE JSP-00008]
[oracle.j2ee.jsp] [tid:
[ACTIVE].ExecuteThread: '15'
for queue:
'weblogic.kernel.Default
(self-tuning)'] [userId:
weblogic] [ecid:
17011f2a001d6b0e:7e22d6ce:12e
3444eb1b:-8000-0000000000002f
0a,0] [APP: FederatedApp_
application1] unable to
dispatch JSP page: The
following exception
occurred:.[[
java.lang.RuntimeException:
Cannot find FacesContext
at
javax.faces.webapp.UIComponen
tClassicTagBase.getFacesConte
xt(UIComponentClassicTagBase.
java:2122)

This is a common mistake and is not related to any components you are using. You forget to put faces in the URL. For example:

http://server:port/FederatedApp
/test.jspx

Put faces in the URL as follows:

http://server:port/FederatedApp/fac
es/test.jspx

B.5.9 Task Form/Action Issues

Table B-9 describes symptoms, possible causes, and possible solutions for task form/ action issues.

Table B-9 Troubleshooting Task Form/ Action Issues

Symptom

Possible Cause

Possible Solution

The task form application does not have an empty JSPX page.

N/A

The task forms are now invoked using an ADF task flow and control is returned to the module that initiated the task form task flow when the task flow completes. Therefore, no empty JSPX is needed.

The task form does not load in Microsoft Internet Explorer.

Microsoft Internet Explorer has a URL length limit.

Your task form URL length is too long.

Deployment fails with a class not found exception.

The shared library entry is missing from weblogic.xml.

If you see the following error:

Caused By:
java.lang.ClassNotFoundException:
oracle.bpel.services.datacontrol.ty
pes.Number

during deployment of a task form, then it is likely due to the missing shared library in weblogic.xml. Add the following element in weblogic.xml:

<library-ref>
<library-name>oracle.soa.worklist.w
ebapp</library-name>
<specification-version>11.1.1</spec
ification-version>
</library-ref>

Deployment/access of task form fails when the hostname is used.

The DNS entry is missing.

If you are using a server with DHCP, the DNS entry may be missing for the host. Therefore, deployment/access using the IP address may succeed, but deployment/access using a hostname may fail. Update your client computer by manually adding the host/IP address:

- On Windows operating systems, this is typically is in %windir%\drivers\etc\lmhosts.

- On Linux/UNIX, this is typically in /etc/hosts.

Task form URL protocol (HTTP or HTTPS).

You are unable to access the task form through HTTPS or HTTP.

- DefaultToDoTaskForm: The worklist accesses the default to-do task form using the port/protocol returned by the getServerInfo API from the runtime config service. This API uses the frontend host setup for the cluster or managed server. It gives preference to the HTTPS protocol if it is enabled. It is dynamic and can be changed using Oracle Enterprise Manager Fusion Middleware Control for default to-do tasks as the other custom task form.

- CustomTaskForm: The custom task form gets the HTTP and HTTPS information from the setup. It uses the JRF API to get the information. This gets the frontend host information from the cluster and then the managed server if the cluster frontend host is not set up. In case the managed server frontend host is not set up, it uses a regular port. If the user enables the HTTPS port during deployment, the task form stores this information in the database. After this occurs, if the user disables the HTTPS port using Oracle WebLogic Server Administration Console, then the user must remove the HTTPS port for the task form using Oracle Enterprise Manager Fusion Middleware Control.

Note:

If you receive a java.lang.OutOfMemoryError: PermGen space error when deploying multiple task forms, you may need to increase PermGen memory. For more information, see PermGen Memory Requirements for Multiple ADF Task Form Deployments.

B.5.10 Task Comments/Attachment Issues

Table B-10 describes symptoms, possible causes, and possible solutions for task comments/attachment issues.

Table B-10 Troubleshooting Task Comments/Attachment Issues

Symptom

Possible Cause

Possible Solution

The file is not getting uploaded.

The file is too big

By default, ADF has a size limit of 2000 KB for each request. Add the following parameters in web.xml to adjust the file size and temporary storage for uploaded files:

<context-param>
<!-- Maximum memory per request
(in bytes) -->
<param-name>oracle.adf.view.faces.U
PLOAD_MAX_MEMORY</param-name>
<!-- Use 500K -->
<param-value>512000</param-value>
</context-param>
<context-param>
<!-- Maximum disk space per
request (in bytes) -->
<param-name>oracle.adf.view.faces.U
PLOAD_MAX_DISK_SPACE</param-name>
<!-- Use 5,000K -->
<param-value>5120000</param-value>
</context-param>
<context-param>
<!-- directory to store temporary
files -->
<param-name>oracle.adf.view.faces.U
PLOAD_TEMP_DIR</param-name>
<!-- Use an ADFUploads
subdirectory of /tmp -->
<param-value>/tmp/ADFUploads/</para
m-value>
</context-param>

The file uploaded in the task details application is not visible in the same task flow.

After uploading a file, the attachment link generated in the task form is invalid. Clicking this link returns an empty stream.

When you upload a file, you see the attachment link in the table. However, this link does not work. You must reload the task details to view the file.

Adding file attachments creates a new task version, but adding a URL attachment does not create a new version.

Inconsistent behavior of the URL attachment and file attachment.

When a file is uploaded, the task is saved because the file is uploaded to persistency storage. This creates a new task version. The URL attachments only update the local task object in the user interface application. Therefore, no task version is created.

B.5.11 Design Time at Runtime Issues

Table B-11 describes symptoms, possible causes, and possible solutions for design time at runtime issues. Two design time at runtime tools are available for use:

- Oracle SOA Composer

- Task Configuration tab of Oracle BPM Worklist

Table B-11 Troubleshooting Design Time at Runtime UI Issues

Symptom

Possible Cause

Possible Solution

Modifications made to a task in a design time at runtime tool do not appear for the task.

The task was instantiated before you actually edited it using a design time at runtime tool.

Design time at runtime updates go into effect only for instances created after the changes, and not for those that were created before the change.

Therefore, if you edit a task using a design time at runtime tool, and then instantiate a new task, the new instance of the task has the changes you made.

Modifications made to a task in a design time at runtime tool do not appear for the task.

The changes made were probably not committed to the MDS repository.

The Save button just saves the changes made in a design time at runtime tool to the sandbox. To see these changes in action, click Commit to send them to the MDS repository.

B.5.12 Human Workflow API (Including SOAP/EJB) Usage Issues

Table B-12 describes symptoms, possible causes, and possible solutions for human workflow API (including SOAP/EJB) usage issues.

Table B-12 Troubleshooting Human Workflow API Usage Issues

Symptom

Possible Cause

Possible Solution

Location of the JavaDoc for human workflow APIs.

N/A

See Workflow Services Java API Reference for Oracle SOA Suite, which is available in the documentation library.

Understanding the API usage.

N/A

1. Refer to the API documentation.

Using .net to access the APIs.

N/A

It is possible to write a .net client that accesses the SOAP web service APIs.

You receive Class not found errors when attempting to use the Java API clients.

Not all required JAR files are in the client class path.

-

Creating a routing slip for simple patterns to use with a simple approval task or to dynamically route a task during task initiation.

N/A

See oracle.bpel.services.workflow.task.impl.SimpleApprovalTaskUtil.

Newly created task does not appear in Task UI

createTask activity requires SimpleWorkflowApp. This did not get deployed during SOA server setup.

Deploy Simple Approval composite before you create a task using Create Task global activity.

B.5.13 Oracle JDeveloper Data Control / Form Generation Issues

Table B-13 describes symptoms, possible causes, and possible solutions for Oracle JDeveloper data control/form generation issues.

Table B-13 Troubleshooting Oracle JDeveloper Data Control / Form Generation Issues

Symptom

Possible Cause

Possible Solution

Empty1.jspx is not generated when creating the task form.

Created an initiator task based on an XSD element and tried to autogenerate the task form.

This file is not required except for the BPM initiator task. If you encounter it, create an Empty1.jspx file in the same directory as referenced by adfc-config.xml and put the following content in it:

<?xml version='1.0'
encoding='UTF-8'?><jsp:root
xmlns:jsp="http://java.sun.com/JSP/
Page" version="2.1"xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:af="http://xmlns.oracle.com/a
df/faces/rich">  <jsp:directive.page
contentType="text/html;charset=UTF-8"/>
<f:view>
<af:document id="d1">
<af:form id="f1"></af:form>
</af:document>
</f:view>
</jsp:root>

B.5.14 Human Workflow Service/ System MBean Browser Issues

Table B-14 describes symptoms, possible causes, and possible solutions for human workflow service/System MBean Browser issues.

Table B-14 Troubleshooting Human Workflow Service/ System MBean Browser Issues

Symptom

Possible Cause

Possible Solution

Setting commonly used human workflow configuration parameters.

N/A

Use the Workflow Task Service and Workflow Notification pages of Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigator, right-click soa-infra.

2. Select SOA Administration > Workflow Config > Mailer tab to access notification properties.

3. Select SOA Administration > Workflow Config > Task tab to access task service properties.

For more information, see Configuring Human Workflow Notification Properties and Configuring Human Workflow Task Service Properties.

Setting human workflow configuration parameters not available in the Oracle Enterprise Manager Fusion Middleware Control properties pages.

N/A

Use the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigator, right-click soa-infra.

2. Select SOA Infrastructure >Administration > System MBean Browser.

3. Select Application Defined MBeans > oracle.as.soainfra.config > server > WorkflowConfig > human-workflow.

4. Set simple parameters by editing the appropriate field in the Attributes tab, and clicking Apply.

5. Make more complex parameter changes (for example, adding a new locale) by switching to the Operations tab, selecting the appropriate operation, entering required fields, and clicking Invoke.

The System MBean Browser does not reflect my changes after editing the human workflow configuration MBeans.

The System MBean Browser is showing a previously cached version of beans.

Click the refresh cached tree data button in the System MBean Browser.

Human workflow services are not locating resource bundles or classes located at the workflow customizations class path URL.

The protocol is not specified in the URL, or the URL is missing a trailing forward slash (/).

Ensure that the configured URL is formatted correctly, and specifies a protocol. If the class path points to a directory (rather than a JAR file), it is important that the URL has a trailing forward slash character. For example:

file:///home/wstallar/wfcustomizati
ons/

Manually setting the URL used for displaying task details for a particular task component.

N/A

Use the Administration page in Oracle Enterprise Manager Fusion Middleware Control for the human task service component.

See Managing the URI of the Human Workflow Service Component Task Details Application for instructions.

You can edit or delete existing task display URL entries, and add new entries. For task display URLs used from Oracle BPM Worklist, the application name must be set to worklist.

B.5.15 AMX Extension Issues

Table B-15 describes symptoms, possible causes, and possible solutions for AMX extension issues.

Table B-15 Troubleshooting AMX Extension Issues

Symptom

Possible Cause

Possible Solution

The dynamic approval group class is not found.

The class file is not accessible in the Oracle SOA Suite class path.

To make the dynamic approval group class accessible, the class file must be placed in the following directory:

$FMW_HOME/SOA_HOME/soa/modules/ora
cle.soa.ext_11.1.1/classes

This directory is part of the SOA class path.

The Oracle WebLogic Server must be restarted.

During design time at runtime, while defining a rule based on the Approval Group list builder, a message keeps appearing indicating that the group does not exist.

The Approval Group name is not enclosed in quotes (" ").

Enclose the name in quotes (for example, "Sample Approval Group Name").

In a ruleset, many rules defined are applicable for a transaction. It appears that the correct constraints are not getting applied; therefore, the generated approver list is not correct.

Only one rule from a ruleset must be applicable for a transaction.

In case many rules are true, the actions associated with the applicable rule with the highest priority are executed.

In case multiple applicable rules have the same priority, the first rule in the list is picked and its actions are executed.

Check that all rules in the ruleset have priorities defined so that multiple rules with the same priority are not applicable for the same transaction.

B.5.16 Oracle BPM Worklist/Task Region Issues

Table B-16 describes symptoms, possible causes, and possible solutions for Oracle BPM Worklist/task region issues.

Table B-16 Troubleshooting Oracle BPM Worklist/Task Region Issues

Symptom

Possible Cause

Possible Solution

You receive the following exception message in the logs:

<Warning>
<oracle.adf.controller.internal.
metadata.MetadataService>
<BEA-000000><ADFc:
/META-INF/adfc-config.xml: >
<Warning>
<oracle.adf.controller.internal.
metadata.MetadataService><ADFC-5
2024> <ADFc: Duplicate managed
bean definition for
'aleCompBindings' detected.>

The shared library oracle.soa.worklist.webapp is referenced in the weblogic.xml file and also the JAR files adflibWorklistComponents.jar and adflibTasklistTaskflow.jar are packaged in the web application.

These JARs should not be packaged inside the web application. They should only be referenced as a shared library. Do not package these JARs in the web application.

You receive the following exception message in the logs:

Duplicate default server in
client configuration.
Configuration needs to have only
one default server in client
configuration.
Specify one default server in
client configuration.

Two default servers are specified in the client configuration file or in the JAXB object passed to the task flow.

Mark only one server as the default in the client configuration file or in the JAXB object passed.

You receive the following exception message in the logs:

The default server is not
specified

The default server is not specified in the client configuration file or in the JAXB object passed to the task flow.

Ensure that the default server is marked in the client configuration file or the JAXB object.

You receive the following exception message in the logs:

Invalid display column.
The display column COLUMN NAME
is not a valid Task column.
Specify a valid column name.

The column name passed to the task flow parameter displayColumnsList is not correct.

Ensure that you pass the correct column name to the task flow parameter.

You receive the following exception message in the logs:

java.lang.IllegalStateException:
Attempt to validate an already
invalid RegionSite:

This is a generic exception that sometimes appears in server logs (for example, AdminServer.log).

See the real exception in the diagnostic logs (for example, AdminServer-diagnostic.log) and provide that exception with the bug you can file.

You receive the following exception message in the logs:

Caused by:
oracle.adf.controller.Controller
Exception: ADFC-02001: The ADF
Controller cannot find
'/WEB-INF/taskList-task-flow-def
inition.xml'

The Oracle BPM Worklist JARs are not provided in the class path, either by referring to the shared library oracle.soa.worklist.webapp or by packaging those in the web application.

Ensure either the JARs are referred through the shared library or packaged inside the application.

Filters for the task list are removed when the task list is refreshed.

Because an inbox is not a persisted view, filters set on it are removed when rendering the page again or refreshing the task list.

Instead of setting filters on the task list, create a user view with the required set of filters and pass the viewId of that view as the value of parameter ViewFilter. This makes that view the default view of the task list.

You have set the taskTypesFilterList parameter, but instead of seeing assigned tasks, you are seeing all tasks.

If you specified the taskTypesFilterList parameter, then you forgot to specify the attributesFilterList parameter.

You have to use both parameters with the AND operator. For example:

<parameter
id="taskTypesFilterList"
value="http://xmlns.oracle.com/H
elpDeskRequestSOAApp/HelpDeskReq
uestComposite/HelpDeskRequestHum
anTask,[
http://xmlns.oracle.com/Vacation
RequestApp/VacationRequest/Vacat
ionRequestTask]"/>

<parameter id=
"attributesFilterOperator"
value="and"/>
<parameter id= "attributesFilterList"
value="state=ASSIGNED"/>

You receive the following exception message in the logs:

[AdminServer] [NOTIFICATION]
[J2EE JSP-00008]
[oracle.j2ee.jsp] [tid:
[ACTIVE].ExecuteThread: '15'
for queue:
'weblogic.kernel.Default
(self-tuning)'] [userId:
weblogic] [ecid:
17011f2a001d6b0e:7e22d6ce:12e344
4eb1b:-8000-0000000000002f0a,0]
[APP: FederatedApp_
application1] unable to dispatch
JSP page: The following
exception occurred:.[[
java.lang.RuntimeException:
Cannot find FacesContext
at
javax.faces.webapp.UIComponentCl
assicTagBase.getFacesContext(UIC
omponentClassicTagBase.java:2122)

This is a common mistake that is generic in nature and is not related to any components you are using. You forgot to put faces in the URL. For example:

http://server:port/FederatedApp/test.jspx

Put faces in the URL as follows:

http://server:port/FederatedApp/
faces/test.jspx

You receive the following exception message in the logs:

[AdminServer] [TRACE] [] []
[tid: [ACTIVE].ExecuteThread:
'5' for queue:
'weblogic.kernel.Default
(self-tuning)'] [userId:
weblogic] [ecid:
17011f2a001d6b0e:7e22d6ce:12e344
4eb1b:-8000-0000000000001d39,0]
[SRC_CLASS:
oracle.bpel.services.workflow.cl
ient.config.ClientConfigurationU
til] [APP: FederatedApp_
application1] [SRC_METHOD:
getClientConfiguration]
WorkflowServiceClientContext:
Cannot find client
configuration file: wf_client_
config.xml

There are three possible causes for this issue:

1. The client configuration file is not provided in the class path.

2. The JAXB object is not passed to the task flow.

3. If one of the above is provided, the port number for the remote/SOAP client is incorrect.

Ensure either the client configuration file wf_client_config.xml is provided in the class path or the JAXB object is passed to the task flow. If it is already done, ensure that the port number refers to the SOA server.

You receive the following exception message in the logs:

<Error> <Deployer> <BEA-149265>
<Failure occurred in the
execution of deployment request
with ID '1297964056778' for
task '3'. Error is:
'weblogic.management.DeploymentE
xception: [J2EE:160149]Error
while processing library
references. Unresolved
application library references,
defined in
weblogic-application.xml:
[Extension-Name:
oracle.soa.workflow.wc,
exact-match: false].'
weblogic.management.DeploymentEx
ception: [J2EE:160149]Error
while processing library
references. Unresolved
application library references,
defined in
weblogic-application.xml:
[Extension-Name:
oracle.soa.workflow.wc,
exact-match: false].

Shared library oracle.soa.workflow.wc is referenced in weblogic.xml, but is not available on the server.

Ensure that this shared library is deployed on the server on which you are deploying your application. The shared library may be deployed, but not targeted, for that server.

You cannot see the mapped attributes mapped columns.

Note: Starting with Release 11g R1 (11.1.1.4), Oracle BPM Worklist flex fields are now known as mapped attributes.

The right set of parameters is not being passed to the task list task flow.

The correct set of parameters to be passed is as follows:

<parameter id= "displayColumnsList"
value="assignees,creator,
assignedDate,state,
textAttribute1,textAttribute2"/>

textAttribute1,textAttribute2 is the correct way to provide a value for the column name. Providing 'label name'(Name of the mapping) associated with these values does not work.

You must specifically pass the fully qualified value to parameter taskTypesFilterList. Otherwise, the column creation does not work.

For example:

<parameter
id="taskTypesFilterList"
value="http://xmlns.oracle.com/Hel
pDeskRequestSOAApp/HelpDeskRequest
Composite/HelpDeskRequestHumanTask
"/>

B.5.17 Test-to-Production Issues

Table B-17 through Table B-20 describe symptoms, possible causes, and possible solutions for test-to-production issues.

Table B-17 Troubleshooting Test-to-Production Issues

Symptom

Possible Cause

Possible Solution

Finding the default realm name for a SOA server.

N/A

The defaultRealmName can be obtained from the identity configuration service. You can get this from the SOAP service test page.

1. From a browser, go to the following URL:

http:host:port/integration/servic
es/IdentityService/configuration

2. Select getDefaultRealmName from the Operation drop-down menu.

3. Click the Invoke button.

This retrieves the default realm name. Here is a sample answer from an invocation:

<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap
/envelope/">
<env:Header/>
<env:Body>
<realmName
xmlns="http://xmlns.oracle.com/bpel/servi
ces/IdentityService">jazn.com</realmName>
</env:Body>
</env:Envelope>

Table B-18 Troubleshooting Test-to-Production Issues

Symptom

Possible Cause

Possible Solution

The following user authentication error (in this example, the user is FMW_USERID and the identity context is jazn.com) is displayed:

[java] Error in workflow service Web
service operation invocation. The
error is ORA-30501:Error in
authenticating user.
[java] Error in authenticating and
creating a workflow context for
user jazn.com/FMW_USERID. [java]
Verify that the user credentials
and identity service configurations
are correct.

This occurs if the given user is not seeded and available in the LDAP provider.

To identify if the user is seeded properly, try to log in to Oracle BPM Worklist from a browser as this user. If the user can log in to Oracle BPM Worklist, that means the user is seeded.

If Oracle Internet Directory or another LDAP provider is used, ensure the configuration of the LDAP provider is completed correctly. Otherwise, you cannot get past this error.

While importing task payload mapped attribute mappings (previously known as flex fields) into the target SOA server, you may encounter the following error in the console logs:

[java] Caused by:
java.sql.SQLIntegrityConstrain
tViolationException: ORA-02291:
integrity constraint (UAT_
SOAINFRA.SYS_C0018364) violated -
parent key not found* *

The importing of task payload mapped attribute mappings into the target SOA server is a two-step process.

Even before the import of task payload mapped attribute mappings into the target SOA server operation is attempted, there is a prerequisite step that must be performed. This is the import of attribute labels into the target SOA server operation.

To be successful, perform the following operations (in the correct order) with the human workflow test-to-production migration tool:

1. Import attribute labels into the target SOA server.

2. Import payload mappings into the target SOA server.

See Moving Human Workflow Data from a Test to a Production Environment for more details.

Table B-19 Troubleshooting Test-to-Production Issues

Symptom

Possible Cause

Possible Solution

Assume you encounter the following error during rule migration:

[java]  Error encountered during
migration. [java] Exception in thread
"main"[java]
UserConfigDataMigrationException:[java]
faultString:Invalid parameters for RULE.
[java] Invalid user and group: both
parameters can not have null
values.[java] To migrate User Rules,
provide the 'user' parameter only.
[java]  To migrate Group Rules, provide
the 'group' parameter only.[java]
oracle.bpel.services.workflow.util.
tools.wfUserConfigDataMigrator.
UserConfigDataMigrationE xception [java]
at oracle.bpel.services.workflow.
util.tools.wfUserConfigDataMigrator.
implhwfMigrator.parseParametersNode

There are two properties in the migration.properties file that are of interest for this error.

- user

- group

During any rule migration (whether export or import) operation, at most one of them (user or group) should have a value. That is, both user and group cannot have null or empty values.

Set values for at most one of them. To perform user rule migration, set the user parameter alone. To perform group rule migration, set the group parameter alone.

Assume you encounter the following error during rule migration:

[java]  Error encountered during
migration.[java] Exception in
thread "main"[java]
UserConfigDataMigrationExcepti
on: [java]  faultString:
Invalid parameters for RULE.
[java]  Invalid user and group: both
parameters can not have values.
[java]  To migrate User Rules,
provide the 'user'parameter only.
[java]  To migrate Group Rules,
provide the 'group' parameter only.
[java]  oracle.bpel.services. workflow.util.tools.wfUserConfigData
Migrator.UserConfigDataMigrationE
xception

This is similar to the previous explanation in this table.

During any rule migration (whether export or import) operation, both user and group parameters cannot have a value.

Provide values for at most one of them.

Table B-20 Troubleshooting Test-to-Production Issues

Symptom

Possible Cause

Possible Solution

Testing the health of the installed server.

N/A

Before performing a test-to-production migration, it is useful to test the health of the server.

From a browser, you can test some SOAP services. The following list provides a subset of human workflow services and Oracle BPM Worklist:

http://host:port/integration/worklistapp/

http://host:port/integration/services
/TaskQueryService/TaskQueryService

http://host:port/integration/services/IdentityService/configuration

http://host:port/integration/services/IdentityService/identity

http://host:port/integration/services/RuntimeConfigService/RuntimeConfigService

You can randomly test some operations in these services, and verify that the operation yields results. Similarly, you can log in as a user to Oracle BPM Worklist and see if everything is fine.

For more information about test-to-production issues, see Moving Human Workflow Data from a Test to a Production Environment.

B.5.18 Identity Service Issues

Table B-21 and Table B-22 describe symptoms, possible causes, and possible solutions for identity service issues.

Table B-21 Troubleshooting Identity Service Issues

Symptoms

Possible Cause

Possible Solution

In a clustered environment, you can receive the following error when you attempt to act on an approval task in Oracle BPM Worklist:

Token Decryption Failed

You are using a file-based repository, instead of an LDAP-based repository. This causes the application roles to not be synchronized across the nodes.

For repository configuration information in a clustered environment, you must follow the instructions in the Enterprise Deployment Guide for Oracle SOA Suite.

Only a subset of users in LDAP can log in to Oracle BPM Worklist.

The user base DN is not configured properly.

Mention the user base under which all the groups are seeded. This can be performed in two ways:

Add the base DN under which all the required groups are seeded. For instance, if users are seeded under:

UserDN 1 : cn=users1,dc=us,dc=oracle,dc=com
UserDN 2 : cn=users2,dc=us,dc=oracle,dc=com
UserDN 3 : cn=users3,dc=us,dc=oracle,dc=com

Then mention the group base DN as follows:

dc=us,dc=oracle,dc=com

This is the common DN. If only some user DNs are required (for example, UserDN1 and UserDN2), then the following property must be added to serviceInstance with the name idstore.ldap in the $DOMAIN_HOME/config/fmwconfig/jps-config.xml file:

<serviceInstance name="idstore.ldap"
provider="idstore.ldap.provider">
<property name="idstore.config.provider"
value="oracle.security.jps.wls.internal.idstore.WlsLd
apIdStoreConfigProvider"/>
<property name="CONNECTION_POOL_CLASS"
value="oracle.security.idm.providers.stdldap.JNDIPool"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users1,dc=us,dc=oracle,dc=com</value>
<value>cn=users2,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>

Users and groups seeded only in the first authenticator are visible, but not from the other authenticators.

By default, users and groups from the first authenticator are authorized.

Starting with Release 11.1.1.4, you can authorize users and groups from multiple authenticators. For more information, see Configuring Multiple Authentication Providers.

Table B-22 Troubleshooting Identity Service Issues

Symptom

Possible Cause

Possible Solution

The following exception appears when myrealm (the default realm in the Oracle WebLogic Server Administration Console configuration) is passed as a parameter to the identity context to the Identity Service APIs.

Exception seen :
Service"
Unknown macro: {0}
"in configuration"
Unknown macro: {1}
" could not be
initialized. Error
in initializing
service
"Authentication"
in configuration
"myrealm".

The human workflow identity service uses the identity context that is set in the WorkflowIdentityConfig file (by default, it is jazn.com) and not from the Oracle WebLogic Server configuration. Therefore, in the customer code, if jazn.com is passed as the identity context, the authenticate API should work fine.

To change the realm name, the WorkflowIdentityConfig file can be edited in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control.

1. In the navigator, right-click soa-infra.

2. Select SOA Infrastructure > Administration > System Mbean Browser.

3. Select Application Defined Mbeans > oracle.as.soainfra.config > Server > WorkflowIdentityConfig > human-workflow > WorkflowIdentityConfig.ConfigurationType.

4. Select the configuration and rename it by invoking the operation setRealmName. This change requires a server restart.

After configuring LDAP with Oracle WebLogic Server, the users are visible in the Oracle WebLogic Server Administration Console, but the following error is thrown:

No Role found
matching the
criteria

The group's base DN is not configured properly. Either the group that is being looked up is not present in LDAP or it may be seeded outside the group base DN that is mentioned while configuring LDAP.

Mention the group base under which all the groups are seeded. This can be performed in two ways.

Add the base DN under which all the required groups are seeded. For instance, if groups are seeded under:

GroupDN 1 : cn=groups1,dc=us,dc=oracle,dc=com
GroupDN 2 : cn=groups2,dc=us,dc=oracle,dc=com
GroupDN 3 : cn=groups3,dc=us,dc=oracle,dc=com

Then mention the group base DN as follows:

dc=us,dc=oracle,dc=com

This is the common DN. If only some group DNs are required (for example, GroupDN1 and GroupDN2), then the following property must be added to serviceInstance with the name idstore.ldap in the $DOMAIN_HOME/config/fmwconfig/jps-config.xml file.

<serviceInstance name="idstore.ldap"
provider="idstore.ldap.provider">
<property name="idstore.config.provider"
value="oracle.security.jps.wls.internal.idstore.WlsL
dapIdStoreConfigProvider"/>
<property name="CONNECTION_POOL_CLASS"
value="oracle.security.idm.providers.stdldap.JNDIPool"/>
extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups1,dc=us,dc=oracle,dc=com</value>
<value>cn=groups2,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>

B.6 Business Events and Event Delivery Network Troubleshooting

This section describes how to troubleshoot business event and event delivery network (EDN) issues.

B.6.1 Increasing the JMS Adapter Connection Pool Size

EDN uses the connection factories shown in Table B-23 for the JMS adapter to communicate with the underlying JMS topic for event publishing and subscription.

Table B-23 Connection Factories for the JMS Adapter

JMS Type

JMS Connection Factories for the JMS Type

Oracle WebLogic Server JMS

- eis/wls/EDNxaDurableTopic

- eis/wls/EDNxaTopic

- eis/wls/EDNLocalTxDurableTopic

- eis/wls/EDNLocalTxTopic

AQ JMS

- eis/aqjms/EDNxaDurableTopic

- eis/aqjms/EDNxaTopic

- eis/aqjms/EDNLocalTxDurableTopic

- eis/aqjms/EDNLocalTxTopic

In environments in which there are a large number of concurrent event publishers, a large number of event subscribers, or both, the default connection pool size (200) for the JMS Adapter can be exceeded. This can cause ResourceLimitException errors similar to that shown below:

The JCA Binding Component was unable to establish an outbound JCA CCI connection
due to the following issue:
javax.resource.spi.ApplicationServerInternalException:
Unable to get a connection for pool = "eis/wls/EDNxaDurableTopic",
weblogic.common.resourcepool.ResourceLimitException:
Configured maximum limit of (0) on number of threads allowed to wait for a
resource reached for pool eis/wls/EDNxaDurableTopic
Please make sure that the JCA connection factory and any dependent connection
factories have been configured with a sufficient limit for max connections.
Please also make sure that the physical connection to the backend EIS is available
and the backend itself is accepting connections.

When this occurs, you must increase the connection pool Max Capacity value of the corresponding JMS connection factory for the JMS adapter in Oracle WebLogic Server Administration Console. Table B-24 identifies the use of each JMS connection factory for the JMS adapter.

Table B-24 Uses of Each JMS Connection Factory for the JMS Adapter

JMS Connection Factory

Used for Outbound Event Publishing?

Used for Inbound Event Subscription?

eis/wls/EDNxaDurableTopic

Yes, for event publishing with a global transaction.

Yes, for durable subscriptions with One And Only One (OAOO) consistency.

eis/wls/EDNxaTopic

No.

Yes, for nondurable subscriptions with OAOO consistency.

eis/wls/EDNLocalTxDurableTopic

Yes, for event publishing with a local transaction.

Yes, for durable subscriptions with guaranteed consistency.

eis/wls/EDNLocalTxTopic

No.

Yes, for nondurable subscriptions with guaranteed consistency.

eis/aqjms/EDNxaDurableTopic

Yes, for event publishing with global transaction.

Yes, for durable subscriptions with OAOO consistency.

eis/aqjms/EDNxaTopic

No.

Yes, for nondurable subscriptions with OAOO consistency.

eis/aqjms/EDNLocalTxDurableTopic

Yes, for event publishing with local transaction.

Yes, for durable subscriptions with guaranteed consistency.

eis/aqjms/EDNLocalTxTopic

No.

Yes, for nondurable subscriptions with guaranteed consistency.

When calculating connections used, you must combine the number of events publishing with the event subscriptions if the corresponding JMS connection factory is used for both event publishing and event subscription.

For example, if there are 200 concurrent BPEL process event publishers that publish events in a global transaction, and the default SOAInternalProcessing_maxThreads is set to 150, then these publishers use all 150 threads, which takes 150 connections from eis/wls/EDNxaDurableTopic. There are also a total of 12 SOA event subscribers with ThreadsPerSubscriber set to 5. These subscribers use 12 x 5 = 60 threads, which takes 60 connections from eis/wls/EDNxaDurableTopic.

Because 150 + 60 = 210 > 200 (the default setting), you receive a ResourceLimitException error.

In this case, you may need to increase the size of the Max Capacity field of the connection pool of eis/wls/EDNxaDurableTopic to a larger value (for example, 300).

To increase the connection pool size:

1. Log in to Oracle WebLogic Server Administration Console.

2. In the Domain Structure window, click Environment > Deployments > JmsAdapter > Configuration > Outbound Connection Pools.

3. In the Outbound Connection Pool Configuration Table, expand oracle.tip.adapter.jms.IJmsConnectionFactory.

4. Click the appropriate connection factory, as described in Table B-24.

5. Click Connection Pool.

6. In the Max Capacity field, increase the value (for example, to 300), and click Save.

B.6.2 Tuning Recommendations For Publishing Many BPEL Process Events with Oracle WebLogic Server JMS

When publishing many BPEL process events (for example, one million) with Oracle WebLogic Server JMS, you can receive numerous recoverable errors (for example, 20% of the one million events) if the EDN is not properly tuned. For example, assume you have the following use case scenario:

- 200 threads

- 5000 iterations

After running for some time (for example, 40 minutes), you can receive the error shown below:

<Jan 8, 2014 10:08:33 AM PST> <Error> <oracle.soa.adapter.jms.outbound>
<BEA-000000> <JMSMessageProducer_produce: [default destination =
jms/fabric/EDNTopic]:weblogic.messaging.kernel.QuotaException: Quota blocking
time exceeded and no quota available>
<Jan 8, 2014 10:08:33 AM PST> <Error> <oracle.soa.adapter.jms.outbound>
<BEA-000000> <JMSMessageProducer_produce: [default destination =
jms/fabric/EDNTopic]:weblogic.messaging.kernel.QuotaException: Quota blocking
time exceeded and no quota available>

In addition, subscriptions are slow (there are many database, Coherence cache, and transaction-related operations for the EDN threads) and the accumulated messages slow down publishing.

If this occurs, tune the following areas:

- The EDN quota is automatically defined on the default EDN topic on Oracle WebLogic Server JMS. This EDN quota has a maximum message limit of 50,000. You may need to define a quota with a different maximum message limit based on your use case scenario. For more information, see Section "Tuning WebLogic JMS" of Tuning Performance of Oracle WebLogic Server.

- Tune the send timeout value on the EDN connection factories based on your use case scenario. The following EDN JMS connection factories have a default value of 10,000 (ms) as the send timeout value:

- EDNConnectionFactory

- xaEDNConnectionFactory

For more information, see Section "Blocking Senders During Quota Conditions" of Tuning Performance of Oracle WebLogic Server.

- When there are heavy loads, messages accumulate in the JMS topic. The EDN client receives a QuoteException when the number of messages exceeds the quota limit. If the EDN client is a composite with a BPEL process service component, the BPEL process persists the messages into the Error Hospital. There may be a big delay in delivery to the subscribers. The messages in the Error Hospital can be recovered manually from the Error Hospital or automatically from the Recovery tab of the BPEL process service engine. For more information, see Recovering From Faults in the Error Hospital and Performing BPEL Process Service Engine Message Recovery.

B.6.3 Tuning EDN Event Bus and Delivery

You can customize the following EDN properties in the System MBean Browser:

1. Right-click soa-infra.

2. Select SOA Infrastructure > Administration > System MBean Browser.

3. Enter EDNConfig in the Search field and click the Search icon or expand Application Defined MBeans > oracle.as.soainfra.config > Server: soa_server > EDNConfig > edn.

4. Double-click an attribute.

Properties

Type

Details

JmsType

WLJMS

The default JMS type for a topic. By default, EDN events published in a given SOA domain are (temporarily) stored in a default JMS topic for consumption by event subscribers. Valid values are:

- WLJMS (Oracle WebLogic Server JMS)

- AQJMS (Oracle Advanced Queuing JMS)

Note:Manually tune the following to avoid ResourceLimitExceptions and performance issue:

- Max Capacity for JMSAdapter Connection Pool from 200 to 300

- SOAIncoming_maxThreads from 60 to 300

- SOA_EDN_WM's min-thread-constraint from current 1 to 100

NumberOfRetrys

integer value

The number of delivery retries that EDN automatically attempts in case of a retriable exception during event delivery. This applies to subscribers of either the guaranteed or one and only one consistency level. Once the retry reaches the NumberOfRetrys value, the event is moved to the Error Hospital and subject to manual recovery.

If the EDN delivers an event and fails with a nonretriable exception, there is no retry, and the event is moved to the Error Hospital immediately.

If GlobalTxMaxRetry = 0, the retry is disabled.

Paused

boolean value

Temporarily stops delivering events.

Values are true or false. If true, the JMS consumer threads for each Oracle SOA Suite subscriber are removed. As a result, published events are lost for nondurable subscribers and retained in a JMS server for durable subscribers.

QueueWaitTime

30,000

The amount of time in milliseconds to wait between retries. This value must be at least 1000. The default value is 30,000 (30 seconds).

ThreadsPerSubscriber

1

The number of inbound poller threads that each SOA subscriber should use for processing events.When an event-subscribing composite is deployed, EDN initializes inbound JMS consumer threads whose number is based on this value. You can customize the thread number by configuring the local thread number as described in Updating the Local Inbound Poller Thread Number Value at the Service Component Level. Once locally customized, the thread number is not subject to changes in this global ThreadsPerSubscriber value.

Note:

- Although the EventTypeToJmsConfigMappings attribute is listed in the EDNConfig > edn section of the System MBean Browser, do not modify it. Instead, modify JMS mappings as described in Mapping Business Events to JMS Topic Destinations on the Business Events Page.

- The NumberOfThreads attribute is used in Release 12c to control event backlog upgrades.

5. Enter a value, and click Apply.

B.6.4 Events Are Consumed by Multiple Revisions of the Same Composites

By design, different composites can subscribe to the same event. However, it is an error if multiple revisions of the same composite subscribe to the same event. This occurs when you have multiple active versions of the composite that may be a result of a patch failure.

Perform the following steps to determine whether there are multiple, active revisions of the same composite and to retire the composite revision that should not be active:

1. Go to Oracle Enterprise Manager Fusion Middleware Control.

2. Click SOA > soa-infra.

In the Deployed Composites section of the Dashboard tab, you see a list of deployed composite names, revisions, and modes (for example, active).

3. Identify composites with the same name and with an active mode, but with different revisions.

4. Click the composite revision that should not be active.

5. Click the Retire button.

B.6.5 Business Event Is Picked Up Twice (Or More) By SOA Server

Business events may be raised from J2EE applications and picked up more than once. Expected behavior is that they must be picked up only once.

If a patch fails, it may be possible for two versions of a given composite to be active (that is, the older version has not been retired). When multiple versions of a composite are active, they all become subscribers and the event is picked up more than once. This should not happen under normal scenarios. Reapply the patch and ensure that the deployed composite only has one active version.

B.6.6 Some Messages Are Lost Between EDN and Composites or Composites Across Clusters

Messages primarily may get lost for the following reasons:

1. The EDN message was not delivered.

2. The target asynchronous service did not respond.

3. The message was roll backed (though it was not lost; you still see it in Oracle Enterprise Manager Fusion Middleware Control).

This issue typically requires you to identify where the messages are supposed to be and to diagnose the path.

- Check if the Oracle Web Services Manager Policy Manager security configurations allow the client to invoke the SOA composite.

- Verify that the transaction is not transient (nonpersistent).
Oracle BPEL Process Manager uses the dehydration store database to maintain long-running, asynchronous processes and their current state information in a database while they wait for asynchronous callbacks. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.

- Transient processes: This process type does not incur any intermediate dehydration points during process execution. If there are unhandled faults or there is system downtime during process execution, the instances of a transient process do not leave a trace in the system. Instances of transient processes cannot be saved in-flight (whether they complete normally or abnormally). Transient processes are typically short-lived, request-response style processes. The synchronous process you design in Oracle JDeveloper is an example of a transient process.

- Durable processes: This process type incurs one or more dehydration points in the database during execution because of the following activities:

- Receive activity

- OnMessage branch of a pick activity

- OnAlarm branch of a pick activity

- Wait activity

Instances of durable processes can be saved in-flight (whether they complete normally or abnormally). These processes are typically long-living and initiated through a one-way invocation. Because of out-of-memory and system downtime issues, durable processes cannot be memory-optimized.

- If a business flow instance is not visible in Oracle Enterprise Manager Fusion Middleware Control and the SOA Infrastructure is running, check that the Audit Level is not set to Off on the SOA Infrastructure Common Properties page. This can be checked in Oracle Enterprise Manager Fusion Middleware Control:

1. Right-click soa-infra (SOA_cluster_name).

2. Select SOA Administration > Common Properties.

- If the business flow instance is available, check the oneWayDeliveryPolicy BPEL property value. You can check the value in Oracle Enterprise Manager Fusion Middleware Control:

1. In the navigation pane, expand soa-infra (SOA_cluster_name).

2. Expand the partition, and select the composite.
The Dashboard page for the composite is displayed.

3. In the upper right corner, click the Show XML Definition icon.
The contents of composite.xml for that composite are displayed.

If this is set to async.cache, you may lose messages. Set it to async.persist for reliable messages. This is typically specified in the BPEL process service component section of the composite.xml file. Therefore, this can be set for custom composites. If the value is not set in composite.xml, the value for oneWayDeliveryPolicy in the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control is used. The following values are possible:

- async.persist: Messages are persisted in the database hash map.

- async.cache: Messages are stored in memory.

- sync: Direct invocation occurs on the same thread.

For more information about these settings, see the "Deployment Descriptor Properties" appendix and the "Transaction and Fault Propagation Semantics in BPEL Processes" chapter of Developing SOA Applications with Oracle SOA Suite.

For information about setting the oneWayDeliveryPolicy property in the System MBean Browser, see Configuring BPEL Process Service Engine Properties.

It is also possible that the transaction has invoked a target asynchronous service that has not responded back. In this case, the business flow instance shows the call to the target asynchronous service.

- Check if the instance has rolled back and the message is in recovery.

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. Right-click soa-infra (SOA_cluster_name), and select Service Engines > BPEL.

3. Click the Recovery tab.

This may occur if any external references receiving the message are not reachable (for example, an external web service, enterprise applications such as Siebel, and so on).

B.7 Performance Troubleshooting

This section describes how to troubleshoot performance issues.

B.7.1 Resolving Issue Where BPEL Compiler Does Not Terminate or Report Exceptions

If a large SOA composite application containing many BPEL process service components is compiled, the BPEL compiler may not terminate and report any exceptions. If this occurs, increase the JVM heap size in the ant-sca-compile.xml file as follows:

- Change <jvmarg value="-Xmx1024m"/>

- To <jvmarg value="-Xmx4g"/>

The code sample below provides details:

<scac input="${scac.input}" outXml="${scac.output}"
error="${scac.error}" appHome="${scac.application.home}"
failonerror="true" displayLevel="${scac.displayLevel}"
reportErrors="${scac.reportSchemaValidationErrors}">
<jvmarg
value="-Djavax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom=oracle.
xml.xpath.JXPathFactory"/>
<jvmarg value="-Xms128m"/>
<jvmarg value="-Xmx4g"/>
<jvmarg value="-XX:PermSize=32m"/>
<jvmarg value="-XX:MaxPermSize=256m"/>
<jvmarg value="-Doracle.xdkjava.compatibility.version=11.1.1"/>
<jvmarg value="-Doracle.soa.compatibility.version=11.1.1"/>
<!-- jvmarg
value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"/ -->
</scac>
</target>

B.7.2 Resolving Message Failure Caused by Too Many Open Files

You can receive the following error at runtime or compilation time, depending on the number of JAR files being used, the use of file descriptors by JDK 6/JRE, or both.

Message send failed: Too many open files

To resolve this error, increase the number of file descriptors to at least 4096.

1. Use the limit command (for the C shell) or the ulimit command (for the Bash shell) to identify the value for descriptors. A value of 1024 is typically too low, especially for JDK 6.

% limit

cputime      unlimited
filesize     unlimited
datasize     unlimited
stacksize    10240 kbytes
coredumpsize unlimited
memoryuse    unlimited
vmemoryuse   unlimited
descriptors  1024
memorylocked 500000 kbytes
maxproc      46720

2. Log in as the root user on your operating system.

3. Edit the /etc/security/limits.conf file to increase the value for descriptors.

For this example, the limits.conf file appears as follows after increasing the limit for all users to 4096:

#<domain>      <type>  <item>         <value>
#

#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4

# End of file
@svrgroup    soft    memlock         500000
@svrgroup    hard    memlock         500000
*           soft    nofile          4096
*           hard    nofile          4096

4. Close your terminal and reopen for the change to take effect. A system restart is not required.

B.7.3 Resolving MaxMessageSizeExceededException Errors Caused By Large Payloads

MaxMessageSizeExceededException error occurs when you provide a large payload (for example, 200vu*500iter which is 100,000 requests) to your deployed SOA composite application. MaxMessageSize configuration must be configured based on the load. Click View XML Document in the audit trail to view the payload, and check for MaxMessageSizeExceededException errors. To resolve the error either increase the MaxMessageSize to 80000000, or decrease the session-flush-threashold to 50.

Note:
This values depend on the load. The default value of MaxMessageSize is 10000000. Change the values according to you load.

Increasing MaxMessageSize

To increase the MaxMessageSize:

1. Login to admin console.

2. Navigate to servers, protocols, general, max message size.

3. Changed the value to 80000000. (both the admin and the soa).

4. Navigate to servers, configuration, server start, arguments, and set-Dweblogic.MaxMessageSize = 80000000.

You can also change the -Dweblogic.MaxMessageSize value by adding weblogic.MaxMessageSize property. To change the value by adding the property:

1. Open the following file:

- On UNIX operating systems, open $MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh.

- On Window operating systems, open MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.bat.

2. Add the weblogic.MaxMessageSize property with the following value:

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Dweblogic.MaxMessageSize=80000000"
export EXTRA_JAVA_PROPERTIES

3. Restart the server.

Decreasing session-flush-threashold

Navigate to console cluster, soa_cluster, Configuration, Replication, Advanced, and change the Session Flush Threshold value to 50 (smaller value).

B.7.4 Extending Tablespaces to Avoid Problems at Runtime

If the database tablespace is not extended, runtime processing can be impacted. Messages are not processed or persisted, and exception errors similar to that shown in Example 1 and Example 2 below can appear in the log files. This is because Oracle BPEL Process Manager relies on the database to store instance data. If the database is not available, runtime processing is impacted.

Example 1

INFO: MediatorServiceEngine returning after processing the request for
operation = processResponse

[EL Warning]: 2009.01.14 11:46:16.783--UnitOfWork(32372128)--Exception
[EclipseLink-4002] (Eclipse Persistence Services - 1.1 (Build
SNAPSHOT-20081007)): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.BatchUpdateException: ORA-01691: unable to
extend lob segment SH_SOAINFRA.SYS_LOB0000145067C00007$$ by 1024 in
tablespace SH_SOAINFRA

Error Code: 1691
Query: InsertObjectQuery(com.collaxa.cube.persistence.dto.AuditTrail@199b33d)
[EL Warning]: 2009.01.14 11:46:16.782--UnitOfWork(32372128)--Exception
[EclipseLink-4002] (Eclipse Persistence Services - 1.1 (Build
SNAPSHOT-20081007)): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.BatchUpdateException: ORA-01691: unable to
extend lob segment SH_SOAINFRA.SYS_LOB0000145067C00007$$ by 1024 in
tablespace SH_SOAINFRA
. . .
. . .

Example 2

<bpelFault><faultType>0</faultType><subLanguageExecutionFault
xmlns="http://schemas.oracle.com/bpel/extension"><part
name="summary"><summary>XPath expression failed to execute.
An error occurs while processing the XPath expression; the expression is
ora:readBinaryFromFile('/scratch/vbasaval/dropbox/LFile/PO_5Gig.zip').
The XPath expression failed to execute; the reason was:
java.sql.SQLException: ORA-01652: unable to extend temp segment by 128 in
tablespace DEV12_IAS_TEMP

Ensure that you set a tablespace to automatically extend itself by a specified amount when it reaches its size limit. If you do not enable autoextend, ensure that you respond when alerted that the tablespace is reaching its critical or warning threshold size. You can respond to size alerts by manually increasing the tablespace size.

To manually add data files in SQL*Plus:

SQL> alter tablespace SOA12_SOAINFRA add datafile
'/scratch/db12101/Oracle/oradata/SOA12_soainfra2.dbf' size 1000M autoextend on
next 30M maxsize unlimited;

ALTER DATABASE TEMPFILE '/scratch/db12101/Oracle/oradata/SOA12_iastemp.dbf' RESIZE
100M;
ALTER DATABASE TEMPFILE '/scratch/db12101/Oracle/oradata/SOA12_iastemp.dbf'
AUTOEXTEND ON NEXT 30M MAXSIZE UNLIMITED;
ALTER DATABASE DATAFILE '/scratch/db12101/Oracle/oradata/SOA12_mds.dbf' RESIZE
100M;
ALTER DATABASE DATAFILE '/scratch/db12101/Oracle/oradata/SOA12_mds.dbf' AUTOEXTEND
ON NEXT 50M MAXSIZE UNLIMITED;
ALTER DATABASE DATAFILE '/scratch/db12101/Oracle/oradata/SOA12_soainfra.dbf'
RESIZE 2048M;
ALTER DATABASE DATAFILE '/scratch/db12101/Oracle/oradata/SOA12_soainfra.dbf'
AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED;
ALTER DATABASE DATAFILE '/scratch/db12101/Oracle/oradata/SOA12_svctbl.dbf' RESIZE
100M;
ALTER DATABASE DATAFILE '/scratch/db12101/Oracle/oradata/SOA12_svctbl.dbf'
AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED;

ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA1.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA2.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA3.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA4.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA5.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA6.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA7.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA8.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRA9.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAA.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAB.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAC.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAD.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAE.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAF.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAG.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAH.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAI.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAJ.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;
ALTER TABLESPACE "C0123_SOAINFRA" ADD DATAFILE
'/scratch/db12101/Oracle/oradata/SOA12_SOAINFRAK.dbf' SIZE 100M AUTOEXTEND ON
NEXT 30M MAXSIZE UNLIMITED;

B.7.5 Resolving Database Growth Issues Caused by a High Volume of Transactions

If Oracle SOA Suite transactions fail and the logs indicate that the database is running out of space, the dehydration store or MDS store may be running out of space due to a high volume of transactions. In the latter example, you see errors such as the following:

java.sql.SQLException: ORA-01653: unable to extend table SH_MDS.CUBE_INSTANCE by
16 in tablespace FUSION_TS_TOOLS

This indicates that the tablespace is full and the database cannot extend it.

Perform the following tasks.

1. Purge the dehydration store tables periodically, taking into account the appropriate record retention policies and ensuring that the applications have no dependencies on runtime data.

The purge should be followed by commands to coalesce the space. For the purging strategy to work, it is important to understand how long to retain the data in the database. Factors that drive the retention policy include the following:

- Legal requirements

- Line of business requirements

- Overall company policy on retention of data

The longer the retention policy, the greater the volume of data that must be stored and, correspondingly, the higher the disk capacity requirements.

For details on creating a purging strategy, see Developing a Database Growth Management Strategy and Managing Database Growth .

2. Ensure that the database hardware has sufficient resources to handle the demands of Oracle database partitioning before configuring your tables for partitioning.

For the dehydration store, database partitioning using range partitioning and hash partitioning is an optimal solution. Partitioning by definition means storing data in multiple tables to reduce bigger data sets into smaller, more manageable data sets. Partitioning strategies play a large role in easing maintenance overheads (dropping and pruning the partition) and improving performance. Partitioning should at least be done for tables having high activity. This plays a large role in balancing disk I/O and preventing hot disks. One important requirement that you must meet before configuring your tables for partitioning is to ensure that the database hardware has sufficient resources to handle the demands of Oracle database partitioning. If preproduction testing has indicated that the installation is large, Oracle expects that you have sized your environment (CPU, memory, and disk space) correctly to take advantage of the partitioning features.

3. Tune database parameters for memory, tablespace, and partitions to get maximum performance. For more information, see Section "Tuning Database Parameters" of Tuning Performance.

4. For other tablespaces running out of space, use the following query to check for free tablespace:

SELECT TOTAL.TABLESPACE_NAME "TABLESPACE NAME", FREE_SPACE, (TOTAL_SPACE-FREE_
SPACE) USED_SPACE, TOTAL_SPACE, ROUND((FREE_SPACE*100/TOTAL_SPACE),2) "FREE %"
FROM (SELECT TABLESPACE_NAME, SUM(BYTES/1024/1024) FREE_SPACE FROM SYS.DBA_
FREE_SPACE GROUP BY TABLESPACE_NAME) FREE,
(SELECT TABLESPACE_NAME, SUM(BYTES/1024/1024) TOTAL_SPACE FROM SYS.DBA_DATA_
FILES GROUP BY TABLESPACE_NAME) TOTAL
WHERE FREE.TABLESPACE_NAME = TOTAL.TABLESPACE_NAME AND TOTAL.TABLESPACE_NAME =
'<TABLESPACENAME>'
ORDER BY 5;

5. To increase tablespace settings, use the administrator account. For example:

ALTER TABLESPACE TABLESPACE_NAME ADD DATAFILE 'DATAFILE_NAME' SIZE 500M
AUTOEXTEND ON;

For more details, see Resolving Message Failure Caused by Too Many Open Files.

B.7.6 Observing Slow Application Performance Such as Longer Time to Serve Pages or Finish Transactions

You can observe slow application performance and/or memory trashing. For example, it may take longer to load and serve pages or to complete composite transactions. Response time may seem slower compared to normal behavior.

There are various reasons for slow performance. It may be due to a large number of servers running on the same host, or there may be a large number of records/sessions/locking in the database. Thread contention can also be a reason for poor performance.

Note:

All configuration changes in Oracle Enterprise Manager Fusion Middleware Control may be unavailable due to this problem.

To diagnosis this issue:

1. Check the CPU utilization to see if it is saturated due to a heavy load or too many processes in relation to CPU capacity.
If CPU utilization is at 100% during normal load hours (the target should be 70-80%), you have no capacity to handle a peak load and the hardware resources are insufficient. Add scale-out servers to handle the additional load.

2. Check applications using Oracle Enterprise Manager Fusion Middleware Control to report on performance. Check the performance of services and the invoke/response times in the BPEL process audit trail.

3. To maximize performance, it is recommended that you not set the logging level higher than the default INFO level.
For debugging purposes, you must set the logging level to the FINEST level. However, once issues are resolved, reset the logging level to the default level for best performance. It is also recommended that you set Audit Level to Production on the SOA Infrastructure Common Properties page. This can be set in Oracle Enterprise Manager Fusion Middleware Control as follows:

a. Right-click soa-infra (SOA_cluster_name).

b. Select SOA Administration > Common Properties.

c. Set Audit Level to Production.

4. Purge periodically based on retention requirements to maintain any service level agreements (SLAs).
To identify the tables where data growth may lead to performance issues, see Section "Identifying Tables Impacted By Instance Data Growth" of Tuning Performance.

For information about using the purge scripts, see Managing Database Growth .

5. Check the memory/IO/paging/swapping/CPU usage load statistics using Top or Glance or another monitoring tool.

6. Optimize the JVM to avoid full garbage collection or out-of-memory errors.
Frequent garbage collection can be either due to higher memory usage or memory leaks.

a. Ensure that the sum of the maximum heap size of all the JVMs running on your system does not exceed the amount of available physical RAM to avoid operating system level paging activity.

b. Use the JRockit mission control memory profiling tools to get thread dumps and memory snapshots, which helps Oracle Support Services debug any code issues. For more information about thread dumps, see Diagnosing Problems with SOA Composite Applications.

7. Optimize threads to avoid contention. Get a thread dump to investigate and submit it to Oracle Support Services.

8. Check the JVM and thread dumps for methods invoking the database to identify if database performance is a bottleneck.

9. Run database AWR snapshots to identify causes of database performance issues.

10. Ensure that database statistics are updated at regular intervals and other tunable parameters for memory, tablespace, and partitions are used effectively to obtain maximum performance.
Here are some common tuning recommendations. For more information, see the "Tuning Database Parameters" section of Tuning Performance.

- Put indexes and tables in as physically separate disk areas, if possible.

- Never put rollback segments with data or index segments.

- Separate highly active tables and indexes into their own tablespaces.

- Partition high activity tables and indexes to help balance disk I/O and prevent hot disks.

- Have processes in place to generate database table statistics at regular intervals.

11. Tune database tables to control the high watermark (HWM) contention of large objects. Tune database advanced queues (AQ) to control HWM contention and ensure consistent performance of producing and consuming messages from AQ.
The EDN AQ names to be aware of are EDN_EVENT_QUEUE_TABLE and EDN_OAOO_DELIVERY_TABLE.

12. Tune the BPEL process properties to reduce overhead (for example, disable the ValidateXML and StatsLastN (statistics gathering batch size) properties on the BPEL Service Engine Properties page in Oracle Enterprise Manager Fusion Middleware Control), if they are not needed.

13. In case of integration with packaged applications (for example, Siebel), check if the issue lies with the legacy applications.

For more information about performance tuning the various components, see the "Top Performance Areas" chapter and the "SOA Suite Components" part in Tuning Performance.

For information about setting properties on the BPEL Service Engine Properties page, see Configuring BPEL Process Service Components and Engines.

B.7.7 Observing Incoming Message Rates Exceeding Outgoing Message Rates

When the incoming rate of messages exceeds the processing rate of messages (that is, the outgoing rate), you can receive the warning message shown below:

[2012-04-09T16:49:40.342-04:00] [Soa_server1] [WARNING] []
[oracle.soa.bpel.engine.dispatch] [tid:
weblogic.work.j2ee.J2EEWorkManager$WorkWithListener@e3d0e3d
] [userId: <anonymous>] [ecid: 0000JSnNKVTBh4Z5ln1FiZ1Fdnmd001gWL,0] [APP:
soa-infra] BPEL service engine is overloaded, the inflow is higher than the
outflow, there are "100000" invoke messages pending in the dispatcher in-memory
cache, the configured threshold is "102",the new incoming invoke messages will not
be dispatched or processed immediately, they are going to be persisted in the
dehydration store and can be recovered later using recovery.

To resolve this issue, either increase the processing rate or lower (that is, throttle down) the incoming rate. The relatively low processing rate may be due to any or all of the following issues:

- Not enough invoke threads

- Not enough JVM capacity

- The external partners that the BPEL process is calling cannot scale, which causes the messages to back up in the BPEL process.

To identify the exact causes and resolve them, perform the following steps:

1. Check the oneWayDeliveryPolicy property value in the composite.xml file. Is it set to async.persist, async.cache, or sync? For information about this property, see Appendix "Deployment Descriptor Properties" of Developing SOA Applications with Oracle SOA Suite.

2. Ensure that the outgoing invocations from the BPEL process to external services are not backed up due to low scalability of the external services. If the bottleneck is in an external service, any tuning you perform in Oracle SOA Suite (that is, Step 3) does not help. You must first resolve the bottleneck.

3. Monitor your JVM garbage collection (GC). If the GC frequency appears higher than normal and the JVM appears to be near capacity, increase the JVM heap size.

B.8 Server Troubleshooting

This section describes how to troubleshoot server issues.

For more information about server startup issues, see Stopping and Starting the Managed Server and SOA Infrastructure .

B.8.1 Best Practices for Starting and Stopping a Managed Server

As a best practice, it is always recommended that you start and stop a managed server through one, but not both, of the following methods. Do not mix these methods, such as starting the managed server from the command line and stopping it from Oracle Enterprise Manager Fusion Middleware Control, or vice versa.

- Oracle Enterprise Manager Fusion Middleware Control
With this method, the node manager must be up and running. The node manager tracks all managed server startups and shutdowns performed from Oracle Enterprise Manager Fusion Middleware Control. With this method, the server state is not an issue.

- Command line
With this method, the node manager does not track the server state. Therefore, if you start the server from the command line and shut it down from Oracle Enterprise Manager Fusion Middleware Control, the Oracle WebLogic Administration Server accesses the node manager to determine its status, which returns a state of unknown.

Perform the following steps to stop and start the server from Oracle Enterprise Manager Fusion Middleware Control.

1. Expand the WebLogic domain.

2. Select the managed server (for example, named soa_server1).

3. Select Control > Shut Down.

4. Select Control > Start Up.

For information on starting and stopping managed servers from the command line, see Installing and Configuring Oracle SOA Suite and Business Process Management.

B.8.2 Diagnosing SOA Server Startup Problems

If the SOA server (soa_infra) does not start, there can be various reasons for server startup issues. A discovery-based approach to finding the root cause is required. Check the server and diagnostic logs as a first attempt to diagnose the issue. In addition, check the following.

To diagnose server startup issues:

1. Check if the database is not available or there are not enough connections available. Some failures with Oracle SOA Suite runtime can result from database outage/connectivity issues. Perform the following steps:

a. Log in to Oracle WebLogic Server Administration Console.

b. In the Domain Structure, view the status by selecting Services > Data Sources > SOADatasource > Monitoring > Testing to test the data source. You can also check this from a SQL prompt.

2. Check the list of ports used for port conflicts.

3. Check if the MDS repository cannot load shared documents (incorrect MDS configuration or the database that holds the MDS schema is not reachable).

4. Check the Oracle Coherence configuration if using an Oracle SOA Suite cluster (use of unicast versus multicast).
This issue only applies after provisioning is complete. Clustering of SOA servers may fail if there are port conflicts (used by Oracle Coherence). For example, one SOA server may be picking up the deployment, but the other server is not. In some cases, this may only present the following error:

[soa_server1] [ERROR] [] [Coherence] [tid: Logger@352821903 3.6.0.4]
[ecid: 46f620208907e045:63f295ec:12dd091ec2e:-8000-0000000000000003,1:27187]
[APP: soa-infra] 2011-01-28 23:06:19.463/414.816 Oracle Coherence GE 3.6.0.4
<Error> (thread=[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)', member=n/a):
Error while starting cluster: com.tangosol.net.RequestTimeoutException: Timeout
during service start: ServiceInfo(Id=0, Name=Cluster, Type=Cluster[[...

In this example, Oracle Coherence timeouts are prominently available. However, sometimes it presents itself with an unrelated error, such as the following:

Error creating bean with name 'SensorManager' defined in ServletContext
resource

The root cause of this is still primarily related to Oracle Coherence configuration.

5. Check if both the administration server and managed server ports are open and accessible.

6. Check if managed server startup failed because the administration server is not reachable.

7. Check network issues (for example, IP routing filtering/rules that may be causing issues).

8. Check Oracle WebLogic Server LDAP security corruption.
The managed server may report that policies for the application System MBeans Browser already exist or do not exist.

B.8.3 Specifying the Proxy Server

To use system properties to specify the proxy server, write your client application in the standard way, and then specify Java system properties when you execute the client application. The code sample below provides details:

setenv PROXY_SETTINGS "-DproxySet=true
-Dhttp.proxyHost=www-myproxy.us.mycompany.com -Dhttp.proxyPort=80
-Dhttp.nonProxyHosts=localhost|*.us.mycompany.com
|0:0:0:0:0:0:0:1|fe80:0:0:0:250:56ff:fe31"

Note:

When you specify values for proxy properties such as http.proxyHost and http.proxyPort, also specify the http.nonProxyHosts property.

B.8.4 Flow Diagram Does Not Display The First Time on Some Lower End Hosts

The flow diagram for an instance ID of a deployed SOA composite application in Oracle Enterprise Manager Fusion Middleware Control may not display the first time on some lower end hosts. Instead, you receive a failed to load resource message.

As a workaround, close the flow trace page and click the instance ID to return to the flow trace page.

B.8.5 Accessing Oracle Enterprise Manager Fusion Middleware Control on Dual Stack Hosts that Support IPv4 and IPv6

If you run Oracle SOA Suite on a dual stack host that supports both IPv4 and IPv6, you must update the etc/hosts file as shown in Table B-25 for IPv4 clients to access IPv6 URLs in Oracle Enterprise Manager Fusion Middleware Control.

Table B-25 IPv4 and IPv6 Settings in etc/hosts File

On The...

Edit the etc/hosts File as Follows....

On the IPv4 client:

xx.xxx.xxx.xxx myhost10-ipv6

where xx.xxx.xxx.xxx is the IP address of IPv6.

On the IPv6 client

2001:0db8:db0a::0:1  myhost10-ipv6 myhost10-ipv6.us.example.com

Note: Replace 2001:0db8:db0a::0:1 with a value appropriate to your host environment.

B.9 Browser Troubleshooting

This section describes how to troubleshoot browser issues.

B.9.1 Limitation on Using the Safari Browser to View WSDL File Content

If you are using the Safari browser, note the following limitation and workaround for viewing WSDL file contents in Oracle Enterprise Manager Fusion Middleware Control. Note also that Mozilla Firefox works correctly and does not require this workaround.

1. Go to the home page for a SOA composite application.

2. Click the Show WSDL and endpoint URI link at the top of the page.

3. Click the WSDL link that is displayed.

This opens a blank page that does not display the contents of the selected WSDL.

As a workaround, perform the following additional steps.

4. In the upper right corner of this page, click the Display a menu for the current page icon.

5. Select View Source from the menu that is displayed.

This displays the contents of the selected WSDL in another page.

B.10 Additional Troubleshooting Documentation

Table B-26 describes documentation to see for additional troubleshooting issues.

Table B-26 Additional Troubleshooting Documentation

For Information About...

See...

SOA Infrastructure startup and shutdown issues

Stopping and Starting the Managed Server and SOA Infrastructure .

Using WebLogic Diagnostic Framework (WLDF) and Diagnostics Framework (DFW) to diagnosis Oracle SOA Suite problems

Diagnosing Problems with SOA Composite Applications.

Managing large documents and metadata and for managing environments with large numbers of instances

Chapter "Managing Large Documents and Large Numbers of Instances" of Developing SOA Applications with Oracle SOA Suite.

Deployment and compilation errors

Section "Testing and Troubleshooting" in Developing SOA Applications with Oracle SOA Suite.

Oracle Web Services Manager Policy Manager errors

Section "Diagnosing Problems" chapter in the Administering Web Services.

Oracle Business Rules

Appendix "Oracle Business Rules Troubleshooting" of Designing Business Rules with Oracle Business Process Management.

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.