8  Managing SOA Composite Applications

This chapter describes how to manage SOA composite applications, including initiating a test instance of an application; managing faults, policies, and instance states; and testing SOA composite applications.

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

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, select a specific SOA composite application.

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

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

  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:

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

If you are specifying an RPC/literal-style WSDL file with a message defined by "element=", in the Test 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 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.

Table 8-1 Application State Actions

Action Perform in the Deployed Composites Page of the SOA Infrastructure? Perform on the Application Home Page (All Tabs)?

Shut Down and Start Up

Yes

Yes

Retire and Activate

Yes

Yes

Set as Default

Yes

  • No: If only one version of the composite application is set as the default.

  • Yes: If there are multiple versions of the same composite application, this option is visible for all other versions of the same composite expect the one that is the default.

Deploy

Yes

Yes (through the Composite menu by selecting SOA Deployment > Deploy Another Composite)

Undeploy

Yes

Yes (through the Composite menu by selecting SOA Deployment > Undeploy)

Redeploy

Yes

Yes (through the Composite menu by selecting SOA Deployment > Redeploy)

Test

No

Yes

Composite Audit Level

No

Yes

Payload Validation

No

Yes

Enable/Disable Business Monitoring

No

Yes

Show WSDL and Endpoint URI (icon)

No

Yes

Show XML Definition (icon)

No

Yes

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

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

8.2.1 Managing the State of All Applications at the SOA Infrastructure Level

You can manage the state of all SOA composite applications from the Deployed Composites page at the SOA Infrastructure level.

To manage the state of all applications 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 Deployed Composites tab.

    The Deployed Composites page displays the following details:

    • A utility for searching for a specific SOA composite application by specifying a full or partial composite name and clicking Search. You can also search for SOA composite applications by partition.

    • A list of all SOA composite applications deployed in the SOA Infrastructure, including the partition in which they are deployed, current mode (active or retired), number of instances, number of faulted instances, and last modification date (deployment time, redeployment time, or any composite configuration change). The green dot to the left of the composite name indicates that this is the default revision of the application.

    Description of sca_deployedcomps.gif follows
    Description of the illustration sca_deployedcomps.gif

    Note:

    To always see the latest details about deployed SOA composite applications, click the Refresh icon in the upper right corner or navigate away from this page and return to it.

  3. Click Deploy to deploy a new application. For all other options listed above the Composite section, first select the composite application by clicking the column to the left of the name, then select a specific option to perform.

    Description of sca_selectinstance.gif follows
    Description of the illustration sca_selectinstance.gif

    The following table describes the available options:

    Action Description
    Shut Down Shuts down a running SOA composite application revision. Any request (initiating or a callback) to the composite is rejected if the composite is shut down. New incoming requests cannot be processed. All existing instances are allowed to complete as usual (the same as when a composite is retired).

    Note: The behavior differs based on which binding component is used. For example, if it is a web service request, it is rejected back to the caller. A JCA adapter binding component may do something else in this case (for example, put the request in a rejected table).

    This option is displayed when the composite application has been started.
    Start Up Restarts a composite application revision that was shut down. This action enables new requests to be processed (and not be rejected). No recovery of messages occurs.

    This option is displayed when the composite application has been stopped.
    Retire Retires the selected composite revision. If the process lifecycle is retired, you cannot create a new instance. Existing instances are allowed to complete as usual.

    An initiating request to the composite application is rejected back to the client. The behavior of different binding components during rejection is as described for the shut down option.

    A callback to an initiated composite application instance is delivered properly.

    This option is displayed when the composite application is active.
    Activate Activates the retired composite application revision. Note the following behavior with this option:

    • All composite applications are automatically active when deployed.

    • Other revisions of a newly deployed composite application remain active (that is, they are not automatically retired). If you want, you must explicitly retire them.

    This option is displayed when the application is retired.
    Set As Default Sets the selected composite application revision to be the default. Default revisions are indicated by a green dot in the Composite table. If a new request comes in for a specific composite application revision, that composite application revision is invoked. If a new request comes in without specifying a revision, the default revision is invoked. The default revision does not change when a composite application is retired. The default revision is changed automatically when a default composite application revision is undeployed.

    The default composite revision also changes automatically when you redeploy a composite application. The newly redeployed revision automatically becomes the default revision, unless at the time of redeployment, you specify to keep the previous default revision unchanged.

    Note that inbound adapters are activated only on the default revision.
    Deploy Deploys a revision. Deployment activates the composite application in the SOA Infrastructure. Use this selection when you want to deploy:

    • A new SOA composite application for the first time.

    • A new revision (for example, 2.0) of a SOA composite application that has a different revision that is currently deployed (for example, 1.0). This option enables both revisions 1.0 and 2.0 to be deployed at the same time.

    If you specify a revision that exists, you receive an error. You must change this revision outside of the Deploy SOA Composite wizard.

    For more information, see Section 5.1, "Deploying Applications" and Section 8.10, "Grouping SOA Composite Applications into Partitions."
    Undeploy Undeploys the selected composite application revision. The consequences of this action are as follows:

    • You can no longer configure and monitor this revision of the composite application.

    • You can no longer process instances of this revision of the composite application.

    • You cannot view previously completed processes.

    • The state of currently running instances is changed to stale and no new messages sent to this composite application are processed.

    • If you undeploy the default revision of the composite application (for example, 2.0), the next available revision of the composite application becomes the default (for example, 1.0).

    Note: Undeploying multiple SOA composite applications at the same time is supported if they are in the same partition.

    For more information, see Section 5.3, "Undeploying Applications" and Section 8.10, "Grouping SOA Composite Applications into Partitions."
    Redeploy Redeploys an existing revision of a SOA composite application. The consequences of this action are as follows:

    • A new version of a revision of a currently deployed SOA composite application is redeployed (for example, old version 1.0 is redeployed as new version 1.0).

    • The older, currently deployed version of this revision is removed (overwritten).

    • If the older, currently deployed version of this revision has running instances, the state of those instances is changed to stale.

    For more information, see Section 5.2, "Redeploying Applications."

    For more information, see Section 1.4.3.3, "Introduction to the Lifecycle State of SOA Composite Applications."

