1. Administering Oracle SOA Suite and Oracle Business Process Management Suite
  2. Administering the SOA Infrastructure
  3. Managing SOA Folders and Work Manager Groups

8 Managing SOA Folders and Work Manager Groups

This chapter describes how to manage SOA folders, manage work manager groups, and secure access to folders, including how to create, delete, and edit folders; perform bulk management lifecycle tasks on composites; view and configure work manager properties; view work manager pending and completed requests; view and create work manager groups; view SOA folder roles; and assign users to SOA folder roles.

Support for SOA permissions and roles changed between 11g and 12c as follows:

  • In 11g, Oracle SOA Suite APIs and runtime were protected using Oracle SOA Suite application roles and Oracle Enterprise Manager Fusion Middleware Control protected user actions with the Oracle WebLogic Server role. Role mapping was required.

  • In 12c, Oracle SOA Suite APIs and runtime and Oracle Enterprise Manager Fusion Middleware Control both protect user actions and the user interface using Oracle SOA Suite permissions. (Oracle SOA Suite application roles are defined by a set of permissions.) Therefore, mapping a user to one of the application roles gives them the required permissions.

This chapter includes the following sections:

For information about monitoring the overall status of a specific folder, see Monitoring the Overall Status of the SOA Infrastructure or Individual SOA Folder.

For information about tracking the status of business flow instances in a specific folder, see Tracking Business Flow Instances .

For information about performing error recovery in a specific folder, see Recovering From Faults in the Error Hospital.

Managing SOA Folders

You can deploy SOA composite applications into separate sections of the SOA Infrastructure known as folders. Deploying composites to folders enables you to:

  • Logically group SOA composites

  • Perform the following bulk lifecycle management tasks on all SOA composite applications within a specific folder:

    • Start all composites

    • Shut down all composites

    • Retire all composites

    • Activate all composites

    • Undeploy all composites

  • Secure access to folders

At least one folder is required for deploying SOA composite applications. A default folder named default is automatically included with Oracle SOA Suite. You can delete the default folder. You cannot rename existing folders; only creation and deletion of folders is supported.

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

Note:

If SOA composite applications using the same inbound resource are deployed to different folders, it cannot be guaranteed which folder 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 Folder1 and Folder2, when a file is placed in /home/Directory1, either the composite in Folder1 or Folder2 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.

To manage folders:

Access the Manage SOA Folders page through one of the following options:

From the SOA Infrastructure Menu... From the SOA Node in the Target Navigation Tree...

  1. Select Manage SOA Folders.

  1. Expand the SOA node.

  2. Right-click soa-infra, select Manage SOA Folders.

The Manage SOA Folders page displays the following details:

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

  • Links for creating, deleting, and editing folders.

  • A Composites Control list for starting up, shutting down, activating, and retiring all composites in the selected folder.

  • A Deployment list for deploying to this folder or undeploying all from this folder.

  • A table that lists each folder, the work manager group, the number of active and retired SOA composite application revisions in each folder, and the name of the composites contained in each folder (under the View link).

Manage SOA Folders page

You can perform the following folder management tasks:

For more conceptual information about folders, see Introduction to SOA Folders.

Creating SOA Folders

You can create folders from the Manage SOA Folders page.

Note:

You must ensure that the Session Lock on the Change Center in the Oracle WebLogic Server Administration Console is released before creating a folder.

To create a folder:

  1. Access the Manage SOA Folders page as described in Managing SOA Folders.

  2. Click Create.

    The Create New SOA Folder dialog is displayed.

    1. In the Name field, enter a folder name.

      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 myfolder, folder2, dept-a, customer_services, and 22. Examples of invalid names are -folder2, /folder, and null or empty names.

    2. From the Work Manager Group list, select an existing work manager group or click Add to create a new work manager group. To create a new work manager group, see Viewing and Creating Work Manager Groups.

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

  3. Click Create.

    The new folder is displayed under the SOA Folder column of the Manage SOA Folders page. You can now deploy composites to this SOA folder by selecting Deploy to This Folder from the Deployment dropdown list. Once deployed, a composite cannot be transferred to a different folder.

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

