Deploying and Managing SOA Composite Applications

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:

A new SOA composite application for the first time.
A new revision (for example, 2.0) alongside an older revision (for example, 1.0) without having an impact on the latter. The revision deployed last becomes the new default revision of that composite (unless you specify otherwise at a later step during deployment).
A SOA bundle (ZIP file) containing any shared data JAR files and multiple revisions (for example, revisions 2.0, 3.0, and 4.0) of a SOA composite application that has different revisions currently deployed (for example, 1.0). This option enables you to deploy revisions 1.0, 2.0, 3.0, and 4.0 together. When deploying a SOA bundle, all shared metadata JAR files are deployed first, after which the composite SAR files are deployed in random order.

The bundle can also contain revisions of different composites. There is no restriction that all revisions must be of the same composite application. There should not be any cross references between the composites in the same bundle. For example, composite A revision 1.0 should not reference composite B revision 1.0.

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.
Do not remove the user OracleSystemUser. This user is required for the proper functioning of Oracle SOA Suite, including deployment of SOA composite applications.

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...
Select SOA Deployment > Deploy.	Right-click soa-infra. Select SOA Deployment > Deploy.	Click the Deployed Composites tab. Above the Composite table, click Deploy.	Select SOA Deployment > Deploy Another Composite.

Note:

You can also access the Deploy SOA Composite wizard in the following ways:

Selecting Deploy To This Folder from the Deployment dropdown list on the Manage SOA Folders page or home page of a specific SOA folder
From the SOA Folder menu at the top of the home page of a specific SOA folder
Right-clicking a specific SOA folder in the navigator

The Select Archive page appears.

Description of soa-composite-deployment.png follows

Description of the illustration soa-composite-deployment.png

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.
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.
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.
Select the SOA folder into which to deploy this SOA composite application.

SOA folders enable you to logically group SOA composite applications into separate sections. Even if there is only one SOA folder available, you must explicitly select it. Once deployed, a composite cannot be transferred to a different SOA folder.

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

If the server contains no SOA folders, 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 SOA folder named default is automatically included with Oracle SOA Suite. You can delete the default SOA folder.
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 SOA folders:
- For the same task definition type, mapped attributes defined in one SOA folder are visible in another SOA folder.
- Rules defined on a task definition in one SOA folder can apply to the same definition in another SOA folder.
If you invoke the Deploy SOA Composite wizard by selecting Deploy To This SOA Folder from the Deployment dropdown list on the Manage SOA Folders page or home page of a specific SOA folder, the SOA folder to which to deploy is selected. Therefore, the Select Target page is skipped.
Click Next.

The Confirmation page appears.
Review your selections.

If your SOA composite application is using global token variables, a warning message is displayed asking you to verify that all tokens are configured in the system's mdm-url-resolver.xml file. If the token is not configured in the system or is defined in an incorrect location (for example, the import section of the composite.xml file), the SOA composite application does not deploy and an error message is displayed. For information about managing global token variables, see Managing Global Token Variables for Multiple SOA Composite Applications.
Select whether to deploy the SOA composite application as the default revision. The default revision is instantiated when a new request comes in.
Click Deploy.

Processing messages are displayed.

At this point, the deployment operation cannot be canceled. Deployment continues even if the browser page is closed.
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 Developing SOA Applications with Oracle SOA Suite.

Understanding Additional Deployment Behavior Scenarios

This section describes additional deployment behavior scenarios.

PermGen Memory Requirements for Multiple ADF Task Form Deployments

Memory consumption in the SOA and BPM servers increases with the deployment of each ADF task form.

If you must use Oracle JDK for production environments, deploy multiple task forms, and encounter a java.lang.OutOfMemoryError: PermGen space error, update the PermGen memory in $Domain/bin/setSOADomainEnv.sh file (for Unix) or DOMAIN_HOME\bin\setSOADomainEnv.cmd file (for Windows) to a value appropriate to your environment.

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). The following example provides the details:

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