8.2.2 Managing the State of an Application from the SOA Composite Application Home Page

You can manage the state of an individual SOA composite application from the application's home page.

To manage the state of an application from the SOA composite 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, select a specific SOA composite application.

    The Dashboard of the selected SOA composite application is displayed (for this example, POApprovalEventPublisher).

    Description of sca_helloworld.gif follows
    Description of the illustration sca_helloworld.gif

    Notes:

    • The Total field of the Recent Instances section sometimes does not display the correct number of total instances despite instances having completed successfully. In these cases, click the Refresh icon in the upper right corner to view the actual number of total instances.

    • When the Capture Composite Instance State checkbox is enabled on the SOA Infrastructure Common Properties page, created instances are displayed immediately even if you have defined a constraint that appears to prevent an instance from being displayed immediately (for example, you have defined a flush delay of 10 minutes or specified a batch size of 100 records to write to a database). This is because instance tracking is moved to the immediate mode since the state of the composites must be captured.

  2. From the list of options at the top of the page, select a specific action to perform. These options are also displayed at the top of the Instances, Faults and Rejected Messages, Unit Tests, and Policies pages of the SOA composite application.

Action Description
Shut Down See the table under Step 3 for a description of this option.
Start Up See the table under Step 3 for a description of this option.
Retire See the table under Step 3 for a description of this option.
Activate See the table under Step 3 for a description of this option.
Test Enables you to initiate a test instance from the Test Web Service page.

Note: This button is disabled when the SOA composite application is stopped or retired. This is because you cannot create an instance for a stopped or retired application. This button is also disabled when there are no web services available for the application. Only composite applications having services with web service bindings can be tested from this page.

For more information, see Section 8.1, "Initiating a SOA Composite Application Test Instance."
Settings: Composite Audit Level Sets the level of audit tracking to perform at the SOA composite application level. This setting can override the audit level defined at the SOA Infrastructure level. By default, the value is Inherit, which does not override the SOA Infrastructure level setting.

