D87561GC10 sg2 PDF

This document should not be distributed.
For Instructor Use Only.

Oracle SOA Suite 12c: System
Architecture and Administration
Student Guide – Volume II

D87561GC10
Editi 1
Edition 1.0
0|D
December
b 2016 | D91683
Learn more from Oracle University at education.oracle.com

Authors Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Glenn Stokol Disclaimer
Ron Pinkerton This document contains proprietary y information and is protected by

y copyright
y g and
Armando Hernandez other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
in any way. Except where your use constitutes "fair use" under copyright law, you
Technical Contributors may not use, share, download, upload, copy, print, display, perform, reproduce,
publish, license, post, transmit, or distribute this document in whole or in part without
and Reviewers the express authorization of Oracle.
Veerabhadra Rao Putrevu
The information contained in this document is subject to change without notice. If you
Alessandro Leite find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
S. Matt Taylor Jr warranted
t d to
t be
b error-free.
f

Mark Lindros
Restricted Rights Notice
TJ Palazzolo
David Mills If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is
Jonathan Ortiz Luna applicable:
Jay Kasi
U.S. GOVERNMENT RIGHTS

Fermin Castro Alonso The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Deepak Arora license agreement and/or the applicable U.S. Government contract.
Derek Kam
Trademark Notice
David Read
Vishal Parashar Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Colin Pearce
Maria Salzberger
Donna Keeslingg
Scott Haaland
Joe Greenwald
Taj-Ul Islam
Antonella Giovannetti
Rajesh Raheja
Anuj Dwivedi
Editors
Vijayalakshmi Narasimhan
Aju Kumar
Graphic Designer
Seema Bopaiah
Publishers
Giri Venugopal
Michael Sebastian Almeida
Jobi Varghese
Sumesh Koshy
Contents
1 Introduction to Oracle SOA Suite 12c Administration

Agenda 1-2
Course Objectives 1-3

Agenda 1-4
Class Introductions 1-5
Audience 1-6
Prerequisites 1-7
Agenda 1-8

Lesson Objectives 1-9
Course Scope 1-10
Course Map 1-11
Course Schedule 1-12
Agenda 1-14
Service-Oriented Architecture: Overview 1-15
SOA Applications and Services 1-16
Agenda 1-17
Introducing Oracle SOA Suite 12c 1-18
Oracle SOA Suite 12c Components 1-20
Agenda 1-21
Roadmap for Implementing an Enterprise Deployment 1-22
Planning an Enterprise Deployment 1-23
Installing the Initial Enterprise Deployment 1-24
Extending an Enterprise Deployment: Selecting Your Topology or
Building Your Own 1-25
Course Enterprise Deployment Topology: Overview 1-26
How Can I Learn More? 1-28
Summary 1-29
2 Planning an Oracle SOA Suite 12c Deployment Architecture

Objectives 2-2
Agenda 2-3
Java Platform Enterprise Edition 2-4
Oracle WebLogic Server 2-5
WebLogic Server Domain 2-6
Administration Server 2-7
iii
Managed Servers 2-8
Node Manager 2-9
Machines and Clusters 2-10
WebLogic Server Administrative Tools 2-11
Agenda 2-13
Primary (Standard) Installation Topology 2-14
Standard SOA and BPM Topology 2-15
Enterprise Deployment: Overview 2-16
Purpose of the Hardware Load Balancer (LBR) 2-18

Understanding the Web Tier 2-19
Understanding the Application Tier 2-20
The Data Tier 2-21
Centralized Directory Server 2-22
Agenda 2-23

Roadmap for Planning an Enterprise Topology 2-24
Roadmap for Scaling an Enterprise Topology 2-25
Documenting the Topology Components 2-26
Oracle SOA Suite Enterprise Deployment Workbook 2-27
Agenda 2-28
Planning an EDG SOA Installation 2-29
Network Preparation 2-30
Providing External and Internal Access Points 2-31
Configuring Firewalls for Enterprise Deployment 2-32
Configuring the Application Tier Firewall 2-33
Configuring the Data Tier Firewall 2-34
Load Balancer Considerations 2-35
Virtual Host Names and Virtual IP Addresses 2-37
Configuring Virtual IP Addresses 2-39
Load Balancer Configuration 2-41
Directories for Installation and Configuration 2-42
Creating Multiple Home Directories 2-43
Choosing the Installation Directory Structures 2-44
Approaches for Installing Oracle Fusion Middleware and Related Products 2-45
Understanding OPSS and Security Requests 2-46
Resource Planning 2-47
Typical Disk Space Requirements 2-48
Sizing Guidelines (Approximations) 2-49
Agenda 2-51
Course Enterprise Deployment Architecture 2-52
Roadmap for Arriving at High Availability 2-53
Summary 2-54
Practice 2: Overview 2-55
iv
3 Installing Oracle SOA Suite 12c- Creating the Fusion Middleware
Infrastructure
Objectives 3-2
Agenda 3-3
Installation Topology Types 3-4
Quick Start Installation: Overview 3-5
Standard Installation Topology for Oracle SOA Suite 3-6
Agenda 3-7
Creating an Enterprise Installation Topology Roadmap 3-8

Fusion Middleware Infrastructure Installation Roadmap 3-9
Verifying Your Requirements 3-10
Installation Checklist 3-11
Installing the Oracle Database Software 3-12
Installing the Java Development Kit 3-13

Installing Oracle Fusion Middleware Infrastructure 3-14
Agenda 3-15
Configuring Oracle Fusion Middleware Infrastructure: Overview 3-16
Creating the Infrastructure Schemas (with RCU) 3-17
Selecting Infrastructure Schemas in RCU 3-18
Configuring the Infrastructure Domain 3-19
Domain Configuration and Database Schemas 3-20
Servers, Clusters, Machines, and Node Managers 3-21
Coherence in Clustered Domain Configurations 3-22
Unicast Communication in the Application Tier 3-23
Agenda 3-25
Propagating Configuration to Managed Servers 3-26
Propagating the Domain with Pack and Unpack Scripts 3-27
Agenda 3-28
Starting the Servers in an Enterprise Deployment Domain 3-29
Stopping the Servers and the Node Manager 3-30
Starting and Stopping the Servers with Node Manager 3-31
Controlling the Servers with Administration Applications 3-32
Agenda 3-33
Creating an LDAP Authentication Provider 3-34
Additional Authentication Provider Configuration 3-35
Creating a SOA Administrator in the LDAP Server 3-36
Authorization Roles for Web Services Manager 3-37
Authorizing Management of WSM-PM Functions 3-38
Authorizing a Custom LDAP Group as an Administrator 3-39
Summary 3-40
v
4 Installing Oracle SOA Suite 12c - Extending the Domain with Oracle SOA Suite
Objectives 4-2
Agenda 4-3
Installing a Web Tier: Overview 4-4
Configuring the Web Tier: Overview 4-5
Configuring Web Tier Virtual Hosts in httpd.conf 4-6
Routing to the AdminServer and Oracle Web Services Manager 4-7
Updating the Web Tier OPSS Java Platform Security (JPS) Configuration 4-8
Enabling SSL Between the Load Balancer and the Web Tier 4-9

Agenda 4-10
Course Enterprise Deployment Topology: Review 4-11
SOA Suite Installation Roadmap 4-12
Installing the Oracle SOA Suite Software (Product-Specific) 4-13
Agenda 4-14

Configuring the Oracle SOA Suite Schemas (with RCU) 4-15
Creating the SOA Database Schemas (with RCU) 4-16
Sizing Guidelines (Approximations) 4-17
Extending the Domain with Oracle SOA Suite 12c 4-18
Domain Configuration and Database Schemas 4-19
Configuring SOA Suite Components in the Domain 4-20
Configuring JMS File Store Settings 4-21
Propagating the Extended Domain Configuration 4-22
Agenda 4-23
Application Roles and Permissions 4-24
Authorizing Management of SOA Suite Components 4-25
Routing from the Web Tier to the Oracle SOA Servers 4-26
Configuring the WebLogic Proxy Plug-In 4-27
Backing Up the Configuration 4-28
Summary 4-29
5 Installing Oracle SOA Suite 12c - Configuring the Load Balancer for an
Enterprise Deployment
Objectives 5-2
Agenda 5-3
Load Balancer (LBR): Overview 5-4
Load Balancer Features for Enterprise Deployment 5-5
Purpose of the Hardware Load Balancer 5-7
Accessing Oracle SOA Suite via the Load Balancer 5-8
WebLogic Proxy Plug-In Enabled Setting 5-9
Configuring the WebLogic Proxy Plug-In Enabled Setting for a Cluster 5-10
vi
Agenda 5-11
Course Load Balancer Architecture: Overview 5-12
Course Load Balancer Configuration: Overview 5-13
Agenda 5-14
Validating and Examining the Load Balancer Configuration 5-15
Load Balancer Configuration Examples 5-16
Validating the Load Balancer Configuration with URLs 5-17
Summary 5-19

6 Configuring High Availability
Objectives 6-2
Agenda 6-3
Reviewing a High Availability Architecture 6-4

Course High Availability Architecture: Review 6-5
Agenda 6-6
Roadmap for Scaling Out Your Topology 6-7
Agenda 6-8
Planning Considerations for High Availability 6-9
Administration Server High Availability Topology 6-10
Failing Over the Administration Server 6-11
Additional Post-Configuration Tasks 6-12
Agenda 6-13
Making the File Adapter Highly Available 6-14
Modifying the File Adapter Deployment Descriptor 6-15
High Availability for the Oracle Database Adapter 6-16
Preparing Resources for the Database Adapter 6-17
Creating a JDBC Data Source 6-18
Creating a Database Adapter Connection Factory 6-19
Configuring the Connection Factory Data Source 6-20
High Availability for Oracle JMS Adapters 6-21
Agenda 6-23
Configuring SSL Communication with the Load Balancer 6-24
Configuring SSL for Oracle SOA Suite Applications 6-26
Generating Self-Signed Certificates with utils.CertGen 6-27
Creating an Identity Keystore by Using the utils.ImportPrivateKey Utility 6-28
Creating a Trust Keystore By Using the Keytool Utility 6-29
Importing the Load Balancer’s Certificate into the Trust Store 6-30
Adding the Trust Store to the Server Start Scripts 6-31
Configuring Node Manager to Use Custom Keystores 6-32
Configuring WebLogic Server to Use Custom Keystores 6-33
vii
Deploying Applications to an Enterprise Deployment 6-35
Testing Composites By Using SSL Endpoints 6-36
Agenda 6-37
Configuring Whole Server Migration: Overview 6-38
Components for Whole Server Migration 6-39
Summary 6-40
7 Fundamentals of Oracle SOA Suite

Objectives 7-2
Agenda 7-3
Understanding Composite Applications 7-4
Problem Statement 7-5
Definition of SOA 7-6

Building a Service Portfolio 7-7
Assembling Services as Composite Applications 7-8
Agenda 7-9
How Services Communicate 7-10
Synchronous and Asynchronous Interactions 7-11
Describing a Message with XSD 7-12
Web Services Description Language 7-13
Abstract WSDL 7-14
Concrete WSDL 7-15
Quiz 7-16
Agenda 7-17
Elements of a SOA Composite Application 7-18
SOA Components: Oracle Mediator 7-19
Routing Data 7-20
Transforming Data 7-21
Additional Features of Mediators 7-22
Quiz 7-23
Agenda 7-24
SOA Components: Oracle BPEL Process Manager 7-25
Business Processes and BPEL 7-26
Parts of a BPEL Process 7-27
BPEL, WSDL, and XSD 7-28
Partners, PartnerLinks, and Roles 7-29
Quiz 7-30
Agenda 7-31
SOA Components: Oracle Human Workflow 7-32
Human Workflow Service Component 7-33
viii
Facets of a Task 7-34
Task Participants 7-35
Task Routing 7-36
Notifications 7-37
Task Forms 7-38
Components of Human Workflow 7-39
Oracle BPM Runtime Architecture 7-40
Quiz 7-41
Agenda 7-42

SOA Components: Oracle Business Rules 7-43
Introducing Business Rules 7-44
Declarative Rule Concepts 7-45
Decision Tables 7-46
Using Business Rules in a Composite Application 7-47

The Spring Component 7-48
Quiz 7-49
Agenda 7-50
Services and References: Web Services 7-51
Services and References: Adapters 7-52
Quiz 7-54
Summary 7-55
8 Deploying and Testing Composite Applications

Objectives 8-2
Agenda 8-3
WebLogic Application Server 8-4
SOA Infrastructure 8-5
Service Engines 8-6
Binding Components 8-7
SOA Infrastructure Database Connections 8-8
SOA Infrastructure Life Cycle 8-9
Quiz 8-10
Agenda 8-11
Packaging and Deploying a Composite Application 8-12
Building a Service Archive 8-13
Deploying a Composite Application 8-14
Packaging Multiple SOA Projects 8-15
Agenda 8-16
JDeveloper 8-17
Enterprise Manager 8-18
ix
Oracle Enterprise Manager: The Application Dashboard 8-20
Composite Application Management Tools 8-21
Managing SOA Applications with the WLST Utility 8-22
Deploying and Undeploying Applications with WLST 8-23
Managing SOA Applications with Ant Scripts 8-24
Deploying and Undeploying Applications with Ant 8-25
Understanding Composite Application Instances 8-26
Testing a Composite Application 8-27
The Response Tab 8-28

Flow Trace 8-29
The Component Audit Trail 8-30
Examining the composite.xml Source 8-31
Project Files 8-32
Creating a Mediator 8-33

Creating an Adapter 8-34
Summary 8-35
9 Managing the Composite Application Life Cycle

Objectives 9-2
Agenda 9-3
Composite Application Revisions 9-4
Revisions and SOA Bundles 9-5
Redeploying an Application 9-6
Quiz 9-7
Agenda 9-8
Composite Partitions 9-9
Creating Partitions 9-10
Managing Composites Within a Partition 9-11
Securing Access to Partitions 9-12
Securing with Partition Roles 9-13
Quiz 9-14
Agenda 9-15
Composite Application Dependencies 9-16
Configuration Plans: Overview 9-17
Editing a Configuration Plan 9-18
Validating a Configuration Plan 9-19
Deploying with a Configuration Plan 9-20
Using WLST to Create and Manage Configuration Plans 9-21
Migrating a Composite Application Across Environments 9-22
Quiz 9-23
x
Agenda 9-24
Managing Global Token Variables for Multiple SOA Composite Applications 9-25
Global Tokens: Example 9-26
Quiz 9-28
Summary 9-29
10 Administering Composite Applications at Run Time

Objectives 10-2

Agenda 10-3
Log Files: Overview 10-4
ODL Log File Format 10-5
Logging Levels 10-6
Configuring Logging Levels 10-7

Configuring Log Files 10-9
Audit Levels 10-10
Order of Precedence for Audit Level Settings 10-11
Managing the Audit Level of BPEL Components 10-12
Sensors 10-13
Enabling and Disabling Sensors 10-14
Monitoring Composite Instances and Faults 10-15
Quiz 10-17
Agenda 10-18
Managing Faults in the Error Hospital 10-19
Specifying and Saving Fault Search Criteria 10-20
Viewing Aggregated Fault Statistics 10-22
Performing Bulk Fault Recoveries and Terminations 10-23
Quiz 10-24
Summary 10-25
11 Administering Business Events

Objectives 11-2
Agenda 11-3
Business Events: Introduction 11-4
Events and Event Delivery Network 11-5
Event Delivery Network (EDN) Concepts 11-6
Event Delivery Network and Business Events 11-7
Quiz 11-9
Sample Applications That Publish and Subscribe to Business Events 11-10
Agenda 11-11
xi
Managing EDN in Enterprise Manager 11-12
Viewing Events in Enterprise Manager 11-13
Testing Events with Enterprise Manager 11-14
Viewing Event Subscriptions 11-15
Viewing Event Faults 11-16
Quiz 11-17
Summary 11-18

12 The Oracle User Messaging Service
Objectives 12-2
Agenda 12-3
Introducing Oracle User Messaging Service 12-4
BPEL: Email Activity 12-6

BPEL: User Notification Activity 12-7
User Notifications and Human Tasks 12-8
Agenda 12-9
UMS Message Channels and Drivers 12-10
Relationship Between UMS and an Identity Service 12-11
Deploying Drivers 12-12
Configuring UMS and UMS Drivers 12-13
Common Driver Properties 12-15
Monitoring Oracle User Messaging Service 12-16
Viewing and Testing Email Notifications 12-17
Configuring User Preferences 12-18
Workflow Notification Properties 12-19
Configuring UMS Notification Properties 12-20
Quiz 12-21
Summary 12-22
13 Troubleshooting and Performance Tuning of Oracle SOA Suite 12c

Objectives 13-2
Agenda 13-3
Performance Tuning: Overview 13-4
Top Performance Tuning Areas 13-5
Agenda 13-7
Monitoring and Diagnostic Tools: Overview 13-8
Monitoring with Oracle Enterprise Manager Fusion Middleware Control 13-9
Oracle Fusion Middleware Diagnostic Framework 13-10
Oracle Dynamic Monitoring Service and Architecture 13-12
xii
WLDF Watch and Notification Component 13-14
Configuring Diagnostic Framework Settings 13-15
Viewing DMS Metrics 13-17
Viewing Metrics with Oracle Enterprise Manager Fusion Middleware Control 13-18
Viewing Metrics with the Spy Servlet 13-19
Agenda 13-20
Monitoring the Java Virtual Machine Performance 13-21
Tuning a Java Virtual Machine Memory 13-22
Monitoring and Tuning the Database Size 13-23

Tuning the Oracle Database 13-24
Extending Tablespaces to Avoid Problems at Run Time 13-26
Configuring Database Connections 13-27
Developing a Strategy for Managing Database Size 13-28
Automatically Purging Instance Data 13-29

Monitoring the SOA Infrastructure Performance and Metrics Data 13-30
Tuning SOA Infrastructure 13-31
Work Managers and Work Manager Groups 13-33
Work Managers Types 13-35
Managing Work Manager Component Configuration 13-37
Work Managers Groups and SOA Partitions 13-38
SOA Work Manager Examples 13-39
Configuring Work Manager Groups 13-40
Associating a Work Manager Group with a Partition 13-41
Monitoring and Tuning Service Engines 13-42
Tuning the BPEL Engine Parameters 13-43
Configuring BPEL Engine Parameters 13-45
Monitoring SOA Composite Application Performance 13-46
Monitoring an Inbound Adapter Properties 13-47
Accessing Adapter Logs 13-48
Activating Adapter Reports 13-49
Selective Tracing Configuration: Introduction 13-50
Viewing and Disabling Selective Tracing 13-52
Agenda 13-53
Common Problems and Solutions 13-54
Troubleshooting SOA Server Startup Failures 13-55
Resolving Message Failure Caused by Too Many Open Files 13-56
Resolving Connection Timeouts 13-57
Resolving Common Application-Related Problems 13-58
Summary 13-59
xiii
14 Backup and Recovery of Oracle SOA Suite
Objectives 14-2
Agenda 14-3
Documenting Oracle Fusion Middleware Installations 14-4
About Backup and Recovery 14-5
Types of Backups 14-6
Recommended Backup Strategy 14-7
Limitations and Restrictions for Backing Up Data 14-8
Quiz 14-9

Agenda 14-10
Backup Tools 14-11
Backing Up an Enterprise Deployment Topology 14-12
Performing a Full Offline Backup 14-13
Performing an Online Backup of Runtime Artifacts 14-14

Backing Up the Domain Configuration File 14-15
Quiz 14-16
Agenda 14-17
Recovery After Disaster 14-18
Recommended Recovery Strategy 14-19
Directories to Restore 14-20
Recovering a Middleware Home 14-21
Managed Server Independence (MSI) 14-22
Recovering a Managed Server 14-23
Summary 14-24
15 Configuring Security Services and Policies

Objectives 15-2
Agenda 15-3
Web Services Security: Introduction 15-4
Transport-Level Security 15-5
Message-Level Security 15-6
WS-Security: Overview 15-7
WS-Security Tokens 15-9
Security Assertion Markup Language (SAML) 15-11
WS-Security and SAML 15-13
Quiz 15-14
Agenda 15-15
Oracle Web Services 15-16
Oracle Web Services Manager 15-17
Oracle Web Services Manager Policy Framework 15-18
xiv
Oracle Web Services Manager Architecture: Components 15-19
Web Services Policies: Introduction 15-20
Policy Assertion 15-21
Oracle Web Services Manager Policy Assertions 15-22
Supported Policies 15-23
Policy Interceptor Pipeline 15-24
Oracle WSM Predefined Policies and Assertion Templates 15-25
Viewing Available Web Services Policies 15-26
Quiz 15-27

Agenda 15-28
WSM-PM WS-Security Policies Versus WLS WS-Security Policies 15-29
Securing SOA and Identity Propagation 15-30
Attaching Policies in JDeveloper (Development Time) 15-31
Viewing Attached Policies in EM Console 15-32

Attaching and Detaching Policies By Using EM Console 15-33
Monitoring the Performance of the SOA Composite 15-35
Quiz 15-36
Summary 15-37
16 Enterprise Scheduler Service

Objectives 16-2
Agenda 16-3
Enterprise Scheduler Service: Introduction 16-4
What the Enterprise Scheduler Service Provides 16-5
Job Modeling 16-6
Schedule and Resource Modeling 16-8
Integration with SOA 16-9
Job Security 16-10
Agenda 16-11
Basic Tasks for Configuring and Managing ESS 16-12
Extending a Domain with ESS 16-14
Configuring a Job Request Dispatcher 16-15
Starting the Instance 16-16
Agenda 16-17
Creating a Web Service Job Definition 16-18
Creating Schedules 16-19
Creating and Submitting Job Requests 16-20
Creating Job Sets 16-21
Defining Restrictions with Incompatibilities 16-22
Binding a Work Assignment to a Request Processor 16-23
xv
Agenda 16-24
Creating a Purge Policy 16-25
Monitoring Oracle Enterprise Scheduler Service: Overview 16-26
Quiz 16-27
Summary 16-28
17 Oracle Cloud
Agenda 17-2

What is Cloud? 17-3
What is Cloud Computing? 17-4
History – Cloud Evolution 17-5
Components of Cloud Computing 17-6
Characteristics of Cloud 17-7

Cloud Deployment Models 17-8
Cloud Service Models 17-9
Industry Shifting from On-Premises to the Cloud 17-13
Oracle IaaS Overview 17-15
Oracle PaaS Overview 17-16
Oracle SaaS Overview 17-17
Summary 17-18
18 Oracle SOA Cloud Service Overview

Objectives 18-2
About Oracle SOA Cloud Service 18-3
Benefits of Oracle SOA Cloud Service 18-4
Components of Oracle SOA Cloud Service 18-5
Oracle SOA Suite 18-6
Oracle Service Bus 18-7
Oracle Technology Adapters 18-8
Oracle Cloud Adapters 18-9
Oracle API Manager 18-10
Oracle BAM 18-11
Additional Components Needed for Oracle SOA Cloud Service 18-12
Differences Between the Cloud and On-Premises Environments 18-14
Summary 18-16
A Appendix A
Composite Instance Patching A-2
Overview of Composite Instance Patching A-3
Cycle of Composite Instance Patching Process A-4
xvi
Switching to SOA Patch Developer Role A-5
Generate the patch.xml A-6
Generate a Sparse Deployment Profile A-7
Use the WLST Tool to validate and apply the patch A-8
In-Memory SOA A-9
Performance Problem A-10
In-Memory Solution A-11
In-Memory Integration A-12
In-Memory Integration: Use Cases A-13

States for In-Memory SOA Instances A-14
Managing Instances A-16
Configuring In-Memory SOA A-17
Integrated Workload Statistics A-18
Integration Workload Statistics (IWS) Reports A-19

IWS Reports Identify Bottlenecks and Backlogs A-20
Sample Scenario: Slow Downstream Service Causing Back log and
Error Instances A-21
Performance Tuning Areas A-22
Performance Tuning with Oracle SOA Suite A-23
IWS Data Collection and Reports A-24
Configuring Data Collection Levels for IWS Reports A-26
Configuring IWS Data Collection in Enterprise Manager A-27
Generating an IWS Report A-28
IWSReport MBean A-31
IWS WLST Commands A-32
Statistics Included in an IWS Report A-33
Resiliency: Circuit Breaker A-34
Problem and solution A-35
The Resiliency Solution A-36
Unavailable Downstream Service Results in Suspended Upstream Service A-37
Alternative example diagram to embellish A-40
Types of Upstream Endpoints Supported A-41
Configuring Resiliency at the Global Level A-42
Overriding Global Resiliency Settings for a Downstream Endpoint A-43
Global Resiliency Properties and Endpoint Resiliency Properties A-44
Viewing and Resuming Suspended Services A-45
Viewing and Resuming a Suspended Endpoint A-46
Locating Activity in the Log File A-47
IWS and Resiliency A-48
xvii
11

Administering Business Events

Copyright © 2015, Oracle and/or its affiliates. All rights reserved.
Objectives
After completing this lesson, you should be able to:

• Describe business events and the Event Delivery Network
• Manage events by using Oracle Fusion Middleware Control

This lesson discusses business events and Event Delivery Network concepts, and how to
monitor business events in Enterprise Manager.
Oracle SOA Suite 12c: System Architecture and Administration 11 - 2

Agenda
• Introducing Business Events and the Event Delivery Network

• Managing Business Events


Business Events: Introduction
• Event: Is a message structure that represents the occurrence

of a business event that must be communicated to other
applications
• Business Event: Defines the occurrence and structure of an
event when it occurs