If you want to deploy the task flow for the SOA composite application on all partitions, leave PartitionName blank. If you want to use different task flows for the composites on different partitions, then PartitionName must be specified.

In addition, if you want to reuse the same task flow project for another partition, you must change the web context-root.

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.

For information about deploying with ant scripts, see Developing SOA Applications with Oracle SOA Suite.
For information about deploying with WLST, see WLST Command Reference for SOA Suite.

Updating Instance, Fault, and Rejected Message States to Aborted During Undeployment or Redeployment

When you undeploy or redeploy a SOA composite application, the behavior of some states of instances, faults, and rejected messages is updated to aborted. This section describes which states are updated to aborted for the following instances, faults, and rejected messages:

SOA composite business flow instances
Oracle Mediator instances
BPEL process instances
Oracle BPMN instances
Human workflow task instances
Business rules instances
Oracle B2B instances
Reference binding component instances
Rejected messages
Business flow instance faults

Note:

Note the following details about business flow instances:

Instances no longer marked as aborted can still be purged.
Instances that are in the completed or failed state are not changed to aborted after undeployment or redeployment. This is a change from Release 11g (11.1.1.6) and earlier.

Table 12-1 shows the states that are updated to aborted during a SOA composite application redeployment or undeployment.

Table 12-1 Instance, Fault, and Rejected Message States Updated to Aborted During Undeployment or Redeployment

Element	Instance, Fault, And Rejected Message States Updated to Aborted
SOA composite business flow instances	The following flow instance states are updated to aborted: Running Requires recovery Suspended
Oracle Mediator instances	The following instance states are updated to aborted when their associated composite is redeployed and undeployed: Running Requires recovery
BPEL process instances	The following instance states are updated to aborted when their associated composite is redeployed and undeployed: Running Requires recovery There are scenarios under which you can redeploy a SOA composite application with the same revision ID and not have the initial instance marked as aborted. For information, see Redeploying SOA Composite Applications with the Same Revision ID Without Changing the Initial Running Instance to Aborted.
Oracle BPMN	The following instance states are updated to aborted when their associated composite is redeployed and undeployed: Running Requires recovery
Human workflow task instances	The following instance states are updated to aborted when their associated composite is redeployed and undeployed: Assigned Information requested Outcome updated Suspended Alerted
Business rule instances	The following instance states are updated to aborted when their associated composite is redeployed and undeployed: Running Completed successfully Faulted
Reference binding component instances	Reference binding component instances are not updated to aborted. Instead, the original state for the reference binding component is retained: Completed successfully Policy faulted Business faulted Faulted (neither policy or business)
Rejected messages	The following error categories associated with the rejected message are updated to aborted: System Business Policy Aborted Unknown
Instance faults	The following error categories associated with the business flow instance fault are updated to aborted: System Business Policy Aborted Unknown

For information about redeployment and undeployment, see Redeploying SOA Composite Applications and Undeploying SOA Composite Applications.

Redeploying SOA Composite Applications

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

When you undeploy and redeploy the same SOA composite application, you cannot retrieve the business flow instances created prior to composite undeployment. This is because if a composite is deployed, undeployed, and then deployed again, the two composites are not considered the same. Undeployment means the composite (and all related artifacts) has been removed from the system. The redeployed composite is treated as a completely new composite.
A new version of a revision of a currently deployed SOA composite application is redeployed on the same deployment target (for example, old version 1.0 is redeployed as new version 1.0).
If the older, currently deployed version of this revision has running instances, you can select whether to change the state of those instances to aborted. See Step 6 for a description of the Running Instances section of the Redeploy SOA Composite wizard and limitations on this option.

The instance state is available in the instance listing, and you can access audit and flow trace details.

For information about instance, fault, and rejected message states that are updated to aborted during redeployment, see Updating Instance, Fault, and Rejected Message States to Aborted During Undeployment or Redeployment.