If you select to set the audit tracking level, the following options are available:

  • Inherit: Logging matches the SOA Infrastructure audit level that you set on the SOA Infrastructure Common Properties page. This is the default setting.

  • Production: Minimal information for SOA composite application instances is collected. For example, the BPEL process and Oracle Mediator service engines do not capture the payload. Therefore, the payload details are not available in the flow audit trails. The BPEL service engine collects payload details for all activities except assign activities. This level is optimal for most standard operations and testing.

  • Development: Complete information for SOA composite application instances is collected. This option allows both composite instance tracking and payload tracking. This setting may have an impact on performance because the payload is stored at each step in the message flow. This setting is useful for debugging purposes.

  • Off: No logging is performed. Composite instance tracking information and payload tracking information are not collected.

Setting audit level tracking at the SOA composite application level overrides the same tracking set at the SOA Infrastructure level. By default, the settings are the same at the SOA composite application and SOA Infrastructure levels. SOA composite application settings are automatically changed when the global SOA Infrastructure settings are changed. By choosing any other setting at the SOA composite application level, you are overriding the inherited settings.

One form of overriding is when you explicitly select the same local composite value that happens to be the current global value. If the SOA Infrastructure setting is then changed, this specific composite application does not inherit the new value. For example, assume the SOA Infrastructure setting is Off. Therefore, all composite applications have their audit tracking set to Off. Then, you explicitly set composite application XYZ to Off. Then, go to the SOA Infrastructure and change the setting to Production. The tracking levels for all composite applications are now Production; except for XYZ, which is still set to Off.

Note the following impact of instance tracking changes on message flows that span several SOA composite applications (for example, a composite application invoking another composite application through a reference binding component or an event published in one composite application and subscribed to in another composite application).

  • If an intermediate composite application has disabled instance tracking, then a single message flow across multiple composite application instances appears as separate, unconnected flows. For example, assume a message flows through composite applications C1, C2, and C3. C1 and C3 have enabled instance tracking, while C2 has disabled it. Two separate flows for C1 and C3 are displayed in Oracle Enterprise Manager.

  • Sources or targets of events or messages may not be displayed. For example, assume you have two composite applications: C1 and C2. If C1 has disabled instance tracking, the flow trace does not show the origin of the message flow and makes it appear as if C2 were directly invoked.
Settings: Payload Validation Validates the XML schema-based payload at the inbound and outbound points of the composite application revision. If you enable payload validation and there is an invalid payload (that does not follow the schema), a fault is generated for that message.

The exception to this is the response message of a synchronous service. That message is not validated, even with payload validation enabled. Note that the inbound message is still validated; only the outbound message is not.
Settings: Enable/Disable Business Monitoring Select an option to invoke a confirmation dialog that displays the current status of the sensors.

  • Disable: Select to disable BPEL sensors for all BPEL components in this SOA composite application.

  • Enable: Select to enable BPEL sensors for all BPEL components in this SOA composite application.

The Enable/Disable Business Monitoring selection is only displayed for composites that have a BPEL service component, regardless of whether that component includes sensors.

Note that when BPEL sensors are disabled at the service engine level, you cannot enable or disable BPEL sensors at the SOA composite application level. You can enable or disable BPEL monitors and sensors at the service engine level in the BPEL Service Engine Properties page.

For more information, see Section 8.11, "Disabling and Enabling BPEL and BPMN Business Monitors" and Section 11.1, "Configuring BPEL Process Service Engine Properties."
Show WSDL and endpoint URI (icon) Click to display the end point addresses and WSDLs of all external services for this SOA composite application.

Note: If you are using the Safari Browser to view this information, see Section B.11, "Limitation on Using the Safari Browser to View WSDL File Content."
Show Composite XML Definition (... icon) Click to show the XML definition of the SOA composite application.

For more information, see the following sections:

8.2.3 Starting and Stopping a Managed Oracle WebLogic Server