You can also create SOA folders with the Oracle WebLogic Scripting Tool (WLST) and ant commands. For information, see WLST Command Reference for SOA Suite and Developing SOA Applications with Oracle SOA Suite.

Deleting Folders

Note:

You must have at least one folder. If you delete all folders, you cannot deploy a SOA composite application.

You can delete folders from the Manage SOA Folders page.

Note the following:

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

  • Before deleting the selected folder, all SOA composite application revisions in the folder are undeployed. The states of all active instances of undeployed composites are changed to aborted.

To delete a folder:

  1. Access the Manage SOA Folders page as described in Managing SOA Folders.
  2. Select a specific folder and click Delete.
    The Delete SOA SOA Folder dialog is displayed.
  3. Click Delete (Undeploy All Composites).

    All composites that were deployed in the folder are undeployed and no longer appear in the navigator. The folder is then deleted from the SOA Folder column of the Manage SOA Folders page.

Changing the Work Manager Group of a SOA Folder

You can change the work manger group associated with a folder by either selecting an existing group or creating a new group.

Note:

You must ensure that the Session Lock on the Change Center in the Oracle WebLogic Server Administration Console is released before changing the work manager group of a folder.

To change the work manager group of a folder:

  1. Access the Manage SOA Folders page as described in Managing SOA Folders.
  2. Select a specific folder, and click Edit.

    The Edit SOA Folder dialog is displayed.

  3. From the Work Manager Group list, select an existing work manager group or click Add to create a new work manager group. To create a new work manager group, see Viewing and Creating Work Manager Groups.
  4. Click Apply.
  5. Restart the server for the work manager group change to take effect.

Performing Bulk Lifecycle Management Tasks on Composites in SOA Folders

You can perform bulk lifecycle management tasks on all SOA composite applications in a specific folder on the Manage SOA Folders page or on the SOA Folder page of a specific folder.

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 business flow instances, 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 folder:

  1. Access the Manage SOA Folders page as described in Managing SOA Folders.

    Two dropdown lists enable you to perform bulk lifecycle management actions:

    • Composites Control list

    • Deployment list

    On the Manage SOA Folders page, these lists are displayed above the SOA Folder table.

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

    • Start all composites.

    • Shut down all composites.

    • Activate all composites.

    • Retire all composites.

    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.

    2. Click OK to continue.

      Note:

      Be aware that when you select Retire All from the Composite Control list, all composites in that folder are retired with no warning message to indicate that the default, last active composite is being retired.

      This is the expected behavior when performing a bulk retirement of all composites in a folder.

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

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

    • Undeploy all composites in this folder.

      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.

Managing Work Manager Groups

Each folder must be associated with a work manager group that consists of work managers. A work manager is an Oracle WebLogic Server entity that represents a logical thread pool. It is similar to a queue in which work items line up for processing. You can define priorities for the work to be processed by work managers. Work managers manage thread pools internally and automatically, providing for optimal scheduling. Work managers provide the following capabilities:

  • A single internal global pool.

  • A multiple, priority-based, work request queue. The priority is computed internally based on the work manager constraints.

  • New threads that are automatically added and removed based on the work load.

Oracle WebLogic Server manages the thread pool on behalf of Oracle SOA Suite. It automatically controls the number of threads required based on defined criteria. You define the priority and Oracle WebLogic Server determines if more threads are required.

There are two ways to define work priorities in the Oracle WebLogic Server Administration Console.

  • Request classes:

    • Defines the necessary percentage of server resources to share

    • Defines the necessary application response times

  • Constraints:

    • Maximum thread constraints: Once reached, the server does not schedule requests of this type until the number of concurrent executions falls below the limit. If you do not specify a value, the default value is unlimited.

    • Minimum thread constraints: Ensures the number of threads the server allocates to impacted requests to avoid deadlocks. The default value is zero.

    • Capacity: Causes the server to reject requests when it has reached its capacity.

    Note:

    The minimum and maximum threads are defined using the work manager names and they can be shared by multiple work managers. Work managers are defined at the domain level.