Note:

When you redeploy Oracle JMS Adapter after making changes, the JMS subscribers become inactive. This also results in EIS Connectivity Errors. As the inbound adapter services become inactive, consumer JMS Adapter does not receive messages. To resolve this, shut down and restart the composite. For information on EIS Connectivity Errors see, Viewing SOA Composite Applications and Adapters Availability.
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:

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...
Select SOA Deployment >Redeploy. The Select Composite page appears. In the SOA Composite Deployments section, select the SOA composite application revision you want to redeploy, and click Next.	Right-click soa-infra. Select SOA Deployment > Redeploy. The Select Composite page appears. In the SOA Composite Deployments section, select the SOA composite application revision you want to redeploy, and click Next.	Click the Deployed Composites tab. In the Composite table, select a specific SOA composite application. Only one application can be redeployed at a time. Above the Composite table, click Redeploy.	Select SOA Deployment > Redeploy.

Note:

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

The Select Archive page appears.

In the Archive or Exploded Directory section, select the location of the SOA composite application revision you want to redeploy.
In the Configuration Plan section, optionally specify the configuration plan to include with the archive.
Click Next.

The Confirmation page appears.
In the Default Revision section, select whether to redeploy the SOA composite application as the default revision.

In the Running Instances section, select whether to continue running the current business flow instance.

Change states of running instances to aborted:
- Select to change the states of currently running instances to aborted after redeployment of the SOA composite application.
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, or a BPEL process that includes an embedded Java snippet with a dehydration call. 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 aborted.
  
  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 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.

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

Click Redeploy.

Processing messages are displayed.

At this point, the deployment operation cannot be canceled. Deployment continues even if the browser page is closed.
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.

Redeploying SOA Composite Applications with the Same Revision ID Without Changing the Initial Running Instance to Aborted

You can redeploy SOA composite applications with the same revision ID without changing the initial running instance to aborted. Redeployment is permitted in the following situations:

The composite does not include a durable BPEL process. Durable BPEL processes 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.
None of the durable BPEL processes have changed since the last deployment.

During redeployment, a check is performed to determine if the BPEL component has changed since the last deployment. If a change is detected, redeployment is rejected.

Note the following guidelines:

Modifying or deleting partner links is not allowed.
Dehydration activities must exactly match. For example, if the original BPEL process had three receive activities, the modified process must also have three identical receive activities.

Examples of Redeployment Behavior for Synchronous and Asynchronous BPEL Processes

This section provides several examples of redeployment behavior.

Assume you perform the following actions to redeploy a synchronous process:

Deploy a SOA composite application that includes synchronous BPEL process A.
Initiate several instances of a composite.
Modify synchronous BPEL process A by adding and deleting activities.
Redeploy the composite in promiscuous mode.

These actions result in the following:

Older instances of synchronous BPEL process A are not marked as aborted.
The audit trail of older instances shows the old process execution.
The audit trail of new instances shows the new process execution.

Assume you perform the following actions to redeploy an asynchronous process waiting on an activity.

Deploy a SOA composite application that includes asynchronous BPEL process B. This process is waiting on dehydration activity (wait/receive) act1.
Modify asynchronous BPEL process B by adding and deleting activities after act1.
Redeploy the composite in promiscuous mode.

These actions result in the following:

Old instances of asynchronous BPEL process B are not marked as aborted.
The audit trail of old instances still shows the old process execution.
The audit trail of new instances shows the new process execution.
The instances of asynchronous BPEL process B waiting on act1 continue from the activity using the new process definition.

Note:

For asynchronous processes waiting on a human task, the behavior for this scenario is identical to waiting on a receive activity.

Assume you perform the following actions to redeploy an asynchronous process waiting on a deleted activity.

Modify asynchronous BPEL process B by adding and deleting activities after act1 and also deleting activity act1.
Redeploy the process in promiscuous mode.

These actions result in deployment failing with an error indicating that the new process definition must include the activity act1.

