Introduction and Concepts

1 Introduction and Concepts

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

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

What Is Oracle Fusion Middleware?

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

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

What Is Oracle SOA Suite?

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

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

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

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

Introduction to the SOA Infrastructure Application

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

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

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

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

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

Description of "Figure 1-1 SOA Composite Applications Deployed in the SOA Infrastructure"

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

Figure 1-2 SOA Composite Application Home Page

Description of "Figure 1-2 SOA Composite Application Home Page "

For more information, see the following sections:

Introduction to SOA Folders

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

You can perform the following tasks:

Deploy SOA composite applications into a SOA folder using Oracle Enterprise Manager Fusion Middleware Control, Oracle JDeveloper, WebLogic Scripting Tool (WLST) commands, or ant commands.
Access the folder and its deployed composites using the SOA Folders tab on the SOA Infrastructure page.
Perform the following bulk lifecycle management tasks on the composites in a specific folder:
- Start all composites
- Shut down all composites
- Undeploy all composites
- Retire all composites
- Activate all composites
- List all composites
Secure user access to folders, which provides the following benefits:
- Administrative access control
- Striping of instance data by folders
- Folder level resource management

Note:

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

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

Introduction to SOA Composite Applications

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

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

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

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

Figure 1-3 SOA Composite Application

Description of "Figure 1-3 SOA Composite Application"

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

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

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

For more information, see the following documentation:

Introduction to Business Flow Instances

When you create an instance of a SOA composite application, a business flow instance is created. A business flow instance is defined as follows:

Corresponds to an end-to-end business transaction.
Consists of a single SOA composite application or multiple SOA composite applications connected together in a business flow. The SOA composite application that initiates the business flow instance is known as the initiating composite. All other SOA composite applications in the business flow instance are known as the participating composites. A business flow can also include Oracle Service Bus components.
Provides a complete view of the flow, rather than a subsection of the flow.
Is identified by a single flow ID value.

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

Monitor the state of business flow instances (completed, recovery required, and so on).
Delete or terminate business flow instances.
Recover from faults.
View composite sensor values.
View the initiating and participating composites.
View any resequencing groups.

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

Programmatically invoke the service and pass a unique ID through a WS-Addressing header (messageId).
Create an instance using the Test Web Service page. The only exception to this is when the Enable Stress Test checkbox of the Additional Test Options section of the Test Web Service page is selected. In that case, a conversation ID is not created for the instance.

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

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

For more information, see the following sections:

Introduction to Service Components

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

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

BPEL process: For process orchestration of synchronous and asynchronous processes
BPMN process (if Oracle BPM Suite is installed): For creating and modeling business processes using Business Process Management Notation and Modeling (BPMN)
Oracle Mediator: For content transformation and routing events (messages) between service producers and consumers
Human task: For modeling a human task (for example, manual order approval) that describes the tasks for users or groups to perform as part of an end-to-end business process flow
Spring: For integrating Java interfaces into SOA composite applications
Decision service: For making a decision or for processing based on business rules

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

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

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

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

Spring Service Component Support

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

There are no spring service engine management pages.
A spring composite is displayed in the flow trace, but there is no audit trail for it.
Spring composite metrics are shown in the composite application home page.
The spring service component does not support the running and terminated instance states. Because the spring service component is synchronous, by design, there is no support to terminate the synchronous, running spring instance. Therefore, you cannot abort the running instance and cannot have a terminated state for the spring service component.

Introduction to Binding Components

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

Services: Provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. The service bindings define how a SOA composite service can be invoked (for example, through SOAP).
References: Enable messages to be sent from the SOA composite application to external services (for example, the same functionality that partner links provide for BPEL processes, but at the higher SOA composite application level).

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

Figure 1-7 Binding Components

Description of "Figure 1-7 Binding Components"

For more information, see Administering Binding Components.

Introduction to Service Engines

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

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

Figure 1-8 Service Components Running in a Service Engine

Description of "Figure 1-8 Service Components Running in a Service Engine"

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

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

Note:

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

Introduction to the Service Infrastructure

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

For more information, see the following sections:

Monitoring Message Delivery Processing Requests
Developing SOA Applications with Oracle SOA Suite for details about wiring

Introduction to the Contents of SOA Composite Applications

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

BPEL processes
BPMN processes (if Oracle BPM Suite is installed)
Human workflows
Oracle Mediator
Decision services (Oracle Business Rules)
Spring
JCA adapters
HTTP binding
REST service
EJB service
Direct binding service
Oracle Application Development Framework (ADF) Business Component service
Oracle BAM 11g (This adapter can only connect to an Oracle BAM 11g server.)
Oracle B2B
Oracle Healthcare
Business events
Oracle User Messaging Service

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

