1 Introduction and Concepts

This chapter describes 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. Oracle Enterprise Manager 11g Grid Control and the Oracle SOA Management Pack are also briefly described.

This chapter includes the following sections:

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

1.1 What Is Oracle Fusion Middleware?

Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services: from Java EE and developer tools, to integration services, business intelligence, and collaboration. Oracle Fusion Middleware offers complete support for development, deployment, and management of applications.

1.2 What Is Oracle SOA Suite?

Oracle SOA Suite is a middleware component of Oracle Fusion Middleware. Oracle SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing SOA composite applications. Oracle SOA Suite enables services to be created, managed, and orchestrated into SOA composite applications. Composites enable you to easily assemble multiple technology components into one SOA composite application. Oracle SOA Suite plugs into heterogeneous IT infrastructures and enables enterprises to incrementally adopt SOA.

You can administer Oracle SOA Suite from Oracle Enterprise Manager Fusion Middleware Control. The following sections provide an overview of the components of Oracle SOA Suite:

For introductory information about Oracle SOA Suite, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

1.2.1 Introduction to the SOA Infrastructure Application

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

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

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

From the SOA Infrastructure home page, you can perform administration tasks such as monitoring SOA composite applications, monitoring individual composite instances, and updating the state of SOA composite applications and individual composite instances. You can also perform corrective actions such as fault recovery.

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

Description of Figure 1-1 follows
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 upper part of the home page for a SOA composite application. From the SOA composite application home page, you can perform administration tasks such as monitoring instances, recovering from faults, managing the state of application instances, and attaching policies. You can also perform a limited number of configuration tasks at the SOA composite application level, such as specifying the composite audit level and payload validation. These tasks are displayed as buttons at the top of the page.

Figure 1-2 SOA Composite Application Home Page (Upper Part)

Description of Figure 1-2 follows
Description of "Figure 1-2 SOA Composite Application Home Page (Upper Part)"

If messages are awaiting recovery, a BPEL Message Recovery Required message is displayed at the top of the Dashboard page and all other SOA composite application home pages.

Figure 1-3 shows the lower part of the home page for this SOA composite application. The service components and service and reference binding components included in the composite are shown.

Figure 1-3 SOA Composite Application Home Page (Lower Part)

Description of Figure 1-3 follows
Description of "Figure 1-3 SOA Composite Application Home Page (Lower Part)"

For more information, see the following sections:

1.2.2 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-4 provides an example of a SOA composite application in the SOA Composite Editor in Oracle JDeveloper. Service binding components (such as orderprocessor_client_ep) advertise their capabilities to external consumers. The service exposes a public interface of the SOA composite application (OrderBookingComposite) consisting of BPEL process, Oracle Mediator, human task, and decision service components. A wire connects the service to a specific component or reference in the composite. Reference binding components (such as CreditCardAuthorizationService and PartnerSupplierService) 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.

Figure 1-4 SOA Composite Application

Description of Figure 1-4 follows
Description of "Figure 1-4 SOA Composite Application"

The service components and binding components included in a SOA composite application appear in the lower part of an application home page, as shown in Figure 1-3 and Figure 1-5. The example in Figure 1-5 shows three BPEL process service components in the Component Metrics section and one binding component in the Services and References section. You can click a specific service component or binding component to access its home page.

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

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

For more information, see the following documentation:

1.2.3 Introduction to SOA Composite Application Instances

When a SOA composite application is invoked, a new composite instance is created. This instance is identified by a unique instance ID that is displayed in pages of Oracle Enterprise Manager Fusion Middleware Control. For example, Figure 1-6 shows instance IDs displayed for SOA composite applications in the Instances page of the SOA Infrastructure. When you first access this page, instances do not display. You must first click Search to display instances. You can click these IDs to access more specific details about the state of SOA composite application instances. From the Instances page, you can also monitor the state of SOA composite application instances.

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 instance ID. This box is visible in both the Instances page and in the Recent Instances table of the Dashboard page of the SOA Infrastructure and SOA composite application.

For some SOA composite applications, conversation IDs are also generated. Conversation IDs provide another method for distinctly identifying a set of generated instances. As shown in Figure 1-6, conversation IDs are not automatically displayed for all instances. To see a conversation ID generated, perform one of the following tasks:

  • Programatically 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-6 SOA Composite Application Instance IDs

Description of Figure 1-6 follows
Description of "Figure 1-6 SOA Composite Application Instance IDs"