Undeploying SOA Composite Applications

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

You can no longer configure and monitor this revision of the application.
You can no longer process instances of this revision of the application.
The state of currently running instances is changed to aborted and no new messages sent to this composite are processed.
The instance state of the undeployed composite application is set to aborted. The instance state is available in the instance listing, and you can access audit trail and flow trace details.
If you undeploy the default revision of the SOA composite application (for example, 2.0), the next active, available revision of the application is automatically designated as the new default (for example, 1.0).
A warning message is displayed at the end of this wizard when you undeploy the default composite revision.

If no active revision is available and the 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 this 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.

For information about instance, fault, and rejected message states that are updated to aborted during undeployment, see Updating Instance, Fault, and Rejected Message States to Aborted During Undeployment or Redeployment.

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 SOA folder. For information, see Managing SOA Folders and Work Manager Groups.

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...
Select SOA Deployment >Undeploy. The Select Composite page appears. In the SOA Composite Deployments section, select a specific SOA composite application to undeploy, and click Next.	Right-click soa-infra. Select SOA Deployment > Undeploy. The Select Composite page appears. In the SOA Composite Deployments section, select a specific SOA composite application to undeploy, and click Next.	Click the Deployed Composites tab. In the Composite table, select a specific SOA composite application. Only one application can be undeployed at a time. Above the Composite table, click Undeploy.	Select SOA Deployment > Undeploy.

Note:

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

Right-clicking a SOA folder and selecting SOA Deployment > Undeploy All From This Folder
Selecting Deployment > Undeploy All From This Folder on the SOA folder home page
Selecting Deployment > Undeploy All From This Folder for the selected SOA folder from the Manage SOA Folders page

The Confirmation page appears.

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.
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 SOA folder is deleted, all SOA composite applications in it are automatically undeployed. A message is displayed indicating that all the applications in that SOA folder are to be undeployed.

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 12-2 provides details.

Table 12-2 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 except 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
Settings: Composite Audit Level	No	Yes
Settings: Payload Validation	No	Yes
Settings: Enable/Disable Analytics & Sensors	No	Yes
Show WSDL and endpoint URI icon	No	Yes

Note:

To view the XML definition of the SOA composite application, click the Source tab at the bottom of the Composite Definition tab.

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

For more information, see Introduction to SOA Composite Applications.

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:

Access this page through one of the following options:

From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...	From the SOA Composite Menu...
Select Home.	Click soa-infra.	Select SOA Infrastructure.

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 SOA folder.
- A checkbox for searching only for activate SOA composite applications.
- A set of options for managing the lifecycle states of SOA composite applications (start up, shut down, set as default, and so on).
- A list of all SOA composite applications deployed in the SOA Infrastructure, including the SOA folder in which they are deployed, current mode (active or retired), 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 the illustration soa-infra-deployed-composit.png

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.

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 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 business flow instance is delivered properly. Note: Only callback of HTTP/web service requests will be processed. This won't handle composites using an adapter callback service, such as the AQ Adapter. 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 Deploying SOA Composite Applications and Managing SOA Folders and Work Manager Groups.
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 aborted 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 SOA folder. For more information, see Undeploying SOA Composite Applications and Managing SOA Folders and Work Manager Groups.
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 aborted. For more information, see Redeploying SOA Composite Applications.

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

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:

Access this page through one of the following options:

From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...
Select Home. Select the Deployed Composites tab. Select a specific SOA composite application.	Under soa-infra, expand the SOA folder. Select a specific SOA composite application.

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

Description of soa-composite-dashboard.png follows

Description of the illustration soa-composite-dashboard.png

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 Composite Definition, Flow Instances, Unit Tests, and Policies pages of the SOA composite application.

