8  Managing SOA Composite Applications

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...
   Select Home. Select the Deployed Composites tab. In the Composite section, select a specific SOA composite application. At the top of the page, click Test.	Under soa-infra, select a specific SOA composite application. At the top of the page, click Test.	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 end point URL are populated automatically based on the service you selected to test. The end point 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 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 end points 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. If you want to edit the end point 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 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.

   
   

6. 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. 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.

   
   

7. 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.

   
   

8. 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).

   
   

9. 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.

10. Click Test Web Service.

    The test results appear in the Response tab upon completion.

    
    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.

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

12. 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.

13. 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:

• Section 1.2.3, "Introduction to SOA Composite Application Instances" for conceptual details about instances

• Section 1.4.3.2, "Introduction to Policies" for an overview of policies

• Oracle Fusion Middleware Security and Administrator's Guide for Web Services for specific details about policies and testing web services from the Test Web Service page

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

8.2 Managing the State of Deployed SOA Composite Applications

You can manage the lifecycle state of deployed SOA composite applications from either of two pages:

• From the Deployed Composites page of the SOA Infrastructure, which lists all SOA composite applications deployed to the SOA Infrastructure

• From the application home page of a specific SOA composite application (all tabs)

The management tasks that you can perform are based on the page you are on. Table 8-1 provides details.

See the following section based on the action you want to perform:

• Section 8.2.1, "Managing the State of All Applications at the SOA Infrastructure Level"

• Section 8.2.2, "Managing the State of an Application from the SOA Composite Application Home Page"

For more information, see Section 1.2.2, "Introduction to SOA Composite Applications."

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

Section 8.2, "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...
   Select Home. Select the Deployed Composites tab. Select a specific SOA composite application.	Under soa-infra, select a specific SOA composite application from its partition.

   
   

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 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 the illustration soaapp_instance2.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
   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: 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 end points in all previous revisions are de-activated.

For more information, see the following sections:

• Section 1.2.3, "Introduction to SOA Composite Application Instances"

• Section 1.4.3.3, "Introduction to the Lifecycle State of SOA Composite Applications"

• Section 8.1, "Initiating a SOA Composite Application Test Instance"

• Oracle Fusion Middleware Administrator's Guide for details about viewing and searching log files

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

Section 8.2, "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...
   Select Home.	Click soa-infra.	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 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
   Delete Selected	Deletes the selected instance.
   Delete With Options	Prompts you to first specify criteria for deleting the selected instance directly from the database. 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: 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." If you delete an instance with faults, those faults are no longer displayed in the Faults and Rejected Messages page. This option does not purge BPEL process service engine recoverable invoke and callback messages. To completely purge those messages, use the purge scripts described in Section 9.3, "Deleting Large Numbers of Instances with the Purge Scripts."
   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. From the View list, select Columns > Partition to display the partition in which the instance of the SOA composite application revision is contained.

6. 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.

7. 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.

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

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

8.5 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 your 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.

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...
   Select Home.	Click soa-infra.	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.

   • 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 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. Note that 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: 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. In the Recovery column, click the Recover link to access the Faults page of the instance audit trail to perform fault recovery. 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: Use Shift+Click or Control+Click to select specific faults in the rows. or 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: 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	From the Select menu, choose Select All Recoverable. 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, click Delete Rejected Messages.

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

   
   Description of the illustration bp_delrejmess.gif
   
   

6. Specify criteria and click Delete.

7. 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 the illustration soaapp_recovwithopts.gif
   
   

8. 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).

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

10. 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.

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

    • Section 8.5.1, "Examples of Fault Recovery for BPEL Processes"

    • Section 8.5.2, "Examples of Fault Recovery for BPMN Processes"

    • Section 8.5.3, "Examples of Fault Recovery for Oracle Mediator"

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

• Section 1.4.3.1, "Introduction to Fault Recovery"

• Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite

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

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

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

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

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

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

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

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

You can monitor and perform individual and bulk fault recoveries in your 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...
   Select Home. Select Deployed Composites. In the Composite section, select a specific SOA composite application.	Under soa-infra, 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.

   • 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 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.5, "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, click Delete Rejected Messages.

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

   
   Description of the illustration bp_delrejmess.gif
   
   

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 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). Note that 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:

• Section 1.2.4, "Introduction to Service Components and Service Component Instances"

• Section 1.4.3.1, "Introduction to Fault Recovery"

• Section 8.5.1, "Examples of Fault Recovery for BPEL Processes"

• Section 8.5.3, "Examples of Fault Recovery for Oracle Mediator"

8.7 Automating the Testing of SOA Composite Applications

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 web service partners before deployment in a production environment. This helps to ensure that a process interacts with web service partners as expected by the time it is ready for deployment to a production environment. You create test cases in Oracle JDeveloper and include them in a SOA composite application that is then deployed and administered from Oracle Enterprise Manager Fusion Middleware Control.

To automate the testing of SOA composite applications:

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...
   Select Home. Select Deployed Composites. In the Composite section, select a specific SOA composite application. Click the Unit Tests tab.	Under soa-infra, select a specific SOA composite application beneath the partition. Click the Unit Tests tab.	Select Unit Test.

   
   

   The test cases that are displayed were designed in Oracle JDeveloper and included in a deployed SOA composite application.

2. Select the entire test suite or individual tests of a suite to run, and click Execute.

   
   Description of the illustration sca_unittest.gif
   
   

   You are prompted to create a test.

3. Enter the following values, and click OK.

   Field	Description
   Test Run Name	Enter a name for the test instance. When testing is complete, report details are captured under this name.
   Timeout	Enter a value in seconds in which to complete this test. If the test does not complete within this time limit, then testing is terminated.
   Number of Concurrent Test Instances	Enter the number of test instances to create.

   
   

   The Test Runs page is automatically displayed for tracking the running tests.

   The Test Runs page enables you to track running test cases and view test results. 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.

   
   Description of the illustration sca_unittest2.gif
   
   

4. In the Test Run Name column, click a specific test run to display details in the Results of Test Run section. If you want to create more test runs, you can switch back to the Test Cases page at any time.

   The Results of Test Run section displays details about the executed test run, such as a test summary and the success rate. Click the Help icon for additional details.

5. View assertion details at the bottom of the page. Assertions enable you to verify variable data or process flow.

   
   Description of the illustration sca_unittest3.gif
   
   

6. Click a composite instance number to view specific test details.

   The composite instances created by executing unit test runs are displayed with a yellow square next to the instance ID in the Instances page of a SOA composite application and in the Recent Instances tables of the SOA Infrastructure and SOA composite application. This yellow box distinguishes these instances from test instances created on the Test Web Service page or automatically created by external consumers of the application.

For more information, see the following documentation:

• Section 1.4.3.4, "Introduction to SOA Composite Application Automated Testing"

• Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for instructions on creating test cases in Oracle JDeveloper

8.8 Managing SOA Composite Application Policies

You can attach or detach security policies to and from currently deployed SOA composite applications. Policies apply security to the delivery of messages.

To manage SOA composite application policies:

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...
   Select Home. Select Deployed Composites. In the Composite section, select a specific SOA composite application. Click the Policies tab.	Under soa-infra, select a specific SOA composite application beneath the partition. Click the Policies tab.	Select Policies.

   
   

   The Policies page enables you to attach and detach policies to and from BPEL process service components. The policies table displays the attached policy name, the component to which the policy is attached, the policy reference status (enabled or disabled) that you can toggle, the category (Management, Reliable Messaging, MTOM Attachment, Security, or WS-Addressing), the violations, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.

   
   Description of the illustration sca_policy.gif
   
   

2. Click Attach/Detach To.

   If multiple services or components are available, you are prompted to select the service or component for which to perform the attachment or detachment.

3. Select the component to which to attach or detach a policy.

   
   Description of the illustration soaapp_policy1.gif
   
   

   This invokes a dialog for attaching or detaching policies.

   Currently attached policies appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.

   
   Description of the illustration soaapp_policy2.gif
   
   

4. Select policies to attach that are appropriate to your environment.

5. Click Attach.

   The attached policy appears in the Attached Policies section.

   
   Description of the illustration soaapp_policy3.gif
   
   

6. Attach additional policies as needed.

