8  Managing SOA Composite Application Instances

This chapter describes how to manage SOA composite application instances, including initiating a test instance of an application, monitoring and deleting instances, recovering from faults, and deleting rejected messages.

This chapter includes the following topics:

Note:

The procedures in this guide describe how to access Oracle Enterprise Manager Fusion Middleware Control pages from the SOA Infrastructure menu, soa-infra icon in the navigator, SOA Composite menu, and SOA Partition menu. You can also access many pages from the Farm home page. For more information, see Section 2.2.6, "Navigating to the SOA Infrastructure or SOA Composite Application Home Page from the Farm Home Page."

8.1 Initiating a SOA Composite Application Test Instance

This section describes how to initiate a test instance of a deployed SOA composite application.

To initiate a SOA composite application test instance:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... From the Composite Menu...

    1. Select Home.

    2. Select the Deployed Composites tab.

    3. In the Composite section, select a specific SOA composite application.

    4. At the top of the page, click Test.

    1. Under soa-infra, expand the partition.

    2. Select a specific SOA composite application.

    3. At the top of the page, click Test.

    1. Select Test Service > client.

    Note:

    The Test button is disabled in the following situations:

    • The SOA composite application revision is stopped or retired.

    • There are no web services available for the application. Only composites having services with web service bindings can be tested from this page.

  2. If the composite includes multiple services, the Test button has a drop-down list to select the service to test.

    The Test Web Service page for initiating an instance appears.

    This page provides many options for initiating an instance. At a minimum, you must specify the XML payload data to use in the Input Arguments section.

    The WSDL file and endpoint URL are populated automatically based on the service you selected to test. The endpoint URL is derived from the WSDL and can be overridden to invoke that service at a different location. If the service selected has multiple ports, a drop-down list is displayed. Otherwise, the port of the current service is displayed.

    Description of sca_test_payload.gif follows
    Description of the illustration sca_test_payload.gif

  3. Accept the default values for these fields or provide values appropriate to your test environment.

  4. If you change the WSDL file, click Parse WSDL to reload the WSDL file.

    If the WSDL URL does not contain the revision number, it is processed by the default composite application. For example, if there are two revisions of a composite application named HelloWorld, then the following endpoints are exposed by them:

    • http://host:port/soa-infra/services/default/HelloWorld!1.0/client

    • http://host:port/soa-infra/services/default/HelloWorld!2.0/client

    However, if the WSDL specified for web service invocation does not contain the revision details (for example, http://host:port/soa-infra/services/default/HelloWorld/client), it is processed by the composite revision that is set as default.

  5. Select the operation that you want to test from the Operation menu. The available operations are determined from the WSDL.

    To test a RESTful web service, select the GET or POST service port operation.

  6. If you want to edit the endpoint URL, click Edit Endpoint URL and make appropriate changes.

    The lower part of the Test Web Service page consists of the Request tab. This tab enables you to specify security, quality of service, HTTP transport, stress testing options, and XML input arguments:

    Description of sca_test_payload2.gif follows
    Description of the illustration sca_test_payload2.gif

    The Security section includes the following fields for passing security properties with messages.:

    Field Description

    WSS Username Token

    Inserts a WS-Security SOAP header. The Username field is required, and the Password field is optional.

    HTTP Basic Auth

    Inserts the username and password credentials in the HTTP transport header. Both the Username and Password fields are required.

    Custom Policy

    Uses a custom policy to authenticate the user (specifies the URI for the custom policy). The Username and Password fields are optional.

    None

    Select to not specify security credentials. This is the default selection.

    When testing RESTful Web services, because the SOAP protocol is not used, the only security options are HTTP Basic Authentication or None.

  7. Accept the default values for these fields or provide values appropriate to your test environment.

    The Quality of Service section includes the following fields. Oracle Fusion Middleware uses a policy-based model to manage web services. A policy applies behavior requirements to the delivery of messages. This section is not available when testing RESTful web services. For additional details about using the Test Web Service page, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

    Field Description

    WS-RM

    Select one of the following options for testing WS-Reliable Messaging (RM) protocol policies. Reliable messaging policies support this protocol, which guarantees the end-to-end delivery of messages.

    • WSDL Default: Executes the default behavior of the WSDL. For example, if the WSDL contains a reference to a WS-RM policy, then the policy is enforced. If the WSDL does not contain a reference to a WS-RM policy, then reliable messaging is not tested.

    • None: No policy for WS-RM is tested even if the WSDL contains a reference to a policy.

    • Custom: Enforces a custom policy. Specify the URI of the custom policy in the Policy URI field. If a WS-RM policy is referenced in the WSDL, it is ignored, and the policy specified in the Policy URI field is used instead.

    MTOM

    Select one of the following options for testing Message Transmission Optimization Mechanism (MTOM) policies. MTOM policies ensure that attachments are in MTOM format, a format for efficiently sending binary data to and from web services.

    • WSDL Default: Executes the default behavior of the WSDL. For example, if the WSDL contains a reference to an MTOM policy, then the policy is enforced. If the WSDL does not contain a reference to an MTOM policy, then MTOM is not tested.

    • None: No policy for MTOM is tested, even if the WSDL contains a reference to a policy.

    • Custom: Enforces a custom policy. Specify the URI of the custom policy in the Policy URI field. If an MTOM policy is referenced in the WSDL, it is ignored, and the policy specified in the Policy URI field is used instead.

    WS-Addressing

    Select one of the following options for testing WS-Addressing policies. WS-Addressing policies verify that SOAP messages include WS-Addressing headers in conformance with the WS-Addressing specification.

    • WSDL Default: Executes the default behavior of the WSDL. For example, if the WSDL contains a reference to a WS-Addressing policy, then the policy is enforced. If the WSDL does not contain a reference to a WS-Addressing policy, then WS-Addressing is not tested.

    • None: No policy for WS-Addressing is tested even if the WSDL contains a reference to a policy.

    • Custom: Enforces a custom policy. Specify the URI of the custom policy in the Policy URI field. If a WS-Addressing policy is referenced in the WSDL, it is ignored, and the policy specified in the Policy URI field is used instead.

  8. Accept the default values for these fields or provide values appropriate to your test environment.

    The HTTP Transport Options section includes the following fields:

    Field Description

    Enable SOAP Action

    Specifies whether the WSDL soap:operation has a soapAction attribute. This flag is enabled if a soapAction attribute exists. If you do not want to send a request with the SOAP action HTTP header, then clear the checkbox.

    SOAP Action

    Displays the soapAction attribute of the WSDL soap:operation, if one exists. You may specify a different SOAP action in this text box.

    This section is not available when testing RESTful web services.

  9. Accept the default values for these fields or provide values appropriate to your test environment.

    The Additional Test Options section includes the following fields. This section provides a simple stress test that simultaneously invokes multiple instances.

    Note:

    This is not a real stress test tool. Therefore, do not enter huge values for both concurrent threads and the number of times to invoke the operation. Doing so can result in errors.

    Field Description

    Enable Stress Test

    Click Enable to create a simple stress test. With this enabled, no conversation ID is displayed.

    Concurrent Threads

    Enter the number of concurrent threads on which to send the invocations. The default is 5 threads.

    Loops per Thread

    Enter the number of times to invoke the operation. The default is 10 times.

    Delay in Milliseconds

    Specify the delay of milliseconds to wait between operation invocations. The default is 1000 milliseconds (1 second).

  10. Accept the default values for these fields or provide values appropriate to your test environment.

    The Input Arguments section includes the following fields for entering XML payload data.

    Field Description

    Tree View

    Displays a graphical interface of text fields in which to enter information. This field automatically generates the required headers and XML structure.

    XML View

    Displays the XML file format for inserting values. You can paste the raw XML payload of your message into this field.

    Note:

    If you are using Oracle Enterprise Manager Grid Control, you can save the payload you enter. This feature is not available with Oracle Enterprise Manager Fusion Middleware Control.

  11. Click Test Web Service.

    The test results appear in the Response tab upon completion.

    Description of soaapp_testresult.gif follows
    Description of the illustration soaapp_testresult.gif

    Note:

    The Response tab does not display payload data if you are performing a stress test or are testing an asynchronous service.

  12. Click Launch Message Flow Trace to access the flow trace of the instance.

  13. To return to the composite home page, click the name of the composite that appears at the top of the page or select Home from the composite target menu.

  14. Return to the Dashboard page of the SOA composite application.

    The Recent Instances table lists recent SOA composite application instances. Each created instance has its own unique ID.

For more information, see the following sections:

8.1.1 Specifying RPC/Literal-Style WSDL Files on the Test Web Service Page

If you are specifying an RPC/literal-style WSDL file with a message defined by "element=" in the Test Web Service page in Oracle Enterprise Manager Fusion Middleware Control, use the XML View option of the Input Arguments section to modify the SOAP message. The SOAP body should look as follows:

<soap:Body>
    <ns:initiate>
        <payload>
          <value xmlns="...">3</value>
        </payload>
    </ns:initiate>
</soap:Body>

where initiate is the operation name, payload is the part name, and value is the element defined in the WSDL message/part.

8.2 Monitoring and Deleting SOA Composite Application Instances from the Application Home Page

Section 7.4, "Managing the State of Deployed SOA Composite Applications" describes how to manage the lifecycle state of SOA composite applications. You can also monitor and delete specific SOA composite application instances from the Instances page of the application home page.

To monitor and delete SOA composite application instances from the application home page:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...

    1. Select Home.

    2. Select the Deployed Composites tab.

    3. Select a specific SOA composite application.

    1. Under soa-infra, expand the partition.

    2. Select a specific SOA composite application.

  2. Click the Instances tab.

    The Instances page displays the following details:

    • A utility for searching for a specific instance by specifying criteria and clicking Search.

    • SOA composite application instance ID, name, conversation ID, most recent known state of each instance since the last data refresh of the page (for example, completed successfully, running, unknown, and so on), instance start time, and a log file describing any faults. A unique instance ID is created whenever a new instance of a SOA composite application is initiated either automatically by an external consumer of the application, or manually by an administrator from the Test Web Service page.

      If a ? icon is displayed, the Capture Composite Instance State checkbox was not enabled on the SOA Infrastructure Common Properties dialog. Therefore, the instance state was not evaluated. Determining the composite instance state requires evaluating the states of the underlying component, Therefore, this can be disabled to improve performance.

    Description of soaapp_instance.gif follows
    Description of the illustration soaapp_instance.gif

    Note:

    It is possible to generate orphaned service component instances. These instances are generated without any associated composite application instances. The orphaned component instances are generated under the following circumstances:

    • The SOA Infrastructure audit level is set to Off or the composite audit level is set to Off. Even in such cases, the BPEL process service engine can generate instance data for the service components that are included in the SOA composite application.

    • The SOA Infrastructure audit level is set to Off. However, the BPEL process or Oracle Mediator service engine audit level is set to a value other than Off.

    • All the audit levels are set to Off, but some faults are generated in one of the service engines. In these cases, the component instance gets generated.

    To delete orphaned instances or large numbers of instances, use the purge script described in Section 9.3, "Deleting Large Numbers of Instances with the Purge Scripts." Selecting the Delete All Instance options in the Delete with Options dialog does not delete orphaned component instances.

    If composite sensors are included in your SOA composite application, the Instances tab has the following differences:

    • The Add Fields button appears next to Search and Reset in the search utility. This button enables you to add sensor values to your search criteria.

    • A Composite Sensors column appears in the Instances table. Click the sensor icon in that column to display the details about sensor values available in a given instance of the composite.

  3. From the Add Fields list, select composite sensors to add to the search criteria. In this example, four have been selected (CustomerDetails, NameSensor, Datesensor, and Yearsensor).

  4. Input specific values by which each sensor searches. Only the composite instances in which the sensor values match your specified criteria are returned.

    Description of soaapp_instance2.gif follows
    Description of the illustration soaapp_instance2.gif

    The Composite Sensors column indicates that this SOA composite application includes composite sensors.

    Description of soaapp_instance3.gif follows
    Description of the illustration soaapp_instance3.gif

  5. Click Reset to remove all composite sensor fields from the search criteria or click the Remove icon to the right of the field to remove an individual sensor.

  6. Select a specific instance to delete by clicking a row in the Instances table. To select multiple instances, press Ctrl-Click or Shift-Click for the rows you want to select.

  7. Select a specific action to perform.

    Action Description

    Filter By

    Specify criteria for displaying composite instance states:

    • Execution State

      Filter the display of instances by execution state (running, completed, terminated, or stale).

    • Fault State

      Filter the display of instances by fault state (with or without faults). You can further customize the faulted state by selecting to display faults requiring recovery or nonrecoverable faults. It you select Stale from the Execute State list, the Fault State list is disabled.

    • BPEL Recovery

      Filter the display of instances by whether a recovery action is required. By default, this filter excludes all messages and instances created in the last five minutes, and displays the rest. You can control the number of minutes with the excludeBpelMaxCreationTime key of the AuditConfig property in the System MBean Browser. This property is available in the More SOA Infra Advanced Configuration Properties section of the SOA Infrastructure Common Properties page. For more information, see Section 3.1, "Configuring SOA Infrastructure Properties."

    Delete Selected

    Deletes the selected instance.

    After deleting an instance, instance details are no longer available for review.

    Delete With Options

    Prompts you to first specify criteria for deleting the selected instance directly from the database.

    Use this option to delete running, rolled back instances. However, this option does not delete the associated invoke messages that are awaiting recovery. As a result, there are orphaned messages pending in BPEL message recovery. To delete these messages, go to the Recovery page of the BPEL process service engine.

    • Common Delete Options: Select a preset range of instances to delete from a list (for example, older than 24 hours).

    • Delete All Instances Of This Composite: Select to delete all instances of the composite. This option deletes the rejected messages associated and all component, service, and reference instances associated with the composite, including those not associated with any composite instance ID.

      Note: If this composite has thousands of instances to delete, do not use this option. Instead, use the purge script described in Section 9.3, "Deleting Large Numbers of Instances with the Purge Scripts."

    • Delete All Instances That Match These Criteria: Specify criteria for deleting instances, including the start and stop times, and instance state.

    Any selections you may have made in the Instances page (such as specifying and executing a search criteria) are ignored for this operation.

    To monitor the progress of instance deletion, you must check the log files. For information about log files, see Section 3.4, "Configuring Log Files."

    Abort

    Terminates the selected instance. However, instance details are still available for review.


  8. From the View list, select Columns > Partition to display the partition in which the instance of the SOA composite application revision is contained.

  9. From the View list, select Columns > ECID to display execution context IDs (ECIDs). An ECID enables you to track a message flow that crosses instances of different composites.

  10. In the Instances table, perform the following additional tasks:

    1. In the Instance ID column, click a specific instance ID to show the message flow through the various service components and binding components. If an instance ID is listed as unavailable, you can click the Unavailable link for details.

    2. In the State column, if an instance state is marked as Unknown, click it to display more details.

    3. If the Composite Sensors column is available, click a sensor icon to display details about composite sensors included in the instance, such as name, location, and value.

    4. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.

    Note:

    Multiple revisions of a SOA composite application that includes inbound JCA adapters are displayed as running. However, only the most recent revision (the default version) is considered active. All previous revisions are not considered active. This is because for inbound JCA adapters, there can only be one active revision of a SOA composite application at any time. The JCA adapter endpoints in all previous revisions are de-activated.

For more information, see the following sections:

8.2.1 Mismatch Between the Number of SOA Composite Application Instances and Service Component Instances

The number of SOA composite application instances may not always match the number of service component instances displayed in Oracle Enterprise Manager Fusion Middleware Control.

A SOA composite application instance is first created when the composite is invoked. When the service components within the composite receive a subsequent invocation, a corresponding service component instance is created that refers to the composite instance ID previously created.

There can be scenarios under which the composite instance is created, but the underlining service component instance is not created. For example:

  • The composite instance is created, but the invocation has not yet reached the service component due to a system failure.

  • The composite instance is created, but the invocation fails payload validation and is rejected. In this case, invocation does not reach the underlining service components.

You can also have orphaned service component instances for which no SOA composite application instance has been created.

8.2.2 Instance States of Service Components and SOA Composite Applications

Assume you have a SOA composite application with multiple service components (for example, two BPEL process service components). If these service components are marked with the following instance states:

  • Instance state of one BPEL process is marked as completed.

  • Instance state of the other BPEL process is marked as faulted.

This results in the overall composite instance state being marked as faulted. This behavior differs from 11g Release 1 (11.1.1.2), in which the same scenario resulted in the overall composite instance state being marked as completed.

Assume you have a parent SOA composite application that calls a child SOA composite application, and a fault occurs in the child composite (and is handled by the parent composite). This results in the following instance states:

  • The instance state of the child composite is marked as faulted.

  • The instance state of the parent composite is marked as completed.

8.3 Monitoring and Deleting SOA Composite Application Instances at the SOA Infrastructure Level

Section 7.4, "Managing the State of Deployed SOA Composite Applications" described how to manage the lifecycle state of all instances of a specific SOA composite application. You can also monitor and delete any number of instances across all deployed SOA composite applications by using the Instances page of the SOA Infrastructure home page. This page lists all SOA composite application instances deployed to the SOA Infrastructure.

To monitor and delete SOA composite application instances at the SOA infrastructure level:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... From the SOA Composite Menu...

    1. Select Home.

    1. Click soa-infra.

    1. Select SOA infrastructure.

  2. Click the Instances tab.

    The Instances page displays the following details:

    • A utility for searching for a specific instance by specifying criteria and clicking Search.

    • All SOA composite application instances in the SOA Infrastructure, including instance and conversation IDs, composite name and revision, SOA composite application instance state, and instance start time.

    Description of sca_instanceids.gif follows
    Description of the illustration sca_instanceids.gif

    You can also terminate and delete instances from this page.

  3. Select a specific instance by clicking a row in the Instances table. To select multiple instances, press Ctrl-Click or Shift-Click for the rows you want to select.

  4. Select a specific action to perform.

    Action Description

    Filter By

    Specify criteria for displaying composite instance states:

    • Execution State

      Filter the display of instances by execution state (running, completed, terminated, or stale).

    • Fault State

      Filter the display of instances by fault state (with or without faults). You can further customize the faulted states by selecting to display faults requiring recovery or nonrecoverable faults. It you select Stale from the Execute State list, the Fault State list is disabled.

    • BPEL Recovery

      Filter the display of instances by whether a recovery action is required. By default, this filter excludes all messages and instances created in the last five minutes, and displays the rest. You can control the number of minutes with the excludeBpelMaxCreationTime key of the AuditConfig property in the System MBean Browser. This property is available in the More SOA Infra Advanced Configuration Properties section of the SOA Infrastructure Common Properties page. For more information, see Section 3.1, "Configuring SOA Infrastructure Properties."

    Delete Selected

    Deletes the selected instance.

    Delete With Options

    Prompts you to first specify criteria for deleting the selected instance directly from the database.

    Use this option to delete running, rolled back instances. However, this option does not delete the associated invoke messages that are awaiting recovery. As a result, there are orphaned messages pending in BPEL message recovery. To delete these messages, go to the Recovery page of the BPEL process service engine.

    • Common Delete Options: Select a preset range of instances to delete from a list (for example, older than 24 hours).

    • Delete All Instances That Match These Criteria: Specify criteria for deleting instances, including the start and stop times, and instance state.

    Any instance state selections you made at the top of the Instances page are ignored for this operation.

    To monitor the progress of instance deletion, you must check the log files. For information about log files, see Section 3.4, "Configuring Log Files."

    Notes:

    Abort

    Terminates the selected instance. However, instance details are still available for review.

    Note: If you delete an instance with faults, those faults are no longer displayed in the Faults and Rejected Messages page. In addition, if a terminated instance (shown as aborted) had a fault, it is not added to the fault count.

  5. In the instances table, perform the following tasks:

    1. From the View list, select Columns > Partition to display the partition in which the instance of the SOA composite application revision is contained.

    2. From the View list, select Columns > ECID to display execution context IDs (ECIDs). An ECID enables you to track a message flow that crosses instances of different composites.

    3. In the Instance ID column, click a specific instance ID to show the message flow through the various service components and binding components. If the instance ID is unavailable, the message flow cannot be accessed. However, you can still click the link for details.

    4. In the Composite column, click a specific SOA composite application to access its home page.

    5. In the Instance State column, click the Recovery icon to access the Faults and Rejected Messages page with faults filtered based on the composite instance ID. There can be multiple faults for a composite instance ID.

    6. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.

8.4 Recovering from SOA Composite Application Faults at the SOA Infrastructure Level

You can monitor and perform individual and bulk fault recoveries for BPEL process and Oracle Mediator service components across any number of SOA composite applications. 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. However, without defining any fault policies, the fault takes its standard course as either a recoverable or nonrecoverable fault. Examples of performing both individual and bulk recovery are provided in this section. Human task service component or human workflow service engine faults are recovered from Oracle BPM Worklist.

You can also perform a manual recovery of undelivered BPEL process invoke or callback messages. For more information, see Section 14.4, "Performing BPEL Process Service Engine Message Recovery."

To recover from SOA composite application faults at the SOA Infrastructure level:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... From the SOA Composite Menu...

    1. Select Home.

    1. Click soa-infra.

    1. Select SOA Infrastructure.

  2. Click the Faults and Rejected Messages tab.

    The Faults and Rejected Messages page displays the following details for all SOA composite application faults:

    • A utility for searching for a specific fault by specifying criteria and clicking Search. Click the Help icon for details.

    • Options for selecting instance recovery actions (for example, retry, abort, replay, and others), deleting rejected messages, and performing bulk message recovery.

    • Faults and rejected messages, including the error message, whether you can recover from the fault, the time of the fault, if the fault message is classified as a rejected message (if so, a checkmark is displayed), the SOA composite application in which the fault occurred, the fault location, the instance ID, and a link to log files describing the fault.

    Description of sca_faultandmanage.gif follows
    Description of the illustration sca_faultandmanage.gif

    Note:

    You cannot search for human workflow error messages by entering details in the Error Message Contains field because these faults do not persist in the dehydration store.

    Faults identified as recoverable can be recovered.

  3. Select faults for recovery using one of the following options. Fault recovery selection at the SOA Infrastructure level matches the SOA composite application level and BPEL process and Oracle Mediator service component levels.

    For... Then...

    Single fault recovery

    There are three options from which to choose for single-fault recovery:

    1. Click the row of the fault that has been identified as recoverable. With the row highlighted, select a specific action from the Recovery Action list, as described in Step 4.

    2. In the Recovery column, click the Recover link to access the Faults page of the instance audit trail to perform fault recovery.

    3. In the Error Message column, click the message of a fault that has been identified as recoverable. This displays complete fault details, including the fault ID, fault time, fault location, fault type, and error message text. A Recover Now option is displayed for recoverable faults. Click Recover Now to access the Faults page of the instance audit trail to perform fault recovery.

    Bulk fault recovery

    There are two options from which to choose for bulk-fault recovery:

    1. Use Shift+Click or Control+Click to select specific faults in the rows.

      or

    2. From the Select menu, choose Select All Recoverable. Then use Shift+Click or Control+Click to deselect the faults to not include in the recovery operation.

      Then:

    3. Select an action from the Recovery Action list, as described in Step 4.

      Note: Only the actions applicable to all selected faults are available.

    Recovery of all faults

    1. From the Select menu, choose Select All Recoverable.

    2. Select an action from the Recovery Action list, as described in Step 4.

      Note: Only the actions applicable to all selected faults are available.

  4. Select an action from the Recovery Action list.

    Action Description Action is Available for...

    Retry

    Retries the instance directly. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.

    BPEL process and Oracle Mediator

    Abort

    Terminates the entire instance.

    BPEL process and Oracle Mediator

    Replay

    Replays the entire scope again in which the fault occurred.

    BPEL process

    Rethrow

    Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.

    BPEL process

    Continue

    Ignores the fault and continues processing (marks the faulted activity as a success).

    BPEL process

    Note:

    In most cases, fault policy actions are automatically executed. The only exception is if you defined a fault policy that uses the action ora-human-intervention. This action creates a recoverable fault that can be recovered from Oracle Enterprise Manager Fusion Middleware Control.

  5. If you want to delete rejected messages for all composites in the SOA Infrastructure, see Section 8.6, "Deleting Rejected Messages at the SOA Infrastructure Level."

  6. If you want to perform a bulk recovery of messages, click Recover with Options.

    This displays the Recover with Options dialog for specifying criteria for recovering BPEL and Oracle Mediator messages of all composites directly from the database. Human workflow messages can be recovered manually from Oracle BPM Worklist. Business event and business rule messages cannot be recovered.

    Description of soaapp_recovwithopts.gif follows
    Description of the illustration soaapp_recovwithopts.gif

  7. Specify criteria. Retry and Abort are the only recovery actions permitted.

    Note:

    For bulk fault recovery at the SOA Infrastructure level, a check of the state of composites cannot be performed. If the state of a composite is set to off, a recovery of its faults cannot be performed. However, no error or warning message is displayed. Upon submission of the bulk fault recovery request, the server checks if the originating composite's state is set to off. That fact is then noted in the log, and the fault is skipped.

    You are also not notified when a fault has been skipped during recovery for any other reason (for example, an unsupported service engine, an unrecoverable fault, and so on).

  8. Click Recover. Depending upon the number of messages, recovery can take some time.

  9. Perform the following additional tasks from within the faults table:

    1. From the View list, select Columns > Fault ID to display the fault IDs for each error message. The fault ID is automatically generated and uniquely identifies a fault. The fault ID is also displayed when you click an error message.

    2. In the Composite column, click a specific SOA composite application to access its home page.

    3. In the Fault Location column, click a specific location to access the faults page for the location of the fault. The location can be a service, service component, or reference.

    4. In the Composite Instance ID column, click a specific ID to access the flow trace of the instance.

    5. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.

  10. See the following sections for examples of single and bulk fault recovery with BPEL processes and Oracle Mediator.

For more information about concepts and instructions on designing a fault policy, see the following documentation:

8.4.1 Examples of Fault Recovery for BPEL Processes

This section provides examples of how to define a fault policy that enables human intervention on a BPEL process fault and perform single and bulk fault recovery on a BPEL process service component.

In this example, you define a fault policy by specifying that a fault can be manually recovered through human intervention. If an invalid social security number is submitted from a loan broker BPEL process to a credit rating service, the credit rating service returns a negative credit fault. This human intervention action is defined with the ora-human-intervention action in the fault-policies.xml file. Without fault policies, BPEL instances do not generate recoverable faults (instead they are nonrecoverable); the ora-human-intervention action makes the fault recoverable.

<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
           id="CRM_ServiceFaults"
           xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://schemas.oracle.com/bpel/faultpolicy"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <Conditions>
               <faultName xmlns:credit="http://services.otn.com" 
               name="credit:NegativeCredit">
               <!-- get this fault when SSN starts with 0-->
                  <condition>
                     <test>$fault.payload="Bankruptcy Report"</test>
                     <action ref="ora-human-intervention"/>
                  </condition>
               </faultName>
            </Conditions>
</faultPolicy>
</faultPolicies>

The fault-bindings.xml file associates the fault policies defined in the fault-policies.xml file with the CRM_ServiceFaults composite application.

<faultPolicyBindings version="2.0.1"
 xmlns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite faultPolicy="CRM_ServiceFaults"/>
</faultPolicyBindings>

Because human intervention is defined as an action, you perform BPEL process fault recovery in Oracle Enterprise Manager Fusion Middleware Control.

For more information about creating and designing fault-policies.xml and fault-bindings.xml files, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

For information about BPEL process message recovery, see Section 14.4, "Performing BPEL Process Service Engine Message Recovery."

8.4.1.1 Example: Single Fault Recovery for BPEL Processes

This example assumes the following:

To perform single fault recovery for BPEL processes:

  1. From the SOA Infrastructure menu, select Home.

  2. Click the Faults and Rejected Messages tab.

  3. In the faults table, locate the fault that has been identified as recoverable. You can use the search utility to locate the specific fault.

  4. In the Recovery column, click Recover. If you first want to see details about the fault, click the error message. Then, click Recover Now.

    The Faults page for that BPEL process instance is displayed.

  5. In the Recovery column, click Recoverable.

    The page refreshes to display the fault recovery section at the bottom of the page.

    Description of sca_faults2.gif follows
    Description of the illustration sca_faults2.gif

  6. From the Recovery Action list, select Retry.

  7. Select None from the Chain Action Upon Successful Retry list. This list enables you to select Java callout recovery actions. For more information, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

  8. Select a variable from the Variable list. The content of this variable is displayed in the Value field. For this example, the variable crInput is selected. This variable is used in an invoke activity and contains an incorrect social security number value.

  9. Enter the correct value in the Value field. For this example, the social security number is edited to begin with 1:

    <ssn xmlns="http://service.otn.com">123456789</ssn>

  10. Click Set Value, and click Yes when prompted to continue.

  11. Click Recover to recover from the fault, and then click Yes when prompted to continue.

    The page refreshes to indicate that no faults occurred.

8.4.1.2 Example: Bulk Fault Recovery for BPEL Processes

For the social security number example, selecting Retry is not an option for performing a bulk recovery, because the value for the social security number is incorrect and requires correction. An example of performing a bulk recovery with the Retry option is if the social security number is correct, but the system providing the credit rating service was temporarily unavailable and caused a composite reference fault. This prevents the messages from being delivered. Once the credit rating service is available again, selecting Retry attempts the invocation to the credit rating service through the composite reference again.

To perform bulk fault recovery for BPEL processes:

  1. Perform Step 1 and Step 2 of Section 8.4.1.1, "Example: Single Fault Recovery for BPEL Processes."

  2. In the search utility, enter criteria based on known fault parameters (for example, the time range, composite name, component type (BPEL process), and so on).

  3. If the search returns too many results, limit it by selecting the Show only recoverable faults checkbox.

  4. From the Select list, choose Select All Recoverable.

  5. From the Recovery Action list, select Abort.

    All selected faults are manually terminated.

8.4.2 Examples of Fault Recovery for BPMN Processes

This section provides examples of how to define a fault policy that enables human intervention on a BPMN process fault and perform single and bulk fault recovery on a BPMN process service component.

Note:

When a multi-instance process has met the conditions for its completion, it raises a nonrecoverable system fault (to cancel remaining instances). Although this fault appears in the Oracle Enterprise Manager Fusion Middleware Control, you do not need to take any action. It appears simply to notify you that the multi-instance process was finalized because the condition was completed.

In this example, you define a fault policy specifying that a fault be manually recovered through human intervention. If an invalid social security number is submitted from a loan broker BPMN process to a credit rating service, the credit rating service returns a negative credit fault. This human intervention action is defined with the ora-human-intervention action in the fault-policies.xml file. Without fault policies, BPMN instances do not generate recoverable faults (instead they are nonrecoverable); the ora-human-intervention action makes the fault recoverable.

<faultPolicies xmlns="http://schemas.oracle.com/bpmn/faultpolicy">
<faultPolicy version="2.0.1"
           id="CRM_ServiceFaults"
           xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://schemas.oracle.com/bpmn/faultpolicy"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <Conditions>
               <faultName xmlns:credit="http://services.otn.com" 
               name="credit:NegativeCredit">
               <!-- get this fault when SSN starts with 0-->
                  <condition>
                     <test>$fault.payload="Bankruptcy Report"</test>
                     <action ref="ora-human-intervention"/>
                  </condition>
               </faultName>
            </Conditions>
</faultPolicy>
</faultPolicies>

The fault-bindings.xml file associates the fault policies defined in the fault-policies.xml file with the CRM_ServiceFaults composite.

<faultPolicyBindings version="2.0.1"
 xmlns="http://schemas.oracle.com/bpmn/faultpolicy"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <composite faultPolicy="CRM_ServiceFaults"/>
</faultPolicyBindings>

Because human intervention is defined as an action, you perform BPMN process fault recovery in Oracle Enterprise Manager Fusion Middleware Control.

For more information about creating and designing fault-policies.xml and fault-bindings.xml files, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

8.4.2.1 Example: Single Fault Recovery for BPMN Processes

This example assumes the following:

To perform single fault recovery for BPMN processes:

  1. From the SOA Infrastructure menu, select Home.

  2. Click the Faults and Rejected Messages tab.

  3. In the faults table, locate the fault that has been identified as recoverable. You can use the search utility to locate the specific fault.

  4. In the Recovery column, click Recover. If you first want to see details about the fault, click the error message. Then, click Recover Now.

    The Faults page for that BPMN process instance is displayed.

  5. In the Recovery column, click Recoverable.

    The page refreshes to display the fault recovery section at the bottom of the page.

    Description of sca_faults2.gif follows
    Description of the illustration sca_faults2.gif

  6. From the Recovery Action list, select Retry.

  7. From the Chain Action Upon Successful Retry list, select None. This list enables you to select Java callout recovery actions. For more information, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

  8. From the Variable list, select a variable. The content of this variable is displayed in the Value field. For this example, the variable crInput is selected. This variable is used in an invoke activity and contains an incorrect social security number value.

  9. In the Value field, enter the correct value. For this example, the social security number is edited to begin with 1:

    <ssn xmlns="http://service.otn.com">123456789</ssn>

  10. Click Set Value, and click Yes when prompted to continue.

  11. Click Recover to recover from the fault, then click Yes when prompted to continue.

    The page refreshes to indicate that no faults occurred.

8.4.2.2 Example: Bulk Fault Recovery for BPMN Processes

For the social security number example, selecting Retry is not an option for performing a bulk recovery because the value for the social security number is incorrect and requires correction. An example of performing a bulk recovery with the Retry option is if the social security number is correct, but the system providing the credit rating service was temporarily unavailable and caused a composite reference fault. This prevents the messages from being delivered. Once the credit rating service is available again, selecting Retry re-attempts the invocation to the credit rating service through the composite reference.

To perform bulk fault recovery for BPMN processes:

  1. Perform Steps 1 through 2 of Section 8.4.2.1, "Example: Single Fault Recovery for BPMN Processes."

  2. In the search utility, enter criteria based on known fault parameters (for example, the time range, composite name, component type (BPMN process), and so on).

  3. If the search returns too many results, limit it by selecting the Show only recoverable faults checkbox.

  4. From the Select list, choose Select All Recoverable.

  5. From the Recovery Action list, select Abort.

    All selected faults are manually terminated.

8.4.3 Examples of Fault Recovery for Oracle Mediator

This section provides an example of how to perform single and bulk fault recovery on an Oracle Mediator service component.

In this example, a service binding component for an inbound Siebel adapter submits a payload message to Oracle Mediator for transformation. The processed payload message is then delivered to a reference binding component for an outbound file adapter. However, the outbound directory into which to write the payload message is not configured with write permissions. This causes a fault to occur. The fault policy defined during design time specifies that the fault be manually recovered through human intervention. Three retries are attempted, as defined with the retryCount attribute. The condition and action are defined as follows in the fault-policies.xml file.

Recoverable Oracle Mediator faults do not require a fault policy (though it is one way to make faults recoverable, as described through an ora-human-intervention action). Any parallel routing rule that receives a remote fault from the outbound endpoint also creates a recoverable fault (in this specific example, the fault policy is not required if the Oracle Mediator uses a parallel routing rule to invoke the outbound file adapter).

<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
           id="ConnectionFaults"
           xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://schemas.oracle.com/bpel/faultpolicy"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
              <Conditions>
                <faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
                name="medns:mediatorFault">
                   <condition>
                      <test>contains($fault.mediatorErrorCode, "TYPE_FATAL_
                         MESH")</test>
                      <action ref="ora-retry"/>
                   </condition>
                </faultName>
              </Conditions>
. . .
. . .      <Action id="ora-retry">
        <retry>
          <retryCount>3</retryCount>
          <retryInterval>5</retryInterval>
          <retryFailureAction ref="ora-human-intervention"/>
          <retrySuccessAction ref="ora-terminate"/>
        </retry>
      </Action>
   </Actions>
</faultPolicy>
</faultPolicies>

Processing is set to retry 3 times before terminating.

The fault policies are associated with the ConnectionFaults composite application in the fault-bindings.xml file:

<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/fault
policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <composite faultPolicy="ConnectionFaults"/>
</faultPolicyBindings>

8.4.3.1 Example: Single Fault Recovery for Oracle Mediator

For this example, the sap output directory is made read-only. An inbound file adapter retrieves the sender.xml file from the siebel directory and the message is routed through Oracle Mediator to an outbound file adapter reference for placing a file in the sap directory.

To perform single fault recovery for Oracle Mediator:

  1. Change the directory permissions at the operating system command prompt.

    chmod 000 sap
cp sender.xml siebel/

  2. From the SOA Infrastructure menu, select Home.

  3. Click the Faults and Rejected Messages tab.

    Three faults appear, based on three retries being attempted. In this case, you see three retries only because the fault policy on the Oracle Mediator interaction with the outbound file adapter defines three retries. Without the fault policy, there is only one fault (no automated retries).

  4. Click the specific instance ID in the Composite Instance ID column.

    The Flow Trace appears. The faults table at the top of the page displays the fault messages. If you want to see where the faulted Oracle Mediator instance is located in the overall message flow, select the fault in the faults table. This highlights the associated instance in the trace table. You can then click the instance to access its audit trail to see more details about the faulted flow.

    Note:

    Steps 4 through 10 represent one way to recover this single fault. The fault can also be recovered directly from the Oracle Mediator faults page through the Recovery Action list.

  5. Locate the Oracle Mediator component instance fault you want to recover in the Faults table and click Recover in the Recovery column.

  6. Select Sender from the Payload Part list.

    The payload is automatically displayed in the Payload field. If necessary, payload modifications can be performed in this field. For this example, payload modification is not necessary.

  7. Change the sap directory to be writable at the operating system command prompt.

    chmod 777 sap

  8. Return to the Faults tab and click the Refresh icon in the upper right corner of the page.

  9. Click Retry.

  10. Click Yes when prompted to resubmit the selected fault for recovery.

    The page refreshes to indicate that no faults occurred.

  11. Click the Audit Trail tab.

    The final message indicates that manual recovery was successful and the message payload was written to the sap directory.

    Description of bp_flt29.gif follows
    Description of the illustration bp_flt29.gif

8.4.3.2 Example: Bulk Fault Recovery for Oracle Mediator

Assume the sap directory to which to write the sender.xml payload message is again configured with read-only permissions at the operating system command prompt. Three copies of the sender.xml file are placed in the siebel directory of the service binding component for the inbound Siebel adapter. This creates three instances.

chmod 000 sap
cp sender.xml siebel/
cp sender.xml siebel/
cp sender.xml siebel/

To perform bulk fault recovery for Oracle Mediator:

  1. Change the sap directory to be writable.

  2. From the SOA Infrastructure menu, select Home.

  3. Click the Faults and Rejected Messages tab.

  4. In the search utility, enter criteria based on known fault parameters (for example, the time range, composite name, and so on).

  5. If the search returns too many results, limit it by selecting the Show only recoverable faults checkbox.

  6. Change the sap directory to be writable at the operating system command prompt.

    chmod 777 sap

  7. Select all the faults to be recovered.

  8. Select Retry from the Recovery Action list.

  9. Select Yes when prompted to perform fault recovery.

  10. Click the Audit Trail tab.

    The final message indicates that manual recovery was successful and the message payload was successfully written to the sap directory.

8.5 Recovering from SOA Composite Application Faults in the Application Home Page

You can monitor and perform individual and bulk fault recoveries in a SOA composite application. 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. However, without defining any fault policies, the fault takes its standard course as either a recoverable or nonrecoverable fault. Human workflow faults can also be recovered, but not directly from Oracle Enterprise Manager Fusion Middleware Control. Instead, the audit trail provides a link to the Oracle BPM Worklist, from which the fault can be addressed.

To recover from SOA composite application faults in the application home page:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...

    1. Select Home.

    2. Select Deployed Composites.

    3. In the Composite section, select a specific SOA composite application.

    1. Under soa-infra, expand the partition.

    2. Select a specific SOA composite application.

  2. Click the Faults and Rejected Messages tab.

    The Faults and Rejected Messages page displays the following details for the selected SOA composite application:

    • A utility for searching for a specific fault by specifying criteria and clicking Search. Click the Help icon for details.

    • Options for selecting instance recovery actions (for example, retry, abort, replay, and others), deleting rejected messages, and performing bulk message recovery.

    • Faults and rejected messages in SOA composite application instances, including the error message, whether you can recover from the fault, the time of the fault, if the fault message is classified as a rejected message (if so, a checkmark is displayed), the fault location, the composite instance ID, and links to log files that describe the fault.

    Description of sca_soaapp_search.gif follows
    Description of the illustration sca_soaapp_search.gif

    Note:

    You cannot search for human workflow error messages by entering details in the Error Message Contains field because these faults do not persist in the dehydration store.

    Faults identified as recoverable can be recovered.

  3. Select faults for recovery. As with fault recovery at the SOA Infrastructure level and BPEL process and Oracle Mediator service component levels, you can perform single fault recovery, bulk fault recovery, and recovery of all faults. See Step 3 of Section 8.4, "Recovering from SOA Composite Application Faults at the SOA Infrastructure Level" for instructions on selecting faults to perform these types of recovery.

  4. Select an action from the Recovery Action list.

    Action Description Action is Available for...

    Retry

    Retries the instance directly. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.

    BPEL process and Oracle Mediator

    Abort

    Terminates the entire instance.

    BPEL process and Oracle Mediator

    Replay

    Replays the entire scope again in which the fault occurred.

    BPEL process

    Rethrow

    Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.

    BPEL process

    Continue

    Ignores the fault and continues processing (marks the faulted activity as a success).

    BPEL process

    Note:

    In most cases, fault policy actions are automatically executed. The only exception is if you defined a fault policy that uses the action ora-human-intervention. This action creates a recoverable fault that can be recovered from Oracle Enterprise Manager Fusion Middleware Control.

  5. If you want to delete rejected messages for the current SOA composite application, see Section 8.7, "Deleting Rejected Messages from the Application Home Page."

  6. If you want to perform a bulk recovery of messages, click Recover with Options.

    This displays the Recover with Options dialog for specifying criteria for recovering BPEL and Oracle Mediator messages of the current composite directly from the database. Human workflow messages can be recovered manually from Oracle BPM Worklist. Business event and business rule messages cannot be recovered.

    Description of soaapp_recovwithopts.gif follows
    Description of the illustration soaapp_recovwithopts.gif

  7. Specify criteria. Retry and Abort are the only recovery actions permitted.

    Note:

    For bulk fault recovery at the SOA composite application level, a check of the state of the composite is performed. If the state of the composite is set to off, a message is displayed warning you that a recovery cannot be performed.

    You are not notified when a fault has been skipped during recovery for any reason (for example, an unsupported service engine, an unrecoverable fault, and so on).

  8. Click Recover. Depending upon the number of messages, recovery can take some time.

  9. Perform the following additional monitoring tasks from within the faults table:

    1. From the View list, select Columns > Fault ID to display the fault IDs for each error message. The fault ID is automatically generated and uniquely identifies a fault. The fault ID is also displayed when you click an error message.

    2. In the Fault Location column, click a specific location to access the faults page for the location of the fault. The location can be a service, component, or reference.

    3. In the Component Instance ID column, click a specific service component ID to access task details about the instance (for example, the current state of a task). Rejected messages do not have a component instance ID.

    4. In the Logs column, click a specific log to access the Log Messages page with filtered messages specific to that instance.

For more information, see the following sections:

8.6 Deleting Rejected Messages at the SOA Infrastructure Level

You can delete rejected messages for all composites in the SOA Infrastructure directly from the database by specifying a criteria in the Delete: Rejected Messages dialog.

To delete rejected messages for all composites at the SOA Infrastructure level:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... From the SOA Composite Menu...

    1. Select Home.

    1. Click soa-infra.

    1. Select SOA Infrastructure.

  2. Click the Faults and Rejected Messages tab.

    The Faults and Rejected Messages page displays the following details for all SOA composite application faults:

    • A utility for searching for a specific fault by specifying criteria and clicking Search. Click the Help icon for details.

    • Options for selecting instance recovery actions (for example, retry, abort, replay, and others), deleting rejected messages, and performing bulk message recovery.

    • Faults and rejected messages, including the error message, whether you can recover from the fault, the time of the fault, if the fault message is classified as a rejected message (if so, a checkmark is displayed), the SOA composite application in which the fault occurred, the fault location, the instance ID, and a link to log files describing the fault.

    Description of sca_faultandmanage.gif follows
    Description of the illustration sca_faultandmanage.gif

  3. Click Delete Rejected Messages.

    Note:

    Oracle recommends that you run the purge scripts to delete composite instances in production environments. The purge scripts have better performance and scalability. Only use the Delete Rejected Messages option to manage exceptions not covered by the purge scripts. For more information about the purge scripts, see Section 9.3, "Deleting Large Numbers of Instances with the Purge Scripts."

    This displays the Delete: Rejected Messages dialog for specifying criteria for deleting rejected messages of all the composites directly from the database.

    Description of bp_delrejmess.gif follows
    Description of the illustration bp_delrejmess.gif

  4. Specify criteria and click Delete.

For information about recovering from faults at the SOA Infrastructure level, see Section 8.4, "Recovering from SOA Composite Application Faults at the SOA Infrastructure Level."

8.7 Deleting Rejected Messages from the Application Home Page

You can delete rejected messages for the current SOA composite application directly from the database by specifying a criteria in the Delete: Rejected Messages dialog.

To delete rejected messages for the current SOA composite application:

  1. Access this page through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...

    1. Select Home.

    2. Select Deployed Composites.

    3. In the Composite section, select a specific SOA composite application.

    1. Under soa-infra, expand the partition.

    2. Select a specific SOA composite application.

  2. Click the Faults and Rejected Messages tab.

    The Faults and Rejected Messages page displays the following details for all SOA composite application faults:

    • A utility for searching for a specific fault by specifying criteria and clicking Search. Click the Help icon for details.

    • Options for selecting instance recovery actions (for example, retry, abort, replay, and others), deleting rejected messages, and performing bulk message recovery.

    • Faults and rejected messages, including the error message, whether you can recover from the fault, the time of the fault, if the fault message is classified as a rejected message (if so, a checkmark is displayed), the SOA composite application in which the fault occurred, the fault location, the instance ID, and a link to log files describing the fault.

    Description of sca_soaapp_search.gif follows
    Description of the illustration sca_soaapp_search.gif

  3. Click Delete Rejected Messages.

    Note:

    Oracle recommends that you run the purge scripts to delete composite instances in production environments. The purge scripts have better performance and scalability. Only use the Delete Rejected Messages option to manage exceptions not covered by the purge scripts. For more information about the purge scripts, see Section 9.3, "Deleting Large Numbers of Instances with the Purge Scripts."

    This displays the Delete: Rejected Messages dialog for specifying criteria for deleting rejected messages of the current composite directly from the database.

    Description of bp_delrejmess.gif follows
    Description of the illustration bp_delrejmess.gif

  4. Specify criteria and click Delete.

For information about recovering from faults in the SOA composite application home page, see Section 8.5, "Recovering from SOA Composite Application Faults in the Application Home Page."