Oracle WebLogic Server includes a number of Oracle SOA Suite work managers. You can create Oracle SOA Suite work manager groups that are automatically associated with these work managers. A work manager group consists of work managers dedicated to processing Oracle SOA Suite background work for a given folder. Work manager groups isolate folder configuration and request processing. A work manager group can be shared by multiple folders.

The mapping works as follows:

  • Mapping between a service engine thread pool (for example, a BPEL invoke pool) and a work manager in a work manager group.

  • Mapping between a folder and a single work manager group. A work manager group comprises all logical thread pools for background processing tasks in a given folder. Multiple folders can share a single work manager group. For example:

    • The default and HR folders can be associated with a standard work manager group.

    • The sales folder can be associated with a high priority work manager group.

    However, each folder is associated with only one work manager group.

Viewing and Configuring Work Manager Properties

You can view and configure work manager properties through one of the following options:

  • Configure the following properties:

    • The SOADataSource property in the Oracle WebLogic Server Administration Console to configure the number of database connections in the data source.

    • The SOAMaxThreadsConfig property in the System MBean Browser to allocate percentages for the various work managers in the group.

    Maximum thread constraints are automatically created based on these settings. For information, see Configuring Database-bound Processing Threads.

  • Configure work manager properties such as minimum thread, maximum thread, and capacity constraints from Oracle WebLogic Server Administration Console. This option is a more advanced method than the first one. For information, see Viewing and Configuring Work Manager Constraints.

Viewing and Configuring Work Manager Constraints

You can view and configure Oracle SOA Suite work managers in Oracle WebLogic Server Administration Console:

  1. Log in to Oracle WebLogic Server Administration Console.
  2. In the Domain Structure under domain_name (for example, named soainfra), expand Environment > Work Managers.

    The default work managers automatically included with each SOA folder are displayed. The work managers for the group are prefixed with the SOA folder name (for this example, default). This enables you to easily identify which work manager is for which SOA folder.

    Description of soa-work-manager-wls.png follows
    Description of the illustration soa-work-manager-wls.png
  3. Click Next to display additional work managers automatically included with the SOA folder.
  4. Click a specific work manager to display details about request classes and constraint settings. You can change settings, as necessary.

Viewing Work Manager Pending and Completed Requests

You can view the number of pending and completed requests of each work manager.

  1. Log in to Oracle WebLogic Server Administration Console.
  2. In the Navigator under soainfra, click Deployments.
  3. In the table, browse for and select soa-infra.
  4. At the top, click Monitoring, then Workload.

    Details about pending and completed requests in the work managers are displayed. The Oracle WebLogic Server default thread is used to process all client-initiated work.

    Description of soa-work-manager-wls-monitr.png follows
    Description of the illustration soa-work-manager-wls-monitr.png

For information about exception messages caused by the unavailability of work manager threads, see Unavailability of Work Manager Threads for Incoming Processing.

Viewing and Creating Work Manager Groups

You can create work manager groups for each SOA folder. When you create a group, the Oracle SOA Suite work managers shown in Managing Work Manager Groups are automatically added to the group. A default work manager group named default is automatically included with Oracle SOA Suite.

Note:

You must ensure that the Session Lock on the Change Center in the Oracle WebLogic Server Administration Console is released before creating or deleting work manager groups.