Events are one-way, fire-and-forget, asynchronous interactions.

New customer Stock low Stock received
An event is a message structure that represents an occurrence of a business event that must
be communicated to other applications. A business event is a name to define the occurrence
and structure of an event when it occurs. 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. Developers declaratively define business
events and specify raise conditions that dictate when the event is raised. As data is changed,
these conditions are evaluated and all events whose raise conditions are met are fired.
You raise business events when a situation of interest occurs. Business events are a one-
way, fire-and-forget, asynchronous interaction to send a notification of a business occurrence.
The business process does not:
• Rely on any service component receiving the business event to complete
• Care if any other service components receive the business event
• Need to know where subscribers (if any) are and what they do with the data
These are important distinctions between business events and direct service invocations that
rely on the Web Service Description Language (WSDL) file contract (for example, a SOAP
service client). If the author of the event depends on the receiver of the event, messaging
typically must be accomplished through service invocation rather than through a business
event. Unlike direct service invocation, the business event separates the client from the
server.

Events and Event Delivery Network
Events are one-way, fire-and-

forget, asynchronous
notifications of a business
occurrence.
Events are not targeted
to a specific service
publish provider, but are

available to any and all
interested parties.
Event subscribe
Delivery

Events are messages Network
that typically have a
header and a payload.
subscribe
Events are messages. They typically have a header and a payload. The header contains
metadata such as the event type and a time stamp. The payload contains details that
describe the facts of the event instance that the business logic in the consumer will process.

Event Delivery Network (EDN) Concepts
Event Delivery Network:

• Supports events processing and provides a JMS-based
messaging infrastructure
• Provides a way to declaratively work with publish-subscribe
implementations

• Offers subscription capabilities based on:
– Namespaces
– Event names

– Content-based XPath filters
• Handles events defined in Event Definition Language (EDL)
format
The subsystem of Oracle SOA Suite that accepts published business events and delivers
them to the subscribers is called the Event Delivery Network (EDN). An EDN provides a true
publish-subscribe abstraction. Therefore, developers do not need to know about the
underlying event infrastructure. EDN supports a fully declarative approach, and does not
require explicit wiring between components, thereby leading to truly decoupled applications.
A business event is defined by using the Event Definition Language (EDL), which is an XML
language. Each event is identified by a QName, such that it is uniquely identified by a name
qualified by a namespace. Therefore, an EDN offers the following three levels of subscription
granularity:
• Namespaces, where the subscriber receives any event with a specific namespace
• Event names, where the subscriber receives an event with a specific QName
• Content-based XPath filters, where a subscriber can add content-based filters to accept
or reject events

Event Delivery Network and Business Events
The Event Delivery Network distributes events within the Oracle

Fusion Middleware service infrastructure.
OEP EDN
With EDN Adapter API
Composite Java
Application Event Delivery Network Application

mediator BPEL mediator

describe
events Service Infrastructure
MDS
EDL XSD
The Event Delivery Network (EDN) is provided by Oracle Fusion Middleware to reliably
distribute events within the SOA Suite service infrastructure. EDN offers:
• Various qualities of services
• A declarative, graphical UI to abstract the underlying messaging infrastructure (JMS-
based). The JMS resource that is used to deliver event information needs to be
configured.
Events are defined by an XML file in Event Definition Language (EDL) format, whose XML
structure is defined by an associated XML Schema Definition (XSD). EDL contains:
• The event information
• The description of the payload structure and elements derived from the XSD file
Events are one-way asynchronous interactions that are immutable, that is, events are not
alterable. A new event is required to alter a previous fact. Mediator and BPEL components
are the only SOA components that can subscribe to and publish events. Subscription and
publication must be done in Oracle JDeveloper. ADF-BC applications can only publish events.

EDN is based on a standard JMS messaging infrastructure that supports business event–based
interactions among Oracle SOA Suite components and non-Oracle SOA Suite components.
EDN provides two JMS-based types:
• Oracle WebLogic Server JMS: By default, all business events use a single, default Oracle
WebLogic Server JMS topic.
• Oracle Advanced Queuing (AQ) JMS
The default JMS type can be switched from Oracle WebLogic Server JMS (default) to AQ JMS
in Oracle Enterprise Manager Fusion Middleware Control.


Quiz Q
Event Delivery Network (EDN) provides a standard JMS-based
messaging infrastructure for Oracle SOA Suite.
a. True
b. False

Answer: a
Event Delivery Network (EDN) provides a standard JMS-based messaging infrastructure.

Sample Applications That Publish and Subscribe to
Business Events
DemoEvtPublisher

DemoEvtSubscriber

The slide shows the assembly model of two composite applications that consist of the
mediator components:
• DemoEvtPublisher: Takes a SOAP message (from EM interface) and publishes an
event (NotifyEvent) with the input data
• DemoEvtSubscriber: Receives the event published by DemoEvtPublisher, and then
either sends an email message based on the event details, or writes the message and a
date to the file name specified
The DemoEvtPublisher request message provides the following three input elements:
• SendTo: The value (in lower case) is either “file” or “email.”
• Destination: If SendTo is “file,” this should be a file name (without the path); if
SendTo is “email,” this should be an email address such as
weblogic@soa12c.example.com.
• Messaged Text: Any text string that is written to the file or email body

Agenda
• Introducing Business Events and the Event Delivery Network

• Managing Business Events


Managing EDN in Enterprise Manager
The Business Events page:

• Is found in Oracle Enterprise Manager Fusion Middleware
Control with tools for tracking, testing,
and managing events in EDN
• Can be accessed from

the soa-infra folder, or
the SOA Infrastructure
menu

Oracle Enterprise Manager Fusion Middleware Control provides a Business Events page that
can be accessed to manage, track, and test events in EDN. After you log in to Enterprise
Manager Fusion Middleware Control, to access the Business Events page, expand the SOA
folder in the Target Navigation pane and perform either of the following:
• Right-click the soa-infra node and select Business Events.
• Click the soa-infra page to open the soa-infra page, click the SOA Infrastructure >
Business Events.

Viewing Events in Enterprise Manager

2

The slide shows the Business Events home page that is displayed when you select the
Business Events menu option from the soa-infra context menu, or the SOA Infrastructure
menu on the soa-infra home page. The Business Events page gives you visibility of all the
events in the SOA Infrastructure EDN. It 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
• Business events, including the namespace used, event name, number of subscriptions
to each event, and number of failed event deliveries. Business events are contained
within their namespace.
You can select a specific event in the Namespaces and Events section to view its event
definitions, as shown in the example in the slide. To select an event and view its details,
perform the following steps:
1. Select an event entry and click Show Event Definition.
2. In the XML Definition window, view the XML syntax for the event and click OK.
In this example, the business event named StockUpdated appears in the event definition. The
namespace (StockEventDefinition) and the associated schema file (StockEvents.xsd) are
referenced.

Testing Events with Enterprise Manager
On the Events tabbed page, perform the following steps:

1. Select the event to be tested and click Test.
2. In the Test Event window, enter an XML payload and click
Publish.

1

2
While on the Events tabbed page, you can:

1. Select an event and click Test. This opens a Test Event window.
2. In the Test Event window, you can enter the XML data that is needed to form the event
payload that you wish to test. This initiates any application that is subscribing to the
event that is being tested.
The XML data you enter needs to include the namespace declaration; in this case, it is
xmlns:evt1="http://schema.oracle.com/events/edl/StockEventDefinition". In
addition, all the elements should be namespace-specific.

Viewing Event Subscriptions
Click the Subscriptions tab and search for different subscriptions.

The Subscriptions tab page displays and provides options to search for information about all
subscriptions. In the example in the slide, the Search section shows some of the options to
search for different subscriptions, such as:
• Component Subscriptions: Narrows the search result to component subscriptions
In the Component Subscriptions section, a table lists the events and components, their
owning composite application that subscribes to the event, event consistency settings, and
number of delivery failures, if any. This enables you to quickly monitor the state of events in
EDN. In this example, the SubscribeStockUpdComposite application is a subscriber to the
published event StockUpdated.

Viewing Event Faults
Expand SOA, select soa-infra, click the Error Hospital tab, and
enter search criteria to locate the event faults of interest.

To view details about event faults, in the Target Navigation pane, expand SOA, select soa-
infra, and click the Error Hospital tab. On the Error Hospital tab, you can search for specific
faults, and view the faults occurring in a business event, their error messages (if any), and
whether you can recover from the fault. You can recover from business event faults that are
identified as recoverable. The Recovery column identifies faults for which recovery actions
can be performed.

Quiz Q
Which of the following statements is true?
a. Mediator components can publish and subscribe to business
events only in JDeveloper.
b. Mediator components can publish and subscribe to business
events only in Enterprise Manager.

c. Mediator and BPEL components can publish and subscribe to
business events in both JDeveloper and Enterprise Manager.
d. Business rule components can publish and subscribe to
business events in JDeveloper.

Answer: c
Mediator and BPEL components support business events in both JDeveloper and Enterprise
Manager.

Summary
In this lesson, you should have learned how to:

• Describe business events and the Event Delivery Network
• Manage events by using Oracle Fusion Middleware Control


Practice 11: Overview
This practice covers the following topics:

• Practice 11-1: Deploy the Stock Update Composite as an
event subscriber for StockUpdated business event
• Practice 11-2: Test the Subscriber of the StockUpdated Event
by using Oracle Enterprise Manager Fusion Middleware

Control
• Practice 11-3: Deploy, Test, and Monitor the
PublishStockUpdComposite application, which publishes the
StockUpdated business event

Composite applications can publish and subscribe to events, known as business events. The
business event subscribers are effectively applications that begin processing as a result of
some event occurrence. The SubscribeStockUpdComposite application uses a Database
Adapter to query and manipulate data in the EXTERNAL_STORE database table of the
SOADEMO database schema.
The PublishStockUpdComposite application sends the event to begin a stock update process.
You can also test event subscription by using tools in Oracle Fusion Middleware Control
Console before you deploy the application that publishes the associated events.

12
The Oracle User Messaging

Service

Objectives

• Explain how UMS is used by Oracle SOA Suite 12c
• Configure UMS message channels and drivers


Agenda
• Introduction to UMS
• Configuring UMS


Introducing Oracle User Messaging Service
WebLogic Server SOA Instance

Composite
Application
SOA/EJB Client 3
Human 3
Task
web services
remote client
JMS EJB
Business

Process
User Messaging Server 1

UMS
Adapter
message
JMS repository

XMPP EMAIL SMPP Extension 2 drivers
Worklist
Application 4 servers
The User Messaging Service (UMS) is an Oracle Fusion Middleware component that enables
communication between users and applications. It consists of the following:
1. UMS Server: The UMS Server orchestrates message flows between applications and
users. The server routes outbound messages from a client application to the appropriate
driver, and routes inbound messages to the correct client application. The server also
maintains a repository of previously sent messages in a persistent store, and correlates
delivery status information with previously sent messages.
2. UMS Drivers: UMS Drivers connect UMS to the messaging gateways, adapting content
to the various protocols supported by UMS. Drivers can be deployed or undeployed
independently of one another depending on what messaging channels are available in a
given installation.
3. UMS client applications: UMS client applications implement the business logic of
sending and receiving messages. A UMS client application might be a SOA application
that sends messages as one step of a BPEL workflow, or a WebCenter Spaces
application that can send messages from a web interface.

4. In addition to the components that comprise UMS itself, the other key entities in a
messaging environment are the external gateways that are required for each messaging
channel. These gateways are not a part of UMS or Oracle WebLogic Server. Because
UMS Drivers support widely adopted messaging protocols, UMS can be integrated with
existing infrastructures such as corporate email servers or XMPP (Jabber) servers.
Alternatively, UMS can connect to outside providers of SMS services that support SMPP.
Exchanges between UMS client applications and the UMS Server occur as SOAP/HTTP web
service requests for UMS Web Services API clients, or through remote Enterprise JavaBeans
(EJB) and JMS calls for UMS Java API clients. Exchanges between the UMS Server and UMS
Drivers occur through JMS queues.
UMS supports various messaging channels such as Email, SMS, Instant Messaging, and

Voice. It provides a messaging proxy between the Oracle BPEL or Mediator products and the
external world. UMS provides two-way messaging: inbound and outbound messaging, and
provides robust message delivery, including delivering delivery status, and message resend
through Enterprise Messages. UMS also provides support for failover address.

BPEL: Email Activity
BPEL Process
Email
UMS
Email
Activity
Activity

Email
Configuration
driver

The BPEL process component provides ways to notify users through email, IM, SMS, and voice
activities. The example in the slide implements email notification by adding and configuring an
email activity to the business process. At run time, these settings are passed in communication
with UMS.

BPEL: User Notification Activity
BPEL Process
Email
UMS
User
Notification
Activity
Activity

Voice
Configuration
SMS

IM
The user notification activity enables a BPEL process design in which a notification channel is
not explicitly specified during design time, and simply indicates that a notification must be sent.
The notification channel to be used is resolved at run time based on the user preferences
defined on the Notifications tab of the Worklist application, or in the User Messaging
Preferences user interface of Oracle UMS. Therefore, the responsibility of notification channel
selection is moved from Oracle BPEL Designer to the end user. If the end user has not selected
a preferred channel or rule, email is used by default.

User Notifications and Human Tasks
Human Email
UMS
Task

Voice
• Assign • Request Info • Resume

• Complete • Update Outcome • Update
• Error • Suspend • Alerted
• Expire • Withdraw • other SMS

Actions that Worklist
Application IM
can trigger a
Notification
Although not technically part of a human workflow, you can configure a human task to use
notifications. Notifications enable users to receive alerts about changes in the state of a task
during the task life cycle. You can specify that notifications should be sent to different types of
participants for different actions. For example, you can specify that:
• The owner of a task should receive a notification message when a task is in error (for
example, the task has been sent to a nonexistent user)
• A task assignee should receive a notification message when a task has been escalated
Notifications can be actionable, which enables users to respond.
The box in the lower-left of the slide lists the many actions that can be used to trigger a
notification.

Agenda
• Introduction to UMS
• Configuring UMS


UMS Message Channels and Drivers
WebLogic Domain
User Messaging Server

JMS
XMPP EMAIL SMPP Extension drivers

servers
Message channels are configured with drivers that handle the sending of messages to and
receiving of messages from devices that are associated with that type of channel through an
appropriate server or channel service provider.
The email channel is configurable out of the box. To configure additional UMS driver channels,
you deploy the driver JEE application EAR file and ensure that you have access to a service
provider for the type of channel driver deployed.

Relationship Between UMS and an Identity Service
The Identity Service

is responsible for:
UMS Identity • Authentication
Service • Authorization

• People resolution

User information is typically
stored in organizational
directories, such as an
LDAP directory.
The notification service typically works with an identity service, which is responsible for
resolving the set of users to whom the messages are delivered. The identity service is in
charge of the user-related features such as authentication, authorization, or people resolution.
User information is frequently stored in organizational directories, such as an LDAP directory or
a relational database. By default, the identity service uses the embedded LDAP server in
Oracle WebLogic Server as the default authentication provider. You can, however, use an
alternative authentication provider, such as Oracle Internet Directory or Microsoft Active
Directory, along with the default authenticator.

Deploying Drivers
By default, the email driver is already

deployed to WebLogic Server.
WebLogic Server
Voice

WLST
SMS EMAIL
Administrator IM

To deploy the others, you can deploy the drivers when creating or extending
the domain by using the Oracle Fusion Middleware Configuration Wizard.
You can also deploy additional drivers by using WLST commands
(recommended), Admin Console, or Oracle Enterprise Manager.
When you install Oracle SOA Suite 12c, the Oracle-supported UMS drivers (email, XMPP,
SMPP, and VoiceXML) are included as *.ear files. By default, the email driver is already
deployed to WebLogic Server. To deploy the others, you can deploy the drivers when creating
or extending the domain by using the Oracle Fusion Middleware Configuration Wizard. You can
also deploy additional drivers by using WLST commands (recommended), the Admin Console,
or Oracle Enterprise Manager. If you deploy drivers by using Enterprise Manager, you need to
use a Deployment Plan. Deployment Plan templates for supported drivers are supplied in
$ORACLE_HOME/communications/plans.
Note: The Worklist driver must be deployed to a SOA Server if you want to make use of the
UMS integration with Worklist. Because this integration involves multiple JEE applications and
a SOA composite, there is a special extension template that you must use to enable this feature
in one step.

Configuring UMS and UMS Drivers
The server and drivers can be

configured by using WLST or
Enterprise Manager.
Physical/Virtual Physical/Virtual
Server 1 Server 2

Node Node
Manager Manager
WLST Domain
Admin
Server
Administrator
Cluster

Configuration can be
defined at the domain level
or at the cluster level.
UMS is deployed as one enterprise archive for the server and one enterprise archive per driver
type. The configuration can be defined at the domain level or cluster level, where cluster level
overrides the domain level. It is possible to configure the server and drivers by using WebLogic
Scripting Tool (WLST) and Enterprise Manager (EM).
Cluster is the finest level of configuration that UMS supports. In other words, it is not possible to
specify Managed Server–specific configurations. It is assumed that all the Managed Servers in
a cluster are clones of each other containing the same driver deployments and configuration. If
no cluster exists in a domain, the same applies to deployments at the domain level. If a domain
contains at least one cluster containing UMS, it is mandatory to have all UMS deployments at
the cluster level in that domain. In such a case, deployment is supported only at the cluster
level. If UMS is deployed in a cluster, it is recommended to always create configuration at the
cluster level.

UMS drivers support only one configuration per instance, except for the Email driver (as of
12.1.3). You can create multiple configurations of a single deployment of the Email driver by
using a unique name in each configuration. This makes it possible to have one instance of the
Email driver configured differently in a domain without having to deploy several instances of
that driver.
Because UMS can be deployed in a cluster or a domain, the configuration of drivers can be
done at the cluster or domain level. It is recommended that the configuration be done at the
same level as that of the deployment. However, exceptional scenarios might justify creating
configuration at a level different from that of the deployment level.


Common Driver Properties
Common Properties
• Quality of Service WebLogic Server
• Driver Cost EMAIL
• Driver Speed

• Supported Carriers Voice
• Configuration Level
Administrator SMS
• Supported Protocols
IM
• Supported Delivery Types
• Supported Content Types

Developer
UMS drivers share common properties that are used by the Messaging Engine when routing
outbound messages. Typically, administrators set such Quality of Service (QoS) properties as
driver cost (Cost) and driver speed (Speed), supported carriers (SupportedCarriers),
configuration level, and supported protocols (SupportedProtocols). Driver developers configure
properties that typically do not require modification by the administrator, such as supported
delivery types (SupportedDeliveryTypes) and supported content types
(SupportedContentTypes). For detailed description of these properties, refer to
driverconfigpropertynames in User Messaging Service Java API Reference.

Monitoring Oracle User Messaging Service

You can monitor UMS logs and metrics by using Oracle Enterprise Manager Fusion
Middleware Control. To monitor UMS, perform the following steps:
1. Log in to Oracle Enterprise Manager as an administrator.
2. Expand the User Messaging Service folder. You see a User Messaging server, and a list
of User Messaging drivers.
3. Select the server or driver of your choice.
If you select a driver, quick statistics are displayed that indicate the state and performance of
the driver. If you select a server, you see a list of associated drivers, in addition to the quick
statistics. You can select one of the drivers to view its statistics, or you can click the Configure
Driver icon to configure it.

Viewing and Testing Email Notifications

3
You can monitor and view the notification activity performed by the human workflow service
engine. To view and test the human workflow notification activity, perform the following steps:
1. In Enterprise Manager, in the Target Navigation pane, expand the SOA folder and right-
click soa-infra.
2. In the context menu, select Service Engines > Human Workflow.
3. On the Human Workflow Engine page, click the Notification tab. You can examine any
notification messages in the Outgoing Notifications and Incoming Notifications sections. If
you click Send Test Notification, the Send Test Notification window is displayed.
4. In the Send Test Notification window, you can select the notification channel type to test
(provided that it has been configured) and send a message. In the example, the Email
channel is selected for the test.
Note: The test message mechanism uses BPEL notification activities to send test messages.
The messages that are sent appear in the list in the Outgoing Notifications section. The
example message in the Outgoing Notifications section is actually from the human task of a
composite application that is identified by the WORKFLOW value in the Source column.

Configuring User Preferences

User Communication Preferences (UCP) allows users who have access to multiple channels to
control how, when, and where they receive messages. Users define filters or delivery
preferences that specify which channel a message should be delivered to, and under what
circumstances. Information about a user’s channels and filters are stored in any database that
is supported for use with Oracle Fusion Middleware. Because preferences are stored in a
database, this information is shared across all instances of UCP in a domain.
UCP does not provide services for message delivery. Rather, it provides a user interface and
APIs to access and manage a user’s channels and delivery preferences. When a message is
addressed to a user, UMS acquires the user’s delivery preferences from UCP services and
sends the message according to the user’s preferences.
Note: The User Messaging Preferences UI is available at
http://host:port/sdpmessaging/userprefs-ui or https://host:sslport/sdpmessaging/userprefs-ui.

Workflow Notification Properties

3
In addition to configuring the workflow notification properties, configure the user messaging
email driver settings to ensure that the email server and protocol settings are correctly
specified. To access and configure the user messaging email driver settings, perform the
following steps:
1. On the Workflow Notification Properties page, click the “Go to the Messaging Driver page”
link. Alternatively, on the Enterprise Manager Control page, in the Target Navigation
pane, expand the User Messaging Service folder and click usermessagingserver
(soa_server1).
2. On the User Messaging Service page, click the Configure Driver icon in the User
Messaging Email Driver row entry.
3. On the User Messaging Email Driver page, enter the email driver properties and other
driver-specific configuration settings. These include mail protocols, such as Post Office
Protocol (POP3), the outgoing Simple Mail Transport Protocol (SMTP) server name, and
the incoming server name, among other settings. Click Apply.
4. After confirming the changes to be made, restart the WebLogic Managed Server (SOA
server) instance.

Configuring UMS Notification Properties
Changes require
a server restart.
1 3

Set notification mode and email
2 properties as appropriate.
The workflow notification services are communicated through Oracle UMS components.
To configure the workflow notification properties, use Enterprise Manager Fusion Middleware
Control and access the SOA Infrastructure page menu by performing the following steps:
1. In the Target Navigation pane, expand the SOA folder and right-click soa-infra.
2. In the context menu, select SOA Administration > Workflow Properties.
3. On the Workflow Notification Properties page, set the notification mode to All (or Email).
Set other email properties as appropriate to your email server configuration. Click Apply.
Note: After making changes to the workflow notification properties, you must restart the SOA
server.

Quiz Q
UMS configuration can be defined at the domain level, cluster
level, or at the Managed Server level.
a. True
b. False

Answer: b
False. Cluster is the finest level of configuration that UMS supports. It is not possible to
specify Managed Server–specific configuration. It is assumed that all Managed Servers in a
cluster are clones of each other, containing the same driver deployments and configuration.

Summary

• Explain how UMS is used by Oracle SOA Suite 12c
• Configure UMS message channels and drivers



• Practice 12-1: Configuring the Email Driver
– Seeding the LDAP Server
– Configuring the Email Driver
• Practice 12-2: Deploying the Composite Application

• Practice 12-3: Instantiating the Composite that Generates
Email
– Observing how Oracle SOA Suite uses UMS with a BPEL
Email activity and User Notification Services


13
Troubleshooting and
Performance Tuning of Oracle

SOA Suite 12c

Objectives

• Design a tuning methodology
• Identify top areas that require tuning
• Monitor and tune Oracle SOA Suite by collecting performance

information and by using diagnostic tools
• Configure selective tracing
• Troubleshoot common problems:
– Managed Server startup problems

– Message failure caused by too many open files
– Connection timeouts
– Application-related problems

Agenda
• Tuning methodology: Overview

• Tools for monitoring Oracle Fusion Middleware environments
• Monitoring and tuning with Oracle SOA Suite
• Troubleshooting common problems


Performance Tuning: Overview
Performance tuning is an iterative process, where you:

• Set performance goals as measurable objectives
• Monitor environment (best done during peak periods) to
obtain a baseline

• Tune based on data collected from monitoring tasks and tools
• Check results, and repeat setting goals, monitoring, tuning,
and check cycle as needed
Start here

Set targets Monitor
Check results Tune
A performance methodology requires planning to obtain any benefit from actual tuning tasks.
Oracle Fusion Middleware components are built for performance and scalability. To maximize
the performance capabilities of your applications, you must build performance and scalability
into your design. The performance plan should address current performance requirements,
existing issues (such as bottlenecks or insufficient hardware resources), and any anticipated
variances in load, users, or processes. The performance plan should also address how the
components would scale during peak usage without impacting performance.
The following areas create a plan for tuning your application environment and optimize
performance:
• Define performance objectives: This requires understanding user and organizational
goals and targets.
• Design applications for performance and scalability: Though this is not an
administrative task, an administrator can provide guidance to developers with
information about the resources and constraints that influence application design
decisions.
• Monitor and measure performance metrics: This is the main topic of this lesson and
this is where administrators play a part in this process, although developers also have
their parts to play with regard to application performance.

Top Performance Tuning Areas
• Hardware resources
• Operating system
• Java Virtual Machine (JVM)
• Database

• WebLogic Server
• Database connections and data source statement caching
• Concurrency of Fusion Middleware components
• Logging levels

