Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite
11g Release 1 (11.1.1.6.3)

Part Number E10226-16
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Deploying and Managing SOA Composite Applications

This chapter describes how to deploy and manage SOA composite applications, including managing the states of deployed composites; deploying, redeploying, and undeploying a SOA composite application from Oracle Enterprise Manager Fusion Middleware Control; automating testing of SOA composite applications; managing policies; exporting deployed composites; grouping composites into partitions; and managing BPEL and BPMN monitors.

This chapter includes the following topics:

For information on the following:

Note:

If Oracle Enterprise Manager Fusion Middleware Control is run in a single sign-on (SSO)-enabled environment, you are again prompted to enter the user name and password credentials as part of the last step of the Deploy SOA Composite, Undeploy SOA Composite, and Redeploy SOA Composite wizards. This information is only requested once per Oracle Enterprise Manager Fusion Middleware Control session.

7.1 Deploying SOA Composite Applications

You can deploy SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control with the Deploy SOA Composite wizard. You must first create a deployable archive in Oracle JDeveloper or with the ant or WLST command line tool. Use the Deploy SOA Composite wizard to deploy any of the following:

Deployment extracts and activates the composite application in the SOA Infrastructure. After an application is deployed, you can perform administration tasks, such as creating instances, configuring properties, monitoring performance, managing instances, and managing policies and faults.

Note:

If you want to redeploy an existing revision of an application, do not use this wizard. Instead, use the Redeploy SOA Composite wizard.

To deploy SOA composite applications:

  1. Access the Deploy SOA Composite wizard through one of the following options:

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... From the SOA Infrastructure Home Page... From the SOA Composite Menu...
    1. Select SOA Deployment > Deploy.

    1. Right-click soa-infra.

    2. Select SOA Deployment > Deploy.

    1. Click the Deployed Composites tab.

    2. Above the Composite table, click Deploy.

    1. Select SOA Deployment > Deploy Another Composite.


    Note:

    You can also access the Deploy SOA Composite wizard by selecting Deploy To This Partition from the Deployment dropdown list on the Manage Partitions page or home page of a specific partition, from the SOA Partition menu at the top of the home page of a specific partition, or by right-clicking a specific partition in the navigator.

    The Select Archive page appears.

    Description of sca_deploy.gif follows
    Description of the illustration sca_deploy.gif

  2. In the Archive or Exploded Directory section, specify the archive of the SOA composite application to deploy. The archive contains the project files of the composite to be deployed (for example, HelloWorld_rev1.0.jar for a single archive or OrderBooking_rev1.0.zip for multiple archives). This information is required.

  3. In the Configuration Plan section, optionally specify the configuration plan to include with the archive. The configuration plan enables you to define the URL and property values to use in different environments. During process deployment, the configuration plan is used to search the SOA project for values that must be replaced to adapt the project to the next target environment.

  4. Click Next.

    The Select Target page appears.

    This page lists the Oracle SOA Suite managed server or cluster to which to deploy the SOA composite application archive.

  5. Select the partition into which to deploy this SOA composite application. Partitions enable you to logically group SOA composite applications into separate sections. Even if there is only one partition available, you must explicitly select it. Once deployed, a composite cannot be transferred to a different partition.

    If you want to deploy a SOA composite application to a partition that does not exist, exit the wizard and create the partition before deploying the composite. You create partitions in the Manage Partitions page, accessible from the SOA Infrastructure menu.

    If the server contains no partitions, you cannot deploy composite applications to that server. Also, if the server is not in a running state, you cannot deploy this archive. By default, a partition named default is automatically included with Oracle SOA Suite. You can delete the default partition.

    Note:

    Human workflow artifacts such as task mapped attributes (previously known as flex field mappings) and rules (such as vacation rules) are defined based on the namespace of the task definition. Therefore, the following issues are true when the same SOA composite application with a human workflow task is deployed into multiple partitions:

    • For the same task definition type, mapped attributes defined in one partition are visible in another partition.

    • Rules defined on a task definition in one partition can apply to the same definition in another partition.

    If you invoke the Deploy SOA Composite wizard by selecting Deploy To This Partition from the Deployment dropdown list on the Manage Partitions page or home page of a specific partition, the partition to which to deploy is selected. Therefore, the Select Target page is skipped.

  6. Click Next.

    The Confirmation page appears.

  7. Review your selections.

  8. Select whether to deploy the SOA composite application as the default revision. The default revision is instantiated when a new request comes in.

  9. Click Deploy.

    Processing messages are displayed.

    At this point, the deployment operation cannot be canceled. Deployment continues even if the browser page is closed.

  10. When deployment has completed, the home page of the newly deployed composite revision is displayed automatically. A confirmation message at the top of the page tells you that the composite has been successfully deployed. In the case of a bundle deployment, the Deployed Composites page of the SOA Infrastructure is displayed.