7. When you are finished attaching policies, click Validate.

8. If an error message appears, make the necessary corrections until you no longer have any validation errors.

9. Click OK.

   The attached policy is displayed in the policies table.

   
   Description of the illustration soaapp_policy4.gif
   
   

For more information about policies, see the following documentation:

• Section 1.4.3.2, "Introduction to Policies"

• Oracle Fusion Middleware Security and Administrator's Guide for Web Services for definitions of available policies and details about which ones to use for your environment

<binding.ws
port="http://xmlns.oracle.com/CalledBPELProcessApp_
jws/CalledBPELProcess/CalledBPELProcess#wsdl.endpoint(calledbpelprocess_client_
ep/CalledBPELProcess_pt)"

location="http://sta00634.us.oracle.com:8001/soa-infra/services/default/CalledBPEL
Process!1.0/calledbpelprocess_client_ep?WSDL">
      <wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
                           orawsp:category="security"
orawsp:status="enabled"/>
      <wsp:PolicyReference URI="oracle/log_policy"
orawsp:category="management"
                           orawsp:status="enabled"/>
                            <property
name="oracle.webservices.local.optimization">false</property>
    </binding.ws> 

8.9 Exporting a Running SOA Composite Application

You can export the contents of a running SOA composite application to an archive JAR file. The file can include some or all of the following data:

• The original design-time composite

• Postdeployment changes in the rules dictionary and domain value maps (DVMs)

• Postdeployment property changes such as binding component properties, composite properties such as audit level settings and payload validation status, and policy attachments

To export a running SOA composite application:

1. Go to the home page of the SOA composite application to export.

2. From the SOA Composite menu, select Export.

   The Export Composite page appears.

   
   Description of the illustration soaapp_export.gif
   
   

3. Select an option.

   • Option 1: Generates an archive file containing the original design-time composite and the postdeployment details described in Option 2 and Option 3.

   • Option 2: Includes the original design-time composite and postdeployment changes in the rules dictionary and DVMs.

   • Option 3: Includes the original design-time composite and postdeployment property changes such as binding component properties, composite properties such as audit level settings and payload validation status, and policy attachments.

   • Option 4: Generates an archive file containing only the original design-time composite. Options 2 and 3 are not included.

4. If you want to append an additional name to the existing file, select Specify Custom Extension Text. For example, entering MyText to a file named sca_OrderBookingComposite_rev1.0.jar names the exported file as sca_OrderBookingComposite_rev1.0-MyText.jar.

5. Click Export.

   The Processing: Export Composite dialog displays the progress of archive file generation. When generation completes, you are prompted to save the file.

6. Click Save File.

   A dialog appears for either opening or saving the file to a directory on your local host.

   Note:

   It is important that you click the Save File button. Do not simply close this dialog. Although the composite is exported, you cannot retrieve the actual exported file.

7. Specify the local directory in which to save the JAR file.

8. In the upper right of the Processing: Export Composite dialog, click the x icon to close the dialog.

9. On the Export Composite page, note that the Cancel button has changed to Done.

10. Click Done.

    The Export Composite is closed and you are returned to the SOA composite application home page.

8.10 Grouping SOA Composite Applications into Partitions

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 all SOA composite applications within a specific partition. Partitions are similar to the domain feature that was part of 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.

You can manage partitioning from either of two pages:

• From the Manage Partitions page of the SOA Infrastructure, which lets you create partitions, delete partitions, and perform bulk lifecycle management tasks on all SOA composite applications in a specific partition

• From the partition home page, which also enables you to perform bulk lifecycle management tasks on all SOA composite applications in a specific partition

Table 8-2 provides more specific details on the tasks you can perform from both pages.

See the following section based on the tasks you want to perform:

• Section 8.10.1, "Creating and Deleting Partitions"

• Section 8.10.2, "Performing Bulk Lifecycle Management Tasks on Composites in Partitions"

For more information about partitions, see Section 1.4.3.5, "Introduction to Partitioning of the SOA Infrastructure."

8.11 Disabling and Enabling BPEL and BPMN Business Monitors

The term business monitoring comprises different types of sensors that can be defined for some types of SOA components, such as the following:

• BPEL sensors: Enable you to create sensors in BPEL faults, activities, and variables.

• BPEL Monitors: Enable you to capture BPEL process metrics that are sent to Oracle BAM Server, and then used for analysis and graphic display.

• BPMN measurements: Enable you to measure a business indicator at a certain point in the process or in a section of the process.

At the SOA composite application level, you set the same status for all sensors defined for all types of service components comprising the selected composite. You cannot selectively enable or disable sensors defined for a specific type of service component for just one composite. However, you can globally disable service component-type specific sensors for all composites in the respective BPEL Service Engine Properties page or BPMN Service Engine Properties page.

By default, BPEL and BPMN sensors defined in SOA composite applications are enabled. Disabling sensors means that sensor values are not captured during runtime. For example, this results in the values not being displayed in the Sensor Values section of the BPEL audit trail.

To disable sensors at the service engine level:

1. Access the BPEL Service Engine Properties page by following the steps in Section 11.1, "Configuring BPEL Process Service Engine Properties."

2. Select the Disable BPEL Monitors and Sensors checkbox.

3. Click Apply.

4. Access the BPMN Service Engine Properties page by following the steps in Section 36.1, "Configuring BPMN Process Service Engine Properties"

   Note:

   The BPMN Service Engine Properties page is only displayed if Oracle BPM Suite is installed.

5. Select the Disable BPMN Measurements checkbox.

6. Click Apply.

To disable or enable sensors at the SOA composite application level:

1. Go to the home page of the SOA composite application in which you want to disable or enable sensors.

2. From the Settings menu, select Enable/Disable BPEL Business Monitoring. This selection is only displayed for composites that have at least one BPEL or BPMN service component, regardless of whether those components include sensors.

   
   Description of the illustration sca_sensordis.gif
   
   

   A dialog is invoked that displays the current status of sensors and enables you to change that status. The dialog only displays the options applicable to the component types present in the selected composite. For example, if the composite contains only BPEL components but not BPMN, you see only the option to set the status of BPEL sensors.

   The following steps describe the types of dialogs that can be displayed and the available actions.

   1. If sensors are disabled at both service engine levels, the message Disabled Globally is displayed for each. You cannot select Enable All or Disable All in this dialog. Both buttons are disabled.

      
      Description of the illustration sca_sensordis3.gif
      
      

      In addition, if sensors are disabled at the BPEL service engine level and the BPMN service engine does not appear because Oracle BPM Suite is not installed, you cannot select Enable All or Disable All in this dialog. Both buttons are disabled.

      
      Description of the illustration sca_sensordis8.gif
      
      

   2. If sensors are not disabled at the composite level, checkmarks are displayed. If sensors are also not disabled at both the BPEL and BPMN service engine levels, the message Disabled Globally does not display.

      Click Disable All to disable all types of sensors defined for service components that comprise the selected composite. (If sensors are disabled at the service engine level, they remain disabled.)

      
      Description of the illustration sca_sensordis4.gif
      
      

   3. If sensors are disabled at a specific service engine level, the sensor status you set for those types of sensors at the composite application level only takes effect when the corresponding Disable BPEL Monitors and Sensors or Disable BPMN Measurements checkbox in the service engine Properties page is deselected.

      For example, if sensors are disabled at the BPMN service engine level (as shown below), and you select Enable All for all sensors at the selected composite level, that status is only applied to other types of sensors, such as BPEL. BPMN sensors and monitors remain disabled. However, if you later change the BPMN service engine setting, BPMN sensors are automatically enabled in this composite.

      
      Description of the illustration sca_sensordis5.gif
      
      

   4. If sensors are disabled at the composite level, no checkmark is displayed. Click Enable All to enable all types of sensors defined for service components that comprise the selected composite. (Sensors disabled at the service engine level remain disabled until you change the service engine level setting.) Note that because the composite does not include BPMN service components, BPMN is not displayed.

      
      Description of the illustration sca_sensordis7.gif
      
      

After you select an action, an inline message is displayed in the page confirming that sensors were enabled or disabled.

For more information about BPEL sensors and monitors, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

For more information about BPMN measurements, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.