Note: Tune the lowest level first, such as the hardware
resources, then the operating system, and then additional
layers as required. Always tune the foundation layers first.
Hardware resources: Sufficient CPU, memory, and network resources to support user and
application requirements are of primary importance. No matter how well you tune your
applications, without appropriate hardware resources, applications cannot reach optimal
performance. Check Oracle Fusion Middleware documentation for minimum hardware
requirements.
Operating system: Provide native tools and utilities for monitoring and tuning purposes, and
have commands for monitoring CPU utilization, paging activity, swapping, and other system
activity information. Consult the operating system documentation for more information.
Java Virtual Machine (JVM): How you tune your Java Virtual Machine (JVM) greatly affects
the performance of Oracle Fusion Middleware and your applications.
Database: Monitoring and tuning the database ensures that you get the best performance
from your applications. Areas to tune include database parameters, database files, and
Automatic Segment Space Management (ASSM). This information is provided in detail in the
Oracle Database Administration documentation.
WebLogic Server: Oracle Fusion Middleware applications that run on WebLogic Server can
benefit from tuning the performance of Oracle WebLogic Server. Refer to the Oracle
WebLogic Server documentation for more details.

Database connections and statement caching: Database connection creation can be
resource intensive. To avoid connection creation delay, configure JDBC resources to initialize
a suitable number of connections (depending on expected workload) at server startup, instead
of relying on creating connections on demand.
A data source connection has a cache of prepared and callable statements that are used with
the connection. Statement cache options can be configured for each data source. Statement
cache configuration options include Statement Cache Type and Statement Cache Size
settings.
Concurrency: Limiting concurrency at multiple layers to match specific usage needs can
improve performance. For example, when system capacity is reached, and a web server or
application server continues accepting requests, application performance and stability can

deteriorate.
For the web tier, if you are use Oracle HTTP Server, directives in the httpd.conf
configuration file can be set to manage the maximum number of HTTP requests that are
processed simultaneously, logging details, and certain limits and timeouts. In addition to
configuring the web tier server connection limits, the application tier provides configuration

options to manage connection pools, and the thread pool for tuning the WebLogic Server
instances.
Logging levels: The volume of information logged by applications depends on the log
configuration and how application code is instrumented for logging. To maximize
performance, logging level should not be higher than the (default) INFO level logging. For
production systems, ensure that debugging properties and other application-level debugging
flags are configured appropriately or disabled. You can avoid performance impacts by
minimizing use of log levels such as FINE or TRACE, which produce more diagnostic data.
However, log level may need to be altered temporarily to produce more information for
troubleshooting various conditions.

Agenda



Monitoring and Diagnostic Tools: Overview
Oracle Fusion Middleware management tools include:

• Oracle Enterprise Manager Fusion Middleware Control
• Oracle WebLogic Server Administration Console
• Oracle Fusion Middleware Diagnostic Framework, which

integrates with the WebLogic Diagnostic Framework (WLDF)
• WebLogic Scripting Tool (WLST)
• DMS Spy Servlet for access to the Dynamic Monitoring
Service (DMS)

Monitoring is an important step in performance tuning and enables you to evaluate server
activity, watch trends, diagnose system bottlenecks, debug applications with performance
problems, and gather data that can assist you in tuning the system. Oracle Fusion Middleware
management tools for monitoring and diagnostics include:
• Oracle WebLogic Server Administration Console
• Oracle Fusion Middleware Diagnostics Framework, which integrates with WebLogic
Diagnostics Framework (WLDF), is a monitoring and diagnostic framework that collects
diagnostic data generated by servers and applications. WLDF can be configured to
collect data, such as log records, data events, and harvested metrics, and store it in
various locations.
• WebLogic Scripting Tool (WLST)
• DMS Spy Servlet, which is part of the DMS web application, and deployed by default as
part of a JRF-enabled server instance with the DMS web application’s dms.war (web
archive file). For example, the URL to access DMS Spy is:
http://admin.example.com:8080/dms/Spy.
Note: Only users with the Administrator role can access can this URL.
In addition to the preceding tools, the operating system that is being used provides its own
native commands and network tools for performance monitoring and tuning. The operating
system tools are not discussed in this course.
Monitoring with Oracle Enterprise Manager Fusion
Middleware Control
Oracle Enterprise Manager Fusion Middleware Control provides
the capability to monitor:
• The state and performance of each element of the farm by
providing default performance metrics
• CPU usage, Work Manager, JMS servers, and JDBC and JTA

usage for Oracle WebLogic Server
• JVM performance in terms of heap versus non-heap usage,
garbage collection, and threads performance
• Deployed composite applications and web services

• Servlets, JSPs, and EJBs by using a wide range of application
metrics , as well as faults, invocations, and violations by using
web services metrics
Note: The performance summary page can be customized to
help administrators monitor performance and diagnose problems.
Oracle Enterprise Manager Fusion Middleware Control organizes a wide variety of

performance data and administrative functions into distinct, web-based home pages for the
farm, domain, servers, components, and applications. The Fusion Middleware Control home
pages make it easy to locate the most important monitoring data and the most commonly
used administrative functions, all from your web browser.
In addition, Oracle Enterprise Manager Fusion Middleware Control provides a set of MBean
browsers that allow you to browse the MBeans for a WebLogic Server, or for a selected
application, and perform specific monitoring and configuration tasks from the MBean browser.

Oracle Fusion Middleware Diagnostic Framework
Oracle Fusion Middleware Diagnostic Framework aids in

detecting, diagnosing, and resolving targeted problems, and
integrates with the WebLogic Diagnostic Framework (WLDF).

Diagnostic
data
Log files Dumps

Command-line
utilities
Automatic Diagnostic Repository (ADR)
WebLogic Diagnostic Framework (WLDF) is a monitoring and diagnostic framework that

defines and implements a set of services that run within WebLogic Server processes and their
standard server life cycle. WLDF can be used to create, collect, analyze, archive, and access
diagnostic data that is generated by a running server and the deployed applications. The data
that is collected provides insight into the runtime performance of servers and applications, and
provides information for isolating and diagnosing faults when they occur.
Oracle Fusion Middleware includes a Diagnostic Framework for detecting and diagnosing
problems that identify critical errors caused by code bugs, metadata corruption, customer data
corruption, deadlocked threads, and inconsistent states.
When a critical error occurs, it is assigned an incident number and diagnostic data for the
error (such as log files, thread dumps) is immediately captured and tagged with this number.
The data is then stored in the Automatic Diagnostic Repository (ADR), from where it can later
be retrieved by incident number and analyzed. The Automatic Diagnostic Repository (ADR) is
a file-based hierarchical repository for Oracle Fusion Middleware diagnostic data, such as
traces and dumps. The data collected is accessible through command-line utilities.

In addition to capturing WebLogic Server images on detection of critical errors, Oracle Fusion
Middleware Diagnostic Framework integrates with the following features of WebLogic
Diagnostic Framework (WLDF):
• Creates incidents by using the WLDF Watch and Notification component, which watches
specific logs and metrics for specified conditions, and sends a notification when a
condition is met. There are several types of notifications, including JMX notification and
a notification to create a Diagnostic Image.
• Writes the server state (packaging it) into a single artifact, called a Diagnostic Image, to
the ADR. The WLDF Diagnostic Image Capture mechanism gathers the most common
sources of the key server states used in diagnosing problems.


Oracle Dynamic Monitoring Service and Architecture
The Oracle Dynamic Monitoring Service (DMS) provides data

about component performance, state, and ongoing behavior.
Managed Server
Component WLDF diagnostic
(SOA Suite) image MBean

2 Log messages
9
Oracle Diagnostics
8 Write
5 Log (ODL) log handler
Invoke
Log file
Write 3 Filter

Diagnostics
Incident detection log filter
rules
1 4
6 Execute 6 Execute Create Automatic
Register
incident Diagnostic
Application dump Component dump Repository
(ADR)
7 Write
The Oracle Dynamic Monitoring Service (DMS) provides data about component performance,
state, and ongoing behavior to administration tools. Components push data to DMS, which in
turn publishes that data through a range of different mechanisms.
DMS measures and reports metrics, trace events, and system performance, and provides a
context correlation service for these components.
The Diagnostic Framework is active in each server and provides automatic error detection
through predefined configured rules. Incidents are automatically detected in two ways:
• By the incident detection log filter, which is automatically configured to detect critical
errors
• By the WLDF Watch and Notification component. The Diagnostics Framework listens for
a predefined notification type and creates incidents when it receives such notifications.
Note: Some components create incidents directly through programmatic (API) incident
creation functionality. Regardless of the source of an incident, Oracle Fusion Middleware
components and applications automatically benefit from the DMS, which is always enabled.
The steps that are represented in the architecture diagram are listed on the next page.

1. The incident detection log filter is initialized with component and application diagnostic
rules.
2. An application or component logs a message by using the java.util.logging API.
3. The ODL log handler passes the message to the incident detection log filter.
4. The incident log detection filter inspects the log message to see if an incident should be
created, basing its decision on the diagnostic rules for the component. If the diagnostic
rule indicates that an incident should be created, it creates an incident in ADR.
5. The ODL log handler writes the log message to the log file, and returns control to the
application. An example of a log message that is written to the log file is:
[2014-03-28T11:05:34.603-07:00] [wls_server_1] [NOTIFICATION]

[DFW-40101] [oracle.dfw.incident] [tid: [ACTIVE].ExecuteThread:
'4' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId:
weblogic] [ecid: 66217af9-247f-4344-94a9-14f90e75a586-
000e093f,0] An incident has been signalled with the incident
facts: [problemKey=MDS-50500 [MANUAL] incidentSource=MANUAL
incidentTime=Fri March 28 11:05:34 PDT 2014 errorMessage=MDS-

50500 executionContextId=null]
6. The Diagnostic Framework executes the diagnostic dumps that are indicated by the
diagnostic rules for the component.
7. The Diagnostic Framework writes the dumps to ADR, in the directory created for the
incident.
8. The Diagnostic Framework invokes the WLDF Diagnostic Image MBean requesting that
a Diagnostic Image be created in ADR.
9. WLDF writes the Diagnostic Image to ADR.

WLDF Watch and Notification Component
Oracle Fusion Middleware Diagnostic Framework registers a

notification listener, which listens for events from the WLDF
Watch and Notification system.
Managed Server
Watch WLDF diagnostic

Notification image MBean
2 3 7 8
Register Notify Invoke Write
Diagnostics
Incident notification listener

rules
1 4
5 Execute 5 Execute Create Automatic
Register
incident Diagnostic
Application dump Component dump Repository
(ADR)
6 Write
The information flow in architecture diagram flow shown in the slide is as follows:
1. The incident notification listener is initialized with component and application diagnostic
rules.
2. Oracle Fusion Middleware Diagnostic Framework registers a JMX notification listener,
which listens for events from the WLDF Watch and Notification system. It processes
only notifications of type oracle.dfw.wldfnotification.
3. An event in the system causes the configured WLDF watch to be triggered, and a
notification is sent to the incident notification listener. The notification includes event
information describing the data that caused the watch to trigger.
4. The Diagnostic Framework creates an incident in ADR.
5. The Diagnostic Framework executes the diagnostic dumps that are indicated by the
diagnostic rules.
6. The Diagnostic Framework writes the dumps to ADR, in the directory created for the
incident.
7. The Diagnostic Framework invokes the WLDF Diagnostic Image MBean requesting that
a Diagnostic Image be created in ADR.
8. WLDF writes the Diagnostic Image to ADR.
Note: Configuring the WLDF Watch and Notification settings is done through the Oracle
WebLogic Administration Server Console interface.

Configuring Diagnostic Framework Settings
The Diagnostic Framework MBean, called DiagnosticConfig, is

used to enable or disable:
• Detection of incidents through the log files
• Flood control and its parameter settings

The slide shows the steps in Oracle Enterprise Manager Fusion Middleware Control for using
the System MBean browser to locatethe DiagnosticFrameworkMBean, whose ObjectName is
oracle.dfw:type=oracle.dfw.jmx.DiagnosticsConfigMBean,name=Diagnosti
csConfig, where you can configure several parameters, such as:
• floodControlEnabled: When set to true (the default value), enables flood control.
A value of false disables the function.
Note: Flood control does not apply to manually created incidents.
• floodControlIncidentCount: Sets the number of incidents with the same problem
key that can be created within the time period specified by
floodControlIncidentTimeoutPeriod, before they are controlled by flood
control. The default is 5.
• floodControlIncidentTimeoutPeriod: Sets the time period in which the
number of incidents with the same problem key can be created before they are
controlled by flood control. The default is 60 minutes.
• incidentCreationEnabled: Is enabled when the value is true (the default).
false disables it.

• logDetectionEnabled: Enables or disables detection of incidents through log files.
Specify true for enabled or false for disabled. The default is true.
Refer to the Oracle Fusion Middleware Administering Oracle Fusion Middleware
documentation for more details.


Viewing DMS Metrics
DMS metrics can be viewed with:

• The Spy Servlet
• Other tools

DMS metrics can be viewed with the following tools:

• The Spy Servlet
• Other tools, such as:
- WebLogic Diagnostic Framework (WLDF)
- WLST
- JConsole
Note: The next few pages discuss how to access the metrics by using Oracle Enterprise
Manager Fusion Middleware Control and the Spy Servlet tools.

Viewing Metrics with Oracle Enterprise Manager Fusion
Middleware Control
Fusion Middleware Control provides:
• A Routing Topology Viewer for the domain and related metrics
• Performance monitoring and metrics for different components

a2 b2
a1
b1

a3
b3
The slide shows the steps to open two of the means that are available for viewing metrics in
Oracle Enterprise Manager Fusion Middleware Control:
a. On the left of the slide, you can use the Routing Topology viewer. To open the Routing
Topology viewer, perform the following steps:
1. Click the domain name in the Target Navigation pane to open the domain home
page.
2. On the domain home page, click WebLogic Domain > Routing Topology to open
the viewer page, which requires the flash plug-in to be installed for your web
browser.
3. On the Routing Topology page, click items to view metrics for specific
components.
b. On the right of the slide, for example, to view the performance and metrics for the
AdminServer WebLogic Server instance, perform the following steps:
1. In the Target Navigation pane, click the AdminServer entry (below the WebLogic
Domain node in the tree) to open the AdminServer page.
2. On the AdminServer page, click WebLogic Server > Monitoring > Performance
Summary.
3. On the Performance Summary page, you can click Show Metric Palette to control
which metrics are displayed.

Viewing Metrics with the Spy Servlet

The example in the slide shows how to view JDBC Connection metrics by using the DMS Spy
Servlet and performing the following steps:
1. In a web browser, enter the URL admin.example.com:8080/dms/Spy.
2. Log in as the WebLogic administrator user.
3. The DMS Spy Servlet provides several Metrics Tables categorized by DMS Metrics,
WebLogic Metrics, and Aggregated Metrics. In the example, the DMS Metrics category
is used, and the JDBC Connection link is clicked.
4. The JDBC_Connection page is opened and displays metrics for all JDBC connections
configured in the servers.

Agenda



Monitoring the Java Virtual Machine Performance
To monitor Java Virtual Machine (JVM) performance, select one

of the server instances (AdminServer or Managed Servers), and
click WebLogic Server > Monitoring > JVM Performance.

How you tune your JVM greatly affects the performance of Oracle SOA Suite and your
applications.
Garbage collection is the JVM process of freeing up unused Java objects in the Java heap.
JVM garbage collection can be a resource-intensive operation and may affect application
performance. In some cases, inefficient garbage collection can severely degrade application
performance. Therefore, it is important to monitor garbage collection.
An acceptable rate for garbage collection is application-specific, and should be adjusted after
analyzing the actual time and frequency of garbage collections. To tune the JVM garbage
collection options, you must monitor and analyze garbage collection data and check for the
frequency and type of garbage collections, the size of the memory pools, and the time spent
on garbage collection.
At the bottom of the slide, you see information about Threads executing in the JVM. This
information can be useful for monitoring Thread metrics to help you to decide on settings for
threading properties.

Tuning a Java Virtual Machine Memory
• Tuning heap size to minimize JVM garbage collection, while

maximizing the number of SOA clients at a given time:
– Ensuring that the sum of (maximum heap size multiplied by
number of JVMs) is less than the physical memory (RAM)
– Increasing the minimum size of the dynamic heap (the –Xms

option), if out of heap memory (not due to memory leakage)
– Decreasing maximum size of the memory pool (the –Xmx
option), if out of native memory
• Selecting an appropriate garbage collection scheme

Tip: A general rule is to set minimum heap size (-Xms) equal
to the maximum memory pool size (-Xmx) to minimize
garbage collection processing.
Java heap is where the objects of a Java program reside. It is a repository for live objects,
dead objects, and free memory. When an object can no longer be reached from any pointer in
the running program, it is considered “garbage” and ready for collection. A best practice is to
tune the time spent doing garbage collection to within 5% of execution time.
The JVM heap size determines how often and how long the virtual machine spends collecting
garbage. An acceptable rate for garbage collection is application-specific, and should be
adjusted after analyzing the actual time and frequency of garbage collection. If you set a large
heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap
size in accordance with your memory needs, full garbage collection is faster, but occurs more
frequently.
Depending on which JVM you are using, you can choose from several garbage collection
schemes to manage your system memory. Some garbage collection schemes are more
appropriate for a given type of application. After you have a quantitative understanding of the
workload of the application and the different garbage collection algorithms utilized by the
JVM, you can optimize the configuration of the garbage collection.

Monitoring and Tuning the Database Size
Monitoring database performance is a task for the database

administrator, who can perform some of the following tasks:
• Collecting schema statistics for MDS schemas
• Increasing redo log size
• Reclaiming disk space, such as purging data in the SOAINFRA

and MDS schemas
Note: Use automatic purging configuration or supplied PL/SQL
scripts for purging SOA instance data.

The slide lists some of the recommended actions that can be taken to monitor (measure) and
tune the database repository, including the MDS schemas. The default Metadata Store (MDS)
configuration must be tuned in almost all deployments. For optimal performance of MDS APIs,
the database schema for the MDS repository must be monitored and tuned by the database
administrator.
Collecting Schema Statistics: MDS database indexes may not be used as expected due to
lack of schema statistics. A database administrator can enable statistics collection for a
database schema to assist with improving performance for MDS operations, such as
accessing or updating metadata in the database repository, to ensure that the statistics are
available and current.
Increasing Redo Log Size: Redo log file size can influence performance due to the
database writer and archiver processes depending on the redo log sizes. In generally, larger
redo log files provide better performance, whereas small redo log files increase checkpoint
activity, which can reduce performance.
Reclaiming Disk Space: Although manual and auto-purge operations delete the metadata
content from the repository, the database may not immediately reclaim the space held by
tables and indexes, resulting in the disk space being consumed by a growing MDS schema.
Database administrators can manually rebuild the indexes and shrink the tables to increase
performance and to reclaim disk space.
For more information, see the section titled “Generating Automatic Workload Repository
Reports” in the Oracle Database Performance Tuning Guide.

Tuning the Oracle Database
• Tuning the database initialization parameters in the
init.ora file:
– Processes
SQL> SELECT value FROM v$parameter WHERE name = 'processes';
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE;
– Buffer pool size

• Using Automatic Segment Space Management (ASSM) for
permanent tablespaces
• Extending tablespaces early to avoid problems at run time

• Managing database growth by purging data with either
of the following:
– Auto purging in Oracle SOA Suite 12c
– Manual purge scripts that run PL/SQL
procedures loaded into the SOAINFRA
database schema
To achieve optimal performance for applications that use the Oracle database, the database
tables that you access must be designed with performance in mind. Monitoring and tuning the
database ensures that you get the best performance from your applications. The following list
gives some of the Oracle database parameters that can be configured in the init.ora file
by using SQL commands similar to those shown in the slide:
• Number of processes: On most operating systems, each connection to the Oracle
server spawns a shadow process to service the connection. Thus, the maximum number
of processes allowed for the Oracle server must account for the number of simultaneous
users, as well as the number of background processes used by the Oracle server.
• Buffer pool size: The buffer pool usually is the largest part of the Oracle server system
global area (SGA). This is the location where the Oracle server caches data that it has
read from disk.
• Shared pool size: The shared pool is an important part of the Oracle server system
global area (SGA). The SGA is a group of shared memory structures that contain data
and control information for one Oracle database instance.
• Maximum opened cursor: To prevent any single connection from taking all the
resources in the Oracle server, the OPEN_CURSORS initialization parameter allows
administrators to limit the maximum number of opened cursors for each connection.

Using Automatic Segment Space Management (ASSM)
For permanent tablespaces, consider using Automatic Segment Space Management. Such
tablespaces, often referred to as bitmap tablespaces, are locally managed tablespaces with
bitmap segment space management. For backward compatibility, the default local tablespace
segment space management mode is MANUAL.
Managing Database Growth
Over time (either quickly or slowly), depending on the number and frequency of application
instances that are created, the amount of data in the Oracle SOA Suite database (SOAINFRA
schema) can grow very large. Maintaining the database can become difficult and performance
of the system can degrade.

With the release of Oracle SOA Suite 12c, purging instance data can be automated by
configuring the automatic purging parameters. In addition, you can also install the purge
PL/SQL procedures in the SOAINFRA schema by running the soa_purge_scripts.sql
SQL script in the
MW_HOME/soa/common/sql/soainfra/sql/oracle/121300/soa_purge folder.
Note: The MW_HOME/soa/common/sql/soainfra/sql folder contains different versions

of these scripts depending on the database and version that are being used for the database
schemas. The PL/SQL scripts can purge (delete) large amounts of instance information. A
sample code can be found in the README file that is located in the same folder as the
soa_purge_scripts.sql script or you can use the examples shown in the Oracle Fusion
Middleware Administering Oracle SOA Suite and Oracle Business Process Management
Suite documentation.

Extending Tablespaces to Avoid
Problems at Run Time
If a tablespace is not extended when it reaches its size limit,
runtime processing will be impacted.
Solutions:
• Enable autoextend for the tablespace.

• Manually increase the tablespace size if you receive an alert.

If the database tablespace is not extended, runtime processing can be impacted. Messages
are not processed or persisted, and exception errors similar to the following can appear in the
log files. In this example, the reason is that Oracle BPEL Process Manager relies on the
database to store instance data. If the database is not available, runtime processing is
negatively impacted.
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 EDG_SOAINFRA.SYS_LOB0000145067C00007$$ by 1024 in
tablespace EDG_SOAINFRA
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.

Configuring Database Connections
Consider the following data source configurations when

performance is an issue:
• Ensure that the connection pool has enough free connections.
• Statement caching can eliminate potential performance
impacts.

• Disable unnecessary connection testing and profiling.

Consider the following data source configurations when performance is an issue:

• When configuring the data source, ensure that the connection pool has enough free
connections.
• Statement caching can eliminate potential performance impacts caused by repeated
cursor creation and repeated statement parsing and creation. Statement caching also
reduces the performance impact of communication between the application server and
the database server.
• Disable unnecessary connection testing and profiling.

Developing a Strategy for Managing Database Size
Three main strategies for reducing database schema size are:

• Purging SOA Suite instance data regularly:
– Automatically by using the auto purge functionality
– Manually by running PL/SQL purge procedures from SQL*Plus
• Partitioning database tables (automatically enabled when you

extend the domain with SOA Suite and select the LARGE
option for database size)

To develop a strategy for managing database size due to table growth requires an action plan
that implements purging and partitioning techniques for the dehydration store (SOA runtime
database data). 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.
In the first two strategies listed in the slide, the same purge script is used. However, if you are
partitioning, edit the purge script and comment out your partitioned 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.
To help decide if partitioning is required, first obtain a profile of the input messages flowing
through the system, the database growth rate as a result of the message flow, and the
amount of data that is purged in the purge process. If the input rate and purge rate match,
regular purging is sufficient. Otherwise, consider partitioning.
When using partitioning, 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.

Automatically Purging Instance Data
From the SOA folder in the Navigator, right-click soa-infra and

select SOA Administration > Auto Purge.

In Oracle Enterprise Manager Fusion Middleware Control, there are different ways to access
the Auto Purge configuration page. The slide lists one of those navigation paths, where you
right-click the soa-infra (server_name) node in the Target Navigation pane and select SOA
Administration > Auto Purge.
The Auto Purge Job provides the following two predefined database purge jobs:
• delete_instances_auto_job1: Runs on a schedule that is appropriate for weekdays
(Monday through Friday at midnight). This job is automatically enabled.
• delete_instances_auto_job2: Runs on a weekend schedule (Saturday and Sunday) that
may be more aggressive. This job is not automatically enabled.
Note: To 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, unsaved changes for
the selected job are lost.
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 12.1.3 installations, but not for
upgraded environments.

Monitoring the SOA Infrastructure Performance and
Metrics Data

You can monitor the overall status of SOA Infrastructure or an individual partition from the
Dashboard pages, which provide information such as:
• The overall health of the SOA run time, including any faults
• The health of deployed applications and adapter endpoints, including any problems
since the system was restarted or when applications were deployed or upgraded
• The health of the business transactions, including any related faults
• The key events that occurred in the system in the last operating time range (for
example, 24 hours)
To access the SOA Infrastructure page, in the Target Navigation pane, expand the SOA
folder and click soa-infra (soa_server1) or any soa-infra (server_name) entry for a clustered
configuration. From the SOA Infrastructure page, you can assess the Performance Summary
page by clicking SOA Infrastructure > Monitoring > Performance Summary.
On the Performance Summary page, you can click Show Metric Palette to display a
navigation tree that allows you to focus on specific metric information.
Note: You can select the SOA Infrastructure > Monitoring > Request Processing menu option
to view information about request statistics and processing times for the various SOA service
engines, the service infrastructure, and binding components.