If you start and stop a managed Oracle WebLogic Server on which the SOA Infrastructure is deployed in the middle of BPEL processing in a SOA composite application, note the following issues:

  • For synchronous BPEL processes

    The whole scenario is synchronous and the instances that are in a running state (after server restart) are pending in the BPEL wait activity. Therefore, the flow thread ends with the server (while sleeping in the wait activity). When the server is restarted, the same instance is not restarted because the flow is synchronous. Therefore, these instances always remain in a running state because no processing can happen on them after server restart.

  • For asynchronous BPEL process

    If server shutdown occurred in the middle of a BPEL invoke activity, the messages received by BPEL are not handled. BPEL does not automatically recover these messages during restart; they must be recovered manually using Facade API calls.

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...
    1. Select Home.

    2. Select the Deployed Composites tab.

    3. Select a specific SOA composite application.
    1. 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 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 Script." 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

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

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

8.3.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.3.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.3 Setting the Composite Instance Name at Design Time

You can set the instance name of a SOA composite application during design time in Oracle Mediator and Oracle BPEL Process Manager. The instance name appears in the Name column on the Instances page of a SOA composite application. When you specify a search criteria on the Instances page of a SOA composite application or the SOA Infrastructure, you can specify this name in the Name field.

8.3.3.1 Setting the Composite Instance Name in Oracle Mediator

To set the composite instance name in Oracle Mediator:

  1. Set the composite instance name through one of the following options:

8.3.3.2 Setting the Composite Instance Name in a BPEL Process

To set the composite instance name in a BPEL process:

  1. Use the Java BPEL exec extension bpelx:exec. This extension includes the built-in method setCompositeInstanceTitle(String title)for setting the instance name.

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

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

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

    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, 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 bp_delrejmess.gif follows
    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 soaapp_recovwithopts.gif follows
    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.

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

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

8.5.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.5.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.5.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.5.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.5.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.5.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.5.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 (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.5.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. Note that 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 end point 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>

Note that 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.5.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.

    Note that 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.5.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.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...
    1. Select Home.

    2. Select Deployed Composites.

    3. In the Composite section, select a specific SOA composite application.
    1. 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 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.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 bp_delrejmess.gif follows
    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 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). 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:

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:

Note:

Before testing SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for instructions on creating test cases.

  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.

    2. Select Deployed Composites.

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

    4. Click the Unit Tests tab.
    1. Under soa-infra, select a specific SOA composite application beneath the partition.

    2. Click the Unit Tests tab.
    1. 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 sca_unittest.gif follows
    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 sca_unittest2.gif follows
    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 sca_unittest3.gif follows
    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:

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.

Note:

Before attaching policies, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services for definitions of available policies and details about which ones to use in your environment.

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...
    1. Select Home.

    2. Select Deployed Composites.

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

    4. Click the Policies tab.
    1. Under soa-infra, select a specific SOA composite application beneath the partition.

    2. Click the Policies tab.
    1. 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 sca_policy.gif follows
    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 soaapp_policy1.gif follows
    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 soaapp_policy2.gif follows
    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 soaapp_policy3.gif follows
    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 soaapp_policy4.gif follows
    Description of the illustration soaapp_policy4.gif

For more information about policies, see the following documentation:

8.8.1 WS-RM Sessions

Multiple requests from Oracle SOA Suite in a single WS-RM session are not currently supported. Each request is in an individual WS-RM session.

8.8.2 Policy Attachments and Local Optimization in Composite-to-Composite Invocations

OWSM supports an Oracle SOA Suite local optimization feature for composite-to-composite invocations in which the reference of one composite specifies a web service binding to a second composite. Local optimization enables you to bypass the HTTP stack and SOAP/normalized message conversions during runtime. Local optimization is not used if the composites are in different containers. If a policy is attached to the web service binding, the policy may not be invoked if local optimization is used.

By default, an OWSM security policy includes a local-optimization property that identifies if the policy supports local optimization. You can view the setting for a policy in Oracle Enterprise Manager Fusion Middleware Control.

To view the local optimization setting for policies:

  1. In the navigator, expand the WebLogic Domain folder.

  2. Right-click WLS_SOAWC, and select Web Services > Policies.

  3. Select a policy and click Export to File.

  4. Open the file with a text editor and search for local-optimization to identify the value. This property supports the following values:

    • on: Local optimization is used in the attached policy, and the policy is not applied at runtime.

    • off: Local optimization is not used in the attached policy, and the policy is applied at runtime.

    • check-identity: If a JAAS subject exists in the current thread, local optimization is used. Otherwise, local optimization is not used.

