Introduction to Fault Recovery

1-18 Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite and Oracle BPM Suite components or human workflow service engines, you perform fault recovery on faults identified as recoverable from the 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. For more information on performing fault recovery, see the following sections: ■ Section 8.5, Recovering from SOA Composite Application Faults at the SOA Infrastructure Level ■ Section 8.6, Recovering from SOA Composite Application Faults in the Application Home Page ■ Section 13.1, Recovering from BPEL Process Service Component Faults ■ Section 13.3, Recovering from BPEL Process Service Engine Faults ■ Section 16.2, Managing Oracle Mediator Faults ■ Section 21.2, Recovering from Human Workflow Service Engine Faults ■ Section 21.4, Recovering from Human Task Service Component Faults ■ Section 32.4, Recovering from Business Event Faults ■ Section 38.1, Recovering from BPMN Process Service Component Faults ■ Section 38.3, Recovering from BPMN Process Service Engine Faults 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 Introduction and Concepts 1-19

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: ■ Section 8.8, Managing SOA Composite Application Policies ■ Section 13.2, Managing BPEL Process Service Component Policies ■ Section 21.1, Managing Human Task Service Component Policies ■ Section 35.1, Managing Binding Component Policies ■ Section 38.2, Managing BPMN Process Service Component Policies ■ Oracle Fusion Middleware Security and Administrators Guide for Web Services for definitions of available policies and details about which policies to use for your environment

1.4.3.2.1 Introduction to How Policies are Executed Policies are executed before a message

reaches the component with the attached policy. This causes the error to be displayed in the component preceding the component with the attached policy. For example: ■ A policy attached to an Oracle Mediator service component is executed on the wire before the message is passed to the Oracle Mediator. This causes the fault to be displayed in the service binding component instead of the 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. 1-20 Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite and Oracle BPM Suite ■ 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 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.