Tuning SOA Infrastructure
SOA Infrastructure:
• Is a Java EE-compliant application that manages composites
and their life cycle, service engines, and binding components
• Provides essential tuning parameters for:
– Audit Level (default value: Production), which is managed from

the SOA Administration > Common Properties settings page
– Audit Purge Policy (default: everyday midnight and purges
records older than 7 days), which is managed from the SOA
Administration > Auto Purge properties page

• Uses Work Managers to manage most SOA-related work
threads
• Manages the Modularity Profile via SOA Administration >
Common Properties page
The SOA Infrastructure configuration parameters impact the entire SOA Infrastructure. The
following configurations have an impact on SOA performance:
• Audit Level: Production level is optimal for most normal production operations;
Development level enables tracking both composite instance and payload detail.
However, the Development setting may negatively impact performance.
• Audit Purge Policy: The problems managed by this setting are exponential growth in
database size, and minimizing resources taken from other processes for the purging
process. This is a balance between how often and when to perform purges (to manage
system load) and managing volume and duration of retaining audit information.
Other factors that can influence SOA Infrastructure performance because they apply to all
applications across all partitions, include:
• Payload validation of incoming messages. When enabled, incoming and outgoing XML
documents are validated against their XML schemas. This can cause extra processing
overhead for the application and add load to the system.
• Logging Level: The default logging level is NOTIFICATION. For stress testing and
production environments, consider using the lowest acceptable logging level, such as
ERROR or WARNING whenever possible.

Beginning with the Oracle SOA Suite 12c (12.1.3) release:
• WebLogic Work Managers are used to handle most SOA-related work threads. The next
few pages provide an introduction to Work Managers and the thread management
parameters.
• Modularity Profile has been added to help improve your memory footprint and server
startup times. Profile options are designed to provide a footprint based on the type of
components and features used by selected composite applications. The Modularity
Profile selected determines what components will be loaded in memory. By default, new
Oracle SOA Suite 12c installations use the SOA_FOUNDATION profile. If upgrading
from Oracle SOA Suite 11g to Oracle SOA Suite 12c, SOA_CLASSIC is selected as the
default profile. Some Modularity Profiles that are designed for the associated

components are:
- BPEL-ONLY: This is for an environment that is designed to support BPEL
components, the SOA common infrastructure , and a partial adapter set.
- ORCHESTRATION: This includes BPEL-Only and Human Workflow.
- SOA FOUNDATION (default for new 12c installations): This includes the

ORCHESTRATION profile, Mediator, and Business Rules.
- SOA FOUNDATION ENTERPRISE: This includes the SOA FOUNDATION profile
and a full adapter set.
Note: The SOA CLASSIC profile includes SOA FOUNDATION with B2B and BPM
modules. For more information, refer to the section titled “Changing Modularity Profiles”
in the Oracle Fusion Middleware Tuning Performance Guide documentation.

Work Managers and Work Manager Groups
• A Work Manager is an Oracle WebLogic Server entity that

represents a logical thread pool.
• A Work Manager assigns priorities for the work to be
processed by defining one or more of the following
components: Work Manager

– Fair Share Request Class
Work Manager Components
– Response Time Request Class
Request Class
– Min Threads Constraint
Thread Constraint
– Max Threads Constraint

– Capacity Constraint
Capacity Constraint
– Context Request Class Configures
• A Work Manager Group consists of Work Managers dedicated

to processing Oracle SOA Suite work for a specific partition.
Starting with Oracle WebLogic Server 12c, a thread pool is used for execution of all types of
work, which is prioritized based on the rules you define, the runtime metrics, the actual time it
takes to execute a request, and the rate at which requests are entering and leaving the pool.
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.
Note: A thread pool is similar to a queue of work items lined up for processing. Work requests
from all Work Managers are executed by a single thread pool; separate thread pools are not
created for each Work Manager. The Work Manager components are called a Request Class
or Constraint, which define the characteristics of how the Work Manager utilizes the thread
pool. 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 workload
A Work Manager Group consists of one or more Work Managers dedicated to processing
Oracle SOA Suite background work for a given partition. For more information, see the slide
titled “Configuring Work Managers for SOA Applications.”

To manage work in your applications, you define one or more of the following Work Manager
components:
• Fair Share Request Class
• Response Time Request Class
• Min Threads Constraint
• Max Threads Constraint
• Capacity Constraint
• Context Request Class
The preceding components fall into the following two categories:
• Request classes: Define the percentage of server resources to share and the

application response time
- Fair Share Request Class: Specifies the average thread-use time required to
process requests. The default fair share value is 50.
- Response Time Request Class: Specifies a response time goal in milliseconds
- Context Request Class: Assigns request classes to requests based on context

information, such as the current user or the current user’s group
• Constraints: Define the minimum (default 0) and maximum (default unlimited) thread
constraints, and a capacity beyond which requests are rejected
- Max Threads Constraint: Limits the number of concurrent threads executing
requests from the constrained work set. The default is unlimited.
- Min Threads Constraint: Guarantees the number of threads that the server will
allocate to affected requests to avoid deadlocks. The default is zero.
- Capacity: Causes the server to reject requests only when it has reached its
capacity. The default is -1. Note that capacity includes all requests, queued or
executing, from the constrained work set. Work is rejected either when an
individual capacity threshold is exceeded or if the global capacity is exceeded.
This constraint is independent of the global queue threshold.
Note: In response to stuck threads, you can define a Stuck Thread Work Manager component
that can shut down the Work Manager, move the application into admin mode, or mark the
server instance as failed.
WebLogic Server maintains three groups of threads for the self-tuning thread pool:
• Running threads: Threads that are currently executing work requests submitted to
Work Managers
• Idle threads: Threads that are idly waiting for a work request
• Standby threads: Threads that are not currently processing or waiting for work
requests
For more information about Work Managers, refer to the section titled “Using Work Managers
to Optimize Scheduled Work” in the Oracle Fusion Middleware Administering Server
Environments for Oracle WebLogic Server documentation.

Work Managers Types
Three types of Work Managers are provided that are

characterized by its scope, its definition, and how it is used:
• Default Work Manager
• Global Work Manager

• Application-scoped Work Manager
Note: Configuration of Work Managers can be done through the
WebLogic Server Administration Console.
WebLogic Server

Thread pool
High Share Medium Share Low Share Work

Console Queue Queue Queue Managers
Work requests from all Work Managers are executed by a single thread pool; separate thread
pools are not created for each Work Manager. The three types of Work Managers provided
are:
• The Default Work Manager is designed to handle thread management and perform self-
tuning. The default Work Manager may be sufficient for most application requirements,
because the thread-handling algorithms assign each application a fair share by default,
and applications are given equal priority for threads and are prevented from
monopolizing them.
Note: You can override the behavior of the default Work Manager by creating and
configuring a global Work Manager called default. This allows you to control the default
thread-handling behavior of WebLogic Server.
• Global Work Managers are available to all applications and modules deployed on a
server, in the WebLogic Server Administration Console and config.xml. An
application uses a globally-defined Work Manager as a template.

• Application-scoped Work Managers can be created specific to an application or a
module, and can be defined through the WebLogic Server Administration Console and
in the following descriptors:
- weblogic-application.xml
- weblogic-ejb-jar.xml for EJBs
- weblogic.xml for a web application
Note: Applications not explicitly assigned a Work Manager use the default Work Manager.


Managing Work Manager Component Configuration
Configure Work Manager components in the

Oracle WebLogic Administration Console.

In the Oracle WebLogic Administration Console web application, to create and configure
Work Managers, request classes, and constraints, perform the following steps:
1. In the Domain Structure pane, expand Environment and click Work Managers.
2. On the Summary of Work Managers page, click New to create a new Work Manager
component, such as a Work Manager, Request Class, or Constraint (Maximum Threads
Constraint, Minimum Thread Constraint, among others).
Note: Alternatively, click the Name link of an existing Work Manager component, such
as the default_bpmnInvoke Work Manager instance, to update the configuration
properties and targets.
3. On the Settings for <name of Work Manager, Request Class, or Constraint> page,
configure the settings on the Configuration subtab page.
Note: Because a Work Manager consists of a Request Class and Constraints, those
types of components should be created before configuring them as values for a Work
Manager instance.
Note: When you create an Oracle WebLogic domain with Oracle SOA Suite, a default set of
Work Managers, Request Classes, and Constraints is configured and used by the Oracle
SOA Suite servers and composite applications that run in the default partition.

Work Managers Groups and SOA Partitions
• A Work Manager Group:

– Is a SOA concept that defines a group of Work Managers
– Is associated with one or more SOA partitions
• A SOA partition is:
– A way to groups applications for providing metadata isolation

and optional thread isolation
– Associated with one and only one Work Manager Group
Service Engine thread pool
Partitions Work Manager (assigned to one Work Manager)

Group
default Work Manager 1
Standard
Work Manager 2
HR
:
Work Manager n
Sales High Priority
A Work Manager Group consists of Work Managers dedicated to processing Oracle SOA
Suite background work for a given partition. Work Manager Groups isolate partition
configuration and request processing. Multiple partitions can share a single Work Manager
Group. A Work Manager Group consists of all the logical thread pools, which are utilized for
background processing tasks in a given partition.
In the slide example:
• The default and HR partitions are associated with a standard Work Manager Group
• The sales partition is associated with a high priority Work Manager Group

SOA Work Manager Examples
• Some non-partition Work Managers are:

Work Manager Name Constraint Name Description
SOA_Default_WM None The default Work Manager for all SOA
services that do not access the soa data
source such as Case Management
SOA_Notification_WM SOAInternalProcessing_maxThreads Notification MDB

SOA_Request_WM SOA_Request_WM_minThreads_1 Work Manager to handle SOA synchronous
SOAIncomingRequests_maxThreads request clients: WS, Direct, Façade, ADF,
Rest
• Some partition-specific Work Managers include:

Work Manager Name Constraint Name Description

default_Adapters None Adapter Work Manager, roughly included in
the 30% buffer
default_dspSystem soa_fairShare_20, minThreads_1 BPEL System Dispatcher Work Manager
SOAInternalProcessing_maxThreads
default_dspInvoke soa_fairShare_20. minThreads_1 BPEL Process Invocation Dispatcher Work
SOAInternalProcessing_maxThreads Manager
default_dspEngine soa_fairShare_80, minThreads_1 BPEL Process Engine Dispatcher Work
SOAInternalProcessing_maxThreads Manager
Oracle WebLogic Server includes a number of Oracle SOA Suite Work Managers, such as
the subset of those listed in the slide.
Note: You can create Oracle SOA Suite Work Manager Groups that are automatically
associated with these Work Managers.
For each table in the slide, the name of each Work Manager, the name of the constraints
assigned to the Work Manager, and a brief description of the Work Manager are provided.
Note: Items in the Constraints Name column can represent a Request Class or a Constraint,
each defining attributes that contribute to the Work Manager configuration.
The first table in the slide shows some of the Work Managers that are created when a domain
is configured, for all SOA components independent of the partition in which the components
execute.
The second table lists some of the Work Managers that are configured for components that
execute in the default partition.

Configuring Work Manager Groups
Configuring a Work Manager Group is done in Oracle Enterprise

Manager Fusion Middleware Control.
Select Metrics from the Show drop-
down list to monitor performance.
2

1
The slide shows the steps to configure a Work Manager Group by using Oracle Enterprise
Manager Fusion Middleware Control.
1. On the SOA Infrastructure page, select SOA Infrastructure > Work Manager Groups to
open the Work Manager Groups page.
2. On the Work Manager Groups page, you can click Create to create a new Work
Manager Group instance.
Note: After creating the new Work Manager Group, the Work Managers (for the
partition) are automatically included in the Work Manager Group. Work Managers for the
Work Manager Group are visible below the expanded Work Manager Group name on
the Work Manager Groups page.
Note: The Show drop-down menu provides a choice of viewing Constraints (the default view)
or Metrics to view performance data related to the list of Work Manager Groups that are
available. A Work Manager Group cannot be changed while a server is running.

Associating a Work Manager Group with a Partition
Associating a Work Manager Group with a partition is done when

you create the partition or manage the partition configuration in
Oracle Enterprise Manager Fusion Middleware Control.

1

2
Click to create a Work
Select a Work Manager Manager Group.
Group from the list.
Click Edit to modify a

selected partition.
Associating a Work Manager Group with a partition is done when you create the partition or
manage the partition configuration in Oracle Enterprise Manager Fusion Middleware Control,
as shown in the slide.
1. On the SOA Infrastructure page, select SOA Infrastructure > Manage Partitions.
2. On the Manage Partitions page, click Create to create a new partition where you can
select an existing Work Manager Group to be associated with the partition, or create a
new Work Manager Group.
Note: Alternatively, on the Manage Partitions page, you can select a SOA Partition entry and
click Edit to change the Work Manager Group that is assigned to the partition. However,
whereas the association of a partition with a new Work Manager Group can be updated, a
server restart is required. Updates to an association between a partition and a Work Manager
Group do not affect the work items that are already submitted.

Monitoring and Tuning Service Engines

To monitor Service Engines statistics (as illustrated in the slide), from the SOA Infrastructure
menu, select Service Engines, and then click one of the following:
• BPEL
• Mediator
• Human Workflow
• Business Rules
Each Service Engine page provides a Statistics tab page where you can view information that
is relevant to the type of Service Engine for which you are monitoring performance.
Note: Each Service Engine has specific tuning parameters that can be configured. Refer to
the Oracle Fusion Middleware Tuning Performance Guide documentation for more
information about Service Engine–specific tuning parameters.

Tuning the BPEL Engine Parameters
The BPEL Engine parameters that are likely or highly likely to

improve performance are:
Parameter Possible Action
auditLevel Use the value Off to stop storing audit information.

SyncMaxWaitTime Decrease value to improve performance.
largedocumentthreshold Decrease value to improve performance.
validateXML Use the default value False to improve performance.

InstanceKeyBlockSize Increase to value greater than the number of updates to
the ci_id_range table to improve performance.
Audit Level Threshold Decrease value to improve performance.
Note: Always consider trade-offs for the actions described.
The table lists some key BPEL Engine parameters that are likely to provide performance
gains. The following points describe each of the parameters listed in the table:
• The auditLevel (default inherit) property sets the audit trail logging level for both durable
and transient processes. Change this when you are experiencing low performance due
to frequent database inserts into the audit_trail table. However, when it is disabled, both
business flow and payload tracking are disabled, and their state cannot be viewed on
the Oracle Enterprise Manager Fusion Middle Console Flow Trace pages.
Note: The auditLevel is set at and inherited from the SOA Infrastructure level.
• The SyncMaxWaitTime property (a default of 45 seconds) sets the maximum time the
process result receiver waits for a result before returning. This property is required for
synchronous interactions and is applicable to transient processes.
• The largedocumentthreshold (default 10000, or 100 kilobytes) property sets the
maximum size (in kilobytes) of a BPEL variable before it is stored in a separate table
from the rest of the instance scope data. It is applicable to both durable and transient
processes. Large XML documents can slow performance if they are constantly read in
and written out whenever processing on an instance must be performed.

• The validateXML property (default of false) can make the Oracle BPEL Process
Manager intercept non-schema-compliant payload data by validating incoming and
outgoing XML documents. However, XML payload validation can slow performance.
• The InstanceKeyBlockSize property (default 10000 keys) controls the instance ID range
size. The Oracle BPEL Server creates instance keys (a range of process instance IDs)
in batches by using the value specified. After creating this range of in-memory IDs, the
next range is updated and saved in the ci_id_range table.
• The Audit Level Threshold property (default 10000) sets the maximum size (in kilobytes)
of an audit trail details string before it is stored separately from the audit trail. Strings
larger than the threshold setting are stored in the audit_details table instead of the
audit_trail table. In cases where the variable is very large, performance can be severely

impacted by logging it to the audit trail.

Configuring BPEL Engine Parameters

2

3
The slide shows the steps to access and set the BPEL Engine properties, some of which were
discussed in the preceding slide. To configure the BPEL Engine properties, perform the
following steps:
1. On the SOA Infrastructure page, after navigating to the page from the Target Navigation
pane, select SOA Infrastructure > SOA Administration > BPEL Properties.
Note: The SOA Administration menu provides options to access Common Properties
and properties for other service engines, such as Mediator and Human Workflow.
2. On the BPEL Service Engine Properties page, the most common properties are listed,
some of which are most likely to give performance improvements.
3. On the BPEL Service Engine Properties page, click the More BPEL Configuration
Properties link to access the System MBean Browser for the BPEL Engine to configure
many more properties that are available to you.
Note: Additional tuning at the level of a BPEL component in a composite application can be
performed by setting BPEL properties in the composite.xml file by the developer with
JDeveloper, or by an administrator by using the System MBean Browser of the composite
application in Oracle Enterprise Manager Fusion Middleware Control.

Monitoring SOA Composite Application Performance

2

You can also monitor the performance of a composite application as illustrated in the slide.
Because the ApprovePOComposite application is not actively processing any requests, there
is not much to see on the Performance Summary page in this example.

Monitoring an Inbound Adapter Properties
Monitoring inbound and outbound adapter properties are similar

to each other. Images are for an outbound adapter example:

1 3

2
Oracle adapters, which are components of a composite application, provide an integrated

view of data and allow multiple application systems to be integrated. You can monitor the
performance and configuration details of adapters on their relevant properties pages by using
Oracle Enterprise Manager Fusion Middleware Control. You perform the following steps as
shown in the slide:
1. Click the composite application name in the Target Navigation pane.
2. Locate and click the outbound adapter entry in the Services and References section of
the composite application page to display the adapter Dashboard page.
3. On the Adapter page, you can monitor Instance and Fault data. Clicking the Table View
link opens a dialog box where you can view the numeric data for the adapter (if any).
4. Returning to the Adapter page, you can click the Properties tab to view and update
various adapter properties, which would vary depending on the type of adapter being
monitored.

Accessing Adapter Logs
1. Access the composite application page that contains the

adapter reference.
2. Click Related Links > composite_name Composite Logs.
3. Enter search criteria to search for specific log information.

1

The JCA Adapter logger is
called oracle.soa.adapter.
Oracle Fusion Middleware components generate log files that contain messages that record
all types of events, including startup and shutdown information, errors, warning messages,
access information on HTTP requests, and additional information.
Note: There is only one logger for all Oracle JCA Adapters, and the logger is called
oracle.soa.adapter.
The slide shows the steps to locate the adapter logs for a specific adapter defined in the
context of a composite application:
1. After landing on the composite application home page in which the adapter resides, click
Related Links > composite_name Composite Logs.
2. The Log Message page is opened, where you can enter search criteria to locate the log
data that is relevant to your circumstances.

Activating Adapter Reports
Adapter configuration through reports, such as:

• Connection Factory properties
• Service Definition properties
• Service Tuning properties

• Reference Definition properties
• Reference Tuning properties

2
In addition to viewing adapter properties and log information as described in the previous
slides, you can activate and enable adapter reports for an adapter reference on its Adapter
Reports tab page, as shown in the following steps:
1. After landing on the composite application home page, click the name of the adapter
reference that you wish to obtain reports for, to open the adapter reference page.
2. On the adapter reference page, click the Adapter Reports tab and select the “Enable
reports” check box, which, by default, is not selected.
Note: When you select the “Enable reports” check box, the Diagnosibility Reports
section is populated with the following report categories:
- Configuration Reports
- Monitoring Reports
- Snapshot Reports
Note: By default, these category sections are expanded. The image in the slide shows
them collapsed to fit into the slide screen size. You can locate the various types of
reports listed in the slide in one of these report category sections.

Selective Tracing Configuration: Introduction
Selective tracing is:

• Fine-grained logging for applications, users, request attributes
• Configured by clicking WebLogic Domain > Logs > Selective
Tracing, for a domain, or by using WLST commands
Search for logger name to trace

specific logger messages.

2 3
Selective tracing provides fine-grained logging for specified applications, users, or request
attributes. For example, a problem arises where a user cannot perform some functions
because of security permissions, and it is unclear what operations or lack of operation
permission is the source of the problem.
Although tracing can be enabled across the entire system, it would generate a large volume of
log messages for all the users in the system. With selective tracing, tracing can be configured
to log messages only for the user that is having the problem. After configuring the tracing
settings accordingly and starting the tracing, the user retries the problem functions. After
capturing the trace messages, identifying the source of the problem that applies to the specific
user request becomes easier with less overhead on the system and resources.
To configure selective tracing using Fusion Middleware Control, perform the following steps:
1. In the Target Navigation pane, click the domain name.
2. On the domain name page, click WebLogic Domain > Logs > Selective Tracing.
3. On the Selective Tracing page, you configure the trace settings and parameters for the
conditions for which you wish to collect trace messages. You can set the log levels to:
NOTIFICATION:16 (CONFIG) level for the least amount of messages, and TRACE:1
(FINE), TRACE:16 (FINER), or TRACE:32 (FINEST) for the most detailed log
messages.

4. After configuring the trace parameters, click Start Tracing.
Note: Set a duration (in minutes) for the selective trace run, which is disabled after the
specified time. In addition, a specific logger name can be chosen to narrow the scope of the
traced messages.


Viewing and Disabling Selective Tracing
On the domain > Logs > Selective Tracing > Active Traces and
Tracing History tab page, you can:
• View:
– The currently active selective traces
– The history of selective traces

• Disable a selected
trace entry in the
table (if any)

To view selective traces, perform the following steps:

1. On the Selective Tracing page, click the Active Traces and Tracing History tab.
2. To view a trace, select it from the appropriate table. The Log Messages page is
displayed, showing messages that were captured by the selective tracing.
Messages displayed in either the Active Traces or Tracing History tables can be searched to
support correlation of messages related to the problem that is being diagnosed. To narrow the
search results for specific messages, enter values in the fields above the respective table
headings.
To disable selective tracing by using Oracle Enterprise Manager Fusion Middleware Control:
1. From the Target Navigation pane, right-click the domain name and click Logs >
Selective Tracing.
2. On the Selective Tracing page, click the Active Traces and Tracing History tabs.
3. On the Active Traces and Tracing History tab page, in the Active Traces table, select the
trace to be disabled and click Disable.

Agenda



Common Problems and Solutions
• Resolving message failure caused by too many open files

• Resolving connection timeouts
• Resolving common application-related problems

This section describes how to troubleshoot some common problems that you can encounter
when using Oracle SOA Suite.

Troubleshooting SOA Server Startup Failures
• Problem:
You receive ClassNotFound errors when the SOA Managed
Server is started by a Node Manager.
• Solution:
Node Manager must be started with the property

StartScriptEnabled=true, so that the Node Manager
can use the start scripts that contain the environment
information of the Managed Server to start the Managed
Server.

If you attempt to start a Managed Server via a Node Manager, you may receive a
ClassNotFound error if the Node Manager has not been configured to use the start scripts
when starting the Managed Server.
If a Managed Server is installed with SOA, the Managed Server environment must be
configured to set the correct classpath and parameters. This environment information is
provided through the start scripts, such as startWebLogic, startManagedWebLogic, and
setDomainEnv, which are located in the domain directory. If you use a Node Manager to
start the Managed Server, the Node Manager must be instructed to use these start scripts so
that the server environments are correctly configured. Specifically, the Node Manager must
be started with the property StartScriptEnabled=true.
There are several ways to ensure that the Node Manager starts with this property enabled. As
a convenience, Oracle Fusion Middleware provides the following script, which adds the
property StartScriptEnabled=true to the nodemanager.properties file:
• ORACLE_COMMON_HOME/common/bin/setNMProps.sh (UNIX)
• ORACLE_COMMON_HOME\common\bin\setNMProps.cmd (Windows)
When you start the Node Manager, it reads the nodemanager.properties file with the
StartScriptEnabled=true property, and uses the start scripts when it subsequently
starts the Managed Servers. Note that you need to run the setNMProps script only once.

Resolving Message Failure Caused by Too Many Open
Files
• Problem: You receive the following error at run time or
compilation time:
Message send failed: Too many open files
• Solution: (UNIX) Edit the /etc/security/limits.conf
file to increase the value for file descriptors to at least 4096.

For example:
#<domain> <type> <item> <value>
#* soft core 0
#ftp hard nproc 0

…
# End of file
@svrgroup soft memlock 500000
@svrgroup hard memlock 500000
* soft nofile 4096
* hard nofile 4096
You can receive the following error at run time 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 in UNIX, 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
2. Log in as the root user on your UNIX operating system.
3. Edit the /etc/security/limits.conf file to increase the value for descriptors as
shown in the slide.
4. Close your terminal and reopen for the change to take effect. A system restart is not
required.

Resolving Connection Timeouts
• Problem: You receive a connection timeout error under

circumstances such as large payload or large number of
message files.
• Solution: Increase the transaction timeout property in Oracle
WebLogic Administration Console.

1

2
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 by using a large payload from the Test Web Service page
of Oracle EM Console.
• You are passing a large number of message files (in excess of one million) into a
composite with a File Adapter service.
• You are retrieving instance and fault count metrics in Oracle EM Console.
To avoid receiving timeout errors, increase the transaction timeout property as follows:
1. On the Oracle WebLogic Administration Console home page, click the domain name in
the Domain Structure pane.
2. On the settings for edg_domain page, click the JTA tab, increase the value in the
Timeout Seconds field (the default is 30), and click Save.
Note: Restarting Oracle WebLogic Server is required after making the change.

Resolving Common Application-Related Problems
• Problem:
– Incorrect XML messages structures
— Incorrect namespace in the input data stream (for File Adapter or
soap-initiated requests)
– Incorrect configuration plans used with deployment

— Incorrect URLs for service references
– Missing configuration of runtime resources
— Incorrect DbAdapter runtime resource configuration
— Incorrect JMS Adapter runtime resource configuration