For information about creating configuration plans and deploying applications from Oracle JDeveloper, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

7.1.1 Deploying SOA Composite Applications with Task Flows

When you deploy a SOA composite application with a task flow Enterprise Resource Archive (EAR) file from Oracle Enterprise Manager Fusion Middleware Control or Oracle WebLogic Server Administration Console to a multiple partition environment, you cannot specify partition details. To specify a partition, modify the hwtaskflow.xml file to include the partition name in the generated EAR file (the project version of the file remains unchanged). This file is located under the TaskForm project adfmsrc directory (for example, HelpDeskRequestTaskFlow\adfmsrc\hwtaskflow.xml).

<hwTaskFlows
 xmlns="http://xmlns.oracle.com/bpel/workflow/hwTaskFlowProperties">
   <ApplicationName>worklist</ApplicationName>
   <LookupType>LOCAL</LookupType>
   <TaskFlowDeploy>false</TaskFlowDeploy>
   <PartitionName>partition2</PartitionName> 

7.1.2 Deploying SOA Composite Applications with ant Scripts and the WLST Command Line Tool

You can also deploy SOA composite applications with ant scripts and the WLST command line tool.

7.2 Redeploying SOA Composite Applications

You can redeploy SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control with the Redeploy SOA Composite wizard. Using the Redeploy SOA Composite wizard has the following consequences:

Notes:

  • If you want to maintain multiple revisions of a deployed application (for example, revisions 1.0 and 2.0), do not use this wizard. Instead, use the Deploy SOA Composite wizard.

  • Redeploying multiple SOA composite applications at once is not supported.

To redeploy applications:

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

    From the SOA Infrastructure Menu... From the SOA Folder in the Navigator... From the SOA Infrastructure Home Page... From the SOA Composite Menu...
    1. Select SOA Deployment >Redeploy.

      The Select Composite page appears.

    2. In the SOA Composite Deployments section, select the SOA composite application revision you want to redeploy, and click Next.

    1. Right-click soa-infra.

    2. Select SOA Deployment > Redeploy.

      The Select Composite page appears.

    3. In the SOA Composite Deployments section, select the SOA composite application revision you want to redeploy, and click Next.

    1. Click the Deployed Composites tab.

    2. In the Composite table, select a specific SOA composite application. Only one application can be redeployed at a time.

    3. Above the Composite table, click Redeploy.

    1. Select SOA Deployment > Redeploy.


    Note:

    You can also access the Redeploy SOA Composite wizard by right-clicking a partition and selecting SOA Deployment > Redeploy.

    The Select Archive page appears.

  2. In the Archive or Exploded Directory section, select the location of the SOA composite application revision you want to redeploy.

  3. In the Configuration Plan section, optionally specify the configuration plan to include with the archive.

  4. Click Next.

    The Confirmation page appears.

  5. In the Default Revision section, select whether to redeploy the SOA composite application as the default revision.

  6. In the Running Instances section, select whether to continue running the current instances of a redeployed SOA composite application.

    • Change states of running instances to stale:

      • Select to change the states of currently running instances to stale after redeployment of the SOA composite application.

        Note:

        Even if the state of a SOA composite application instance becomes stale, the instance states of BPEL process service components included in this composite remain as completed and not as stale. This is done for performance reasons, and is the expected behavior.

    • Continue instances on redeploy (current instance states will not be changed):

      Note:

      This option is displayed if Oracle BPM Suite is installed in the SOA Infrastructure, and only supported for the deployment of BPM composites. Do not select this option if you are deploying:

      • A SOA composite application from a SOA Infrastructure environment in which Oracle BPM Suite is also installed.

      • A BPM composite that includes a durable BPEL process, regardless of whether that process has been modified. Durable BPEL processes are those that take time to complete execution. Examples of durable BPEL processes are asynchronous processes (which are always durable) and synchronous processes that include a durable activity such as a wait activity.

        If you select this option and attempt to redeploy a durable BPEL process, then deployment fails.

      • Select to continue running instances after redeployment of the BPM composite application. This prevents these instance states from being changed to stale.

        Instances of different service components behave differently after redeployment. Ensure that you understand the following details:

    For... Description

    Oracle Business Process Management Notation (BPMN) instances

    You must manually migrate instances.

    BPMN service component instances are displayed as running in Oracle Enterprise Manager Fusion Middleware Control after redeployment. However, to ensure that your redeployed application is running correctly, search for instances with the pending migration state in Oracle BPM WorkSpace and manually migrate these instances to the new component definition.

    Oracle BPEL process, decision service (business rule), Oracle Mediator, and human workflow instances

    Instances are automatically migrated.

    Oracle Enterprise Manager Fusion Middleware Control attempts to automatically migrate the instances of these components. If the migration is successful, your SOA composite application is redeployed. However, if some of the following component instances cannot be migrated, redeployment of the entire composite fails.

    • BPEL instances: This capability is not supported if the composite includes a BPEL process service component that has changed from the previous revision.

    • Oracle Mediator: Checks the new component definition for compatibility. If it is incompatible with the existing component definition, the redeployment of the composite revision fails. However, if at the time of redeployment all Oracle Mediator processes within the running instances of this composite have completed, the definition change has no impact and redeployment is successful. Because Oracle Mediator instances take a short time to complete, their migration does not pose a high risk of redeployment failure.

    • Decision service: If the component definition has changed and is incompatible with the existing component definition, this may cause the redeployment of the composite revision to fail. However, if at the time of redeployment all decision service processes within the running instances of this composite have completed, the definition change has no impact and redeployment is successful. Because decision service instances take a short time to complete, their migration does not pose a high risk of redeployment failure.

    • Human workflow: Changes in human workflow do not impact any existing user task that has been created. Newly created human tasks after redeployment can use a new routing slip.


  7. Click Redeploy.

    Processing messages are displayed.

    At this point, the deployment operation cannot be canceled. Deployment continues even if the browser page is closed.

  8. When redeployment has completed, click Close.

    When redeployment has completed, the home page of the newly redeployed composite revision is displayed. A confirmation message at the top of the page tells you that the composite has been successfully redeployed.