Introduction to Oracle SOA Suite and Oracle Enterprise Scheduler Integration

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

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

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

Schedule web services (composites, proxy services, and others).
Schedule adapter activate and deactivate.
Schedule fault notification and bulk fault recovery.
Schedule scripts.
Submit jobs and job sets from Oracle SOA Suite/Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control. You can use Oracle Enterprise Scheduler web service jobs to schedule SOA composite applications:
- Create job definition metadata using Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control and secure the job with Oracle Web Services Manager (OWSM) policies. The job definition must be created in the namespace /oracle/apps/ess custom/soa. The SOA system administrator has Oracle Enterprise Scheduler permissions to create this job. For information about creating job metadata, see Managing Job Metadata in Administering Oracle Enterprise Scheduler.
- Submit the job using Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control and define a schedule when submitting the job. For information about submitting jobs, see Managing Oracle Enterprise Scheduler Requests in Administering Oracle Enterprise Scheduler.
Create custom metadata from Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control.
Manage, view job output, throttle, and control threads in Oracle Enterprise Scheduler in Oracle Enterprise Manager Fusion Middleware Control.
Submit a job from a BPEL process.
Use Enterprise Scheduler Web service (ESSWebservice) to access a subset of the Oracle Enterprise Scheduler runtime functionality. The ESSWebservice is provided primarily to support SOA integration, for example invoking Oracle Enterprise Scheduler from a BPEL process. However, any client that needs a Web service to interact with Oracle Enterprise Scheduler can use ESSWebservice. ESSWebservice exposes job scheduling and management functionality for request submission and request management.
Use all Oracle Enterprise Scheduler WLST commands in Oracle SOA Suite environments, as described in WLST Command Reference for SOA Suite.

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

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

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

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

The first part publishes where the URL is written to the service table.
The second part consumes where the service table is read and the URL is cached in the local configuration.

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

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

What Is Oracle Business Process Management Suite?

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

Oracle BPM Suite provides the following:

Enables you to create process models based on standards with user-friendly applications. It enables collaboration between process developers and process analysts. Oracle BPM supports BPMN 2.0 and BPEL from modeling and implementation to runtime and monitoring.
Enables process analysts and process owners to customize business processes and Oracle Business Rules.
Provides a web-based application for creating business processes, editing Oracle Business Rules, and task customization using predefined components.
Expands business process management to include flexible, unstructured processes. It adds dynamic tasks and supports approval routing using declarative patterns and rules-driven flow determination.
Unifies different stages of the application development lifecycle by addressing end-to-end requirements for developing process-based applications. Oracle BPM Suite unifies the design, implementation, runtime, and monitoring stages based on a service component architecture (SCA) infrastructure. This allows different personas to participate through all stages of the application lifecycle.

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

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

Oracle Business Rules
Human workflow
Oracle adapter framework for integration

For more information, see the following documentation:

Administration of Oracle SOA Suite and Oracle BPM Suite

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

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

Configuration of Oracle SOA Suite and Oracle BPM Suite

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

SOA Infrastructure (impacting all SOA composite applications)
Service engines (impacting all service components that execute in the service engine, no matter the SOA composite application in which they are included)
SOA composite application (impacting all service components that are included in that composite application)
Oracle B2B bindings
Service and reference binding components message header properties

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

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

Introduction to the Order of Precedence for Audit Level Settings

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

Individual BPEL activity
BPEL process or BPMN process service component
SOA composite application
Service engine
SOA Infrastructure

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

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

BPEL Activity	Component	Composite	Service Engine	SOA Infrastructure	Which Setting Takes Effect?
No property	No property	No property	Inherit	Production	SOA Infrastructure This is the out-of-the-box setting. The audit level is set to Production. The SOA Infrastructure settings are inherited by the child (Service Engine, composite, component, activity) levels. No property defaults to Inherit.
No property	No property	No property	Inherit	Off	SOA Infrastructure The audit level is set to Off. This is the recommended setting, and leads to performance enhancements. Depending on your audit requirements, you can then individually set the audit levels for composites that require auditing for debugging or compliance.
No property	No property	Production/Development	Inherit	Off	Composite The audit level is set to Production/Development. The composite setting overrides the setting at the SOA Infrastructure level.
No property	Production/Development	No property	Inherit	Off	Component The audit level for the component is set to Production/Development, overriding the settings at parent levels.
Production/Development	No property	No property	Inherit	Off	BPEL Activity. The audit level for the BPEL activity is set to Production/Development, overriding the settings at the parent levels.