Action	Description
Shut Down	See the table under Step 3 of 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 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 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 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 of 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 Initiating a Test Instance of a Business Flow
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 parent level setting. depicts setting the audit level using the Composite home page. If you select to set the audit tracking level, the following options are available: Inherit: Logging level is inherited from the parent (Service Engine/SOA Infrastructure) audit level. This is the default setting. See Introduction to the Order of Precedence for Audit Level Settings for more information. Production: Minimal information for business flow 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 business flow instances is collected. This option allows both 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. 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.
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 Analytics & Sensors	Select to enable or disable the collection of the following data in the SOA composite application: Analytics: Enable you to collect analytic data (BPMN measurement marks and BPEL monitors). BPEL Sensors: Enable you to collect sensor data in BPEL faults, activities, and variables. This option is only displayed if the SOA composite application includes BPEL sensors. Composite Sensors: Enable you to collect composite sensor data. You can perform the following data collection actions: Globally enable or disable the collection of analytic and sensor data for all SOA composite applications at the SOA Infrastructure level. Individually disable the collection of analytics and sensor data for a specific SOA composite application. For more information, see Configuring Analytics and Sensors and Disabling and Enabling the Collection of Analytic, BPEL Sensor, and Composite Sensor Data. Note: The options of Enable/Disable Analytics & Sensors are only displayed for composites that include a BPEL process service component.
Show WSDL and endpoint URI (icon)	Click to display the endpoint 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 Limitation on Using the Safari Browser to View WSDL File Content.

The following image depicts an example of setting the audit level from the composite home page:

Setting Audit Level from composite home page.

For more information, see:

Understanding Additional Lifecycle State Behavior Scenarios

This section describes additional lifecycle state behavior issues.

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.

Setting the Business Flow Instance Name

You can set the business flow instance name during design time for Oracle Mediator and Oracle BPEL Process Manager. For more information, see Section "How to Set the Business Flow Instance Name or Composite Instance Name at Design Time" of Developing SOA Applications with Oracle SOA Suite.

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 either of the following locations:

From Oracle Enterprise Manager Fusion Middleware Control (as described in this section)
From Oracle JDeveloper

For more information, see Section "How to Deploy and Run a Test Suite from Oracle JDeveloper" of Developing SOA Applications with Oracle SOA Suite.

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 Developing SOA Applications with Oracle SOA Suite for instructions on creating test cases.

Expand SOA and click soa-infra (server_name) in the navigator.
Click Deployed Composites in the SOA Infra page and click the Composite.
In the Composite section, select a specific SOA composite application.
Click the Unit Tests tab.

The test cases that are displayed were designed in Oracle JDeveloper and included in a deployed SOA composite application.
Select the entire test suite or individual tests of a suite to run, and click Execute.

Description of the illustration soa-composite-unit-test.png

You are prompted to create a test.

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 soa-composite-test-cases.png follows

Description of the illustration soa-composite-test-cases.png

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. Under the weblogic link, click Help > Help for This Page for additional details.

Description of the illustration soa-composite-test-run-res.png
View assertion details at the bottom of the page. Assertions enable you to verify variable data or process flow.

Description of the illustration soa-composite-test-asserts.png
Click an instance number to view specific test details.

The business flow instances created by executing unit test runs are displayed with a yellow square. 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:

Introduction to SOA Composite Application Automated Testing
Chapter "Automating Testing of SOA Composite Applications" of Developing SOA Applications with Oracle SOA Suite for instructions on creating and running test cases for SOA composite applications and BPEL process service components in Oracle JDeveloper

Increasing Response Message Size When Executing Test Suites in Bulk

When executing test suites with large numbers of tests in bulk (for example, with 50 tests) with the sca-test ant command, the Results tab of the Unit Tests page in Oracle Enterprise Manager Fusion Middleware Control may not display any test results. The following error message appears in the server log files:

 <Nov 13, 2013 7:31:45 AM PST> <Error> <Socket> <BEA-000403> <IOException
occurred on socket:
Socket[addr=2606:b400:2010:4049:216:3eff:fe52:613d/2606:b400:2010:4049:216:3ef
f:fe52:613d,port=16139,localport=3872]
 weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'.
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'
     at