To create work manager groups:

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

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

    1. Select Work Manager Groups.

    1. Right-click soa-infra > server_name.

    2. Select Work Manager Groups.

    The Manage Work Groups page is displayed.

  2. Expand the work manager groups to display the work managers automatically created with each group, the maximum thread constraint values and classes, the minimum thread constraint values and classes, and the fair share request classes. Constraints define the configuration values for work to be processed by work managers.

    A fair share request class expresses a scheduling guideline that Oracle WebLogic Server uses to allocate threads to requests. Request classes ensure that high priority work is scheduled before less important work, even if the high priority work is submitted after the lower priority work. Oracle WebLogic Server takes into account how long it takes for requests to each module to complete.

    A fair share request class specifies the average thread-use time required to process requests. The value of a fair share request class is specified as a relative value, not a percentage. Therefore, if two request classes are defined as 400 and 100, they have the same relative values as 80 and 20 or 4 and 1, respectively.

    For example, RequestClass1, RequestClass2, and RequestClass3 have the fair share values of 10, 20, and 50, respectively. There is a 12.5% (10/80) chance that the next free thread performs work for RequestClass1. Similarly, there is a 25% (20/80) chance it next services RequestClass2 and a 62.5% (50/80) chance it next services RequestClass3.

    Description of soa-work-manager-create.png follows
    Description of the illustration soa-work-manager-create.png

  3. From the View list, select Metrics to display the number of processes:

    • Completed

    • Active and pending

    • Active and stuck

    Description of soa-work-manager-metrics.png follows
    Description of the illustration soa-work-manager-metrics.png

  4. From the Server list, select a managed server in a cluster for which to view statistics.

  5. Click Create.

    The Create Work Manager Group dialog is displayed.

  6. Enter a name and an optional description, and click OK.

    Description of soa-work-manager-group-crea.png follows
    Description of the illustration soa-work-manager-group-crea.png

    The work manager group is displayed in the table (for this example, testgroup). The Oracle SOA Suite work managers are automatically included in the work manager group, and display beneath the work manager group name.

    Description of soa-work-manager-group-new.png follows
    Description of the illustration soa-work-manager-group-new.png

  7. From the SOA Infrastructure menu, select Manage SOA Folders.

  8. Assign the work manager group to a SOA folder in either of the following ways:

    1. Click Create to create a new SOA folder to which you assign the work manager group, as described in Creating SOA Folders.

    2. Click Edit to change the work manager group of the selected SOA folder, as described in Changing the Work Manager Group of a SOA Folder.

      This change requires a server restart.

    Note:

    You cannot delete a work manager group that is currently associated with a SOA folder.

Securing Access to SOA Folders

All folders are automatically secured with application roles and folder roles. Folder-based security provides the following benefits:

  • Administrative access control

    • Access control of information is provided at folder levels. You can only view the folder and composites to which you have access. For example, a user with access to only Folder1 can only see Folder1 and its deployed composites. This user cannot see any other folders.

    • Association of different users to separate roles for each folder.

  • Striping of instance data by folders

    • Oracle Enterprise Manager Fusion Middleware Control pages such as Flow Instances and Error Hospital show instance data filtered by folder.

    • The audit trail is displayed based on access control.

  • Folder level resource management

Application roles and folder roles consist of various combinations of Java permission classes and actions.

Table 8-1 shows the Oracle SOA Suite-wide application roles. These applications roles are not limited to a specific folder.

Table 8-1 Application Roles

Application Role Description

MiddlewareOperator

This role provides the following capabilities:

  • Ensures the continued operation of Oracle SOA Suite.

  • Provides the main contact when a deployed SOA composite application does not operate correctly.

  • Customizes operational settings such as the audit level; configures error notification rules; enables, disables, and monitors composites; and manages composite sensors.

MiddlewareAdministrator

This role provides the following capabilities:

  • Ensures the continued operation of Oracle Fusion Middleware servers.

  • Not always responsible for deployed SOA composite applications.

  • Provides backup for operational roles and super user access to perform any tasks required for the continued operation of Oracle SOA Suite.

Table 8-2 describes the roles available with each folder. These folder-specific roles include various combinations of permission classes and actions.

Table 8-2 Folder Roles

Folder Role Description

Composer

For making changes to SOA composite application artifacts, such as business rules, security policies, fault policies, and so on.

Deployer

For deploying new SOA composite applications, upgrading existing SOA composite applications, and managing the continuous integration and build process.

Tester

For performing testing on preproduction systems typically using a combination of command line tools, Oracle Enterprise Manager Fusion Middleware Control, and custom user interfaces.

Monitor

For the successful operation of deployed SOA composite applications in the folder.

ApplicationOperator

For handling user complaints and making decisions on requests that result in faults in the automated process. An administrator receives notifications regarding these transactions and can take steps to recover from the fault or terminate the transaction.

Note: This role does not include the Deployer and Tester roles.

You can perform the following folder access management tasks:

Viewing SOA Folder Roles

