Professional Documents
Culture Documents
D87561GC10 sg2 PDF
D87561GC10 sg2 PDF
Editors
Vijayalakshmi Narasimhan
Aju Kumar
Graphic Designer
Seema Bopaiah
Publishers
Giri Venugopal
Michael Sebastian Almeida
Jobi Varghese
Sumesh Koshy
Contents
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
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
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
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
Practice 5: Overview 5-20
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
Practice 6: Overview 6-41
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
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
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
Practice 9: Overview 9-30
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
Practice 11: Overview 11-19
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
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
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
xv
Agenda 16-24
Creating a Purge Policy 16-25
Monitoring Oracle Enterprise Scheduler Service: Overview 16-26
Quiz 16-27
Summary 16-28
Practice 16: Overview 16-29
17 Oracle Cloud
Agenda 17-2
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
xvii
For Instructor Use Only.
This document should not be distributed.
11
This lesson discusses business events and Event Delivery Network concepts, and how to
monitor business events in Enterprise Manager.
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.
Event subscribe
Delivery
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.
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
Composite Java
Application Event Delivery Network Application
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.
Answer: a
Event Delivery Network (EDN) provides a standard JMS-based messaging infrastructure.
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
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.
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.
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.
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.
Answer: c
Mediator and BPEL components support business events in both JDeveloper and Enterprise
Manager.
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.
• Introduction to UMS
• Configuring UMS
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.
BPEL Process
Email
UMS
Email
Activity
Activity
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 Process
Email
UMS
User
Notification
Activity
Activity
SMS
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.
Human Email
UMS
Task
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.
• Introduction to UMS
• Configuring UMS
WebLogic Domain
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.
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.
WebLogic Server
Voice
Administrator IM
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.
Physical/Virtual Physical/Virtual
Server 1 Server 2
WLST Domain
Admin
Server
Administrator
Cluster
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.
Common Properties
• Quality of Service WebLogic Server
• Driver Cost EMAIL
• Driver Speed
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.
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.
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.
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.
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.
Changes require
a server restart.
1 3
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.
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.
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.
• Hardware resources
• Operating system
• Java Virtual Machine (JVM)
• Database
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.
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 Enterprise Manager Fusion Middleware Control
• 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.
Oracle SOA Suite 12c: System Architecture and Administration 13 - 8
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
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.
2 3 7 8
Register Notify Invoke Write
Diagnostics
Incident notification listener
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.
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.
a1
b1
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.”
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.
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.
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
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.
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 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.
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.
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 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.
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.
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.
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 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.
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
This section describes how to troubleshoot some common problems that you can encounter
when using Oracle SOA Suite.
• 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
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.
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.
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.
• 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
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.
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.
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.
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
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).
• Online
– Nondisruptive
– Possibly inconsistent
– Possibly tricky, especially for a database
• Offline
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.
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.
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.
Answer: b
To be consistent, the Middleware software must be completely stopped.
config product
config
Runtime artifacts
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.
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.
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.
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.
• 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.
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.
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.
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.
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.
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”).
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 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:
– Specifies whether the SOAP messages between a client
application and the Web service should be:
— Digitally signed: Ensures data integrity
— Encrypted: Ensures confidentiality
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.
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.
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
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).
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.
WebCenter
Services
Security &
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.
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
Reliable
MTOM Security Addressing Management
Messaging
Metadata
Services
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
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:
– 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
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.
Reliable Reliable
Messaging Messaging
Client Web service
response Management Management response
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.
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.
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.
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)
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.
OrderProcessComposite
Username
Token ProcessOrder
(BPEL) oracle/wss10_saml_token_service_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.
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.
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.
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
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.
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
Answer: a
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.
Job N
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
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.
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
Schedule Resource
1 2
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.
Work
3
Assignment
1:n 1:1
maps
1 2
Work Shift Specialization
Schedule Resource
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
Components Used
ESS Clients ESS Component
by ESS Jobs
Enterprise
Manager
6
1
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.
ESS
Submit
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.
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
Request
Administrator Enterprise
Manager
ESS Component
Web
EJB Service
Concrete
WSDL
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.
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.
ESS Component
Web
EJB Service
Web Scripts
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.
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
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.
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.
1 2
Work binds to Request
Assignment 3 Processor
1:n 1:1
maps
Schedule Resource
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.
ESS Component
Web
EJB Service
Web Scripts
Service
Administrator Enterprise EJB
Manager
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.
Answer: f
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
Data
• Ready to Rent
Application
• Ready to Use
Provider
PaaS
onsumer
Customizations
Updated
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
Error occurs
Start
Recover
JDeveloper with
instance in
SOA Patch
Error Hospital
Developer role
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
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
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)
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.
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
Oracle SOA Suite 12c: System Architecture and Administration A - 11
In-Memory Integration
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.
connect('weblogic', 'weblogic1')
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.
SOA Infra
Composite Unavailable/
Instance Slow
SOA Infrastructure
Drill Composite
Dehydration/ Database
Service for
NOTE: The diagram illustrates the four areas that may require attention as a
result of performance problems depending on what is reported by IWS.
SOA Infrastructure
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.
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.
Oracle SOA Suite 12c: System Architecture and Administration A - 28
• 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.
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.
Problem
• Unavailable services downstream cause instances to fail and
fill up the error hospital.
• Manual Recovery is cumbersome and time consuming.
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.
SOA Infra
Unavailable
Upstream Composite
downstream
service instance
SOA Infra
Unavailable
Upstream Composite
downstream
service instance
SOA Infra
Available
Upstream Composite
downstream
service instance
Unavailable
Suspend
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.
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.
circuitBreakerEnabled circuitbreaker.disabled
failureRateTime circuitbreaker.failure.rate.time
resumeInitialDelay circuitbreaker.resume.initial.delay
resumeRampupTime circuitbreaker.resume.rampup.time
retryTimeInterval circuitbreaker.retry.interval
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.
bpelprocess1