16 Integrating WebCenter Portal Workflows with Oracle SOA Suite in the Same Domain

WebCenter Portal provides several prebuilt workflows that handle portal membership notifications, portal subscription requests, and so on. WebCenter Portal workflows rely on the Oracle BPM Worklist, which is installed as a component of Oracle SOA Suite.

WebCenter Portal Worklist integration requires that the BPEL Services provided by SOA Suite share the same WebTier, SSO, and Identity Store with the portal. For this Enterprise Deployment Guide, SOA Suite is installed and configured in the same WebLogic Server Domain and included in the WebTier, SSO, and directory configurations.

The SOA Suite may optionally be deployed to a separate WebLogic Server Domain, however the shared WebTier, SSO, and identity Store requirements must be met for the Portal Workflow integration task flows to function correctly.

For more information on Oracle BPM Worklist features, see Using Oracle BPM Worklist in Developing SOA Applications with Oracle SOA Suite.

The tasks that must be performed to enable the WebCenter Portal workflow functionality in WebCenter Portal are as follows.

Note:

Integrating BPM functionality into portal pages using the BPM Process Portal Resource Catalog requires additional steps not covered in this guide. For more information see Integrating BPM Functionality into WebCenter Portal.

Parent topic: Configuring the Enterprise Deployment

16.1 Backing Up the Installation

Back up the environment before re-configuring to include the Portal Workflow Integration with SOA Suite.

This is a quick backup for the express purpose of immediate restore in case of problems executing this chapter. The backup destination is the local disk. You can discard this backup once the enterprise deployment setup is complete. At that point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details.

To back up the environment:
  1. Shutdown the domain resources in order: Managed Servers, Admin Server, Node Managers.
  2. Back up the database. A full database backup (either hot or cold) is strongly recommended.
  3. Clear the WebLogic Server logs to aid in troubleshooting this chapter and reduce backup size (optional). 
    cd ASERVER_HOME