7.3 Undeploying SOA Composite Applications

You can undeploy SOA composite applications from Oracle Enterprise Manager Fusion Middleware Control with the Undeploy SOA Composite wizard. Using the Undeploy SOA Composite wizard has the following consequences:

Note:

If you want to undeploy and then redeploy an existing revision of this application, do not use this wizard. Instead, use the Redeploy SOA Composite wizard. The Redeploy SOA Composite wizard enables you to redeploy an existing revision of a SOA composite application and remove (overwrite) the older, currently deployed version of the revision.

To undeploy applications:

Note:

You can undeploy multiple SOA composite applications together if they are located in the same partition. For information, see Section 7.8, "Grouping SOA Composite Applications into Partitions."

  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 Infrastructure Home Page... From the SOA Composite Menu...
    1. Select SOA Deployment >Undeploy.

      The Select Composite page appears.

    2. In the SOA Composite Deployments section, select a specific SOA composite application to undeploy, and click Next.

    1. Right-click soa-infra.

    2. Select SOA Deployment > Undeploy.

      The Select Composite page appears.

    3. In the SOA Composite Deployments section, select a specific SOA composite application to undeploy, and click Next.

    1. Click the Deployed Composites tab.

    2. In the Composite table, select a specific SOA composite application. Only one application can be undeployed at a time.

    3. Above the Composite table, click Undeploy.

    1. Select SOA Deployment > Undeploy.


    Note:

    You can also access the Undeploy SOA Composite wizard through these additional partition options:

    • Right-clicking a partition and selecting SOA Deployment > Undeploy All From This Partition

    • Selecting Deployment > Undeploy All From This Partition on the partition home page

    • Selecting Deployment > Undeploy All From This Partition for the selected partition from the Manage Partitions page

    The Confirmation page appears.

  2. If you are satisfied, click Undeploy. You are warned if you are about to undeploy the last remaining revision of a deployed composite application.

    Processing messages are displayed.

    At this point, the undeploy operation cannot be canceled. Undeployment continues even if the browser page is closed.

  3. When undeployment has completed, the SOA Infrastructure Deployed Composites page is displayed automatically. A confirmation message at the top of the page tells you that the composite has been successfully undeployed.

Note:

When a partition is deleted, all SOA composite applications in it are automatically undeployed. A message is displayed indicating that all the applications in that partition are to be undeployed.

7.4 Managing the State of Deployed SOA Composite Applications

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

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

Table 7-1 Application State Actions