• Solution: Fix the application.
This slide lists some common problems related to deploying and executing composite
applications. These are not fixable by tuning or configuring; these require correcting the wrong
information or supplying the missing information.

Summary

• Design a tuning methodology
• Identify top areas that require tuning
• Monitor and tune Oracle SOA Suite by collecting performance

information and by using diagnostic tools
• Configure selective tracing
• Troubleshoot common problems:
– Managed Server startup problems

– Message failure caused by too many open files
– Connection timeouts
– Application-related problems

This practice covers the following topics

• Part 1: Performance Tuning
– Practice 13-1: Deploy an EAR application
– Practice 13-2: Examine Server Information in the Routing
Topology

– Practice 13-3: Observe WebLogic Server Instance JVM
Performance
– Practice 13-4: Explore Metrics for Oracle SOA Suite
Components

• Part 2: Troubleshooting
– Practice 13-5: Deploy a Troublesome Composite Application
– Practice 13-6: Testing the TroubleSomeComposite Interfaces
The first part of the practice is devoted to monitoring and performance tuning related tasks.
The second part of the practice is related to troubleshooting, where you are required to
diagnose and take corrective action for fault conditions that occur with a composite
application. During the practice, you make use of the various web-based tools for monitoring,
diagnosing, and fault correction for the conditions created in these practices.

14
Backup and Recovery of Oracle

SOA Suite

Objectives

• Adopt a backup and recovery strategy
• Back up your Oracle Fusion Middleware environment
• Recover Oracle Fusion Middleware and Oracle SOA Suite


Agenda
• Discussing the backup and recovery strategy

– Online
– Offline
– Full
– Incremental

• Backing up your Oracle Fusion Middleware environment
• Recovering Oracle Fusion Middleware and Oracle SOA Suite


Documenting Oracle Fusion Middleware Installations
Keep a record of your Oracle Fusion Middleware product

installations, which should ideally document:
Each Host FMW Installation Database

• Host name • Installation type • Database version

• Virtual host name (e.g. Infrastructure, and patch level
• Domain name SOA Suite) • Base language
• IP address or • Username/ID, • Character set
virtual IPs environment profile, • Global database
• Hardware platform and shell type name

• OS release level • Directory structure, • SID
and patch mount points, full
information path to FMW home,
config, Oracle
home, WLS home
• Port numbers used
by installation
You should maintain an up-to-date record of your Oracle Fusion Middleware installations in
hard copy and in electronic form. You would need this information in the event that you must
restore and recover your installations to a new disk or host. The electronic form should be
stored on a system that is separate from your Oracle Fusion Middleware installation that is
being backed up.
Note: Recall that the Enterprise Deployment Workbook spreadsheet that was introduced in
the lesson titled “Planning an Oracle SOA Suite 12c Deployment Architecture” of this course
is a good starting point for documenting the information discussed in the slide.

About Backup and Recovery
Backup Recovery
• Scheduled • Unscheduled (usually)
• At least weekly • At least annually (if
(to capture logs) only to test procedures)
• Different tools for different • Not necessarily the reverse of

components backup; may be new tools
• Protect against failures of hardware, software, power,
environmental disasters, accidental and malicious changes,
and more

• Guarantee a point of recovery, minimizes loss of business
availability, insures an SLA, and may satisfy legal
requirements
• May impact business
• May be hardware and software
The terms “backup” and “recovery” imply the use of alternative media to keep a copy of data
in the event of data corruption, data loss, failure, or disaster. Alternatively, “redundancy” and
“failover” are a means by which one can provide high availability, a scalable model, and also
quick backup and recovery of data. If an outage occurs with redundancy and failover
implemented, the goal would be to make it undetectable by users.
The most common problem that would require backup and recovery is when a person who is
authorized to make changes accidentally makes a wrong change. Usually, the mistake is
realized within seconds and all that is needed is a mechanism that will enable the user to go
back to a very recent version of the configuration. A more serious problem would be when
there is complete loss of the system that is hosting the WebLogic component.
Therefore, the architectural goal of an enterprise deployment would be to ensure that there is
no single point of failure in the Fusion Middleware architecture. However, some tolerance of
an impact on service for a short period of time may be allowed. For example, no configuration
changes can be made while the Administration Server is down.
Backup and recovery policies may impact your business both financially and in terms of
availability (required maintenance windows).

Types of Backups
• Online
– Nondisruptive
– Possibly inconsistent
– Possibly tricky, especially for a database
• Offline

– Requirement that all processes should be stopped
– Very easy
• Full

– Easier to recover
– Slower to create
• Incremental
– Harder to recover
– Faster to create
Online: If your environment requires 24x7 availability, you have no choice but to perform an
online backup. Different components require different tools to perform online (also known as
hot or inconsistent) backups.
Offline: If you can afford to shut down the entire middleware tier (application servers,
database, Web servers, and so on) for maintenance during some regularly scheduled time, an
offline (also known as cold or consistent) backup is the most simple option. Using OS tools
such as tar or zip, the backup is guaranteed to be consistent. Make sure that you preserve
the file permissions on UNIX systems.
Full: After initial installation, or after a major set of patches, a full backup should be
performed. A backup should be performed before going into production while the system is
offline.
Incremental: Considering that the executable files and the configuration files are usually
backed up separately, most backups are partially incremental. Backing up only changes may
require several sets of backups recovered in order to perform a full recovery. RMAN can help
automate this for databases, especially if the backups are kept online (on disk as opposed to
tape). You can make an incremental backup at the functional level. For example, you can
make a backup of WebLogic from the WebLogic home folder; a backup of the database from
the database Oracle home folder; and a backup of the domain configuration folders, domain
application folders, and deployment plan folders.

Recommended Backup Strategy
• Perform an online backup and ensure that you do not make

configuration changes until the backup is complete.
• Perform a full offline backup immediately after:
– Installing an Oracle Fusion Middleware product
– Updating operating system software

– Upgrading or patching Oracle Fusion Middleware products
• Perform a backup of runtime artifacts after every
administrative change or on a regular basis.
• Create unique names for each backup of the environment.

Backups should be taken of the Oracle Fusion Middleware environment, and of the static and
runtime artifacts. Runtime artifacts are the files that change more frequently.
You should use the following recommended strategy for backing up your Oracle Fusion
Middleware environment:
• If you are performing an online backup, do not make any configuration changes until the
backup is completed. To ensure that no changes are made in the WebLogic Server
domain, lock the WebLogic Server configuration.
• Perform a full offline backup immediately after your Oracle Fusion Middleware
installation or after a major change, such as any upgrade or patch.
• Create a record of your Oracle Fusion Middleware environment.
• When you create the backup, name the archive file with a unique name. Consider
appending the date and time to the name. For example, the course backup scripts
accept a label name for associating backup files for the different runtime artifacts that
are backed up. The label name argument for the backup and recovery scripts should be
unique, and is used to form part of the name of the backup archive files that are created.

Limitations and Restrictions for Backing Up Data
• You should not be adding users or changing permissions

while backing up the directory servers (LDAP).
• Online persistent stores by nature would result in an
inconsistent backup.
– Database backups can accommodate inconsistencies.

– File-based stores and copies thereof cannot accommodate an
online backup.
• HTTP session states and cookies information may be lost.
– In-memory replication may lose the state.

– Replication of the HTTP session state solves this problem.
None of the restrictions listed in the slide apply to offline backups; they apply only to online
backups.
In many cases, the WebLogic Server has the option to be configured to use either database
or file storage for information. Choosing database is always a safer option. The trade-off is
having to manage additional configuration requirements and possibly performance.
Typically, the database administration is responsible for backing up the database anyway.
Thus, backing up WebLogic Server artifacts from the file system is not much of an additional
effort. Therefore, there are benefits to be gained by configuring database storage for some
WebLogic Server components where possible compared to using file storage.
However, for files such as WebLogic config.xml, application JARs, WARs, or EARs, and
properties files, database storage is not an option and backup should, therefore, be performed
separately.
Note: With Oracle SOA Suite using database storage for runtime information, it is essential to
ensure that database backup and file system backup are performed within a short time frame
of each other to ensure that configuration changes are not made between backup operations.

Quiz Q
What mode must the Middleware software be in to perform a full
backup?
a. Online
b. Offline

c. Either online or offline
d. Neither. A full backup is technically impossible.

Answer: b
To be consistent, the Middleware software must be completely stopped.

Agenda

– Online
– Offline
– Full
– Incremental



Backup Tools
To back up your Oracle SOA environment:

• For file-based artifacts, you can use file copy utilities such as
zip, copy, xcopy, tar, or jar
• For database schemas, you can use RMAN for offline, online,
and incremental backups. Alternatively, you can use file-

based utilities for offline backup of key database files (control
files, archive logs, and data files).
Note: The Oracle WebLogic Server pack utility can be used to
create a template archive file for WebLogic configuration data.

To back up your SOA environment, you can use:

• File copy utilities such as copy, xcopy, tar, or jar
- For online backups on Windows, use copy.
- For offline backups on Windows, use copy, xcopy, or jar. Do not use winzip
because it does not work with long file names or extensions.
- For backups on Linux and UNIX, if using tar, make sure that you keep the
permissions; if using zip, make sure that you include empty directories.
• Oracle Recovery Manager (RMAN) to back up database-based metadata repositories.
RMAN supports offline, online, and increment backup scenarios. However, you can also
use file-based tools to backup appropriate database files from the file system for a full
offline backup.
• The Oracle WebLogic Server pack utility can be used to create a template archive
(.jar) file that contains a snapshot of either an entire Oracle WebLogic Server domain
or a subset of a domain.
Note: There are many third-party products that offer backup and recovery solutions.

Backing Up an Enterprise Deployment Topology
For an enterprise deployment architecture, you should back up:

• The static artifacts (product installation binaries)
• The runtime artifacts (WebLogic Server configuration data)
• The Oracle database and product schemas

Note: Ensure that the runtime artifacts are consistent with the
database schema backup.
Static artifacts
/u02 Shared disk /u01 Local disk on each host

oracle oracle
config product
config
Runtime artifacts
For an enterprise deployment architecture, you should back up:

• The static folders, which are the product installation (binary) folders for each host
• The runtime folders, which are the configuration folders for the Administration Server
and each Managed Server
• The Oracle database schemas that are used for the installed products
Note: Backups of the runtime file system artifacts should be performed at the same time (or
as close as possible) as the database schema backups for consistent recovery to be possible!

Performing a Full Offline Backup
1. Shut down all Fusion Middleware–related processes:

A. Stop all the servers in the WebLogic domain.
B. Shut down the database.
C. Stop the database listener and optionally the Node Managers.
2. Perform the backup by using your preferred tool:

A. Back up the Middleware home on all hosts. For example:
tar -cvpf fmw_static_full_init.tar $MW_HOME/*
B. Back up the configuration trees for the AdminServer and each
Managed Server in the domain.

C. Back up the database repositories by using RMAN.
3. Test the backup by performing recovery on another computer.
4. Store the backup offsite.
Shutting Down: Stop all deployed applications so that you can shut down all servers. Stop
the Node Managers and emAgents. In SQL*Plus (sqlplus / as sysdba), issue shutdown
immediate. This may take a while (despite the name, it is not “immediate”). Stop the
database listeners and the Enterprise Manager console.
Performing Backup: Use your preferred tool to archive and compress the source Middleware
home. If the domain is not located within the Middleware home, back up the AdminServer
domain separately. Do the same for the Managed Servers. For detailed steps to back up
database repositories by using RMAN, see the Oracle Database Backup and Recovery
User’s Guide. On Windows, you also need to export the following registry key:
HKEY_LOCAL_MACHINE\Software\oracle.
Testing Restore: Make sure that the first backup that you completed is successful. From the
root directory, signed on as the root user, enter:
tar -xvpf archive_name_label.tar
Because you have signed on as root, it is vital to make sure that the –p switch is used in the
tar command to preserve the original owner and group permissions (for example, oracle
and oinstall versus root). Restart all processes to test the recovery and make sure that it
is complete.

Performing an Online Backup of Runtime Artifacts
1. Back up the Administration Server domain directories.

$ tar -cvpf edg_domain_adm_150101.tar /u02/oracle/config/*
2. Back up the database repositories by using RMAN.

$ rman
RMAN> CONNECT TARGET /
RMAN> :
RMAN> BACKUP AS BACKUPSET TAG "BCK1" DATABASE PLUS ARCHIVELOG;
RMAN> EXIT

$
You should perform a backup of runtime artifacts on a regular basis and at times when
administrative changes are made. To back up runtime artifacts, perform the following steps:
1. Back up the Administration Server domain directories. The example in the slide
performs a backup of the Oracle SOA Suite Administration Server configuration
directory tree.
2. Back up the database repositories by using Oracle Recovery Manager (RMAN).
The example in the slide shows a typical RMAN command that can be used to back up
the entire database, including the archive log. Use the TAG keyword with the value BCK1
to assign an easy-to-remember tag name to the backup set. The tag name allows you to
restore a backup set based on the tag name.

Backing Up the Domain Configuration File
• On the egd_domain > Configuration > General page, scroll

down and expand the Advance section to enable automatic
backup of the config.xml file at domain startup time.

Disabled
by default
On the WebLogic Administration Console home page, click the Domain Name link in the
Domain Structure panel.
When the “Settings for the domain” page is displayed, the Configuration > General tab page is
shown by default. Scroll down the page to the Advanced section. You can enable automatic
backup of the config.xml file for the domain by selecting the Configuration Archive Enabled
check box. This setting is disabled by default.
Archive Configuration Count limits the number of configuration files that are retained, so that
in the example in the slide, not more than three are retained. Older backups are automatically
deleted. If you made a series of mistakes, this provides a very easy way to return to a
previous recent configuration. However, be aware that a typical configuration change requires
clicking Activate Changes a few times, and each change creates a new configuration backup
file. Consider setting the Archive Configuration Count to a higher number such as 10 or 20.

Quiz Q
When making a tar backup in UNIX, what is a key point to
remember?
a. Perform the backup from the lowest directory possible, as far
from root as practical.
b. Make sure that you perform the backup signed on as the

owner of the Middleware Home directory.
c. Make sure that you preserve the original owner, group, and
permissions.
d. Make sure that all Middleware processes are stopped.

Answer: c
In tar, use the –p option to preserve the permissions. Depending on what you are backing
up, “d. stopping all processes,” might be necessary as well.

Agenda

– Online
– Offline
– Full
– Incremental



Recovery After Disaster
• Possible causes of failure:

– Data loss
– User error
– Malicious attack
– Corruption of data

– Media failure
– Application failure
• Recovery depends on the cause:

– Repair
– Replace
– Relocate
• If the problem was caused by a minor configuration error, the administrator may be able
to reverse the steps and resolve the problem without a formal recovery.
• If the problem requires replacing hardware, restoring full backups is a simple procedure.
• Recovery is complicated when you need to relocate some functions from the previously-
active-but-now-dead machine A to an existing, standby machine B. According to the old
configuration (and backups), the functions must be routed to the old name and address
of machine A; but now, according to the new environment, the functions need to be
routed to the new name and address of machine B.

Recommended Recovery Strategy
• Take the Oracle Fusion Middleware environment offline

before performing recovery.
• Rename important existing files and directories before you
begin restoring the files from backup.
• Restore the whole directory even if only one or two files are

lost or corrupted.
• Recover the database to the most current state by using
point-in-time recovery (PITR).

Recovery strategies enable you to recover from critical failures that involve actual data loss.
You can recover your Oracle Fusion Middleware environment in part or in full. You can
recover a domain, the WebLogic Server Administration Server, a Managed Server, the
Middleware home (product binaries), an Oracle home, and deployed applications.
You should use the following recommended strategy for recovery:
• Take your Oracle Fusion Middleware environment offline before performing recovery.
• Rename important existing files and directories before you begin restoring the files from
backup so that you do not unintentionally override necessary files.
• If you think that only one or two files are missing or corrupted, you may be tempted to
recover only those individual files from the system. Instead, you should always recover
whole directories because there may be other files that are related to these files.
• Recover the database to the most current state by using point-in-time recovery (if the
database is configured in Archive Log Mode). This is typically a time just before the
database failure occurred.
Note: Ensure that you recover a consistent state of the Oracle SOA Suite domain
configuration files and the associated product database schemas.

Directories to Restore
• Binaries (static artifacts)

– Be mindful of preserving group ownership and permissions.
– This should be read-only for most users.
• Configurations (administration and Managed Servers)
– If the last configuration caused the problem, recover to a point

in time before that.
• Logs
– These are not required for recovery, because they are created
if they do not exist.

• Data
– The database restores data within tablespaces, not directories.
– RMAN restore brings data up to the last backup; recover brings
data up to a later point in time.
• LDAP data (depending on whether changes have been made)
In most cases, recovery is performed offline. If the directories were backed up from root, you
do not need to worry about where to recover them to. Full path information is provided to the
operating system because it is contained in the backup. Restore them as the root user, from
the root directory, and the restored directories will go back to their correct locations. Do not
forget the –p switch in the tar or jar command to get the original owner and group
information correct.

Recovering a Middleware Home
This applies to recovering a Middleware home, an Oracle home,

or an Instance home after data loss or corruption:
1. Stop all processes.
2. Make a new full offline backup as a checkpoint (which can be
reused).

3. Change directory to the affected home and use relevant copy,
untar, or unzip commands to restore the directories that were
affected.
4. Make a new full offline backup (especially if you have been

performing incremental backups until this point).
5. Restart all processes.
Make sure that all Fusion Middleware software is stopped so that this is an offline recovery.
The most important rule in problem resolution is: “Do not make the problem worse.” By
performing the two additional full backups, you guarantee that you can at least put everything
back to the way it was before you tried to help.
Assume that the last good backup was sequence number 9. As an example, here is how to
recover a damaged Administration Server configuration folder:
1. Stop all processes:
- Use WLST and Node Manager to shut down all the servers, including the
Administration Server. Stop the Node Manager instances as well.
- In SQL*Plus, shut down the database cleanly, that is, by using “immediate.”
- Stop the database listener.
2. tar –zcvpf mycheckpoint.tar /u02/oracle/config
3. tar –zxvpf myinstance09.tar
4. tar –zcvpf myfullbackup10.tar /u02/oracle/config
5. Restart all processes, such as the database and the database listener. Start the Node
Manager instances and use WLST scripts to start the servers in the domain.

Managed Server Independence (MSI)
Managed Server Independence (MSI), which is set by default,

reduces the urgency to fix an outage with the Administration
Server, allowing Managed Servers to start.

2
3
Enabled
by default
The Administration Server is required only for making changes to an active configuration; it is
not required for normal operation of the Managed Servers as long as they are in Managed
Server Independence Enabled mode, which is the default. This allows you time to recover the
Administration Server without any service outages.
You can change the Managed Server Independence Enabled setting by performing the
following steps (in the Oracle WebLogic Administration Server Console):
1. In the Domain Structure panel, expand Environment and click the Servers link.
2. On the Summary of Servers page, click the AdminServer link.
3. On the Settings for AdminServer page, click the Configuration > Tuning subtab, scroll
down and expand the Advanced section, locate and change the Managed Server
Independence Enabled setting as desired, and then save the changes.
Note: A server restart may be required.
You can also set a value to control the heartbeat time detected between the Administration
Server and the Managed Servers. By default, the heartbeat time is set to a one-minute period.
After four minutes of not hearing from the Administration Server, the Managed Servers
become independent. After the Administration Server is fixed, the heartbeats start up again
and the Managed Servers deactivate their independence, but MSI is still enabled for a future
event. These time periods can all be changed to suit your particular environment.

Recovering a Managed Server
• If a Managed Server crashes, the Node Manager

automatically restarts it.
• If files are damaged, you can recover the files in their original
places by using a backup and restart the servers.
• If the computer is damaged, perform either of the following:

– Restore the product folders and Managed Server configuration
files on a new host by using the virtual host name for the
original computer.
– Restore the files with the unpack tool on another host with a

different host name by using templates to extend the domain.
Note: This technique is not applicable for an Enterprise
Deployment topology.
• Configure Whole Server Migration for an Enterprise
Deployment topology.
The original pack command that created the remote Managed Server can be used to re-
create it in a recovery operation. The significant configuration and application files are stored
on the Administration Server, so when the Managed Server comes back, it first refreshes all
its configuration information and redeploys all its applications from the Administration Server.
By nature, an Enterprise Deployment topology is designed to provide automatic failover
capabilities in the event of Managed Server failure. This can be accomplished if you configure
Whole Server Migration for recovery of a failed Managed Server.
If Whole Server Migration is not possible, such as in the course implementation, you can
create additional Managed Servers by extending the domain to include new Managed Servers
in the cluster that can be started on a new machine, with a new virtual host name. Using the
unpack tool, you can then propagate the Managed Server configuration to the new machine
(as discussed in the lesson titled “Configuring High Availability”).

Summary

• Adopt a backup and recovery strategy
• Back up your Oracle Fusion Middleware environment
• Recover Oracle Fusion Middleware and Oracle SOA Suite



• 14-1: Backing up the entire domain and database
• 14-2: Removing a part of the file system for the environment
and recovering from the backup


15
Configuring Security Services

and Policies

Objectives

• Describe Web services security
• Describe Oracle Web Services Manager Policy Framework
• Create or modify security policy

• Attach a security policy to Web services
• Monitor the performance of Web services


Agenda
• Securing Web services

– Transport level
– Message level
– SAML
• Understanding Oracle Web Services Manager Policy

Framework
• Managing Oracle WSM security policies


Web Services Security: Introduction
To secure your Web service, you need to configure one or both

types of security:
• Transport-level security: Secures connections between a
service consumer and a provider
• Message-level security: Secures a message through its

journey between the sender and the intended recipient

Web services security covers a lot of territory. It is usually divided into smaller, more
manageable chunks:
• Transport-Level Security: Security begins at the transport or wire level. It allows the
client and Web service to communicate securely across a network by providing a secure
connection.
• Message-Level Security: Message-level security is end-to-end security. It means that a
message is secured through its journey between the sender and the intended recipient.
In Web service communication, a message can travel through various entities before it
reaches its intended recipient. The message is secured during this journey if message-
level security is applied.
You can have one or both kinds of security configured and applied.

Transport-Level Security
• Transport-level security secures the connection between the

client and the Web service with Secure Sockets Layer (SSL).
• SSL is the most widely used transport-level data-
communication protocol. SSL provides:
– Authentication: Communication is established between two

trusted parties.
– Confidentiality: The data that is exchanged is encrypted.
– Message integrity: The data is checked for possible
corruption.

• The following are the limitations of transport-level security:
– It is point-to-point; secures only the connection.
– It cannot encrypt selected parts of the message.
Transport-level security uses SSL to secure the connection between a client application and
the Web service. SSL enables secure connections by allowing two applications that connect
over a network to authenticate the other’s identity and by encrypting the data that is
exchanged between the applications.
Transport-level security, however, secures only the connection. This means that if there is an
intermediary between the client and the server, such as a router or a message queue, the
intermediary gets the SOAP message in plain text. When the intermediary sends the
message to a second receiver, the second receiver does not know who the original sender
was and may not use SSL. Additionally, the encryption that is used by SSL is “all or nothing,”
that is, either the entire SOAP message is encrypted or it is not encrypted at all. There is no
way to specify that only selected parts of the message should be encrypted.

Message-Level Security
• Message-level security:
– Specifies whether the SOAP messages between a client
application and the Web service should be:
— Digitally signed: Ensures data integrity
— Encrypted: Ensures confidentiality

– Assures authentication by requiring username, X.509, or SAML
tokens
• Security data built into the XML message header
• Advantages:

– Enables end-to-end security
– Allows specific parts of the message to be signed and/or
encrypted
Message-level security specifies whether the SOAP messages between a client application
and the Web service should be digitally signed or encrypted, or both. It can also specify a
shared security context between the Web service and the client in the event that they
exchange multiple SOAP messages. You can use message-level security to assure:
• Confidentiality, by encrypting message parts
• Integrity, by using digital signatures
• Authentication, by requiring username, X.509, or SAML tokens
Security data is built into the XML message text, usually as additional SOAP header fields.
Message-level security includes all the security benefits of SSL, but with additional flexibility
and features. Message-level security is end-to-end, which means that a SOAP message is
secure even when the transmission involves one or more intermediaries. The SOAP message
itself is digitally signed and encrypted, rather than just the connection. And finally, you can
specify that only individual parts or elements of the message should be signed, encrypted, or
required.

WS-Security: Overview
• The goal of Web Services Security (WS-Security) is to provide

comprehensive end-to-end security at the SOAP message
level.
• WS-Security specifies rules to ensure:
– Authentication, by using security tokens

– Data confidentiality, by using XML Encryption specification
– Data integrity, by using XML Signature specification
Authentication WS-Security Allow (Y/N)?
Who? UsernameTokenProfile Authenticate and authorize
(sign, encrypt, propagate) WS-SecurityPolicy

Request Policy
enforcement
point
Response
Client End point Service
The Web Services Security (WS-Security) specification specifies Web services security at the
message level. IBM and Microsoft defined the specification, which is OASIS approved as
“Web Services Security: SOAP Message Security.” OASIS stands for Organization for the
Advancement of Structured Information Standards.
WS-Security is a collection of protocols that specify how different levels of security can be
enforced on messaging in SOAP-based Web services. It is meant to provide comprehensive
end-to-end message content security, and not just transport-level security. The security
matters are not delegated to the transport level, but rather handled directly through an
appropriate security API.
WS-Security defines SOAP extensions to implement client authentication, data integrity, and
data confidentiality at the message level.
• Data confidentiality ensures that data cannot be read during transit, by means of
message encryption. WS-Security uses the XML Encryption specification to encrypt
portions of the SOAP messages. Any portions of SOAP messages, including headers
and body blocks, may be encrypted.

• Data integrity assures the recipient that the data that the application receives has not
been altered during transit. It is implemented by XML Signature in WS-Security. XML
Signature binds the sender’s identity (or “signing entity”) to an XML document. Signing and
signature verification can be done by using asymmetric or symmetric keys.
• Authentication can be done by using security tokens. WS-Security is open to various
security token models, such as:
- X.509 certificates
- Kerberos tickets
- userID/password credentials
- SAML-Assertion

WS-Security defines how to attach XML Signature and XML Encryption headers to SOAP
messages, as well as a way of associating security tokens with a message.
By using WS-* security standards, implementing web services security becomes a declarative
configuration task, which replaces the requirement for adding the associated security logic to
the code. The key benefit of a declarative approach is the ability to change things at post-

deployment time, that is, no code changes.

WS-Security Tokens
WS-Security supports the following security tokens:

• Username/password credentials
• Binary authentication tokens in the form of:
– Kerberos tickets
– X.509 certificates

• Security Assertion Markup Language (SAML) assertion
Example: UsernameToken in plain text (in a SOAP header)

<wsse:UsernameToken>
<wsse:Username>jcooper</wsse:Username>
<wsse:Password>welcome1</wsse:Password>
<wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
</wsse:UsernameToken>
Specific WS-Security (WSS) 1.0 tokens include:

• WSSUsernameToken: This uses a plain username and password, either in plain text or
digest form.
• WSS10UsernameWithCerts: Along with UsernameToken, it sends sensitive data,
which could be signed or encrypted. Certificate information is also passed either in
BinarySecurityToken, IssuerSerial, or KeyIdentifier.
• WSS10AnonymousWithCerts: No username or password is sent. The client does not
identify itself to the server. The message exchange must be secured by using signatures
or encryption.
• WSS10UsernameTokenOverSSL: This is similar to the plain username token. The
“transport security” part is different.
• WSS10MutualAuthWithCerts: The client goes for strong authentication by identifying
itself by using X.509 credentials. The client X509Token is embedded in the message
signature.

Additional tokens defined for WS-Security 1.1 include:
• WSS11AnonymousWithCerts: Similar to WSS10, the requestor is not identified to the
service. The request may be signed or encrypted by using ephemeral keys, or keys
derived from ephemeral keys. The response is signed with the same ephemeral key or
derived key.
• WSS11MutualAuthWithCerts: The request message data is signed by using symmetric
key mechanisms. The signature is computed with an ephemeral key or a derived key by
using asymmetric key mechanisms.


Security Assertion Markup Language (SAML)
• Is an open framework for exchanging security information

between different parties through XML documents
• Conveys information about subjects, human users, or any
entities with the following types of “assertions:”
– An authentication assertion

– An authorization assertion
– An attribute assertion

With WS-Security, you can use any security token that you want. SAML security tokens are
used as an open framework for exchanging security information between different security
domains (parties), especially authentication details such as user login information, user
attributes, and authorization information in the form of policies. It enables different security
services systems to interoperate.
SAML is a protocol that does not define any new approaches to authentication/authorization,
but just generates appropriate tokens and assertions after authentication occurs.
SAML contains one or more “assertions,” each of which conveys information about subjects
(human users or any entities). Each assertion may contain multiple statements about
authentication, authorization, and additional attributes.
SAML supports the following types of “assertions:”
• Authentication Assertion: Conveys information that a certain subject was
authenticated at a certain instant
• Authorization Decision: Conveys information about access privileges for a user to
certain resources
• Attribute: Conveys information about subject attributes

The SAML specification defines a standard, XML-based approach to passing security tokens
that define authentication and authorization rights. Originally, SAML was targeted more toward
distributed authentication and single sign-on (SSO), but these concepts are also central to Web
services security now.


WS-Security and SAML
• WS-Security and SAML work together:

– WS-Security defines how you insert information into a SOAP
envelope.
– SAML defines what the security information is.
• SAML Token Profile 1.1 specifies how SAML assertions can

be used for Web Services Security:
– WS-Security allows SAML assertions to be placed inside a
SOAP header.
– SAML Token Profile 1.1 is supported only through WS-

SecurityPolicy.
WS-Security allows SAML assertions to be placed inside a SOAP header, thereby laying the
foundations of SSO for Web services.
SAML has already adopted WS-Security as the appropriate method for “binding” SAML
assertions to SOAP messages.
WS-Security is the messaging language; SAML is the security language.
SAML Token Profile 1.1 is part of the core set of WS-Security standards, and specifies how
SAML assertions can be used for Web Services Security. The SAML assertions and
references to assertion identifiers are contained in the WS-Security Header element, which in
turn is included in the SOAP envelope Header element (described in the WS-Security SAML
Token Profile).

Quiz Q
WS-Security provides:
a. Single sign-on
b. Point-to-point security at the transport level
c. End-to-end security at the message level

d. Authentication

Answer: c
Web Services Security (WS-Security) provides comprehensive end-to-end security at the
SOAP message level, which includes authentication, data integrity, and data encryption.

Agenda

– Transport level
– Message level
– SAML

Framework


Oracle Web Services
Development Oracle Fusion Middleware

Web Services
Oracle JDeveloper
Oracle Infrastructure
Web Services
WLST SOA Composite
Services

ADF Components
WebCenter
Services
Security &

Administration Policy Management
Oracle EM WebLogic Oracle WSM-PM
Fusion Middleware Web Services Policies
Control
WebLogic Web
Oracle WLS Services (JEE) WebLogic Web
Administration Service Policies
Console
Oracle Web services can be classified into the following categories:

• WebLogic (Java EE) Web services: Implemented according to the Web services for
the Java EE specification (JAX-WS)
• Oracle Infrastructure Web services: SOA service components, ADF business
components, and WebCenter services
To support the two categories, there are two types of policies that can be attached to the Web
services:
• Oracle Web Services Manager Policy Management (WSM-PM): The policy provided
by the Oracle WSM-PM. You can attach Oracle WSM-PM policies to SOA, ADF, and
WebCenter Web services. You manage Oracle WSM-PM policies from Oracle
Enterprise Manager Fusion Middleware Control and from the command line by using
custom WebLogic Scripting Tool (WLST) commands.
• WebLogic Web Service Policy: The policy provided by WebLogic Server. A subset of
WebLogic Web service policies interoperate with Oracle WSM-PM policies. You
manage WebLogic Web service policies from WebLogic Administration Console.

Oracle Web Services Manager
• Oracle Web Services Policy Management (WSM-PM) is a

security and management system that provides a common
security infrastructure for Web services applications.
leverages Oracle Web Services Policy Management to

centrally define security and management policies, and
enforce them locally at run time.
• WSM-PM is based on three main operations:
– Define

– Enforce
– Monitor
Oracle Web Services Policy Management (WSM-PM) is designed to define and implement
Web services security in heterogeneous environments. Instead of coding security logic in the
application, you can use WSM-PM to implement declarative security and management
through predefined policies. The three main operations on which the WSM-PM is based are
as follows:
• Define consists in attaching the security and management policies to the Web services
that are to be protected.
• Enforce is the ability provided by WSM-PM to distribute policies from a central Policy
Management location to policy enforcement points that execute security and
management policies at run time.
• Monitor enables the tracking of the runtime security and management events that are
captured by WSM-PM.
Note: Oracle WSM is installed by default when you install Oracle Fusion Middleware SOA
Suite or Oracle Application Development Runtime.

Oracle Web Services Manager Policy Framework
• It provides a policy framework to manage and secure Web

services consistently.
• The policy framework is built by using the WS-Policy standard,
and leverages the Oracle Platform Security Services (OPSS)
Login Module and the Oracle WebLogic Server authenticator

for authentication and authorization.
Oracle Web Services Manager

Policy Enforcement Point

Oracle Platform Security
Login Module
Oracle WebLogic Server

Authenticator
WSM-PM can be leveraged from Oracle Enterprise Manager Fusion Middleware Control to:
• Centrally define policies by using WSM-PM Policy Management
• Enforce WSM-PM security and management polices locally at run time
The tasks that can be performed from WSM-PM include:
• Handling WS-Security (for example, encryption, decryption, signing, signature
validation, and so on)
• Defining authentication and authorization policies against an LDAP directory
• Generating standard security tokens, such as SAML tokens, to propagate identities
across the multiple Web services that are used in a single transaction
• Segmenting policies into different namespaces by creating policies within different
folders
• Examining log files

Oracle Web Services Manager Architecture:
Components
Reliable
MTOM Security Addressing Management
Messaging
Oracle Enterprise Manager

Fusion Middleware Control WSM-Policy
Management
Oracle JDeveloper
Metadata
Services

(MDS)
Oracle Fusion
Middleware
Database
The components of the Oracle Web Services Manager Architecture can be described as
follows:
• Oracle Enterprise Manager Fusion Middleware Control: Enables administrators to
access the functionality in Oracle Web Services Manager to manage, secure, and
monitor Web services
• Oracle Web Services Manager Policy Management: Reads and writes policies,
including the predefined and custom policies from the Metadata Services (MDS)
• Policy Interceptors: Enforce policies, including reliable messaging, management,
addressing, security, and Message Transmission Optimization Mechanism (MTOM)
• Metadata Services: Are used for storing policies. Policies can be stored either as files
in the file system (supported for development) or to the Oracle Fusion Middleware
database (supported for production).
• Oracle Fusion Middleware Database: Provides database support for the MDS

Web Services Policies: Introduction
The Web services policy:

• Defines a framework for allowing Web services to express
their constraints and requirements
• Provides a model and the syntax for describing the policies of
a Web service

• Is divided into several subsidiary specifications:
– WS-Policy: Defines the grammar that explains Web services
policies
– WS-PolicyAttachment: Associates policies with Web services

– WS-PolicyAssertions: Defines a set of general policy
assertions
A policy is used by Web services primarily to specify requirements that clients must satisfy in
order to use the Web service. The requirements cover security/encryption, transportation
protocol, and so on. Basically, WS-Policy provides the Web service the ability to specify
requirements beyond what is normally definable by its WSDL specification. A policy consists
of a set of rules written in XML that is either incorporated directly into, or referenced by, the
Web service’s WSDL specification.
The Web services Policy Framework, called WS-Policy, provides a model and the syntax for
describing the policies of a Web service.
WS-Policy includes the following specifications:
• WS-Policy: Defines the grammar that explains the Web services policies
• WS-PolicyAttachment: Defines the policy about using attachments
• WS-PolicyAssertions: Defines a set of general policy assertions. The constraints and
requirements of Web services are expressed as policy assertions.

Policy Assertion
• Policy assertion:
– Is a basic unit that represents the individual requirements in a
policy
– Is domain specific (security, reliability)
• Service providers use a policy assertion to convey a condition

under which they offer a Web service.
• An example of policy expression is:
<Policy>
<wsp:TextEncoding Encoding="iso-8859-5" />

</Policy>
A policy assertion is a piece of service metadata that represents an individual requirement, a

capability, or other property of a behavior. Assertions are domain-specific (security, reliability,
and transaction), and the details are specified in separate specifications. Service providers
use a policy assertion to convey a condition under which they offer a Web service. A policy-
aware client can recognize policy assertions and engage these behaviors automatically.
The policy expression (XML form of the policy) in the example in the slide consists of a main
element, Policy, and a child element, wsp:TextEncoding. The child elements of the
Policy element are policy assertions. This example represents a specific policy assertion for
text encoding. A policy-aware client can recognize this policy assertion, and engage text
encoding automatically.
Note: The prefix wsp is used in this example to denote the Web Services Policy XML
Namespace.

Oracle Web Services Manager Policy Assertions
• WSM-PM policies are made of one or more assertions that

exhibit a particular behavior.
• Assertions are executed in the order in which they are listed in
the policy.

Policy
Request

Assertion 1 Assertion 2 Assertion n
Response
Oracle Web Services Manager (WSM-PM) policies consist of one or more assertions that
exhibit a particular capability or behavior. A policy assertion is the smallest unit of a policy that
performs a specific action. For example, a security policy could be made up of two assertions:
• A Log assertion
• A WS-Security assertion
If this particular security policy is attached to a service endpoint, for the request message, the
log assertion is executed first, logging the request message to a log file; then the WS-Security
assertion that authenticates the requestor based on the token that is sent in the message
decrypts the message (if the message is encrypted).
WSM-PM policy assertions are instances of policy assertion templates that are added to a
policy at policy creation time. WSM-PM:
• Provides a set of predefined policy assertion templates
• Enables users to define custom policy assertions that can be combined with predefined
policy assertions
Note: Custom policy assertions are used when specific functionality is not provided.

Supported Policies
The different types of policies that are supported in Oracle Fusion

Middleware 12c are:
• WS-ReliableMessaging
• WS-Management

• WS-Addressing
• WS-Security
• Message Transmission Optimization Mechanism/XML-binary
Optimized Packaging (MTOM/XOP)

The different type of policies that are available are as follows:

• WS-ReliableMessaging: Reliable messaging policies that implement the WS-
ReliableMessaging standard. These policies describe a wire-level protocol that ensures
guaranteed delivery of SOAP messages, and can maintain the sequential order in which
a set of messages is delivered.
• WS-Management: Management policies that log the request, response, and fault
messages to a message log. Management policies may include custom policies.
• WS-Addressing: WS-Addressing policies that verify that the SOAP messages include
WS-Addressing headers that are in conformance with the WS-Addressing specification.
The transport-level data is included in the XML message rather than relying on the
network-level transport to convey this information.
• WS-Security: Security policies that implement the WS-Security 1.0 and 1.1 standards.
They enforce message protection (message integrity and message confidentiality), and
authentication and authorization of Web service requesters and providers. The following
token profiles are supported: username token, X.509 certificate, Kerberos ticket, and
SAML assertion.
• MTOM/XOP: Binary content, such as an image in JPEG format, can be passed between
the client and the Web service. In order to be passed, the binary content is typically
inserted into an XML document.

Policy Interceptor Pipeline
request request
Reliable Reliable
Messaging Messaging
Client Web service
response Management Management response

Addressing Addressing

Security Security
MTOM Network MTOM
The slide depicts policy interceptors acting on the messages between a client and a Web
service. The messaging order can be described as follows:
1. The client sends a request message to a Web service.
2. The policy interceptors intercept and execute the policies that are attached to the client.
After the client policies are successfully executed, the request message is sent to the
Web service.
3. The request message is intercepted by the policy interceptors, which then execute any
service policies that are attached to the Web service.
4. After the service policies are successfully executed, the request message is passed to
the Web service. The Web service executes the request message and returns a
response message.
5. The response message is intercepted by the policy interceptors, which execute the
service policies that are attached to the Web service. After the service policies are
successfully executed, the response message is sent to the client.
6. The response message is intercepted by the policy interceptors, which execute any
client policies attached to the client.
7. After the client policies are successfully executed, the response message is passed to
the client.

Oracle WSM Predefined Policies and Assertion
Templates
• A set of predefined policies and assertion templates is
available by default.
• You can directly attach these predefined policies to your Web
services or clients.
• The naming convention for security policies is as follows:

oracle/wss10_saml_token_with_message_protection_service_policy
Path Authentication Message protection Policy Type

Location Token
Web Services
Standard
A set of predefined policies and assertion templates is automatically available when you
install Oracle SOA Suite. The predefined policies are based on the common best practice
policy patterns that are used in customer deployments.
You can attach these predefined policies to your Web services or clients, and configure them,
or create a new policy by making a copy of one of the predefined policies.
Policies are attached and configured by using Oracle JDeveloper at design time, and the
Oracle Enterprise Manager Fusion Middleware Control console at run time.
Predefined policies are constructed by using assertions based on the predefined assertion
templates. You can also create new assertion templates, as required.

Viewing Available Web Services Policies
Search Filter Personalize Saved Search

You can use both Fusion Middleware Control and the WebLogic Scripting Tool (WLST) to
view the Web service policies in your domain. In Fusion Middleware Control, you view the
policies by using the Web Services Policies page. To access the page:
1. In the Navigator pane, expand WebLogic Domain to show the domain for which you
want to see the policies
2. Right-click the domain name (in this example, DefaultDomain), and select Web Services
> WSM Policies. The WSM Policies page appears as shown in the slide.
On the Web Services Policies page, you can narrow down the number of policies that are
returned by specifying criteria in the Search Filter.
From this page, you can also create, edit, and delete Web services policies.

Quiz Q
Which of the following statements is not true about WS-Policy?
a. It is a set of specifications that describe the capabilities and
constraints of a Web service.
b. It is used only for security purposes.

c. It consists of one or more assertions that represent a
particular capability or behavior.
d. It is written in XML.

Answer: b
WS-Policy can be used in multiple domains. Oracle Fusion Middleware 12c supports the
following policies:
• WS-ReliableMessaging
• Management
• WS-Addressing
• Security
• Message Transmission Optimization Mechanism (MTOM)

Agenda

– Transport level
– Message level
– SAML

Framework


WSM-PM WS-Security Policies Versus WLS
WS-Security Policies
• Oracle WSM WS-Security policies are used for Web services
or clients that interact with SOA Composite Services, ADF
Components, or WebCenter Services.
• WLS WS-Security policies are used only for WLS native JAX-
WS Web services.

Oracle Fusion Middleware 12c products install a portability layer on top of WebLogic Server
that integrates Oracle Web Services Manager (WSM) WS-Security policies into the WebLogic
Server environment. This portability layer provides the Oracle WSM WS-Security policies that
you can use to protect the WebLogic Server JAX-WS Web services and Web service clients.
You can use the Oracle WSM policies as an alternative to the WebLogic Server WS-Security
policies for enforcing security for Web services. You can also create custom Oracle WSM
WS-Security policies and use them with the WebLogic Web services.
You might want to use Oracle WSM WS-Security policies to protect JAX-WS Web services if
you already use SOA, ADF, or WebCenter applications elsewhere in your environment and
you want to have a consistent security environment.
You should secure a WebLogic Server JAX-WS Web service with Oracle WSM WS-Security
policies to have consistent and interoperable Web service security when these Web services
are used in conjunction with Oracle Fusion Middleware applications. That is, you should
secure WebLogic Server JAX-WS Web services with Oracle WSM WS-Security policies for
use with applications that interact with Oracle Fusion Middleware applications, not with stand-
alone WLS Web service applications.

Securing SOA and Identity Propagation
OrderProcessComposite
Username
Token ProcessOrder
(BPEL) oracle/wss10_saml_token_service_policy
• Verify SAML token.

• Authenticate.

receive • Set Subject.
Web client
• Verify security. SAML

• Authenticate. Binds
• Authorize user.
• Set Subject.
oracle/wss_username_token_service_policy

CCAuth
Credit
Authorization
Fulfillment Service
• Read Subject.
• Insert SAML token.
Finalize oracle/wss11_saml_token_client_policy
The graphic example in the slide illustrates the use of three different policies to authenticate,
authorize, and propagate username credentials. Following the request flow, Web service
policies are used for authentication and identity propagation:
• The Web client obtains the username and password from the user, authenticates the
information, and populates the Username token by using WS-Security headers.
• The ProcessOrder BPEL service entry point applies the
oracle/wss_username_token_service_policy attachment to verify security,
authenticate the user, and set the Subject with the identity details.
• The authorization part may then be applied by using a specified policy.
• The ProcessOrder BPEL component is configured with
oracle/wss11_saml_token_client_policy that is attached to the external
reference for the Credit Authorization Service, causing the process to read the Subject
and insert the identity information into the SAML token that is sent in the request to the
external services.
• The Credit Authorization Service has oracle/wss11_saml_token_client_policy
attached so that it can verify the SAML token, authenticate, and set the Subject, thereby
completing the identity propagation between the service and the client.

Attaching Policies in JDeveloper
(Development Time)
In the composite.xml file, security policies are attached in the
bindings of the following:
• Service: Web service endpoint, for example:
<service
<service name="receiveOrder"
name="receiveOrder" ui:wsdlLocation="receiveOrder.wsdl">
ui:wsdlLocation="receiveOrder.wsdl">
<interface.wsdl
<interface.wsdl interface=".../receiveOrder#wsdl.interface(execute)"/>
interface=".../receiveOrder#wsdl.interface(execute)"/>

<binding.ws
<binding.ws port=".../receiveOrder#wsdl.endpoint(receiveOrder/execute)">
port=".../receiveOrder#wsdl.endpoint(receiveOrder/execute)">
<wsp:PolicyReference
<wsp:PolicyReference URI="oracle/wss_username_token_service_policy"
URI="oracle/wss_username_token_service_policy"
orawsp:category="security"
orawsp:category="security" orawsp:status="enabled"/>
orawsp:status="enabled"/>
</binding.ws>
</binding.ws> </service>
</service>
• External reference: Web service client, for example:

<reference name="getCreditCardStatus" ... >
<interface.wsdl interface=".../getStatusByCC#wsdl.interface(execute)"/>
<binding.ws
port=" ... /getStatusByCC#wsdl.endpoint(getStatusByCC/execute_pt)"
location=" ... /validationForCC/getStatusByCC?WSDL">
<wsp:PolicyReference URI="oracle/wss11_saml_token_client_policy"
orawsp:category="security" orawsp:status="enabled"/>
</binding.ws> </reference>
The examples in the slide are presented to give a brief idea of how security policies can be
attached to service endpoint bindings in the composite.xml file at design time in
JDeveloper.
Thus, security policies can be declaratively attached to the inbound requests (the service
endpoints) to a SOA composite, and the outbound requests (the external reference: Web
service client to Credit Authorization Service) from the SOA composite.
The URI attributes in each example identify the policy names, which define one or more
security assertions that are applied at run time to enforce the policy rules during the request-
response message life cycle.
Note: The various URL references in the examples have been shortened (indicated by “…”)
to make it easier to read. Security policies and those used in the examples are discussed on
the subsequent pages of this lesson.

Viewing Attached Policies in EM Console

After the composite application is deployed, you can view the attached policies in the EM
Console. The Policies page displays:
• The attached policy name
• The component to which the policy is attached
• The policy reference status (enabled or disabled)
• The policy category (Management, Reliable Messaging, MTOM Attachment, Security, or
WS Addressing)
• The violations
In addition, the Policies page enables you to toggle the status of the attached policy. When a
policy is attached to a Web service, it is enabled by default. You may temporarily disable a
policy for a single endpoint without disassociating it from the Web service. When a policy is
disabled for an endpoint, it is not enforced for that endpoint. In this example, two security
policies are attached to the ValidateCreditCard_ep Web service, and only
wss_username_token_service_policy is enabled.
Note: A policy can be globally disabled from the Edit Policy page. You can disable a policy
from this central location, and it will be disabled for any policy subject to which it is attached.

Attaching and Detaching Policies By Using EM Console

1

On the Policies page, you can attach policies to and detach policies from the SOA service
components. To do so:
1. Select the component or subject to Attach To or Detach From the policy. The options
are:
- Service endpoints (service binding component)
- Service clients (reference binding component)
- SOA components

Attaching and Detaching Policies By Using EM Console

2

This invokes a dialog box for attaching or detaching policies. The currently attached policies
appear in the Attached Policies section. Additional policies that are available for attachment
appear in the Available Policies section.
2. Select policies to attach that are appropriate to your environment, and click Attach. The
attached policy appears in the Attached Policies section. You can attach additional
policies as needed.
3. When you have finished attaching policies, click Validate. If an error message appears,
make the necessary corrections until you no longer have any validation errors.

Monitoring the Performance of the SOA Composite

On the same Policies page of the composite instance, you can monitor web service endpoint
statistics, or monitor client-specific operation statistics. The following statistics are presented:
• Policy Reference Status
• Category
• Total Violations
• Security Violations
- Authentication
- Authorization
- Confidentiality
- Integrity
The statistics described in the preceding list are started or reset when any one of the following
events occurs:
• When the application is being deployed for the first time
• When the application is redeployed
• If the application is already deployed, and the hosting server is restarted

Quiz Q
Policies can be attached to service endpoints at both design time
and deployment time.
a. True
b. False

Answer: a

Summary

• Describe Web services security
• Describe Oracle Web Services Manager Policy Framework
• Create or modify a security policy

• Attach a security policy to Web services
• Monitor the performance of Web services



• Creating a simple username token service security policy
• Applying the security policy to a service endpoint
• Testing the application with, and without, the credentials

supplied with the client request

In this practice, you use the Oracle Web Services Manager interface to create a simple
security policy that you apply to a service endpoint. You then test the service invocation by
supplying the WS-Security information that is enforced by the attached policy and also by not
supplying it.

16

Enterprise Scheduler Service

Objectives

• Describe the Enterprise Scheduler Service
• Install ESS
• Configure jobs and related metadata

• Administer running and completed jobs


Agenda
• Enterprise Scheduler Service: Introduction

• Setting up and configuring ESS
• Defining ESS Jobs
• Monitoring and administering ESS


Enterprise Scheduler Service: Introduction
Start and Stop

Composites.

Activate &
Deactivate
Adapters.

Job 1
Job 2 Job Orchestration

With BPEL
Job N
Most applications do significant amount of work in the background or on a schedule. Integration

applications are no exception. Enterprise job scheduling is the key activity that allows IT to
prioritize strategic and urgent business needs by defining the processing window of various
back-office jobs. An enterprise job scheduler helps IT increase productivity and reduce costs
through automation of recurring and scheduled jobs, and resource management.
The Enterprise Scheduler Service (ESS) is included in SOA Suite (starting with version 12.1.3).
ESS provides out of the box support for:
• Scheduling SOA composites and proxy services
• Activation and deactivation of adapters
• Orchestrating jobs by using BPEL
• Execution of user-created scripts
• Bulk fault notifications and recovery

What the Enterprise Scheduler Service Provides
The Enterprise Scheduler Service provides:

• Metadata-based schedule, job, and resource definitions
• Multi-technology support for job implementations
– Java, PL/SQL, scripts, Web Services, and EJB

• Support for job dependencies
– Sequential and parallel execution of a set of jobs
– Serialized execution of incompatible jobs
• Security enforcement and identity propagation

• Centralized and integrated administration console (Enterprise
Manager)
• High availability and scalability architecture through clustering

Job Modeling
Work
Assignment
1:n 1:1 1
1. A Job Type is the basic Job Type
maps
definition of what a job • Java
consists of. Work Shift Specialization • PL/SQL

2. A Job Definition, (or Job), is • Web Svc
the smallest unit of work that is
• EJB
performed. Selects jobs
3.
defines
A Job Set is a sequential or and/or • Script
job sets
parallel set of Job Steps, where
Schedule Resource
a Job Step can be a single Job
or another Job Set.

3 2
group of
Job Set Job Definition
A Job Type is the basic definition of what a job consists of. It defines whether the job is of the
Java, PL/SQL, web service, EJB, or Script type.
A Job Definition (or Job) is the smallest unit of work that is performed in the client application’s
context. It is defined by the associated Job Type and additional parameters that are specific to
the job definition.
• The Java Executable class if the job is of the Java type, or the PL/SQL function if the job
is of the PL/SQL type, or the script if the job is of the spawned type
• Parameter definitions for the job and their data type, and default values
A Job Set is a sequential or parallel set of Job Steps, where a Job Step can be a single Job or
another Job Set.

Schedule and Resource Modeling
Work
Assignment
1. A Job Schedule is a predefined
1:n time 1:1
or a recurrence for a period of time.
2. Resources define the threads and maps
throttling that will be allocated.
Work Shift Specialization

selects jobs and/or
defines job sets
Schedule Resource
1 2

group of
Job Set Job Definition
A Job Schedule is a predefined time, a recurrence for a period of time, or an indefinite period
of time. Schedules are defined independent of Jobs but are associated with one or more Jobs
at run time when Requests are submitted.
Resources define the threads and throttling that will be allocated.

Schedule and Resource Modeling
Work
3
Assignment
1:n 1:1
maps
1 2

selects jobs and/or
defines job sets
Schedule Resource

1. A Work Shift defines the resources to be
allocated and the duration for which the
resources are available for job requests.
group of
2. A Specialization definesJob Set
restrictions for job Job Definition
request processing on a request processor.
3. Together, these comprise a Work Assignment,
which defines a set of work shifts and the jobs
that can run in those work shifts.
A Work Assignment consists of a specialization rule and one or more work shifts.
A Work Shift defines the temporal windows when jobs can be processed and the resources
that can be used during these periods. The resources defined in a work shift include threads,
which are a local resource of the request processor, and asynchronous workers, which are a
global resource. The number of asynchronous workers can be specified to throttle the use of a
shared global resource, such as database jobs.
A Specialization defines restrictions for job request processing on a request processor. It
consists of conditions that are joined with operators (AND, OR, and NOT).
Note: Job request processing can be restricted by:
• The user that submits a job
• Job category (user-defined classification)
• Product that the job belongs to
• Application that the job belongs to
• Job name

Integration with SOA
Components Used
ESS Clients ESS Component
by ESS Jobs
Enterprise
Manager
6
1

ESS (job types)
SOA Infra SOA composite
Web
3
EJB Service
OSB proxy
Web Services Scripts
Web
Client
Service
(SOA composite) 2 4

EJB SOA Infra
MDS ESS
Runtime Run
ESS DB Time
Metadata
1. SOA Infra uses the ESS APIs to submit and query jobs. At the scheduled time, ESS
invokes the job.
2. There is also a web service interface to submit a job, query status, and perform other tasks.
You can invoke this web service from a BPEL process in a SOA composite.
3. Composite applications and Service Bus proxy services with a web service interface can be
executed at the scheduled time by ESS.
4. An EJB job can invoke predefined EJBs for SOA to perform bulk recovery, fault notification,
or adapter activation and deactivation.
5. The Oracle Metadata Repository stores Oracle Enterprise Scheduler Service job metadata.
6. Enterprise Manager is the primary interface to configure, manage, and monitor jobs.

Job Security
ESS
Submit

User Job

ESS always checks whether a
user has the privilege to:
• Submit a job
• Add, delete, or update metadata
• View or operate on a job request
Access Control to ESS Metadata and Requests

• ESS filters the list of jobs or job sets metadata that the current user can submit in the user
interface. It always checks whether a user has sufficient privileges to submit a job.
• ESS always checks whether a user has the privilege to add, delete, or update job
metadata.
• It always checks whether a user has the privilege to view or operate on a job request
(data security).
Runtime Identity Management
• A job always runs as the user that submits the job.
• Certain jobs can be configured to run with an application identity that has elevated
privileges.

Agenda



Basic Tasks for Configuring and Managing ESS

• Setting Up and Configuring ESS
• Creating Jobs to Run
• Bundling Jobs and Refining Their Work
• Monitoring the System
Administrator Enterprise
Manager

Oracle Enterprise Scheduler Service is administered by using the Oracle Enterprise Manager
Fusion Middleware Control Console (Fusion Middleware Control). In the Console, the
Scheduling Service home page provides an overview of the scheduler component status, the
top running and completed scheduled job requests, as well as a performance summary of the
scheduled job requests. Other Scheduling Service pages provide a user interface for
performing the tasks that are described subsequently.
A summary of the steps that you will perform to set up Oracle Enterprise Scheduler Service is
as follows:
Setting Up and Configuring ESS
1. Create a domain and configure a cluster. Oracle Enterprise Scheduler Service is installed
by a product that includes it as a service to manage schedules. However, it is possible
that the embedding product did not configure the domains that support Oracle Enterprise
Scheduler Service for deploying.
2. Configure a request processor and a request dispatcher. A job request processor is
bound to a particular Oracle Enterprise Scheduler Service server, and is responsible for
allocating threads for job requests. A job request dispatcher polls for job requests.
3. Start the instance.

Creating Jobs to Run
1. Create job definitions. You can define and manage job definitions that specify values that
are specific to the request at hand.
2. Create schedules. You can define a schedule for managing the execution of job requests,
work assignments, work shifts, and purge policies. You can also create schedules on the
fly when creating a request.
3. Create and submit job requests. A job request pulls together a job definition with a
schedule on which the job runs.
4. Create a purge policy. Purge policies allow you to define the conditions for retaining and
purging the job requests that are associated with a request processor.

Bundling Jobs and Refining Their Work
1. Create job sets. With job sets, you can bundle jobs into groups in which the jobs run at
the same time or in a sequence.
2. Define restrictions with incompatibilities. Incompatibilities specify which jobs should not
run at the same time, along with the conditions under which they are incompatible.
3. Define restrictions with work assignments. Work assignments define rules under which

jobs can be processed, along with windows of time in which they can run.
Monitoring the System
You can monitor job requests, system performance, and system status. You can also get logs
for job requests and the system.

Extending a Domain with ESS
1. Create the ESS schemas with

the RCU. Physical/Virtual Physical/Virtual
Server 1 Server 2
2. Extend the domain.
Node Node
3. Pack the extended domain Manager Manager
and unpack the configuration
on the Managed Server hosts.
1
4. Verify the health and

accessibility of the ESS.
Domain
Admin 2
Server

4 3 3
Administrator Enterprise Cluster
Manager
ESS is automatically installed as part of SOA Suite. Deployment is optional in SOA. ESS can
be deployed to a SOA cluster or to a separate cluster in the domain by using the domain
configuration wizard.
The task of extending a domain with Oracle Enterprise Scheduler Service requires:
1. Creating the ESS schemas in the Oracle Database with the Repository Creation Utility
2. Extending the domain with the Oracle Enterprise Scheduler Service component and
targeting the component to the existing SOA Managed Servers
3. Packing the extended domain and unpacking the updated configuration on the Managed
Server hosts
4. Verifying the health and accessibility of the ESS services after starting the domain

Configuring a Job Request Dispatcher
Enable/disable. Poll for jobs.

Set polling interval. work assignment = ready
Request

Dispatcher
Administrator Enterprise
Manager

ESS Repository
work assignment =
waiting
To configure a request dispatcher, perform the following steps:

1. From the navigation pane of Enterprise Manager, expand the Scheduling Services folder
and select the Oracle Enterprise Scheduler Service application.
2. From the Scheduling Services menu, select Request Dispatcher, and then select
Configure.
3. In the Enable Request Dispatcher field, enable or disable the request processor. Select
the Enable Request Dispatcher check box to enable request dispatching.
4. Optionally, in the Advanced Configuration section, configure the polling interval for the
request dispatcher. In the Maximum Poll Interval field, enter the smallest appropriate
interval value at which the dispatcher polls for requests.
5. Click Apply to save your changes.

Starting the Instance
ESS Component
Web
EJB Service

Web Scripts
Service
Administrator Enterprise EJB
Manager

MDS
Runtime
Start/Stop* ESS DB
• ESS instance Metadata
• Request processor
and dispatcher
Starting and Stopping an Oracle Enterprise Scheduler Service Instance

The Control menu for the scheduling service allows you to start an Oracle Enterprise Scheduler
Service instance and consequently begin managing the scheduled job requests.
To start (or stop) an instance of Oracle Enterprise Scheduler Service, from the Scheduling
Service menu, select Control. Select Start Up or Shut Down as required.
Note: Stopping an Oracle Enterprise Scheduler Service instance or component is not
recommended. Shutting down an Oracle Enterprise Scheduler Service component does not
stop job requests from accumulating in the queue.
You can start or stop a configured request processor or dispatcher from the Scheduling Service
menu.
1. From the navigation pane, expand the Scheduling Services folder and select the Oracle
Enterprise Scheduler Service application.
2. From the Scheduling Services menu, select Request Processor and click Start, or click
Start Up on the Home page. Select a request processor in the Scheduler Components
area. Click the Start or Stop button.
3. When prompted, click OK.

Agenda



Creating a Web Service Job Definition
Concrete
WSDL

Job
Definition

Web Service Job Type
• SOA suite composite
• OSB proxy service
• ADF Business Component
Oracle Enterprise Scheduler Service lets you run job requests of different types. For each type,
you need to specify certain metadata to define the characteristics of the job that you want to
run. You may also want to specify properties of the job request, such as the schedule for when
it runs.
The graphic in the slide illustrates the web service job type. A web service job can call a SOA
Suite composite, an OSB proxy service, or an ADF business component. To call a web service,
the job definition includes most of the information contained in the concrete Web Services
Definition Language (WSDL) for the web service.

Creating Schedules
Recurrence: Contains an expression that

represents a pattern for a recurring date
and time

Explicit Date: Defines a date for use in a
schedule or for exclusion

Exclusion: Contains a list of dates to
exclude or dates and times to exclude from
a schedule
Using Oracle Enterprise Scheduler Service, you can create a schedule to determine when a job
request runs or use a schedule for other purposes, such as determining when a work
assignment becomes active. A schedule can contain a list of explicit dates, such as July 14,
2012. A schedule can also include expressions that represent a set of recurring dates (or times
and dates).
Using Oracle Enterprise Scheduler Service, you create a schedule with one or more of the
following:
• Explicit Date: Defines a date for use in a schedule or for exclusion
• Recurrence: Contains an expression that represents a pattern for a recurring date and
time. For example, you can specify a recurrence representing a regular period such as
Mondays at 10:00 AM.
• Exclusion: Contains a list of dates to exclude or dates and times to exclude from a
schedule. For example, you can create an exclusion that contains a list of holidays to
exclude from a schedule.

Creating and Submitting Job Requests
ESS Component
Web
EJB Service
Web Scripts

Job Service
Request EJB

MDS
Job Runtime
ESS DB
Definition Metadata
You can submit a job request by selecting a job definition that defines the metadata you want
and by defining a schedule that guides when the job runs.
You create a job request by selecting a job definition for the job request, and then selecting or
creating a schedule. You may want to configure system properties for the job request, such as
the number of retries to attempt in the event of an execution error and a timeout value for the
job.
To submit a job request, perform the following steps:
1. Use a pre-existing job definition (or create a new job definition).
2. Select the application for which you want to submit the job request.
3. Select a job definition.
4. Optionally define any parameters that you want to use with the scheduled job request.
5. Select a schedule by which the job is to run.
You can configure a recurring job request by using a job request schedule. Alternatively, you
can configure a job request to run immediately or before a specified end date. Specify how
often (frequency) you want job requests that use this schedule to run. Give the schedule a
name. This appears when you assign the schedule to a job request.

Creating Job Sets
Job Set
Collections of job definitions
that can be grouped together Job Set
to run as a single unit are
called a job set.
Job

Job
A job set may contain a

collection of job definitions or
Job
one or more child job sets.

Each job definition or job set
included within a job set is
Job
called a job set step.
Oracle Enterprise Scheduler Service provides for collections of job definitions that can be
grouped together to run as a single unit called a job set. A job set may be nested; thus, a job
set may contain a collection of job definitions or one or more child job sets. Each job definition
or job set included within a job set is called a job set step.
A job set is defined as either a serial job set or a parallel job set. At run time, Oracle Enterprise
Scheduler Service runs parallel job set steps together, in parallel. When a serial job set runs,
Oracle Enterprise Scheduler Service runs the steps one after another in a specific sequence.
Using a serial job set, Oracle Enterprise Scheduler Service supports conditional branching
between steps based on the execution status of a previous step.
You can define a serial job set to include a parallel job set, or a parallel job set to include a
serial job set. Job sets that include a mix of parallel and serial job sets are called complex job
sets. For example, when a serial job set contains a child parallel job set, the serial job set runs
serially until it reaches the child parallel job set. Then, all the job definitions or job set definitions
in the child parallel job set run in parallel. On completion of the child parallel job set, the serial
job set continues running its remaining steps serially. Nested parallel job sets behave the same
as non-nested parallel job sets.

Defining Restrictions with Incompatibilities
Job
Job Job

Incompatibilities specify which jobs
should not run at the same time.
Incompatibilities can be defined
between jobs and/or job sets. Job Set

Job
Job
Job
An Oracle Enterprise Scheduler Service incompatibility specifies which jobs should not run at
the same time, along with the conditions under which they would be incompatible.
Incompatibility can be defined between jobs and/or job sets. An incompatibility defines either a
global incompatibility or a domain-specific, property-based incompatibility.
An incompatibility consists of one or more job definitions that are configured as incompatible,
and (optionally), the resource over which they must be incompatible. A resource is not specified
for a global incompatibility.

Binding a Work Assignment to a Request Processor
1 2
Work binds to Request
Assignment 3 Processor
1:n 1:1
maps

selects jobs and/or
defines job sets
Schedule Resource

1. A Work Assignment defines a set of work shifts and
the jobs that can run in those work shifts.
2. A Request Processor represents an ESS node
group of in
an ESS cluster, and defines Job Set
the available threads. Job Definition
3. Binding associates a work assignment with a
request processor on a server, determining where
the jobs can run.
Recall that a Work Assignment consists of a specialization rule (restrictions for job request
processing on a request processor) and one or more work shifts (defines the temporal windows
when jobs can be processed and what resources can be used during those periods).
A Request Processor represents an ESS node in an ESS cluster, and defines the available
threads. A request processor is mapped to a server.
Binding associates a work assignment with a request processor on a server, determining
where jobs can run. An exclusive binding mode is supported to not only determine when jobs
can run but also to prevent them from running anywhere else.
Note: By default, no work assignments are bound. When there is no bound or active work
assignment, a virtual default work assignment is started to process all jobs by using all
available resources. This default work assignment is limited to the number of threads that are
configured for the processor, but there is no default limit for asynchronous workers. To limit
asynchronous workers, it is necessary to create and bind one or more work assignments.

Agenda



Creating a Purge Policy
ESS Component
Web
EJB Service
Web Scripts
Service
Administrator Enterprise EJB
Manager

A purge policy automates purging of completed
job history. Purging is actually done in two steps:
• Logical Purge is done by using a purge
policy in Enterprise Manager.
MDS

• Physical Purge is done by a DBA by using a
Runtime
pre-deployed PL/SQL stored procedure. ESS DB
Metadata
DBA
Purge policies allow you to define the conditions for retaining and purging the job requests that
are associated with a request processor. Purge policies allow the scheduling service to remove
completed jobs according to specified criteria. For example, a purge policy might specify the
retention of all Java type job requests by using a particular job definition that was submitted for
execution by a given application for three days. Another purge policy might retain a particular
type of job request—for example, all SQL job requests in a successful state—for only one day.
You can also specify the frequency at which the purge policy is to run. Purge policies are
crucial to establish in a production system.
Job request data is kept in the Oracle Enterprise Scheduler Service runtime store as records in
the runtime store tables. Purging is done in two steps. First, a logical purge is done by using a
purge policy in Enterprise Manager. Then, a physical purge is done by a DBA by using a pre-
deployed PL/SQL stored procedure.
Defining a purge policy involves:
• Selecting the jobs to be purged: The selection criteria would include the related
application or product, a particular job definition or job type, and the job submitter or a
maximum number of requests.
• Specifying retention criteria: Decide how long job requests are to be retained depending
on their status.
• Specifying purge frequency: Decide how often you want the purge policy to run.

Monitoring Oracle Enterprise Scheduler Service:
Overview
The bulk of ESS monitoring is done with Enterprise Manager, and
is related to job requests.
• You can get a snapshot of recent work done as job requests,
including the load that the requests are placing on the system.
You can also view the status of current and pending requests.

• For an Oracle Enterprise Scheduler Service instance, you can
find out how it is performing currently and how it has
performed historically.
• You can get the status of a service instance, as well as that of

service components such as the request dispatcher and
processor.
• Finally, you can get log information about job requests and
Oracle Enterprise Scheduler Service.

Quiz
Q
ESS can be used within SOA to:
a. Schedule SOA composites and proxy services
b. Activate and deactivate adapters
c. Orchestrate jobs by using BPEL

d. Execute user-created scripts
e. Perform bulk fault notifications and recovery
f. All of the above

Answer: f

Summary

• Describe the Enterprise Scheduler Service
• Install ESS
• Configure jobs and related metadata

• Administer running and completed jobs



• Practice 16-1: Extending the Domain with Oracle Enterprise
Scheduler
– In this practice, you extend the Oracle WebLogic edg_domain
to include Oracle Enterprise Scheduler Service (ESS)

• Practice 16-2: Activating and Deactivating Adapters Using
ESS
– In this practice, you deploy an application that uses an inbound
file adapter. You then activate and deactivate the inbound file

adapter, and observe the changes in behavior.

17

Oracle Cloud
An Overview

Agenda
1
What is Cloud Computing?
2
Cloud Evolution
3
Components of Cloud Computing
4 Characteristics and Benefits of Cloud
5 Cloud Deployment Models

6 Cloud Service Models
7 Oracle Cloud Services


What is Cloud?
The term Cloud refers to a Network or Internet.
It is a means to access anyy Software that is available remotely.

y


What is Cloud Computing?
• It is a means to access any Software that is available remotely.

• Refers to the practice of using remote Servers hosted on Internet to store,
manage and process data
• When you store your photos online instead of on your
home computer, or use webmail or a social networking
site,
it you are using
i a “cloud
“ l d computing”
ti ” service.
i


History – Cloud Evolution
Cloud Computing
SaaS Computing
Next generation
Utility Computing Internet
Grid Computing Network based Computing and
Offering subscription to next generation
Silos Computing Computing applications Data Centers
S l i large
Solving l Resources as a

problems with metered
Basic computing parallel service
with dedicated Computing
physical
hardware


Components of Cloud Computing
Client Computers Distributed Servers Data Centers
Data

Devices that end user Often Servers are in Collection of servers where
interact with cloud. Types geographically different application is placed and is

of client Thick, Thin (Most places, but server acts as if accessed via Internet
popular), Mobile they are next to each other

Characteristics of Cloud
Description
 Allows
All users to
t use the
th service
i on demand
d d
On Demand
Self Service  Anywhere, Anytime and Any Device
Rapid Ubiquitous
Elasticity Network Access
 Draw from a pool of computing resources, usually in
remote data centers
Measured Resource
Service Pooling  Request and manage own computing resources

 Service is measured and customers are billed
Pay as you Virtualization accordingly
use
Application
Programming  Select a configuration of CPU, Memory and storage
Interface

 Services can be scaled larger or smaller

Cloud Deployment Models
Deployment models define the type of access to the Cloud.
•The platform for cloud

•Type of cloud hosting in which the computing is implemented on a
cloud services are delivered over a cloud-based secure
network which is open for public environment that is
usage safeguarded by a firewall which
Public Private is under the governance of the
IT department that belongs to
Cloud Cloud the particular organization.

Hybrid Community
• It is an arrangement of two or Cloud Cloud
more cloud servers, i.e. private, •Type of cloud hosting in which
public or community cloud that the setup is mutually shared
is bound together but remain

between many organizations
individual entities.

Cloud Service Models
All three tiers of computing delivered as Service via global network

• Applications: Software as a Service - SaaS
• Platform: Database, Middleware, Analytics, Integration as a Service –
Platform as a Service - PaaS
• Infrastructure: Storage, Compute, and Network as a service –
Infrastructure as a Service - IaaS

SaaS PaaS IaaS


• Provides computer hardware (servers,

networking technology, storage and data center
space) as a web based service.
IT Professional
Customizations
• Virtual Machines with p
pre-installed Operating
p g
Consumer

Application
System
Platform
• Target: Administrators
Provider
• Ready to Rent

IaaS

• Provides platform to develop and deploy

applications
Developer
Customizations • Up to Date Software
Consumer
Application

• Target: Application Developers
• Ready to Use
Provider
PaaS


• Allows usage of the software remotely as a web

based service
Business End User
• Software are automatically Upgraded and
onsumer
Customizations
Updated
Co • All Users are running the same version of the

Software
Provider
• Target: End Users

SaaS • Ready to Wear


Industry Shifting from On-Premises to the Cloud
Transition to the Cloud is driven by a desire for:

• Agility: Self-service provisioning – deploy a database in minutes
• Elasticity: Scale on demand
• Lower cost: Reduction in management and total cost – pay for what is used
• Back to core business: Focus on core activities

• More mobility: Access from any device



Oracle IaaS Overview IaaS
Designed for large enterprises,

enterprises which allow them to scale up their computing
computing, networking
networking,
and storage systems into the cloud, rather than expanding their physical infrastructure.
• Allows large businesses and organizations to run their workloads, replicate their
network, and back up their data in the cloud.


Oracle PaaS Overview PaaS
• Develop, deploy, integrate and manage applications on cloud.

• Seamless integration across PaaS and SaaS Applications.


Oracle SaaS Overview SaaS
Delivers modern cloud applications that connect business processes across the
enterprise.
• Only Cloud integrating ERP, HCM, EPM, SCM
• Seamless co-existence with Oracle’s On-Premise Applications


Summary
In this lesson, you should have:

• Got an overview of Cloud Computing, its Characteristics, History and
Technology
• Understood the various components , Deployment Models and Service
Models of Cloud Computing
• Understood the Oracle Cloud Services


18
Oracle SOA Cloud Service Overview

Objectives
After completing this presentation, you should be able to:

• Describe the benefits and advantage of running Oracle SOA Suite in the
cloud
• Describe the components that comprise the Oracle SOA Cloud Service
• Describe the additional components needed for Oracle SOA Cloud Service

• Describe high-level differences between running Oracle SOA in the cloud
and on-premises environments


About Oracle SOA Cloud Service
• Oracle SOA Cloud Service provides a PaaS (Platform as a Service)

computing platform solution for running Oracle SOA Suite, Oracle Service
Bus and Oracle API Manager applications in the cloud.
• Oracle SOA Suite provides a complete set of service infrastructure
components for designing, deploying, and managing composite
applications.
applications

• Oracle Service Bus is a configuration-based, policy-driven enterprise service
bus that provides capabilities for service discovery and mediation, rapid
service provisioning and deployment, and governance.
• Oracle API Manager allows you to create and publish APIs that can then be

easilyy discovered byy your
y developer communityy through
g an API Portal.

Benefits of Oracle SOA Cloud Service
• Provides a PaaS (Platform as a Service) computing platform solution for

running Oracle SOA Suite applications in the cloud.
• Provides a complete set of service infrastructure components for deploying,
and managing composite applications in the cloud.
• Reduces IT maintenance and administrative costs.
• Quickly subscribe to Oracle SOA Cloud Service to create application test

environments in the cloud.
• Initiate backups, patching, scaling, and recoveries with minimal
configuration from the cloud.
• Extend your enterprise to the cloud and deploy Oracle SOA Suite projects

where you need them
them.

Components of Oracle SOA Cloud Service
• Oracle SOA Suite

• Oracle Service Bus
• Oracle Technology Adapters
• Oracle Cloud Adapters
• g
Oracle API Manager

• Oracle Business Activity
Monitoring


Oracle SOA Suite
• Build, deploy, and manage integrations using

service- oriented architecture (SOA).
• Transform complex application integrations into
agile and reusable service-based applications.
• Shorten the time to market, respond faster to
b i
business requirements,
i t and d llower costs.
t

• Critical business services, can now be rapidly
modeled for mobile devices such as smart
phones and tablets.


Oracle Service Bus
Standards-based integration for high-volume SOA environments.

Connects, mediates, and manages interactions between:
• heterogeneous services
• legacy applications

• packaged applications
• multiple enterprise service bus (ESB) instances
Adheres to the SOA principles of building coarse-grained, loosely coupled, and
standards-based services.
Connect service consumers and back-end business services, regardless of

underlying
d l i iinfrastructure.
f t t

Oracle Technology Adapters
• Are JCA compliant adapters.

• Provide a robust, lightweight,
highly- scalable and standards-based
integration framework.
• Ensure interoperability by integrating
applications
li ti th
thatt are heterogeneous,
h t

provided by different vendors, based
on different technologies, and run on
different platforms.


Oracle Cloud Adapters
• Simplify and accelerate integration with your SaaS applications.

• Provide lower costs of implementation and maintenance.
• Are easier to use.
• Improve developer productivity.
• pp faster time-to-market for SaaS application
Support pp integrations.
g


Oracle API Manager
• Oracle API Manager facilitates the

creation of APIs that expose
functionality of backend systems or
other services.
• APIs are published for use by application developers and are managed and
monitored at runtime
runtime.

• Developers can create WSDL-based SOAP proxy services and REST proxy
services to be published as APIs.
• Developers subscribe to and view information necessary to consume
the APIs.

• Administrative users can use the API Manager Portal to monitor usage
metrics and performance analytics at runtime.

Oracle BAM
• Oracle Business Activity Monitoring (Oracle

BAM) is used to monitor business processes for
making tactical and strategic decisions.
• You can create dashboards that contain
graphical views of data updated either in real time as
streams or on a scheduled basis
basis.

• Oracle BAM also supports alerting capabilities for business users to monitor
business events, manage business exceptions, and continuously optimize
their processes.


Additional Components Needed for Oracle SOA Cloud
Service
Oracle Database Cloud Service is required to host the Oracle Fusion
Middleware component schemas.
• Make sure you have a subscription to Oracle Database Cloud Service
(Database as a Service),
You must select an Oracle Storage Cloud Service when provisioning an Oracle
D t b
Database Cl
ClouddSService.
i

• Always select an Oracle Database Cloud Service that has an Oracle
Storage Cloud Service associated with it.
Oracle Java Cloud Service (JCS) is required to implement some functionality.


Additional Components Needed for Oracle SOA Cloud
Service
Virtual Machine (VM) public key
• An SSH public/private key pair is used for authenticating access to a VM
through an SSH client.
• You generate an SSH public/private key pair using a standard SSH key
generation tool.
Prior to using Oracle SOA Cloud Service, ensure you’re familiar with the

following:
• Oracle Cloud
• Oracle Compute VMs
• Oracle WebLogic Server

• Oracle Traffic Director

Differences Between the Cloud and On-Premises
Environments
Oracle SOA Cloud Service Oracle SOA Suite On-Premises
• Available by subscription on the • You install Oracle SOA Suite on your
Oracle Public Cloud (OPC). own hardware.
• Automatically includes Oracle Java • You create the complete domain.
Cloud Service, which provides an
Oracle WebLogicg Server domain.

• Oracle Java Cloud Service provides • You must develop your own archival
OPC-based backup services. infrastructure.
• During Oracle SOA Cloud Service • You must install a database.
provisioning, you select the database.
• High availability functionality is
• You must set up an environment based

provided by default using a virtual
machine restart. on your high availability requirements
requirements.

Differences Between the Cloud and On-Premises
Environments
Oracle SOA Cloud Service Oracle SOA Suite On-Premises
• Load balancing is provided by the • Oracle HTTP Server serves as the load
built-in Oracle Traffic Director. balancer.
• Application deployment directly from • Applications can be deployed directly
Oracle JDeveloper to the cloud is not from Oracle JDeveloper.
supported.

• Shared storage is not available in the • You typically use shared storage.
cloud.
• External network access must be • Network access for on-premises
configured at the virtual machine level. networks varies from site to site
• Logins to the virtual machine can be

done throughg an SSH tunnel.

Summary
In this presentation, you should have learned how to:

• Describe the benefits and advantage of running Oracle SOA Suite in the
cloud
• Describe the components that comprise the Oracle SOA Cloud Service
• Describe the additional components needed for Oracle SOA Cloud Service

• Describe high-level differences between running Oracle SOA in the cloud
and on-premises environments


A

Appendix A

Composite Instance Patching

Oracle SOA Suite 12c: System Architecture and Administration A - 2

Overview of Composite Instance Patching
The composite instance patching feature:

• Provides the ability to make minor changes to composites and
BPEL processes
• Supports applying changes at runtime without having to create
a new version of the composite, which has running instances

• Provides design time tooling to ensure only permissible
changes can be made to your composites and business
processes
• Provides the ability to create and distinguish between a full

deployment file and sparse deployment file
• Provides command-line utilities to validate and apply a sparse
deployment profile

Cycle of Composite Instance Patching Process
Error occurs
Start
Recover
JDeveloper with
instance in
SOA Patch
Error Hospital
Developer role

Validate and
Fix error
apply patch with
condition
WLST

Generate sparse
Generate the
deployment
patch.xml
profile

Switching to SOA Patch Developer Role
Tools > Switch Roles > SOA Patch Developer

When JDeveloper starts, you are prompted to select the role to start JDeveloper. The list of
roles now includes a new role called SOA Patch Developer. In 12.2.1, the new SOA Patch
Developer role is introduced for design time. This role ensures that only valid changes can be
made to the composites for Composite Instance Patching to be effective. Artifacts created
while in this role are uniquely identified using predefined naming conventions.
When you switch roles or login as Studio Developer role, JDeveloper detects the presence of
patch.xml and lets you know that you have changes made in patch developer role. This is to
ensure that incompatible changes do not get written to patch.xml.
A Patch File Found dialog is displayed with three options:
• Switch back to the SOA Patch Role so you can continue your work
• Close projects that have a patch.xml file so you do not overwrite
• Delete the patch.xml after absorbing the changes so you can continue to work on the
projects in the regular role

Generate the patch.xml
Patch.xml is:
• The first artifact that will be generated whenever you make
any changes in the SOA Patch Developer role
• Generated while you save files in the SOA Patch Developer
mode

• Generated to indicate the components that have changed
• Created in the project’s SOA/SCA-INF folder
• Contains only the changes that have been added in the patch

mode
Note: Sensor information is also gathered to ensure that the
DT@RT changes (if any) are retained

Generate a Sparse Deployment Profile
A sparse deployment file can be generated by using JDeveloper.

• Select deploy using an existing profile (or create a new one).
• Create a connection to the Weblogic for deployment.
• In the Deployment Configuration, there is no choice to create

a new version or overwrite an existing version, because the
sparse deployment profile applies changes to the existing
version.
• By default, ‘_patch’ is added to the sparse deployment file
name generated.

Note: The sparse deployment contains the files that have
changed, whereas a full deployment has all the files.
Using WLST:
• To create the patch JAR use the sca_packagePatch command:
Syntax would be sca_packagePatch(compositeDir, compositeName, revision,
appHome, oracleHome)
• to validate the patch run the sca_validatePatch:
Syntax: sca_validatePatch("http://localhost:7003", "weblogic", "welcome1",
"/path/to/ca_ProcessOrder_patch.jar")
• To apply the patch, use the sca_patchComposite command:
Syntax: sca_patchComposite("http://localhost:7003", "weblogic", "welcome1", "
/path/to/sca_ProcessOrder_patch.jar ")
Note: Undeploying a sparse patch is not supported in this release (12.2.1)

Use the WLST Tool to validate and apply the patch
WLST can be used to create, validate, and apply the sparse

patch, with the following commands:
• The sca_packagePatch command to create the patch JAR
• The sca_validatePatch command to validate the patch

• The sca_patchComposite command to apply the patch
Note: Removing (undeploying) a sparse patch is not supported in
the 12.2.1 release

Using WLST:
• To create the patch JAR, use the sca_packagePatch command:
Syntax would be sca_packagePatch(compositeDir, compositeName, revision,
appHome, oracleHome)
• To validate the patch, run the sca_validatePatch:
Syntax: sca_validatePatch("http://localhost:7003", "weblogic", "welcome1",
"/path/to/ca_ProcessOrder_patch.jar")
• To apply the patch, use the sca_patchComposite command:
Syntax: sca_patchComposite("http://localhost:7003", "weblogic", "welcome1", "
/path/to/sca_ProcessOrder_patch.jar ")
Note: Removing a sparse patch is not supported in the 12.2.1 release.

In-Memory SOA
Improving performance of specific applications


Performance Problem
• Customers with High volumes and/or high SLA expectations

like avoiding disk write and reads and leverage coherence
cache.
• Minimize database over heads for completed transactions
• Current behavior:

– Persist all state and flow data
– Requires regular purging to control database growth


In-Memory Solution
• Dramatically cuts down disk I/O by using coherence cache for

instance tracking, BPEL dehydration
• Has the choice to persist only
on error- flow trace,
BPEL state, audit trail,
SOA

and payloads BPEL Process BPEL Process BPEL Process
Immediate Faulted Deferred
• Has a configurable
write-behind thread for
Deferred option,

and still gives a huge
Incomplete
performance boost All data Only
faulted State data
data
• Lowers database
maintenance costs and Coherence
Dehydration
improves linear scalability Store
Incomplete Cache
State data
Flow, component interaction and their state remains entirely in memory, one or more inputs
are processed intended output is generated with no trace if it completes successful with no
error. During an error, Flow is persisted to database for analysis.
• Enable it by setting inMemoryEnvironment at "common properties" to true (refer
configuration)
• Non transactional adapters, "non-transactional”, long running Bpel processes, and
transactional or non-transactional short running Bpel process can be part of in-memory flow.
• Participating Bpel component, completionPersistPolicy property, defines flow execution model
- Faulted: Flow is persisted only on fault/error
- Deferred: Flow is persisted asynchronously with delay
- Immediate: Regular behavior. Flow is persisted at dehydration
• completionPersistPolicy property is ignored and persisted to database if the component
is long running and a transnational process.
• Audit Level and Audit Store Policy have no bearing on the flow persistence behavior,
persisted or not, and when it is persisted, it is determined by the participating
component's completionPersistPolicy. If the flow is persisted, Audit Level continues to
determine what audit events are part of flow and Audit Store Policy determines how
these events are persisted.
Note: Assume that a lot of memory is available
In-Memory Integration
• Set at the component level – allows mixed processes in a

transaction
• Non - XA transactions only
• Business processes with the property set to “faulted” will not
have audit details on successful completion

• Enterprise Manager flow trace will only read from dehydration
database
• Minimizes ongoing database growth and purge volumes


In-Memory Integration: Use Cases
• Asynchronous call back transactions with short SLA times

• Transactions having small percentage of human interventions
• Chatty transactions with short lived life cycles
• Synchronous and asynchronous transactions that do not

require extensive audit trail


States for In-Memory SOA Instances
Completion Component State Flow State

Persists
Policy
Immediate At dehydration component, It is persisted along with component
state is persisted to db. instance(s) state to db.

Deferred At dehydration component, Flow state, flow trace, and
state is persisted to cache. component instance(s) audit are
persisted to cache.

Faulted Component state Flow state, flow trace, and
(associated Invoke and component instance(s) audit are not
callback messages) is not persisted. On Fault, it is persisted to
persisted for successful Db right away, it can be recovered
execution. from EM (or by auto recovery). On
completion, flow is marked for
immediate purge.
When "In Memory SOA" is enabled, SOA execution behavior is described in the following
manner:
• Immediate: Backward compatibility (: old equivalent value: On). At dehydration,
component state is persisted to db. Flow state/trace is persisted along with component
instance(s) state to db.
• Deferred: At dehydration component, state is persisted to cache.
- It is persisted to db by write-behind thread on configurable "write delay".
- State includes Invoke/callback messages associated with component instance.
Flow state, flow trace, and component instance(s) audit are persisted to cache.
- It is persisted to db by write-behind thread on configurable "write delay"
- Note: At least one component participating in flow is "On", Flow state is persisted
to Db along with component, and cache is not used.
• Faulted: Component state (associated Invoke and callback messages) is not persisted
for successful execution.
- During execution, if component instance hits a dehydration, its state is persisted to
cache, and deleted on completion.
- If instance completion takes longer than write delay, it gets persisted to Db. Refer
"Flow" for EM visibility.
- On Fault, component state is persisted to Db right away.

• Flow state, flow trace, and component instance(s) audit are not persisted.
- If any participant component executes dehydration, it is persisted to Cache. When
flow completes (active instance count is zero), it is deleted from cache.
- If Flow execution takes longer than write delay, it persisted to Db.
- On completion, flow instance is marked for purge if it is in Db.
On Fault, it is persisted to Db right away, and it can be recovered from EM (or by auto
recovery). On completion, flow is marked for immediate purge.
Note
- At least one component participating in flow is "On", Flow state is persisted to Db
along with component, and cache is not used.

- At least one component participating in flow is "Deferred", Flow state is persisted to
cache, and on "write delay“, it is persisted to Db.

Managing Instances
Enterprise Manager continues to work with database, with no

cache and database only. In general, long running process
completion time is greater than write behind delay, Flow/Bpel
state persisted to database is snapshot at the time of write. And it
does not get updated until the next cycle (minimum is write

delay). If users are checking the state, there is a high possibility
that they are viewing stale state. Faulted flows are flushed to
database on encountering fault, so the state user observing in EM
is current.


Configuring In-Memory SOA
• SOA Adminstration" -> "common properties"->

inMemoryEnvironment
• WLST:
connect('weblogic', 'weblogic1')

custom()
cd('oracle.as.soainfra.config/oracle.as.soainfra.config:n
ame=soa-infra,type=SoaInfraConfig,Application=soa-
infra')
set('InMemoryEnvironment', true)

exit()
Configure Cache size

Caches are used by InMemory with default values along with the name of system property to
override them, the value is in KB.
A value of 1024 means 1MB.
Out-of-the-box cache configurations are tuned for SOA servers configured with 4GB heap.
Make sure you run SOA server with 4GB heap when InMemory is enabled, because default
2GB heap configuration may cause OOM issues under stress.

Integrated Workload Statistics
Monitoring and Troubleshooting SOA-Wide Issues


Integration Workload Statistics (IWS) Reports
• Provide SOA systemwide reports

• Help analyze utilizations
• Identify potential bottlenecks and backlogs
• Perform top-down analysis of your integration system

• In 12.21. release, monitoring of the following components is
supported:
– BPEL Service Engine
– EDN

– Web Service Binding, File Adapter, JMS Adapter, FTP Adapter,
DB Adapter, AQ Adapter, and MQ adapter
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 these down. 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.

IWS Reports Identify Bottlenecks and Backlogs
IWS reports can help you narrow down stressed components or

endpoints in your SOA system that are slowing down the system.
For example:
• Identifying slow FTP or database adapter reference endpoints
• Identify BPEL process running slower than expected

• View internal queue backlogs such as BPEL queues and EDN
queues
• View SOA composite-wise summaries


Sample Scenario: Slow Downstream Service Causing
Back log and Error Instances
SOA Infra
Composite Unavailable/
Instance Slow

downstream
service
Back log Error Hospital
Composite Composite
instance
Composite instance
Composite
instance instance

NOTE: This diagram is intended to illustrate the “CONCEPT” of the scenario
and not the internal technical implementation (unknown to author). However,
the question that arises: Is the back log queue different to the error hospital
instance queue?

Performance Tuning Areas
Java Virtual Machine SOA Infrastructure

Composite

Instance Database

Performance Tuning with Oracle SOA Suite
Java Virtual Machine
SOA Infrastructure
Drill Composite

down instance
Dehydration/ Database
Service for

hydration
application data
Database
NOTE: The diagram illustrates the four areas that may require attention as a
result of performance problems depending on what is reported by IWS.

IWS Data Collection and Reports
SOA Infrastructure
IWS Metrics IWS Reports

collection

Generating an
Animate HTML report

capturing data
with moving Database
arrow

IWS Data Collection and Reports
• IWS takes periodic snapshots of performance statistics.

• IWS generates reports that can include:
– Metrics, such as system resource usage
– Composite statistics
– Internal system queue statistics

– Synchronous and asynchronous business process statistics
– Endpoint statistics
• IWS data is stored in separate tables under SOAINFRA
database schema

– By default, the data is kept for seven days.
– The purging is managed by common purging framework.
– User can do manual purging.

Configuring Data Collection Levels for IWS Reports
Granularity of IWS reports, that is, the data collection levels,

statistics levels, and data collected for each level are illustrated in
the following table:
Data Collection Data Collected
Level/Statistics Level

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
NORMAL NORMAL + Data on all BPEL activities
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. To configure the IWS data collection settings in Enterprise Manager:
• Select Monitoring > IWS Reports from the SOA Infrastructure menu. The IWS
Reports page appears.
• Click Configure near the top right corner of the page. The Configure IWS Data
Collection dialog appears.
• Select a Snapshot Interval in minutes. The snapshot interval is the periodic interval at
which data snapshots are collected.
• 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 systemwide 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 select Normal, it includes
additional statistics on BPEL activities like Receive, Invoke, Pick, and
onMessage. The Finest level additionally includes data on all BPEL activities.
• Click OK to save your configuration changes.

Configuring IWS Data Collection in Enterprise Manager


Generating an IWS Report
The IWS Reports page is used to create SOA-wide reports that:

• Help identify bottlenecks and backlogs in the system
• Include metrics like system resource usage
• Composite statistics

• Statistics for internal system queues
• Statistics for synchronous and asynchronous business
processes
• Endpoint statistics.

You must have already configured IWS data collection and set a
snapshot interval.
Use the following steps to create an IWS report in Enterprise Manager Fusion Middleware
Control:
• Select Monitoring > IWS Reports from the SOA Infrastructure menu. The IWS Reports
page appears.
• Select the period for which you want 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.
• Select the SOA Server Name. You can either accept the default server, or select a
different node in cases of multi-cluster environments. For clusters, you can also select
the cluster name to generate a consolidated report for all nodes in the cluster.
• (Optional) Enter the result of the step here.
• Optionally select a partition name if you are using composite partitions and want 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.
• Under Select Composites, optionally select one or more composite names to restrict
your report to the specified composite applications.
• Optionally change the number of results that are displayed. So, if you select the default
of 10, the 10 slowest endpoints, the 10 longest running business processes, and so on,
are selected.
• Click the appropriate report format near the top right of the window to generate and
download the report. You can select between CSV (comma-separated
values), HTML, and XML formats.
The IWS report is generated and downloaded.


Generating an IWS Report


IWSReport MBean
The IWSReport Mbean and its associated operations can be used

to:
• Retrieve information about the data collected for your
Integration Workload Statistics (IWS) reports
• Retrieve data such as snapshot IDs, date, and timestamps

• Generate IWS reports using the supplied snapshot
parameters


IWS WLST Commands
Online WLST Commands can be used to:

• Configure IWS data collection
• Retrieve snapshot information and generate reports

Configure IWS data collection, such as:

• 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
Retrieve snapshot information and generate reports:
• getSoaIWSSnapshotInfo: Retrieves snapshot information from a SOA server or all
servers for the supplied number of hours
• getSoaIWSSnapshotInfoByDate: Retrieves snapshot information 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

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

IWS reports contain 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, and so on) based on
execution time.

Resiliency: Circuit Breaker


Problem and solution
Problem
• Unavailable services downstream cause instances to fail and
fill up the error hospital.
• Manual Recovery is cumbersome and time consuming.

• Failing instances consume unnecessary resources.
Solution
• Automatically suspend upstream inbound services so the
messages accumulate in queues on disk.


The Resiliency Solution
Resiliency enables you to configure the system to:

• Suspends upstream endpoints when a downstream endpoint
is down in a SOA composite
• Prevents fault buildup in the server and eliminating the need
to bulk-recover faulted instances

• Resumes upstream endpoints after the downstream endpoint
becomes active/available
• Monitors downstream services, such as adapters and web
service bindings

• Suspended upstream inbound services, which may be
temporarily resumed to see if downstream services are now
up, configured based on intervals
Enable Resiliency globally by configuring it at the SOA Infrastructure level. When 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.
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.

Unavailable Downstream Service Results in Suspended
Upstream Service
SOA Infra
Unavailable
Upstream Composite
downstream
service instance

service
Fault
Error Hospital
Composite
Composite
instance Composite
Composite
instance instance

instance

and not the internal technical implementation.

Upstream Service
SOA Infra
Unavailable
Upstream Composite
downstream
service instance

service
Suspended
Error Hospital
Composite
Composite
instance
instance

and not the internal technical implementation. However, the question that
arises is: Beta labs required using the error hospital to do some bulk
recovery, when documentation indicates that this should not be necessary?

Upstream Service
SOA Infra
Available
Upstream Composite
downstream
service instance

service
Resumed
Error Hospital

and not the internal technical implementation. However, the question that
arises is: Beta labs required using the error hospital to do some bulk
recovery, when documentation indicates that this should not be necessary?

Alternative example diagram to embellish

Composite Composite
Unavailable
Suspend


Types of Upstream Endpoints Supported
The following types of upstream endpoints can be automatically

suspended:
• Web Service: Incoming requests are rejected for the duration
that the web service is suspended, that is, web services will
also be suspended and will return errors.

• Adapters: JMS, AQ, DB, File, and FTP adapters can be
automatically suspended in this release.
• EDN Subscribers: The EDN subscriber closest to the
downstream endpoint gets 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.

Configuring Resiliency at the Global Level
• Resiliency settings automatically resume suspended services

when the downstream endpoint becomes active
• Alerts can be defined when services are suspended/resumed
• Log file has records for suspended/resumed endpoints

• Enable/disable globally or per downstream service.

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
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 five minutes, then a downstream endpoint failing
10 times in a span of five 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.
5. Optionally, Click Add Notification to configure SMS, email, 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.

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 want 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 want to change.

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
• The properties for a Reference endpoint to override the global

Resiliency settings for the endpoint
Mbean Property Endpoint Property
circuitBreakerEnabled circuitbreaker.disabled

failureRate circuitbreaker.failure.rate
failureRateTime circuitbreaker.failure.rate.time
resumeInitialDelay circuitbreaker.resume.initial.delay
resumeRampupTime circuitbreaker.resume.rampup.time
retryTimeInterval circuitbreaker.retry.interval
Property descriptions are:

• circuitBreakerEnabled: Enables or disables Resiliency
• failureRate: The threshold count of errors that trigger Resiliency
• failureRateTime: 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. (Not available as a property on the endpoint)
• resumeInitialDelay: 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: The time duration, in minutes, after which the initial delay is
reduced to zero. 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 five minutes.
• retryTimeInterval: Periodic interval, in minutes, at which the downstream endpoint is
tested by temporarily re-enabling the upstream endpoint, and letting trickle messages
through.

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.

You can click 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.

Viewing and Resuming a Suspended Endpoint
Example: An upstream web service (bpelprocess1_client_ep)

suspended, because the downstream endpoint (fileReference)
has failed three times in 10 minutes.
bpelprocess1

_client_ep
BPELProcess1 fileReference

Click Resume to have
the service continue
processing.

Locating Activity in the Log File
Resiliency related messages are:

• Written to the log file
• Located by searching for strings like “CircuitBreaker” in the
Log Messages page


IWS and Resiliency
IWS can be configured to take snapshot information and generate

reports that can help identify backlog and issues related to
services and endpoints affected by resiliency.


D87561GC10 sg2 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D87561GC10 sg2 PDF

Uploaded by

Copyright:

Available Formats

This document should not be distributed.

For Instructor Use Only.

Student Guide – Volume II

Learn more from Oracle University at education.oracle.com

Glenn Stokol Disclaimer

Ron Pinkerton This document contains proprietary y information and is protected by

This document should not be distributed.

For Instructor Use Only.

1 Introduction to Oracle SOA Suite 12c Administration

This document should not be distributed.

For Instructor Use Only.

2 Planning an Oracle SOA Suite 12c Deployment Architecture

This document should not be distributed.

For Instructor Use Only.

This document should not be distributed.

For Instructor Use Only.

This document should not be distributed.

For Instructor Use Only.

This document should not be distributed.

For Instructor Use Only.

7 Fundamentals of Oracle SOA Suite

This document should not be distributed.

For Instructor Use Only.

This document should not be distributed.

For Instructor Use Only.

8 Deploying and Testing Composite Applications

This document should not be distributed.

For Instructor Use Only.

9 Managing the Composite Application Life Cycle

10 Administering Composite Applications at Run Time

This document should not be distributed.

For Instructor Use Only.

11 Administering Business Events

This document should not be distributed.

For Instructor Use Only.

13 Troubleshooting and Performance Tuning of Oracle SOA Suite 12c

This document should not be distributed.

For Instructor Use Only.

This document should not be distributed.

For Instructor Use Only.

15 Configuring Security Services and Policies

This document should not be distributed.

For Instructor Use Only.

16 Enterprise Scheduler Service

This document should not be distributed.

For Instructor Use Only.

18 Oracle SOA Cloud Service Overview

This document should not be distributed.

For Instructor Use Only.

This document should not be distributed.

For Instructor Use Only.

After completing this lesson, you should be able to:

This document should not be distributed.

Oracle SOA Suite 12c: System Architecture and Administration 11 - 2

• Introducing Business Events and the Event Delivery Network

This document should not be distributed.

Oracle SOA Suite 12c: System Architecture and Administration 11 - 3

• Event: Is a message structure that represents the occurrence

This document should not be distributed.

For Instructor Use Only.

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

Oracle SOA Suite 12c: System Architecture and Administration 11 - 4

Events are one-way, fire-and-