Note:

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

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

The following sections describe configuring audit levels:

See Configuring the SOA Infrastructure for more information about configuring audit level settings at the SOA Infrastructure level.
See Configuring BPEL Process Service Engine Properties for more information about configuring audit level settings at the BPEL service engine level.
See Managing the State of an Application from the SOA Composite Application Home Page for more information about configuring audit level settings at the composite level.
See Setting the Audit Level at the BPEL Process Service Component Level for more information about configuring audit level settings at the BPEL component level.
See “Auditing SOA Composite Applications at the BPEL Activity Level” in Developing SOA Applications with Oracle SOA Suite for more information about configuring audit level settings at the BPEL activity level.

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

Monitoring of Oracle SOA Suite and Oracle BPM Suite

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

Business flow instances, faults, and rejected messages in the SOA Infrastructure or individual SOA folder.
Service engine, service infrastructure, and binding component processing request performance.
Service and reference binding component message processing totals and average processing times.
Audit trail and process flow behavior in service components. For BPMN processes, the entire BPMN process flow is displayed, and the path taken by the process instance is highlighted.
Service engine request and thread states in BPEL processes, BPMN processes, Oracle Mediator, and human workflows.
Adapter configuration, monitoring, and snapshot reports.

Note:

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

Management of Oracle SOA Suite and Oracle BPM Suite

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

Creating and deleting SOA folders. Once you create SOA folders, you can deploy a composite to the appropriate SOA folder. This action enables you to logically group SOA composite applications into SOA folders.
Creating and managing work manager groups. Each SOA folder is associated with a work manager group that consists of work managers. A work manager is an Oracle WebLogic Server entity that represents a logical thread pool. You can define priorities for the work to be processed by work managers.
Securing user access to SOA folders. This limits users to administering only the composites within the SOA folder to which they are granted access.
Managing the composite state (activating, retiring, starting, stopping, and setting the default composite version).
Deleting and terminating business flow instances.
Deploying, undeploying, and redeploying SOA composite applications.
Exporting a deployed SOA composite application to a JAR file.
Initiating SOA composite application test instances from the Test Web Service page.
Recovering from faults at the SOA Infrastructure level or individual SOA folder level.
Recovering rejected messages in BPEL processes.
Creating error notification rules at the SOA Infrastructure or individual SOA folder level that cause an alert message to be triggered when specific fault criteria are met.
Scheduling the activation and deactivation of JCA adapter services.
Performing automated testing of SOA composite applications.
Attaching policies to SOA composite applications, service components, and binding components.
Managing incoming and outgoing notification messages in human workflow.
Subscribing to business events and testing of event publications.
Disabling and enabling the collection of analytic, BPEL sensor, and composite sensor data.
Storing instance and callback message data in Oracle Coherence distributed cache on Oracle Exalogic platforms.

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

Note:

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

Introduction to Fault Recovery in the Error Hospital

In 12c, fault recovery is centralized at the SOA Infrastructure level (for all SOA folders) and individual SOA folder level. This differs from 11g, where fault recovery actions were displayed at multiple levels (SOA Infrastructure, SOA composite application, service engine, and service component).

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

The following types of fault recovery are supported.

Recovery from individual faults, where you have access to the most granular recovery options specific to each type of fault
Recovery from multiple (bulk) faults, where you select multiple faults for recovery

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

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

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

Business: Application-specific faults that are generated when there is a problem with the information being processed (for example, a social security number is not found in the database).
System: Network errors or other types of errors such as a database server or a web service being unreachable.
Oracle Web Service Manager (OWSM): Errors on policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

Faults can also be classified as either of the following:

Recoverable or nonrecoverable:

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

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

Table 1-2 Recoverable and Nonrecoverable Faults

Recoverable Faults	Nonrecoverable Faults
Business faults and some specific system faults Oracle Mediator input file path and output directory mismatch An Oracle BPM Worklist user is not authorized to perform relevant (expected) actions	Rejected messages Most system faults Non-existent references Service invocation failures Policy faults

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

For information about the Fault Policy Editor, see How to Design a Fault Policy for Automated Fault Recovery with the Fault Policy Wizard in Developing SOA Applications with Oracle SOA Suite.

Introduction to Policies

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

SOA composite applications
Service components
Service and reference binding components

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