Action Perform on 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."

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

    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.

    Note the following details when you attempt to retire the default composite revision, or have already retired a default composite revision. A warning page is also displayed with these details.

    • When you attempt to retire the default composite revision, if another active revision of the composite is found, it is designated as the new default revision. If there are multiple active revisions, the active composite that was most recently the default revision (based on the time stamp) is designated as the default revision. If you then re-activate the retired revision, it does not automatically become the default revision again. You must explicitly make it the default revision again.

    • If you retire the default composite revision and no active revision of this composite is found, a new default revision is not designated and a warning message is displayed. The retired revision remains the default revision. However, this composite can no longer process any incoming requests. To process new incoming requests for this composite, you must deploy a new revision or re-activate one of the previously retired revisions.

    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 can change when a composite application is retired. The change is based on whether there is another active revision of the composite. For details, see the description for the Retire action in this table.

    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. For details, see the description of the Undeploy action in this table.

    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 7.1, "Deploying SOA Composite Applications" and Section 7.8, "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, active revision of the composite application becomes the default (for example, 1.0).

      If no active revision is available and the old default revision is undeployed, your composite may be unable to process new incoming requests. It is recommended that you have at least one active revision of this composite deployed before you undeploy the default revision.

      If you undeploy the default revision and no active revisions of this composite are found, a retired revision is automatically designated as the new default revision. A warning message is displayed after this wizard closes. Although all currently executing instances complete normally in retired composites, they cannot process any incoming requests. To process new incoming requests for this composite after the current default revision is undeployed, you must deploy a new revision or reactivate a previously retired revision.

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

    For more information, see Section 7.3, "Undeploying SOA Composite Applications" and Section 7.8, "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, you can select whether to change the state of those instances to stale.

    For more information, see Section 7.2, "Redeploying SOA Composite Applications."


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

7.4.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, expand the partition.

    2. Select a specific SOA composite application.


    The Dashboard page of the selected SOA composite application is displayed.

    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.

    • After the SOA Infrastructure is started, it may not be completely initialized to administer incoming requests until all deployed composites are loaded. During SOA Infrastructure initialization, a warning message is displayed at the top of the SOA composite application home page. Do not perform operations such as composite deployment, composite undeployment, and others while this message is displayed. For more information, see Section 3.2.1, "Waiting for SOA Infrastructure Startup Initialization to Complete."

  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 of Section 7.4.1, "Managing the State of All Applications at the SOA Infrastructure Level" for a description of this option.

Start Up

See the table under Step 3 of Section 7.4.1, "Managing the State of All Applications at the SOA Infrastructure Level" for a description of this option.

Retire

See the table under Step 3 of Section 7.4.1, "Managing the State of All Applications at the SOA Infrastructure Level" for a description of this option.

Activate

See the table under Step 3 of Section 7.4.1, "Managing the State of All Applications at the SOA Infrastructure Level" 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 process 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 Fusion Middleware Control.

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

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 7.9, "Disabling and Enabling BPEL and BPMN Business Monitors" and Section 12.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.8.1, "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:

7.4.3 Starting and Stopping a Managed Oracle WebLogic Server on Which the SOA Infrastructure is Deployed in the Middle of BPEL Processing

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 processes

    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. For more information about the Facade API, see Chapter 10, "Programmatically Managing SOA Composite Applications."

7.4.4 Setting the Composite Instance Name

You can set the instance name of a SOA composite application during design time for Oracle Mediator and Oracle BPEL Process Manager. For more information, see Section "Setting the Composite Instance Name at Design Time" of Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

7.5 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. You can also create BPEL process service component test cases in the SOA composite application test case.

To automate the testing of SOA composite applications:

Note:

Before testing SOA composite applications or BPEL process service components from Oracle Enterprise Manager Fusion Middleware Control, see Chapter "Automating Testing of SOA Composite Applications" of 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, expand the partition.

    2. Select a specific SOA composite application.

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

7.6 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, expand the partition.

    2. Select a specific SOA composite application.

    3. Click the Policies tab.

    1. Select Policies.


    The Policies page enables you to attach and detach policies to and from SOA composite applications. 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 or from 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:

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

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

For more information about local optimization, see Section 3.7, "Configuring Local Optimization."

7.7 Exporting a Deployed SOA Composite Application

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

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.

7.8 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, 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:

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 7-2 provides more specific details on the tasks you can perform from both pages.

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


Notes:

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

  • After the SOA Infrastructure is started, it may not be completely initialized to administer incoming requests until all deployed composites are loaded. During SOA Infrastructure initialization, a warning message is displayed at the top of the Manage Partitions and Partitions home pages. Do not perform operations such as composite deployment, composite undeployment, and others while this message is displayed. For more information, see Section 3.2.1, "Waiting for SOA Infrastructure Startup Initialization to Complete."

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

7.8.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. 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. 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 7.8.2, "Performing Bulk Lifecycle Management Tasks on Composites in Partitions."

You can also create partitions with the Oracle 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.

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

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

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 12.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 37.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 and not BPMN components, 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.) 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.