find ./servers/AdminServer/logs -type f ! -size 0c -print -exec rm -f {} \+
cd MSERVER_HOME
find ./servers/*/logs -type f ! -size 0c -print -exec rm -f {} \+
  4. Backup up the Administration Server domain directory. 
    cd ASERVER_HOME
cd ..
tar -czf ./ASVR-domain_name.chapter16.1.tgz ./domain_name
  5. Back up the Applications Directory. 
    cd APPLICATION_HOME
cd ..
tar -czf ./APP-domain_name.chapter16.1.tgz ./domain_name
  6. Restart the Node Managers for ASERVER_HOME and MSERVER_HOME. 
    cd ASERVER_HOME/bin
nohup ./startNodeManager.sh > ASERVER_HOME/nodemanager/nodemanager.out 2>&1 &
cd MSERVER_HOME/bin
nohup ./startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &

16.2 Installing Oracle SOA Suite

To support workflows, WebCenter Portal relies on the BPEL server, which is included with Oracle SOA Suite. For information about installing Oracle SOA Suite as part of this domain, see Extending the Domain with Oracle SOA Suite.

16.3 Installing the Oracle WebCenter Portal SOA Composites

To use workflows in WebCenter Portal, you must install WebCenter Portal SOA Composites by using the portal installer after SOA Suite is installed.

During the initial installation, the Extending the Domain with Oracle WebCenter Portal section included an option to select the Portal SOA Composites. If the option was selected, then skip this section and proceed to the Extending the Domain to Deploy the WebCenter Portal Workflows section.

To install WebCenter Portal SOA Composites:

  1. Execute the WebCenter Portal Installer a second time for each shared ORACLE_HOME, selecting an Installation Type of WebCenter Portal SOA Composites.
  2. Verify that the WebCenter Portal composite archive has been installed.

16.3.1 Starting the Oracle WebCenter Portal Installer on WCCHOST1

To start the installation program:

  1. Log in to WCCHOST1.
  2. Go to the directory where you downloaded the installation program.
  3. Launch the installation program by invoking the java executable from the JDK directory on your system, as shown in the example below. 
    JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.2.0_wcportal_generic.jar

    Be sure to replace the JDK location in these examples with the actual JDK location on your system.

    For information about downloading the software and locating the actual installer file name for your product, see Identifying and Obtaining Software Distributions for an Enterprise Deployment.

When the installation program appears, you are ready to begin the installation.

16.3.2 Navigating the Installation Screens

The installation program displays a series of screens, in the order listed in the following table.

If you need additional help with any of the installation screens, click the screen name.

Screen Description

Welcome

This screen introduces you to the product installer.

Auto Updates

Use this screen to automatically search My Oracle Support for available patches or automatically search a local directory for patches that you’ve already downloaded for your organization.

Installation Location

Use this screen to specify the location of your Oracle home directory.

For more information about Oracle Fusion Middleware directory structure, see "Selecting Directories for Installation and Configuration" in Planning an Installation of Oracle Fusion Middleware.

Installation Type

Use this screen to select the type of installation and consequently, the products and feature sets you want to install.

To install the SOA Composites for WebCenter Portal, select:

  • WebCenter Portal SOA Composites

Prerequisite Checks

This screen verifies that your system meets the minimum necessary requirements.

If there are any warning or error messages, you can refer to one of the following documents in the Roadmap for Verifying Your System Environment section in Planning Your Oracle Fusion Middleware Infrastructure Installation.

Security Updates

If you already have an Oracle Support account, use this screen to indicate how you would like to receive security updates.

If you do not have one and are sure you want to skip this step, clear the check box and verify your selection in the follow-up dialog box.

Installation Summary

Use this screen to verify the installation options you selected.

Click Install to begin the installation.

Installation Progress

This screen allows you to see the progress of the installation.

Click Next when the progress bar reaches 100% complete.

Installation Complete

Review the information on this screen, then click Finish to dismiss the installer.

16.3.3 Verifying the Installed Files

Once the installation has been completed, verify that the WebCenter Portal SOA Composite and worklist details application archives have been written to the correct directory structure within ORACLE_HOME as follows:

ls ORACLE_HOME/wcportal/common/soa-composite/wcp/sca_CommunityWorkflows.jar
ls ORACLE_HOME/wcportal/webcenter/applications/WebCenterWorklistDetailApp.ear

Note:

The 12.2.1.0.0 General Availability release has a typo in the deployed path. Verify the directory path and file name carefully.

16.3.4 Performing the Installation on WCCHOST2

The installation should be repeated once for each shared file system containing a unique ORACLE_HOME. See Summary of the Shared Storage Volumes in an Enterprise Deployment.

16.4 Extending the Domain to Deploy the WebCenter Portal Workflows

WebCenter Portal workflows are deployed to Oracle SOA cluster. You must extend the domain in which Oracle SOA is installed with the template: oracle.wc_composite_template.jar.

When executing the configuration wizard, the domain's AdminServer and any managed servers that will be modified by the selected components/templates must be shutdown. All other unaffected managed servers may stay running.

In this case, all clusters except WSM-PM_Cluster are modified by this domain extension. It is recommended that for this section, all managed servers, including those in the WSM-PM_Cluster be shutdown. This will save having to stop and restart them anyway later.

To extend the domain:

  1. Shutdown all managed servers through EM, WLS console, or WLST.
  2. Shutdown the AdminServer for the domain to be extended.
  3. Run the following command to start the configuration wizard. 
    ORACLE_HOME/oracle_common/common/bin/config.sh
  4. On the Configuration Type screen, select Update an existing domain.

    In the Domain Location field, select the value of the ASERVER_HOME variable, which represents the complete path to the Administration Server domain home you created in Creating the Initial Infrastructure Domain for an Enterprise Deployment.

    /u01/oracle/config/domains/domain_name/
  5. On the Templates screen, select the template in either of the following ways:
    • Select Update Domain Using Product Templates, then select:

      Oracle WebCenter Portal Composites - 12.2.1.2.0 [wcportal]

    • Select Update Domain Using Custom Template, and specify the following path in the Template location field:

      ORACLE_HOME/wcportal/common/templates/wls/oracle.wc_composite_template.jar

    The oracle.wc_composite_template.jar template automatically deploys:

    • WebCenterWorklistDetailApp.ear, the ADF application that displays invitations and messages.

    • sca_CommunityWorkflows.jar, the BPEL composite that manages the WebCenter Portal membership mechanism.

  6. Review and click Next to continue through the first few screens until you reach the Advanced Configuration view.
  7. On the Advanced Configuration screen, select Deployments and Services, then click Next.
  8. Deployments Targeting.

    With the Oracle Web Services Manager Policy Manager deployed to a separate cluster, the default targeting of the WSM-PM application to the Portal, Collaboration, Portlet, In-Bound Refinery, Content, and SOA clusters should be removed.

    For each of the Portal_Cluster, Collab_Cluster, Portlet_Cluster, and SOA_Cluster in the Targets panel, select the wsm-pm application entry within the Application folder and click the left arrow button to remove it from the targets list.

    Note:

    If the SOA-MGD-SERVERS-ONLY server group was used when the SOA cluster was created, then the wsm-pm application will not be targeted by default. In this case, the SOA_Cluster will not have the wsm-pm deployment to remove.
  9. Services Targeting.

    With the Oracle Web Services Manager Policy Manager deployed to a separate cluster, the default targeting of the WSM-PM service resources to the Portal, Collaboration, Portlet, In-Bound Refinery, Content, and SOA clusters should be removed.

    For each of the Portal_Cluster, Collab_Cluster, Portlet_Cluster, and SOA_Cluster in the Targets panel, select and remove the following resources from the targets list:

    • mds-owsm

    • WSM Startup Class

  10. Reviewing Your Configuration Specifications and Configuring the Domain.

    The Configuration Summary screen contains the detailed configuration information for the domain you are about to create. Review the details of each item on the screen and verify that the information is correct.

    You can go back to any of the previous screen if you need to make any changes, either by selecting Back or by selecting the required screen in the navigation pane.

    Click Update to execute the domain extension.

    Tip:

    More information about the options on this screen can be found in Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

  11. Start the Administration Server.

    Start the Administration Server, login, and then verify the clusters and servers views to ensure that the changes made to the domain have been applied.

16.5 Propagating the Extended Domain to the Domain Directories and Machines

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the Managed Server domain directory.

To propagate the domain configuration, complete the following steps:
  1. Create a copy of the Managed Server domain directory and the Managed Server applications directory.
  2. Run the following pack command on WCCHOST1 to create a template pack: 
    cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true 
          -domain=ASERVER_HOME 
          -template=/full_path/wcpdomaintemplateExtComposites.jar 
          -template_name=wcp_domain_template_extension_composites

    In this example:

    • Replace ASERVER_HOME with the actual path to the domain directory you created on the shared storage device.

    • Replace full_path with the complete path to the location where you want to create the domain template jar file. You will need to reference this location when you copy or unpack the domain template jar file. It is recommended to choose a shared volume other than ORACLE_HOME, or write to /tmp/ and copy the files manually between servers.

      You must specify a full path for the template jar file as part of the -template argument to the pack command:

      SHARED_CONFIG_DIR/domains/template_filename.jar

    • wcpdomaintemplateExtComposites.jar is a sample name for the JAR file you are creating, which will contain the domain configuration files, including the configuration files for the Oracle HTTP Server instances.

    • wcp_domain_template_extension_composites is the name assigned to the domain template file.

  3. Run the following unpack command on WCCHOST1 to propagate the template created in the preceding step to the MSERVER_HOME directory: 
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtComposites.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

    • wcpdomaintemplateExtComposites.jar is the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

    • The -overwrite_domain=true argument is necessary when you are unpacking a managed server template into an existing domain and existing applications directories.

      For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

    Tip:

    For more information about the pack and unpack commands, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

  4. If the full path to the packed jar file is on a shared volume available to the other servers, skip this step, otherwise, run the following command on WCCHOST1 to copy the template pack created in step 1 to WCCHOST2, WCPHOST1, and WCPHOST2: 
    scp /full_path/wcpdomaintemplateExtComposites.jar oracle@WCCHOST2:/full_path/
scp /full_path/wcpdomaintemplateExtComposites.jar oracle@WCPHOST1:/full_path/
scp /full_path/wcpdomaintemplateExtComposites.jar oracle@WCPHOST2:/full_path/
  5. Run the following unpack command on each of the remote hosts to deploy the domain template copied in the preceding step to the MSERVER_HOME directory: 
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtComposites.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    In this example:

    • Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain will be unpacked.

    • wcpdomaintemplateExtComposites.jaris the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

    • The -overwrite_domain=true argument is necessary when you are unpacking a managed server template into an existing domain and existing applications directories.

      For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

    Tip:

    For more information about the pack and unpack commands, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

16.6 Restoring customizations to setDomainEnv.sh after Unpacking the Domain

If any customizations have been made earlier to the setDomainEnv.sh files in ASERVER_HOME and MSERVER_HOME, then these customizations will need to be repeated after any domain extension.

Verify that all customizations have been restored before starting NodeManager or WebLogic Server instances.

On WCPHOST1:

  1. Verify and update ASERVER_HOME/bin/setDomainEnv.sh.
  2. Verify and update MSERVER_HOME/bin/setDomainEnv.sh.
  3. Copy MSERVER_HOME/bin/setDomainEnv.sh to the other hosts (e.g. WCPHOST2, WCCHOST1, WCCHOST2).

    Note:

    There are unique differences in parameter values stored in the ASERVER_HOME and MSERVER_HOME setDomainEnv.sh configuration files. The same file cannot be copied into both locations and should be edited separately. MSERVER_HOME/bin/setDomainEnv.sh can be copied across the environment consistently.

16.7 Updating the NodeManager Configuration After Unpacking the Domain

When extending a domain, the nodemanager.properties file in MSERVER_HOME may be overwritten with some values from the nodemanager.properties file for ASERVER_HOME. Specifically, the ListenAddress and/or CustomIdentityAlias values can be reset.

Notes::

For the MSERVER_HOME/nodemanager/nodemanager.properties file on each host:
  1. Verify the correct ListenAddress parameter value and reset it, if required. 
    grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties
  2. Confirm the list of configured Identity Aliases from the domain configuration file as a reference for the next command. 
    grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq
  3. Verify the current CustomIdentityAlias parameter value. 
    grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties
  4. Reset the CustomIdentityAlias parameter value to the correct alias string appropriate for the current host, if required.
  5. Restart the nodemanager process: 
    kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &
For more information, see Configuring Node Manager to Use the Custom Keystores.

16.8 Starting the Domain and Validating the WebCenter Portal SOA Composite Domain Extension

Start the entire domain and use Enterprise Manager to verify the deployment of the Portal SOA Composites and WebCenter Worklist Detail application.

16.8.1 Starting the Administration Server Using the Node Manager

After you have configured the domain and configured the Node Manager, you can start the Administration Server, using the Node Manager. In an enterprise Deployment, the Node Manager is used to start and stop the Administration Server and all the Managed Servers in the domain.

To start the Administration Server using the Node Manager:

  1. Start the WebLogic Scripting Tool (WLST): 
    cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
  2. Connect to Node Manager using the Node Manager credentials: 
    wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'ADMINVHN','5556','domain_name',
            'ASERVER_HOME')

    Note:

    This user name and password are used only to authenticate connections between Node Manager and clients. They are independent of the server administrator ID and password and are stored in the nm_password.properties file located in the following directory:

    ASERVER_HOME/config/nodemanager
  3. Start the Administration Server: 
    nmStart('AdminServer')

    Note:

    When you start the Administration Server, it attempts to connect to Oracle Web Services Manager for WebServices policies. It is expected that, since the WSM-PM Managed Servers are not yet started, the following message will appear in the Administration Server log:

    <Warning><oracle.wsm.resources.policymanager>
<WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>
  4. Exit WLST: 
    exit()

16.8.2 Start and confirm all Managed Servers are running

Managed servers created or modified by the latest domain extension should now be started. Managed servers that remained running during the domain extension should be confirmed as running.

Table 16-1 Managed Servers

Cluster Managed Servers Initial State Action

WSM-PM_Cluster

WLS_WSMn

SHUTDOWN

Start and verify all managed servers

SOA_Cluster

WLS_SOAn

SHUTDOWN

Start and verify all managed servers

IBR_Servers

WLS_IBRn

SHUTDOWN

Start and verify all managed servers

WCC_Cluster

WLS_WCCn

SHUTDOWN

Start and verify all managed servers

Portlet_Cluster

WC_Portletn

SHUTDOWN

Start and verify all managed servers

Collab_Cluster

WC_Collaborationn

SHUTDOWN

Start and verify all managed servers

Portal_Cluster

WC_Portaln

SHUTDOWN

Start and verify all managed servers

16.8.3 Verifying the WebCenter Portal SOA Composites Deployment

Two deployments are added when the domain is extended with the WebCenter Portal SOA Composites. These include one enterprise application archive and one SOA composites archive. These resources must be successfully deployed and validated before continuing with this domain extension. The SOA composites rely on the application for the human tasks included in the workflows. They are deployed separately, using different processes.

  • WebCenterWorklistDetailApp.ear — A standard Java EE web application located in ORACLE_HOME/wcportal/webcenter/applications

  • sca_CommunityWorkflows.jar — A SOA Composite located in ORACLE_HOME/wcportal/common/soa-composite/wcp

This section contains instructions for both the validation and deployment processes.

16.8.3.1 Confirming the WebCenter Portal SOA Composite and Application Deployments

To validate the WebCenterWorklistDetailApp.ear application deployment:

  1. Connect to Enterprise Manager as the weblogic_wcp administrative user.

  2. Verify that the WebCenterWorklistDetailApp application is listed Target Navigation > Application Deployments. If the application link is not listed, see section Deploying the WebCenterWorklistDetailApp Application to the SOA_Cluster.

  3. If the WebCenterWorklistDetailApp application is listed, click on the link and validate that the State is listed as Active and the Health is OK in the Summary view. Also, validate that the SOA_Cluster is listed in the Targets column of the Deployments view.

    If the WebCenterWorklistDetailApp does not show the SOA_Cluster in the Targets column, complete the following steps:

    1. From the Domain Application Deployment drop-down list, select Administration > Targets.

    2. From the lock icon in the upper-right corner, select Lock & Edit.

    3. Select WebCenterWorklistDetailApp EAR, then click Change Targets.

    4. In the pop-up window, select SOA_Cluster and then select the All configured Servers in this cluster option.

    5. Click OK. After the changes are complete a confirmation message is displayed

    6. If an information panel is displayed with the following message, click Create New Deployment Plan.

      Information: The configuration changes will be saved in the deployment plan. This application does not currently have a deployment plan. In order to save the configuration changes, you need to first create a new deployment plan for this application.

    7. In a separate command shell, create a shared deployment plan folder for the WebCenterWorklistDetailApp in the DEPLOY_PLAN_HOME folder. See Understanding the Recommended Directory Structure for an Enterprise Deployment.

      mkdir -p DEPLOY_PLAN_HOME/WebCenterWorklistDetailApp

    8. In the Save Deployment Plan dialog, enter or browse to the full path to the new app-specific deployment plan folder, plus the file name plan.xml.

       /u01/oracle/config/dp/WebCenterWorklistDetailApp/plan.xml

    9. Click the Save Deployment Plan button.

    10. From the lock icon in the upper-right corner, select Activate Changes.

      Note:

      If the Activate Chagnes selection is unavailable, click the reload icon next to the date immediately below the lock icon.

    11. Restart the managed servers in the SOA_Cluster.

  4. Expand the Target Navigation panel and navigate to the WebLogic Domain > domain-name > SOA_Cluster.

  5. From the WebLogic Cluster drop-down menu, select Deployments.

  6. Verify that the WebCenterWorklistDetailApp is listed with a green up arrow status and a state of Active.

    If the WebCenterWorklistDetailApp is not deployed to the SOA_Cluster, perform the deployment after all validation steps are completed. See Deploying the WebCenterWorklistDetailApp Application to the SOA_Cluster.

To validate the sca_CommunityWorkflows.jar SOA composites deployment:

  1. Expand the Target Navigation panel and navigate to the SOA > soa-infra (WLS_SOA1) service

  2. Click the Deployed Composites tab.

  3. Verify that the CommunitWorkflows [12.2.1.2.0] composite is listed with a green up arrow for status.

    See Deploying the CommunityWorkflows SOA Composite to the SOA service.

16.8.3.2 Deploying the WebCenterWorklistDetailApp Application to the SOA_Cluster

If the WebCenterWorklistDetailApp application needs to be deployed, perform the following steps:
  1. Connect to Enterprise Manager as the weblogic_wcp administrative user .
  2. Expand the Target Navigation panel and navigate to the WebLogic Domain > domain-name > SOA_Cluster
  3. From the WebLogic Cluster drop-down menu, select Deployments.
  4. Verify that the WebCenterWorklistDetailApp is not listed.
  5. From the Deployment drop-down menu, select Deploy.
  6. Select an appropriate deployment scope. For out-of-box configurations, the appropriate scope is global.
  7. Select Archive on the server where Enterprise Manager is running.
  8. Enter: ORACLE_HOME/wcportal/webcenter/applications/WebCenterWorklistDetailApp.ear.
  9. Select Create a new deployment plan when deployment configuration is done .
  10. Select Deploy this archive or exploded directory as an application.
  11. Click Next.
  12. On the Select Target view, make sure that only the SOA_Cluster is checked and the All configured Servers in this cluster option is selected.
  13. On the Application Attributes view, change only the distribution option to: Install and start application (servicing all requests). Do not alter any other application attributes
  14. Click Deploy. The remaining application deployment configurations do not need to be modified.
  15. Observe the progress messages provided in the Processing: Deploy modal dialog box that appears and wait for it to complete.
  16. Observe that the dialog box is updated with a Deployment Succeeded message.
  17. Close the dialog box.
  18. Verify that the new application deployment is listed with a green up arrow status and a state of Active.

See Deploying Java EE Applications Using Fusion Middleware Control in Administering Oracle Fusion Middleware for details on how to deploy the enterprise application archive.

16.8.3.3 Deploying the CommunityWorkflows SOA Composite to the SOA service

If the CommunityWorkflows SOA composite needs to be deployed, perform the following steps:
  1. Connect to Enterprise Manager as the weblogic_wcp administrative user .
  2. Expand the Target Navigation panel and navigate to the SOA > soa-infra (WLS_SOA1) service.
  3. Click on the Deployed Composites tab.
  4. Verify the CommunityWorkflows composite is listed as Up and Active. If not listed, or the list says No Composites Found, then continue with these deployment steps. If status is down, select and start the CommunityWorkflows composite.
  5. Click Deploy.
  6. Select Archive on the server where Enterprise Manager is running.
  7. Enter: ORACLE_HOME/wcportal/common/soa-composite/wcp/sca_CommunityWorkflows.jar
  8. Select No external configuration plan is required.
  9. Click Next.
  10. Confirm the deployment target is /Domain_< domain_name >/< domain_name >/SOA_Cluster
  11. Choose the appropriate SOA Folder. For out-of-box configurations, the appropriate folder to select is default.
  12. Click Next.
  13. Confirm the Deploy as default revision selection as this is the first time the composites are getting deployed.
  14. Click Deploy.
  15. Observe the progress messages provided in the Processing: Deploy modal dialog box that appears and wait for it to complete.
  16. Observe that the dialog box is updated with a Deployment Succeeded message.
  17. Close the dialog box.
  18. Observe that Enterprise Manager now displays the CommunityWorkflows[12.2.1.2.0] SOA composite dashboard view with several components and services.
See Deploying SOA Composite Applications in Administering Oracle SOA Suite and Oracle Business Process Management Suite for details on how to deploy the composite.

16.9 Configuring WS-Security for Oracle SOA and WebCenter Portal

WebCenter Portal Web services, deployed to Oracle WebCenter Portal, facilitate communication between WebCenter Portal and the SOA server. You must secure these Web service calls.

Note:

Some of the key aliases and other properties values used in this configuration are specifically required by the deployed products. This process has been tuned specifically for a combined topology with Oracle SOA and WebCenter Portal in the same domain. Customizing this process beyond the provided instructions is not recommended.

For more information on configuration for a two-domain topology, see Oracle SOA and WebCenter Portal - WS-Security Configuration in Installing and Configuring Oracle WebCenter Portal.

Set up WS-Security by creating a security application stripe and keystore for WebCenter Portal and the SOA Suite BPEL Server to use. Oracle Fusion Middleware 12c implements these keystores using the Keystore Security Service (KSS) configured via Enterprise Manager or WLST commands.

For more information, see Configuring Keystores for Message Protection in Securing Web Services and Managing Policies with Oracle Web Services Manager.

For syntax and reference information about the KSS commands, see OPSS Keystore Service Commands in Oracle Fusion Middleware Infrastructure Security WLST Command Reference.

16.9.1 Creating the WebCenter Portal Keystore via WLST

To create a new WebCenter Portal keystore, complete the following steps:

  1. Start WLST and connect to the Administration Server as the administrative LDAP user. 
    ORACLE_COMMON_HOME/common/bin/wlst.sh
connect("weblogic_wcp", "weblogic_admin_pwd", "t3://ADMINVHN:7001")
  2. Use the following WLST command to get an OPSS service command object: 
    svc = getOpssService(name='KeyStoreService')
  3. Create the keystore using the following WLST command: 
    svc.createKeyStore(appStripe='WCPortalStripe', name='producer', password='password', permission=true)

    Where:

    • appstripe — The keystore stripe name. Keys and certificates created in the keystore reside in an application stripe or product, and each stripe in a domain is uniquely named

    • keystore_name — The name of the keystore you are creating; typically, you use a name to help identify the component or endpoint being secured

    • password — Enter the password you want to use for this keystore.

    • permission — false if protected by both permission and password (true if keystore is protected by permission only)

  4. Generate the key pair for this newly created keystore, supplying an appropriate password and setting the domain name, organization, location(city), state, and country appropriately: 
    svc.generateKeyPair(appStripe='WCPortalStripe', name='producer', password='password', dn='CN=Producer, OU=WCPortalServices, OU=domain_name, O=MyOrganization, L=MyTown, ST=MyState, C=US', keysize='2048', alias='producer', keypassword='keypassword')

    Where:

    • appstripe — The keystore stripe name. Keys and certificates created in the keystore reside in an application stripe or product, and each stripe in a domain is uniquely named

    • keystore_name — The name of the keystore you are creating; typically, you use a name to help identify the component or endpoint being secured

    • password — The password you defined when you created the keystore.

    • dn — Distinguished Name; used to uniquely identify and organize the key pair within a hierarchical naming structure. Update the OU=domain_name, O=MyOrg, L=MyTown, ST=MyState, C=US, portions of the DN to match your environment and organization appropriately.

    • keysize - number of bits for the encryption key, should be at least 2048

    • alias — Public Key Alias

    • keypassword — Enter a password for new public key that you are creating.

  5. Export the producer certificate (which will be used by the consumer): 
    svc.exportKeyStoreCertificate(appStripe='WCPortalStripe', name='producer', password='password', alias='producer', type='TrustedCertificate',filepath='KEYSTORE_HOME/ksscert_wcportalproducer.crt')

    Where:

    • appstripe — The keystore stripe name. Keys and certificates created in the keystore reside in an application stripe or product, and each stripe in a domain is uniquely named

    • name — Keystore name

    • password — Keystore password

    • alias — Public Key Alias

    • keypassword — Password for new public key

    • filepath — Certificate path

  6. Import the certificate exported by the producer for use by the consumer web service: 
    svc.importKeyStoreCertificate(appStripe='WCPortalStripe', name='producer', password='password', alias='webcenter_spaces_ws', keypassword='keypassword', type='TrustedCertificate', filepath='KEYSTORE_HOME/ksscert_wcportalproducer.crt')

    Where:

    • password — Keystore password

    • keypassword — Password for new public key

    • filepath — Certificate path

    Note:

    The alias for the importKeyStoreCertificate command must always be set to webcenter_spaces_ws. Do not attempt to change this alias; otherwise, the web services communications will fail. This alias is used in the default configuration of the Web services policy security.

  7. Register the producer stripe: 
    configureWSMKeystore('/WLS/domain_name','KSS', 'kss://WCPortalStripe/producer', signAlias='producer', cryptAlias='producer', signAliasPassword='password', cryptAliasPassword='password')

    Where:

    • domain_name – The name of the WebCenter Portal domain; the “/WLS/” prefix is required to provide context for the Web Services Manager manager

    • KSS — The keystore type

    • kss://WCPortalStripe/producer— The location of the keystore: keys and certificates created in the keystore reside in an application stripe or product, and each stripe in a domain is uniquely named

    • signAlias – The alias of the signature key; the value must match the value in the keystore, in this case, ‘producer’

    • cryptAlias — The alias of the encryption key. The value that you specify here must match the value in the keystore, in this case, ‘producer’

    • signAliasPassword— The password for the certificate specified for the signAlias as configured earlier

    • cryptAliasPassword— The password for the certificate specified for the cryptAlias as configured earlier

    Note:

    When using a KSS keystore type, the configureWSMKeystore() command may issue warnings that the passwords are not required. In this specific case, when services are using policies that mandate message protection, the passwords are required, otherwise the services cannot use the certificates to encrypt and decrypt appropriately. Be sure to include the password parameters as indicated in the example.

    For more information, see “Configuring the OWSM Keystore Using WLST” in Securing Web Services and Managing Policies with Oracle Web Services Manager.

  8. Grant Keystore Permission for the newly created producer keystore in the WCPortalStripe stripe: 
    grantPermission(permClass="oracle.security.jps.service.keystore.KeyStoreAccessPermission", permTarget="stripeName=WCPortalStripe,keystoreName=producer,alias=*", permActions="read")

    Note:

    The StripeName and keystoreName values in the permTarget value must match values used in earlier steps. No other changes are required to this command.

16.10 Verifying Application Roles

Before you configure WebCenter Portal with SOA Suite, understand and verify the SOAAdmin and BPMWorkflowAdmin application roles.

The memberships of the SOAAdmin and BPMWorkflowAdmin application roles can be listed as follows:

ORACLE_COMMON_HOME/common/bin/wlst.sh 
connect('weblogic_wcp','password', 't3://ADMINVHN:7001')
listAppRoleMembers(appStripe="soa-infra", appRoleName="SOAAdmin")
listAppRoleMembers(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin")

To revoke a user or group membership from an application role, consider following WLST examples:

revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="weblogic")
revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSGroupImpl", principalName="Administrators")

To specifically grant a user membership to an application role, follow this example:

grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="weblogic_wcp")

For the LDAP group configurations in the enterprise deployment environment, it is not necessary to grant the weblogic_wcp user specific access. The WCPAdministrators group should already be part of the SOAAdmin application role and inherit membership to the BPMWorkflowAdmin application role.

For more information about configuring a remote LDAP server for the enterprise deployment, see Creating a New LDAP Authenticator and Provisioning Enterprise Deployment Users and Group.

For more information about SOA application role configurations, see Configuring Roles for Administration of an Enterprise Deployment.

16.11 Creating the Connection to the BPEL Server

WebCenter Portal uses BPEL server to host internal workflows, such as worklists, membership notifications, subscription requests, and so on. BPEL Services are configured on the SOA Managed Servers. To enable workflow functionality for WebCenter Portal, a connection to the BPEL service is required.

Note:

WebCenter Portal workflows must be deployed on the SOA managed server that WebCenter Portal is configured to use. See also, Back-End Requirements for WebCenter Portal Workflows in Installing and Configuring Oracle WebCenter Portal.

To configure a connection for worklist notifications:

  1. Log in to Fusion Middleware Control, and navigate to the home page for WebCenter Portal.

    See “Navigating to the Home Page for WebCenter Portal” in Administering Oracle WebCenter Portal.

  2. From the WebCenter Portal menu, select Settings, then Application Configuration .
  3. In the BPEL SOAP URL field, specify the internal load-balanced URL.

    For example:

    http://wcp-internal.example.com:80
  4. In the Link URL field, specify the public front-end load-balanced URL for the environment.

    For example:

    https://wcp.example.com:443
  5. Select Enable WebCenter Portal Workflows.
  6. Click Apply.
  7. Restart the Portal_Cluster for this change to take effect.

16.12 Validating the Connection to the BPEL Server

After you create the connection to the BPEL Server, validate the connection to be sure it is working properly.

Use the WLST command listWorklistConnections to display the configured connections and validate the connection details.

Use the getSpacesWorkflowConnectionName() to confirm the name of the active workflow connection.

For example:

listWorklistConnections(appName='webcenter', server='WC_Portal1', verbose=1) 
getSpacesWorkflowConnectionName(appName='webcenter', server='WC_Portal1')

Use the listed URL property value to construct a valid worklist application URL and validate access using a browser. Append the listed URL property value with the path /integration/worklistapp, to generate an appropriate URL for testing.

16.13 Configuring WebCenter Portal Workflow Notifications to be Sent by Email

WebCenter Portal can use human workflows (requiring human interaction), which are integrated with SOA workflows. The SOA server can configure email so that notifications are delivered to a user's inbox, where the user can accept or reject the notification.

This topic briefly explains how to enable email notifications and set your mail server details to have WebCenter Portal workflow notifications sent through email. Both outbound and incoming email addresses or mailboxes that are dedicated to portal workflow notification and reply processing are needed for full functionality. For a more detailed description, see Configuring Human Workflow Notification Properties in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

  1. Connect to Enterprise Manager Fusion Middleware Control as the weblogic_wcp administrative user.
  2. Expand the Target Navigation panel and navigate to the SOA > soa-infra (WLS_SOA1) service.
  3. From the SOA Infrastructure drop-down menu, select SOA Administration > Workflow Properties.
  4. Set the Notification Mode to: Email
  5. Provide the correct email addresses for the Notification Service.
  6. Click Apply and then confirm when prompted. Verify the returned message that confirms changes have been applied.
  7. Click the Go to the Messaging Driver page link.
  8. In the Associated Drivers section, Click the Configure Driver icon for the User Messaging Email Driver.
  9. Click Create to configure an email driver, if one does not already exist.

    For instructions on how to configure the email driver for notifications, see Configuring an Email Driver for Notifications in Using Oracle Managed File Transfer.

  10. Once all required email driver configurations are completed, click Test and validate successful test status.
  11. Click Apply to save the email driver configuration.
  12. Verify that the new UMS driver configuration shows up in the Email Driver Properties table view.
  13. Restart the SOA Cluster. No configuration or restart is required for WebCenter Portal.

16.14 Testing the Oracle BPM Worklist Application in WebCenter Portal

Testing of the WebCenter Portal invitation and membership workflows and email notifications can be performed using end-user accounts and requires specific portal run-time configuration to set up the test case.

To access BPEL worklist task details sent from WebCenter Portal, without incurring additional login prompts, WebCenter Portal and Oracle SOA Suite servers must be configured to a shared Oracle Single Sign-On server. This testing can be more easily validated after completing the instructions in the Configuring Single Sign-On for an Enterprise Deployment section.

For more information, see Task 7 in the Configuration Roadmap for WebCenter Portal Workflows section in the Administering Oracle WebCenter Portal Guide.