Security: Implements WS-Security 1.0 and 1.1 standards. They enforce authentication and authorization of users, identity propagation, and message protection (message integrity and message confidentiality).
Reliable Messaging: Supports the WS-ReliableMessaging protocol, guaranteeing the end-to-end delivery of messages.
Message Transmission Optimization Mechanism (MTOM): Ensures that attachments are in MTOM format, a format for efficiently sending binary data to and from web services.
WS-Addressing: Verifies that SOAP messages include WS-Addressing headers in conformance with the WS-Addressing specification. Transport-level data is included in the XML message rather than relying on the network-level transport to convey this information.
Management: Logs request, response, and fault messages to a message log. Management policies can include custom policies.
SOAP over JMS: Enables web services and clients to communicate using JMS destinations instead of HTTP connections.
Configuration: Enables web service features, such as Fast Infoset, schema validation, persistence, and so on.
Atomic Transactions: Supports web service WS-AtomicTransaction (WS-AT) transaction interoperability between Oracle WebLogic Server and other vendor's transaction processing systems.

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

For more information, see the following documentation:

Managing SOA Composite Application Policies
Managing BPEL Process Service Component Policies
Managing Policies
Managing Human Workflow Service Component Policies
Managing Binding Component Policies
Managing BPMN Process Service Component Policies
Securing Web Services and Managing Policies with Oracle Web Services Manager and Understanding Oracle Web Services Manager for definitions of available policies and details about which policies to use for your environment

Introduction to How Policies are Executed

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

A policy attached to an Oracle Mediator service component is executed on the wire before the message is passed to Oracle Mediator. This causes the fault to be displayed in the service binding component instead of Oracle Mediator.
A policy attached to a human task service component is executed in the preceding BPEL process service component before the message is passed to the human task service component. This causes the fault to be displayed in the BPEL process service component instead of the human task service component.
A policy attached to a human task service component is executed inside the BPMN process in the human steps associated with the human service component before the message is passed to the human task service component. This causes the fault to be displayed in the BPMN process service component instead of the human task service component.

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

Introduction to the Lifecycle State of SOA Composite Applications

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

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

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

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

Create an instance.
Stop and restart application revisions. An application revision is typically started instantly after deployment.
Retire and activate application revisions. Application revisions are instantly activated upon deployment.
Set an application as the default version.
Deploy, undeploy, and redeploy application revisions.
Delete specific instances of an application revision.

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

Introduction to SOA Composite Application Automated Testing

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

The test suite framework provides the following features:

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

For information about the following:

Creating and running test cases, see Automating the Testing of SOA Composite Applications
Designing test cases for SOA composite applications, see Developing SOA Applications with Oracle SOA Suite

Performance and Tuning of Oracle SOA Suite and Oracle BPM Suite

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

For the following information, see Tuning Performance:

Use case tuning recommendations
Key tuning properties per component, including the following information:
- Default values
- Symptoms, if not properly tuned
- Impact of changing properties from their default values
- Recommendations if symptoms appear
Profile-based tuning recommendations (selecting a profile by answering questions during installation and tuning properties based on the profile selected).

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

Administration for Application Developers

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

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

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

Administration Channels for WebLogic Server

WebLogic Server provides pre-configured channels that you do not have to explicitly define.

Default channel — Every Managed Server has a default channel.
Administrative channel — If you configure a domain-wide administration port, WebLogic Server configures an administrative channel for each Managed Server in the domain.

The Default Network Channel

Every WebLogic Server domain has a default channel that is generated automatically by WebLogic Server. The default channel is based on the listen address and listen port defined in the ServerMBean and SSLMBean. It provides a single listen address, one port for HTTP (non-secure) communication (7001 by default), and one port for HTTPS (secure) communication (7002 by default). You can configure the listen address and listen port using the Configuration > General page in the Administration Console; the values you assign are stored in attributes of the ServerMBean and SSLMBean.

The default configuration may meet your needs if:

You are installing in a test environment that has simple network requirements.
Your server uses a single NIC, and the default port numbers provide enough flexibility for segmenting network traffic in your domain.

Using the default configuration ensures that third-party administration tools remain compatible with the new installation, because network configuration attributes remain stored in ServerMBean and SSLMBean.

Even if you define and use custom network channels for your domain, the default channel settings remain stored in ServerMBean and SSLMBean, and are used if necessary to provide connections to a server instance.

Note:

Unless specified, WebLogic Server uses the non-secure default channel for cluster communication to send session information among cluster members. If you disable the non-secure channel, there is no other channel available by default for the non-secure communication of cluster session information. To address this, you can:

Enable the secureReplicationEnabled attribute of the ClusterMBean so that the cluster uses a secure channel for communication.
Create a custom channel for non-secure communication.