For more information, see the following sections:

1.2.4 Introduction to Service Components and Service Component Instances

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 monitoring instances, recovering from faults, and attaching policies.

As described in Section 1.2.3, "Introduction to SOA Composite Application Instances," each application instance has its own instance ID. Each service component instance included in a SOA composite application instance also has its own instance ID that is displayed in Oracle Enterprise Manager Fusion Middleware Control. Figure 1-7 shows instance IDs displayed in the Instance ID column for the LoanBroker BPEL process service component of the SOA composite application. You can monitor the state of that service component instance from the Instances page. You can also click this instance to access more specific details about the service component.

Figure 1-7 Service Component Instance IDs

Description of Figure 1-7 follows
Description of "Figure 1-7 Service Component Instance IDs"

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

1.2.4.1 Spring Service Component Support

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

  • There are no spring service engine management pages.

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

  • Spring composite metrics are shown in the composite application home page (for example, in the Component Metrics section of the Dashboard 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 instance. Therefore, you cannot abort the running instance and cannot have a terminated state for the spring service component.

1.2.5 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 attaching policies, monitoring rejected messages, and setting binding component properties. Figure 1-8 shows the home page of a service binding component (in this example, a JCA adapter).

Figure 1-8 Binding Components

Description of Figure 1-8 follows
Description of "Figure 1-8 Binding Components"

For more information, see Section 35.4, "Administering Binding Components."

1.2.6 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-9 provides an example in Oracle Enterprise Manager Fusion Middleware Control of the BPEL process service engine. In this service engine, the LoanService and CreditRatingService BPEL process service components run. Note the multiple instance IDs for LoanService and CreditRatingService. The BPEL process service components are included in the CompositeTest SOA composite application. When you first access this page, instances do not display. You must first click Search to display instances.

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 instance, the service component itself, or the SOA composite application in which it is included.

Figure 1-9 Service Components Running in a Service Engine

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

In Oracle Enterprise Manager Fusion Middleware Control, you can perform service engine administration tasks such as monitoring instances, recovering from faults, 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. The service engine pages also include service engine-specific statistics and performance metrics.

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.

1.2.7 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:

1.2.8 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

  • EJB service

  • Direct binding service

  • Oracle Application Development Framework (ADF) Business Component service

  • Oracle BAM

  • Oracle B2B

  • Oracle Healthcare

  • Business events

  • Oracle User Messaging Service

For conceptual information about these service components, binding components, and services, see Oracle Fusion Middleware Getting Started with Oracle SOA Suite and Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

1.3 What Is Oracle Business Process Management Suite?

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

Oracle BPM Suite provides the following:

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

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

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

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

  • Enables collaboration with process space, which drives productivity and innovation.

  • 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

1.4 Administration of Oracle SOA Suite and Oracle BPM Suite

You can perform a variety of Oracle SOA Suite and Oracle BPM Suite administration (configuration, monitoring, and management) tasks from Oracle Enterprise Manager Fusion Middleware Control. This section provides an overview of these tasks:

The administrative tasks that you can perform are based on the roles to which you are mapped; each role corresponds to a different set of privileges. Certain users can be mapped to simple monitoring privileges (for instance view-only access), while other users can be granted full access, including the ability to update configurations, restart servers, and so on. For more information about roles in Oracle Enterprise Manager Fusion Middleware Control, see Appendix C, "Roles and Privileges for Oracle SOA Suite Users in Oracle Enterprise Manager."

Note:

While this guide primarily describes how to use Oracle SOA Suite with Oracle WebLogic Server, most of the information is also applicable to using Oracle SOA Suite with other third-party application servers. However, there may be some differences with using third-party application servers.

For information about these differences, see Oracle Fusion Middleware Third-Party Application Server Guide.

1.4.1 Configuration of Oracle SOA Suite and Oracle BPM Suite

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

  • SOA Infrastructure (impacting all SOA composite applications)

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

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

  • Oracle B2B bindings

  • Service and reference binding components message header properties

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

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

1.4.1.1 Introduction to the Order of Precedence for Audit Level Settings

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

  • 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 examples of the order of precedence for audit level settings.

Table 1-1 Examples of Order of Precedence

Component Composite Service Engine SOA Infrastructure Which Setting Takes Precedence?

No property

Off

Production

Development

Composite.

The audit level is set to Off. The service engine and SOA Infrastructure audit levels do not take effect.

No property

Inherit

Development

Production

Service engine.

The audit level is set to Development. The payload is shown in the assign activity. The SOA Infrastructure audit level does not take effect.

No property

Inherit

Inherit

Production

SOA Infrastructure.

The audit level is set to Production.

No property

Inherit

Production/Development/Off/Inherit

Off

The overall audit is not shown.

The composite inherits the audit level from the SOA Infrastructure. The payload is shown in the assign activity based on the service engine audit level setting.

Development

Off

Production

Development

Composite.

Since the composite audit level is set to Off, the overall audit is not shown. The service engine audit level is shown, but the Development setting for the component takes precedence.

The payload is shown in the assign activity based on the component audit level setting of Development.

Inherit

Off

Production

Development

Composite.

Since the composite audit level is set to Off, the overall audit is not shown. The service engine audit level is not shown because Off is inherited from the composite.

Notes:

  • When the composite audit level is set to Off, there is no audit trail generated for this composite and all service engines used within the composite.

  • When the composite audit level is set to Inherit, it always inherits the settings of the SOA Infrastructure.

  • When the composite audit level is set to Off, the component inherits the service engine settings.

For more information, see the following sections:

1.4.2 Monitoring of Oracle SOA Suite and Oracle BPM Suite

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

  • Instances, faults, and rejected messages in the SOA Infrastructure, SOA composite applications, service components, service engines, and service and reference binding components.

  • 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, and human workflows.

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 Chapter 12, "Diagnosing Problems with SOA Composite Applications."

1.4.3 Management of Oracle SOA Suite and Oracle BPM Suite

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

  • Creation and deletion of partitions. Once you create partitions, you can deploy a composite to the appropriate partition. This action enables you to logically group SOA composite applications into partitions. This is similar to the concept of domains in the 10.1.x releases of Oracle BPEL Process Manager.

  • Composite state (activating, retiring, starting, stopping, and setting the default composite version).

  • Deletion and termination of composite instances.

  • Deployment, undeployment, and redeployment actions for SOA composite applications.

  • Export of a deployed SOA composite application to a JAR file.

  • Manual initiation of SOA composite application test instances from the Test Web Service page.

  • Recovery from faults in SOA composite applications, service components, service engines, and business events.

  • Manual recovery of failed messages in BPEL processes.

  • Automated unit testing of SOA composite applications.

  • Attachment of policies to SOA composite applications, service components, and binding components.

  • Incoming and outgoing notification messages in human workflow.

  • Subscriptions to business events and testing of event publications.

  • Publication of web services to the Universal Description, Discovery, and Integration (UDDI) registry.

  • Disabling of business monitors (BPEL sensors, BPEL monitors, and BPMN measurements).

  • Storage of instance and callback message data in Oracle Coherence distributed cache on Oracle Exalogic platforms.

  • Management of the Oracle SOA Suite plug-in introspected by Oracle Virtual Assembly Builder. Oracle Virtual Assembly Builder is a tool for virtualizing installed Oracle components, modifying these components, and deploying them to an environment. Using Oracle Virtual Assembly Builder, you capture the configuration of existing software components in artifacts called software appliances that can then be grouped and their relationships defined into artifacts called software assemblies. For more information about the Oracle SOA Suite plug-in, see Oracle Virtual Assembly Builder User's Guide.

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

Notes:

1.4.3.1 Introduction to Fault Recovery

You can perform fault recovery actions on BPEL process, BPMN process, Oracle Mediator, human workflow, and business event subscription faults (which include database and component subscription faults) identified as recoverable 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

You can perform individual and bulk recovery actions on recoverable faults at the following levels:

  • Faults occurring in all SOA composite applications in the SOA Infrastructure

  • Faults occurring in an individual SOA composite application

  • Faults occurring in service components

  • Faults occurring in service engines

  • Faults occurring in business events

You perform fault recovery on faults identified as recoverable in Oracle Enterprise Manager Fusion Middleware Control. For BPEL process faults to be identified as recoverable, there must be a fault policy defined that is bound to the fault (through the fault-bindings.xml file) and which triggers the action ora-human-intervention. A BPEL component fault can be recovered in only this case. If no fault policy is defined as part of the composite, then a recoverable BPEL process fault is not possible.

You define a fault recovery policy in the fault-policies.xml and fault-bindings.xml files outside of Oracle Enterprise Manager Fusion Middleware Control. These files 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 composite instance, it is classified as a rejected message. A system or a policy fault can be identified as a rejected message.

Table 1-2 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 on performing fault recovery, see the following sections:

1.4.3.2 Introduction to Policies

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

  • SOA composite applications

  • Service components

  • Service and reference binding components

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

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

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

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

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

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

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

For more information, see the following documentation:

1.4.3.2.1 Introduction to How Policies are Executed

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

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

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

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

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

1.4.3.3 Introduction to the Lifecycle State of SOA Composite Applications

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

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

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

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

  • Create an instance.

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

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

  • Set an application as the default version.

  • Deploy, undeploy, and redeploy application revisions.

  • Delete specific instances of an application revision.

With the addition of Oracle SOA Governance tools for lifecycle management, you can perform additional lifecycle management tasks on a SOA composite application, or any component or service within the composite:

  • Collect important information on each component in an Oracle Enterprise Repository to help producers, providers, consumers, or other participants in the lifecycle for better understanding. For example, you can show the relationships between the previous and next versions.

  • Associate a lifecycle stage categorization to components or service endpoints (for example, build, test, stage, or production).

  • Automatically advance and track components and service endpoints through various lifecycle stages, automatically publishing them to an appropriate UDDI service registry for their lifecycle stage.

  • Manage their lifecycle and associated approvals using repeatable processes.

  • Manage their performance in production, and inform prospective consumers of services for better design-time decisions.

SOA Governance Suite provides Oracle SOA Suite and Oracle BPM Suite users with options to specify and automate a complete lifecycle for applications and their components (for example, planning, design, implementation, testing, staging, production, changes, and retirement).

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

1.4.3.4 Introduction to SOA Composite Application Automated Testing

You can create, deploy, and run test cases that automate the testing of SOA composite applications. Test cases enable you to simulate the interaction between a SOA composite application and its references before deployment in a production environment. Test suites consist of a logical collection of one or more test cases. Each test case contains a set of commands to perform as the test instance is executed. The execution of a test suite is known as a test run. Each test corresponds to a single SOA composite application 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 instance ID on the 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:

1.4.3.5 Introduction to Partitioning of the SOA Infrastructure

You can deploy SOA composite applications into separate sections of the SOA Infrastructure known as partitions. Deploying to partitions enables you to logically group SOA composites and perform bulk lifecycle management tasks on large numbers of composites. Partitioning is similar to the concept of domains in the 10.1.x releases of Oracle BPEL Process Manager. However, note that you cannot perform specific configuration tasks on partitions, such as restricting login access to a specific partition or configuring partitions (such as configuring threading).

At least one partition is required for deploying SOA composite applications. A default partition named default is automatically included with Oracle SOA Suite.

Once you create a partition, you can perform the following tasks:

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

  • Access the partition and its deployed composites through the navigation tree.

  • Perform the following bulk lifecycle management tasks on the composites in a specific partition:

    • Start all composites

    • Shut down all composites

    • Undeploy all composites

    • Retire all composites

    • Activate all composites

    • List all composites

Note:

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

For more information, see Section 7.9, "Grouping SOA Composite Applications into Partitions."

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

Many of the configuration parameters that you set can impact performance. For example, you can set configuration parameters in the BPEL process service engine for the dispatcher system, invoke, and engine threads.

For more information, see Oracle Fusion Middleware Performance and Tuning Guide.

1.5 Administration for Application Developers

If your role is that of an application developer, manage and test SOA composites using a combination of Oracle JDeveloper and Oracle Enterprise Manager Fusion Middleware Control. See the Oracle Fusion Middleware Developer's Guide for 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 composite application with Oracle Enterprise Manager Fusion Middleware Control:

To create and model business processes with Oracle BPM Suite, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.

1.6 Administration with Oracle Enterprise Manager 11g Grid Control and the Oracle SOA Management Pack

Oracle Enterprise Manager 11g Grid Control enables you to monitor runtime and historical data for multiple Oracle Fusion Middleware farms and Oracle WebLogic Server domains. Oracle Enterprise Manager 11g Grid Control supports the discovery, monitoring, and central management of the entire family of Oracle Fusion Middleware components, including Oracle SOA Suite through the Oracle SOA Management Pack.

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

For information about the Oracle SOA Management Pack, visit the following URL:

http://www.oracle.com/us/products/middleware/soa/management-pack/overview/index.html