You can view the roles associated with each folder on the Application Roles page.

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

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

    1. Select Security > Application Roles.

    1. Expand SOA.

    2. Right-click soa-infra (server_name).

    3. Select Security > Application Roles.

    The Application Roles page is displayed.

  2. Click the Search application roles icon.

    For each folder, the roles described in Table 8-2 are displayed:

    • folder_name_Monitor

    • folder_name_Composer

    • folder_name_Tester

    • folder_name_Deployer

    • folder_name_ApplicationOperator

    Description of soa-partition-applicat-role.png follows
    Description of the illustration soa-partition-applicat-role.png

Viewing the Permissions Assigned to Each SOA Folder Role

You can view the permissions assigned to each folder role on the Application Policies page.

Note:

Oracle SOA Suite roles grant Oracle Enterprise Scheduler permissions to those roles. These permissions are permission sets. Permission sets are not currently displayed in Oracle Enterprise Manager Fusion Middleware Control.

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

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

    1. Select Security > Application Policies.

    1. Expand SOA.

    2. Right-click soa-infra (server_name).

    3. Select Security > Application Policies.

  2. Select a folder role in the table.

    The bottom of the page is refreshed to display the permission class and actions assigned to the selected folder role.

    Description of soa-partition-applicat-perm.png follows
    Description of the illustration soa-partition-applicat-perm.png

Assigning SOA Folder Roles to a User

You can assign the specific SOA folder roles you want a user to possess on a folder. These roles determine the tasks that a user can perform in Oracle Enterprise Manager Fusion Middleware Control.

Note the following authorization checking changes for 12c:

  • Authorization checking occurs against permissions, which allows for finely granular Oracle SOA Suite roles based on these permissions.

  • Only the Oracle WebLogic Server monitor role and appropriate Oracle SOA Suite roles are required for Oracle Enterprise Manager Fusion Middleware Control access.

  • Avoid granting WLSOperator and WLSAdmin with added privileges for Oracle SOA Suite monitoring.

To assign SOA folder roles to users:

  1. Create a user in which to assign folder roles:

    1. In the Navigator, select WebLogic Domain > soainfra.

    2. From the WebLogic Domain menu, select Security > Users and Groups.

    3. In the Users tab, click the Create icon to create a user.

    4. Create the user name and password, and click OK.

    Note:

    When you create users in Oracle WebLogic Server Administration Console, folder-specific users only require the Monitor role. This role enables these users to access Oracle Enterprise Manager Fusion Middleware Control. Only the system administrator or super user requires the Administrator role.

  2. Log in to Oracle Enterprise Manager Fusion Middleware Control with a user account that includes the Oracle WebLogic Server Admin role. Application policies are controlled by Oracle Platform Security Services. You directly access Oracle Platform Security Services to create SOA roles. This role enables you to view and map application roles to the user you created.

  3. Access the Application Roles page through one of the following options:

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

    1. Select Security > Application Roles.

    1. Expand SOA > soa-infra.

    2. Right-click soa-infra (server_name).

    3. Select Security > Application Roles.

  4. Click the Search application roles icon.

  5. Select the folder role to which to map to the user, and click Edit.

    For this example, the ApplicationOperator role in the folder consoleTests is selected. For all folders, the folder roles shown in Table 8-2 are automatically assigned.

    Description of soa-partition-app-role-edit.png follows
    Description of the illustration soa-partition-app-role-edit.png

    The Edit Application Role page is displayed.

    Description of soa-partition-role-admin.png follows
    Description of the illustration soa-partition-role-admin.png

  6. Click Add.

    The Add Principal dialog is displayed.

  7. From the Type list, select User. This becomes the user assigned to this role.

  8. To the right of the Display Name field, click the Search icon.

  9. From the list that is displayed, select the user you created and click OK.

    Description of soa-partition-role-add-user.png follows
    Description of the illustration soa-partition-role-add-user.png

    This adds the selected user to the folder role ApplicationOperator for the folder consoleTests.

  10. Select additional application roles, as necessary, and click Edit to add more users.

  11. Log out of Oracle Enterprise Manager Fusion Middleware Control.

  12. Log in to Oracle Enterprise Manager Fusion Middleware Control as the user you assigned to the folder role.

    Because the user was given permissions on only the consoleTests folder, they:

    • Cannot expand non-SOA folders in the Application Navigator.

    • Can only see the consoleTests folder in the Application Navigator of which they are a member. All folders to which they do not belong are hidden from view.

    • Cannot create other folders.

    • Cannot change properties in the SOA Infrastructure Common Properties page.