Administration Port and Administrative Channel

You can define an optional administration port for your domain. When configured, the administration port is used by each Managed Server in the domain exclusively for communication with the domain Administration Server.

Administration Port Capabilities

An administration port enables you to:

Start a server in standby state. This allows you to administer a Managed Server, while its other network connections are unavailable to accept client connections.
Separate administration traffic from application traffic in your domain. In production environments, separating traffic ensures that critical administration operations (starting and stopping servers, changing a server's configuration, and deploying applications) do not compete with high-volume application traffic on the same network connection.
Administer a deadlocked server instance using WLST. If you do not configure an administration port, administrative commands such as threadDump and shutdown will not work on deadlocked server instances.

If a administration port is enabled, WebLogic Server automatically generates an administration channel based on the port settings upon server instance startup.

Administration Port Restrictions

The administration port accepts only secure, SSL traffic, and all connections via the port require authentication. Enabling the administration port imposes the following restrictions on your domain:

The Administration Server and all Managed Servers in your domain must be configured with support for the SSL protocol. Managed Servers that do not support SSL cannot connect with the Administration Server during startup—you will have to disable the administration port in order to configure them.
Because all server instances in the domain must enable or disable the administration port at the same time, you configure the administration port at the domain level. You can change an individual Managed Server administration port number, but you cannot enable or disable the administration port for an individual Managed Server. The ability to change the port number is useful if you have multiple server instances with the same listen address.
After you enable the administration port, you must establish an SSL connection to the Administration Server in order to start any Managed Server in the domain. This applies whether you start Managed Servers manually, at the command line, or using Node Manager.
After enabling the administration port, all Administration Console traffic must connect via the administration port.
If multiple server instances run on the same computer in a domain that uses a domain-wide administration port, you must either:
- Host the server instances on a multihomed machine and assign each server instance a unique listen address, or
- Override the domain-wide port on all but one of the servers instances on the machine. Override the port using the Local Administration Port Override option in the Advanced Attributes section of the Server > Connections > SSL Ports page in the Administration Console.

Administration Port Requires SSL

The administration port requires SSL, which is enabled by default when you install WebLogic Server. If SSL has been disabled for any server instance in your domain, including the Administration Server and all Managed Servers, re-enable it using the Server > Configuration > General page in the Administration Console.

Ensure that each server instance in the domain has a configured default listen port or default SSL listen port. The default ports are those you assign on the Server > Configuration > General page in the Administration Console. A default port is required in the event that the server cannot bind to its configured administration port. If an additional default port is available, the server will continue to boot and you can change the administration port to an acceptable value.

By default WebLogic Server is configured to use demonstration certificate files.

Configure Administration Port

Enable the administration port as described in Enabling the Domain-Wide Administration Port in Oracle WebLogic Server Administration Console Help.

After configuring the administration port, you must restart the Administration Server and all Managed Servers to use the new administration port.

Booting Managed Servers to Use Administration Port

If you reboot Managed Servers at the command line or using a start script, specify the administration port in the port portion of the URL. The URL must specify the https:// prefix, rather than http://, as shown below.

-Dweblogic.management.server=https://host:admin_port

Note:

If you use Node Manager for restarting the Managed Servers, it is not necessary to modify startup settings or arguments for the Managed Servers. Node Manager automatically obtains and uses the correct URL to start a Managed Server.

If the hostname in the URL is not identical to the hostname in the Administration Server's certificate, disable hostname verification in the command line or start script, as shown below:

-Dweblogic.security.SSL.ignoreHostnameVerification=true

Booting Managed Servers to Use Administrative Channels

To allow a Managed Server to bind to an administrative channel during reboot, use the following command-line option:

-Dweblogic.admin.ListenAddress=<addr>

This allows the Managed Server to startup using an administrative channel. After the initial bootstrap connection, a standard administrative channel is used.

Note:

This option is useful to ensure that the appropriate NIC semantics are used before config.xml is downloaded.

Custom Administrative Channels

If the standard WebLogic Server administrative channel does not satisfy your requirements, you can configure a custom channel for administrative traffic. For example, a custom administrative channel allows you to segregate administrative traffic on a separate NIC.

To configure a custom channel for administrative traffic, configure the channel as described in Configuring a Channel, and select "admin" as the channel protocol. Note the configuration and usage guidelines described in:

Administration with Oracle Enterprise Manager and the Oracle SOA Management Pack

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

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

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

For more information, visit the following URL:

http://www.oracle.com/enterprise-manager