For information on the default local optimization settings for security policies, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

You can override the local optimization setting for a policy by adding the oracle.webservices.local.optimization property in the binding section of the composite.xml file. The following values are supported:

  • true (default value): Local optimization is used, and the policy is applied if it is applicable to optimized calls (details are defined in the individual policy file).

  • false: Local optimization is not used, regardless of the default setting for the local-optimization property at the OWSM policy level. This setting forces the policy to be applied.

For example, the following setting of false causes oracle/wss_username_token_client_policy to be applied.

 <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

Notes:

  • SOA composite application exporting is currently only allowed at the individual SOA composite level.

  • Shared metadata is not exported as part of the composite export SOA archive (SAR).

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 soaapp_export.gif follows
    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

Note:

If SOA composite applications using the same inbound resource are deployed to different partitions, it cannot be guaranteed which partition picks up the message for processing.

For example, assume you are using the file adapter and /home/Directory1 is the inbound directory for the composite SOAComposite1. If this composite is deployed to both Partition1 and Partition2, when a file is placed in /home/Directory1, either the composite in Partition1 or Partition2 may pick up the file.

With the socket adapter, however, there is a limitation that does not permit you to deploy any composite that uses the same inbound port. In that case, an exception is thrown indicating that the inbound port is in use.

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

Table 8-2 Partition Management Actions

Action Perform on the Manage Partitions Page? Perform on the Partition Home Page?

Create a partition

Yes

No

Delete a partition

Yes

Yes. Select the SOA Partition menu, then select Delete This Partition.

Note: You can also delete a partition by right-clicking it in the navigator and selecting Delete This Partition.

Perform bulk lifecycle management tasks on all composites deployed to a specific partition:

  • Start all

  • Shut down all

  • Retire all

  • Activate all

  • Undeploy all

Yes

Yes

Note:

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

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

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

8.10.1 Creating and Deleting Partitions

You can create and delete partitions on the Manage Partitions page. A default partition named default is automatically included with Oracle SOA Suite. You can delete the default partition. Note that you cannot rename existing partitions; only creation and deletion of partitions is supported.

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

    From the SOA Infrastructure Menu... From the Home Page of a Specific Partition...
    1. Select Manage Partitions.
    1. From the Related Links list of a specific partition, select Manage Partitions.

    The Manage Partitions page displays the following details:

    • The name of each partition, the number of active and retired SOA composite application revisions in each partition, the name of the composites contained in each partition (under the View link), and the total number of running and faulted instances in each partition.

    • A utility for searching for a specific partition. Enter a full or partial partition name and click the Search icon or press the Return key. The search is not case-sensitive.

    Description of soaadmin_partition4.gif follows
    Description of the illustration soaadmin_partition4.gif

  2. To add a partition, click Create.

    The Create New SOA Partition dialog is displayed.

    Description of soaadmin_createpartition.gif follows
    Description of the illustration soaadmin_createpartition.gif

    1. In the Name field, enter a partition name, and click Create.

      Note:

      The name must conform to the following conventions:

      • ASCII letters and numbers are permitted.

      • Underscores (_) are permitted.

      • Hyphens (-) are permitted (except as the first character).

      • Non-ASCII letters are permitted.

      • Spaces are not permitted.

      Examples of valid names are mypartition, partition2, dept-a, customer_services, and 22. Examples of invalid names are -part2, /partition, and null or empty names.

      You cannot rename an existing partition or later transfer the composite applications you deployed to it to a different partition.

      The new partition is displayed in both the navigator under soa-infra and the SOA Partition column of the Manage Partitions page. You can now deploy composites to this partition by selecting Deploy to This Partition from the Deployment dropdown list or right-clicking a specific partition in the navigator and clicking Deploy to This Partition.

      When a composite is deployed to a partition, it is displayed beneath the partition in the navigator. Once deployed, a composite cannot be transferred to a different partition.

      Description of soaadmin_createpartition2.gif follows
      Description of the illustration soaadmin_createpartition2.gif

  3. To delete a partition, select a specific partition and click Delete. Note that you can also right-click a specific partition in the navigator and click Delete This Partition.

    The Delete SOA Partition dialog is displayed. Note the following:

    • If you want to re-create some of your composite deployments in another partition, you can export those composites to a JAR file before you delete this partition.

    • Before deleting the selected partition, all SOA composite application revisions in the partition are undeployed. The states of all undeployed instances of these revisions become stale.

    Note:

    You must have at least one partition. If you delete all partitions, you cannot deploy a SOA composite application.
    Description of soaadmin_deletepartition.gif follows
    Description of the illustration soaadmin_deletepartition.gif

    1. Click Delete (Undeploy All Composites).

      All composites that were deployed in the partition are undeployed and no longer appear in the navigator. The partition is then deleted from both the navigator under soa-infra and the SOA Partition column of the Manage Partitions page.