Note:

When you create an application role and assign it a user on the Application Roles page, it is not immediately visible during a search on the Application Policies page. For the role to be visible, create a policy on the Application Policies page and assign it the application role and some permissions. These actions make the role visible.

Understanding Additional Permission and Role Behavior Scenarios

This section describes additional permission and role behavior scenarios.

Understanding Permissions on Initiating and Participating Composites in Different SOA Folders

The administration operations that you can perform on initiating and participating SOA composite applications in different folders are based on the initiating composite in the business flow instance, and not on the participating composite.

For example, assume you perform the following steps:

  1. In the Security Realms section of Oracle WebLogic Server Administration Console, create a user (for this example, named soamonuser) to which you assign the Monitor group.
  2. Log in to Oracle Enterprise Manager Fusion Middleware Control (for example, as the weblogic user).
  3. Create a new folder (for this example, named test), assuming that the default folder is already present.
  4. From the SOA Infrastructure menu, select Security > Application Roles.
  5. Add the soamonuser user to the test_ApplicationOperator role.
  6. Deploy a SOA composite application (for this example, named ResponseCreditRating) to the default folder.
  7. Deploy a SOA composite application (for this example, named RequestCreditRating) to the test folder.
  8. Create an instance of RequestCreditRating and verify the instance details in the Composites tab of the Flow Instances page. The roles of the composites in this business flow instance are as follows:

    • Initiating composite: RequestCreditRating

    • Participating composite: ResponseCreditRating

  9. Log in to Oracle Enterprise Manager Fusion Middleware Control with the user soamonuser.

    The soamonuser user has administration permissions on the test folder and no permissions on the default folder. However, the soamonuser user can abort and delete instances of the initiating RequestCreditRating composite even though this instance flow also calls the participating ResponseCreditRating composite on the default folder on which the soamonuser user has no permissions.

Viewing Oracle SOA Composer Permission Actions in a SOA Folder

Oracle SOA Composer users have the following permission actions by default for any artifact (domain value maps (DVMs), business rules, composite sensors, and so on) in that folder:

  • CompositePermission with the read permission action for inspecting any artifact in that folder.

  • CompositePermission with the write permission action for changing any artifact in that folder.

  • SOAPlatformPermission with the read-shared-data permission action for inspecting any artifact in the shared folder. The shared folder is the location for all shared artifacts between SOA composite applications that can span multiple folders.

  • SOAPlatformPermission with the write-shared-data permission action for changing any artifact in the shared data folder.

For more information about shared data, see Chapter "Managing Shared Data with the SOA Design-Time MDS Repository" of Developing SOA Applications with Oracle SOA Suite.

To view Oracle SOA Composer permission actions for a folder.

  1. From the SOA Infrastructure menu, select Security > Application Policies.
  2. Click the Search application security grants icon.
  3. Select folder_name_Composer in the table.

    The permission actions are displayed at the bottom of the page.

    Description of soa-composer-permissions.png follows
    Description of the illustration soa-composer-permissions.png
Understanding the MDS Configuration Page and Oracle SOA Suite Permissions

The MDS Configuration page in Oracle Enterprise Manager Fusion Middleware Control does not understand Oracle SOA Suite permissions. For example, assume you perform the following steps:

  1. Create and assign a user to the Monitor group in Oracle WebLogic Server Administration Console.
  2. Log in to Oracle Enterprise Manager Fusion Middleware Control and assign the default_Composer role to that user on the Application Roles page (where default represents the folder for this example).
  3. Log back in to Oracle Enterprise Manager Fusion Middleware Control as that user, and select Administration > MDS Configuration from the SOA Infrastructure menu.
  4. Note that the Import and Export options are disabled. This is the expected behavior.

As a workaround, Oracle SOA Suite users can read and write shared data using the SOA Deployment and Export operations available from the SOA Composite menu for a specific SOA composite application in Oracle Enterprise Manager Fusion Middleware Control.