weblogic.socket.BaseAbstractMuxableSocket.incrementBufferOffset(BaseAbstractMu
xableSocket.java:230)
     at
weblogic.rjvm.t3.MuxableSocketT3.incrementBufferOffset(MuxableSocketT3.java:35
1)
     at weblogic.socket.SocketMuxer.readFromSocket(SocketMuxer.java:991)
     at 
. . .
. . .

This error can occur when the test response message is too large. To resolve this error, increase the MaxMessageSize property.

To increase the response message size:

Open the setDomainEnv.sh file.

Set MaxMessageSize to a larger value.

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Dweblogic.MaxMessageSize=30000000" export EXTRA_JAVA_PROPERTIES
How to Manage SOA Composite Applications with ant Scripts

For information about the sca-test ant script, see the "Deploying and Managing SOA Composite Applications with ant Scripts" section of Developing SOA Applications with Oracle SOA Suite.

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. Policies can require a credential to be entered in the CSF keystore or a certificate to be entered into the certificate store.

For more information about policies, see Introduction to Policies.

Note:

Before attaching policies, see Determining Which Predefined Policies to Use for a Web Service in Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use in your environment.
For information about overriding policy settings, see About Overriding Policy Configuration Properties Using Fusion Middleware Control in Securing Web Services and Managing Policies with Oracle Web Services Manager.

To manage SOA composite application policies:

Access this page through one of the following options:

From the SOA Infrastructure Menu...	From the SOA Folder in the Navigator...	From the SOA Composite Menu...
Select Home. Select Deployed Composites. In the Composite section, select a specific SOA composite application. Click the Policies tab.	Under soa-infra, expand the SOA folder. Select a specific SOA composite application. Click the Policies tab.	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 (such as 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 soa-composite-policy.png follows

Description of the illustration soa-composite-policy.png

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.
Select the component to or from which to attach or detach a policy.

Description of the illustration soa-composite-policy-attach.png

This invokes a dialog for attaching or detaching policies.

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

Description of the illustration soaapp_policy2.gif
Select policies to attach that are appropriate to your environment.
Click Attach.

The attached policy appears in the Directly Attached Policies section.

Description of the illustration soaapp_policy3.gif
Attach additional policies as needed.
When you are finished attaching policies, click Validate.
If an error message appears, make the necessary corrections until you no longer have any validation errors.
Click OK.

The attached policy is displayed in the policies table.

Description of the illustration soaapp_policy4.gif

Policy Subject of a Local Policy Can Become Invalid After a Server Restart

The policy subject of a local policy attached to a SOA composite application can become invalid after a server restart. You must invoke the WSLT listWebServicePolicies command a second time to resolve this issue. For example, perform the following steps:

Restart the SOA server.

Issue the following WLST command with data appropriate to your environment.

wls:/soainfra/serverConfig>
listWebServicePolicies('','default/LocalPolicyTest[1.0]','soa','
bpelprocess1_client_ep','BPELProcess1_pt')

BPELProcess1_pt :
URI="oracle/wss_username_token_service_policy",
category=security, policy-status=null; source=local policy set;
reference-status=enabled; effective=true
Property name="local.policy.reference.source",
value="LOCAL_ATTACHMENT"

The policy subject is invalid in this context:, and the following error is displayed.

WSM-02557 : The documents required to configure the Oracle Web Services
Manager runtime have not been retrieved from the Policy Manager 
application (wsm-pm), possibly because the application is not running
or has not been deployed in the environment. The query
"/policies/oracle/wss_username_token_service_policy" is queued for later
retrieval.

Issue the same WLST command a second time.
The command is successful this time, as indicated by the following message.
```
The policy subject is secure in this context.
```

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:

In the navigator, expand the WebLogic Domain folder.
Right-click WLS_SOAWC, and select Web Services > Policies.
Select a policy and click Export to File.
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 Securing Web Services and Managing Policies with Oracle Web Services Manager.

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://myhost.us.example.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 Configuring Local Optimization.

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.

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:

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

Note:

SOA composite application exporting is currently only allowed at the individual SOA composite level.
Shared data is not exported as part of the composite export SOA archive (SAR).

To export a running SOA composite application:

Go to the home page of the SOA composite application to export.
From the SOA Composite menu, select Export.

The Export Composite page appears.

Description of the illustration soa-compsite-runtime.png
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, and composite properties such as audit level settings and payload validation status.
- Option 4: Generates an archive file containing only the original design-time composite. Options 2 and 3 are not included.
If you want to append an additional name to the existing file, select Specify Custom Extension Text. For example, adding MyText to a file named sca_OrderBookingComposite_rev1.0.jar names the exported file as sca_OrderBookingComposite_rev1.0-MyText.jar.
Click Export.

The Processing: Export Composite dialog displays the progress of archive file generation. When generation completes, you are prompted to save the file.
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 close this dialog. Although the composite is exported, you cannot retrieve the actual exported file.
Specify the local directory in which to save the JAR file.
In the upper right of the Processing: Export Composite dialog, click the x icon to close the dialog.
On the Export Composite page, note that the Cancel button has changed to Done.
Click Done.

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

Disabling and Enabling the Collection of Analytic, BPEL Sensor, and Composite Sensor Data

You can enable and disable the collection of data for the following analytics and sensors in SOA composite applications:

Analytics (consist of BPMN measurement marks and BPEL monitors):

Enable you to collect the following types of data:
- Business indicator measurements at a certain point in the process or in a section of the process.
- BPEL process metrics that are sent to Oracle BAM Server, and then used for analysis and graphical display.
BPEL sensors:

Enable you to collect sensor data in BPEL faults, activities, and variables.
Composite sensors:

Enable you to collect composite sensor data:
- Monitor incoming and outgoing messages.
- Specify composite sensor details in the Flow Instance filter of the Search Options section of the Flow Instances page. This action enables you to locate a particular instance.
- Publish JMS data computed from incoming and outgoing messages.

You can globally enable and disable the collection of analytic and sensor data at the SOA Infrastructure level or you can individually disable the collection of analytics and sensor data composite level. The following order of precedence occurs when disabling or enabling a selection on the SOA Infrastructure Common Properties page or the individual SOA composite application page:

Disabling a selection on the Common Properties page disables the collection of data for that selection for all SOA composite applications. For example, if you disable composite sensors on the Common Properties page, composite sensor details are not collected for any flow instances created after this change.
Enabling a selection on the Common Properties page enables you to disable that setting at the individual SOA composite application level. For example, if you enable composite sensors on the Common Properties page and disable composite sensors for an individual SOA composite application (for example, named LoanFlow) on its home page under Settings > Enable/Disable Analytics & Sensors, composite sensor details are not collected for any instance of the LoanFlow SOA composite application after this change. However, all other flow instances continue to collect composite sensor details.

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 on the SOA Infrastructure Common Properties page.

Note:

Disabling BPEL sensors on the BPEL Service Engine Properties page has the same effect as disabling BPEL sensors on the SOA Infrastructure Common Properties page.

For more information about BPEL sensors, see Section "Using Oracle BPEL Process Manager Sensors and Analytics" of Developing SOA Applications with Oracle SOA Suite.

For more information about BPMN measurements, see Developing Business Processes with Oracle Business Process Management Studio.

Disabling Analytics and Sensors for a Specific SOA Composite Application

To disable analytics and sensors for a specific SOA composite application:

Access the SOA Infrastructure Common Properties page by following the steps in Configuring Analytics and Sensors

All analytics, BPEL sensors, and composite sensors are enabled by default.

Description of the illustration soa-analytic-sensor-view4.png
Go to the home page of the SOA composite application in which you want to disable analytics and sensors.
From the Settings menu of the composite, select Enable/Disable Analytics & Sensors.

Description of the illustration soa-composite-sensors.png

All analytics and sensors are enabled by default. Since this composite includes BPEL sensors, they are displayed in this message. If there are no BPEL sensors in a composite, the BPEL Sensors checkbox is not displayed.
Disable all analytics and sensors, and click OK.

Description of the illustration soa-analytic-sensor-view5.png

This disables the collection of analytic and sensor data for this specific SOA composite application. Because the collection of all analytic and sensor data is enabled at the SOA Infrastructure level, all other SOA composite applications in the SOA Infrastructure continue to collect data.

Disabling Analytics and Sensors for All SOA Composite Applications

To disable analytics and sensors for all SOA composite applications:

Access the SOA Infrastructure Common Properties page by following the steps in Configuring Analytics and Sensors
In the Analytics and Sensors Configuration section, disable all checkboxes.

Description of the illustration soa-analytic-sensor-disable.png
Click Apply, then Yes when prompted to save your changes.
Go to the home page of SOA composite applications.
From the Settings menu, select Enable/Disable Analytics & Sensors.

Description of the illustration soa-composite-sensors.png

The Enable/Disable Analytics & Sensors dialog shows that all analytics and sensors are globally disabled for this composite and all other composites.

Description of the illustration soa-analytic-sensor-view1.png

Selectively Disabling Specific Analytic and Sensor Settings for All SOA Composite Applications

To selectively disable specific analytic and sensor settings for all SOA composite applications:

Return to the SOA Infrastructure Common Properties page and select all checkboxes except Composite Sensors.

Description of the illustration soa-analytic-sensor-view2.png
Click Apply, then Yes when prompted to confirm.
Go to the home page of SOA composite applications.
From the Settings menu, select Enable/Disable Analytics & Sensors.

Note that composite sensors are globally disabled.

Description of the illustration soa-analytic-sensor-view3.png

Linking to Runtime Applications

Some runtime applications such as Oracle SOA Composer include a Links main menu with references to other runtime applications. Figure 12-1 shows the Links menu.

Figure 12-1 Links Main Menu in Runtime Application

Description of "Figure 12-1 Links Main Menu in Runtime Application"

A link is only shown when the application is running and accessible. The following runtime applications are supported for links:

Oracle SOA Composer
Oracle BPM Worklist
Oracle Business Process Composer
Oracle Business Process Management Workspace
Oracle B2B Console
Oracle SOA Suite for Healthcare
Oracle MFT Console

You can customize the Links main menu to display the URLs of other applications.

To customize the Links main menu:

Create a file named ext-app-menu.xml that lists the runtime application and its URL and port. The content of this file looks as follows:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:appMenu xmlns:ns2="http://xml.oracle.com/soa/appMenu">
    <groups>
        <group>
            <app name="Oracle OTN" url="http://otn.oracle.com"/>
            <app name="Oracle Home Page" url="http://www.oracle.com"/>
        </group>
        <group>
            <app name="MyApplication" url="http://www.myapplication.com"/>
        </group>
    </groups>
</ns2:appMenu>

Add ext-app-menu.xml to the $ORACLE_HOME/soa/soa/modules/oracle.soa.ext_11.1.1/classes/META-INF directory.
Change your current directory to $ORACLE_HOME/soa/soa/modules/oracle.soa.ext_11.1.1.

Run ant.

Buildfile: build.xml
create-manifest-jar:
  [delete] Deleting:
  /scratch/bdhenriq/fmwhome12/soa/soa/modules/oracle.soa.ext_
 11.1.1/oracle.soa.ext.jar
 [jar] Building MANIFEST-only jar:
 /scratch/myhome/fmwhome12/soa/soa/modules/oracle.soa.ext_
 11.1.1/oracle.soa.ext.jar
 BUILD SUCCESSFUL
Total time: 0 seconds

Restart the server.