For information about performing bulk lifecycle management tasks from the Composites Control and Deployment lists, see Section 8.10.2, "Performing Bulk Lifecycle Management Tasks on Composites in Partitions."

You can also create partitions with the WebLogic Scripting Tool (WLST) and ant commands. For information, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference and Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

8.10.2 Performing Bulk Lifecycle Management Tasks on Composites in Partitions

You can perform bulk lifecycle management tasks on all SOA composite applications in a specific partition on the Manage Partitions page, on the home page of a specific partition, and from the menu that is displayed when you right-click a partition in the navigator.

Bulk lifecycle management tasks impact not one, but many, composites at once. If a composite has running instances and a lifecycle changing operation is performed on the composite, the instances may not complete. For information about how different lifecycle operations impact the composite instances, see Step 3 of Section 8.2.1, "Managing the State of All Applications at the SOA Infrastructure Level."

To perform bulk lifecycle management tasks on all SOA composite applications in a specific partition:

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

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator...
    1. Select Manage Partitions.
    1. Under soa-infra, select a specific partition.

    Note:

    As a shortcut, you can also right-click a specific partition in the navigator to display a menu for selecting the bulk lifecycle management actions described in this section. For more information about this menu, see Step 3 of Section 2.2.3, "Navigating Through the Partition Home Page and Menu."

    Two dropdown lists that are displayed on either page enable you to perform bulk lifecycle management actions:

    • Composites Control list

    • Deployment list

    On the home page of a specific partition, these lists are displayed at the top of the page.

    Description of soaadmin_partition3.gif follows
    Description of the illustration soaadmin_partition3.gif

    On the Manage Partitions page, these lists are displayed above the SOA Partition table:

    Description of soaadmin_partition4.gif follows
    Description of the illustration soaadmin_partition4.gif

    Note:

    You can also select to deploy composites to a partition and perform bulk lifecycle management tasks by selecting the SOA Partition menu at the top of the partition home page.

  2. To perform one of the following bulk lifecycle management tasks for all SOA composite applications contained in the selected partition, select the Composites Control list:

    • Start all composites.

    • Shut down all composites.

    • Activate all composites.

    • Retire all composites.

    Description of soaadmin_comp_control.gif follows
    Description of the illustration soaadmin_comp_control.gif

    1. Select an operation to perform.

      A dialog is displayed that prompts you to confirm your selection. When the operation completes, a confirmation message is displayed at the top of the page.

  3. To perform one of the following management tasks, select the Deployment list:

    • Specify a composite to deploy to this partition. This selection invokes the Deploy SOA Composite wizard where you specify a composite revision to deploy.

    • Undeploy all composites in this partition.

      A dialog is displayed that prompts you to confirm your selection. When the operation completes, a confirmation message is displayed at the top of the page.

    Description of soaadmin_deployment.gif follows
    Description of the illustration soaadmin_deployment.gif

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 sca_sensordis.gif follows
    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 sca_sensordis3.gif follows
      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 sca_sensordis8.gif follows
      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 sca_sensordis4.gif follows
      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 sca_sensordis5.gif follows
      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 sca_sensordis7.gif follows
      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.