Enable process integration in a cross-cell setup

 

+

Search Tips   |   Advanced Search

 

Overview

To enable an WebSphere Portal server or cluster for process integration...

1. Identify the bootstrap port of the WebSphere Process Server
2. Start WebSphere Portal
3. Install the WebSphere Process Server Client
4. Run business process integration tasks
5. Configure single-sign on

If you are still using VMM file registries, make sure that they contain identical data in both cells.

The automated setup task, setup-wp.processintegration.config...

1. Creates indirect name space bindings for the process server
2. Creates shared libraries for required classes
3. Configures inbound and outbound identity assertion
4. Creates the resource environment provider entries in the WebSphere Portal Configuration Service.
5. Creates the default portal pages where users manage processes and work with the tasks controlled by the process server.

For single sign-on, if both portal and WPS servers use WAS stand-alone LDAP, they need to have the same LDAP server configured as the WAS LDAP and build the LTPA token realm name based on the server name.

If the process portal deployment uses federated LDAP, you can point to a different LDAP server as long as the same users are available in all LDAP directories.

To omit the creation of the default portal pages where users manage processes and work with the tasks controlled by the process server, run the alternate setup task...

setup-base-wp.processintegration.config

If you are migrating a process portal environment and you choose to enable the portal server with process integration after you migrate the process portal configuration, use the setup-base-wp.processintegration.config task.

Procedure

To enable business process integration within the portal environment on a stand-alone server, a federated server, or an existing portal cluster...

1. Install the WPS Client on the WebSphere Portal server or on all portal nodes of the portal cluster.

   When using WPS client version 6.2.x first install the Webservices feature pack on top of WebSphere Portal. The version of the feature pack must match the level of the appserver used for WebSphere Portal.

   1. Refer to the prerequisites for setting up process portals.
   2. Launch the installation wizard from your WPS CDs.
   3. Choose your existing portal server as installation base for the WPS installation.
   4. Choose the Client installation option.

2. Depending on your setup, you may have to enable CSIv2 identity assertion from the portal cell to the process server cell. Here is one way of doing this:

   1. Activate CSIv2 inbound authentication

      1. For WAS v6.1, from the admin console on the process server...
         Security | Secure Administration, applications, and infrastructure | RMI/IIOP Security | CSIv2 inbound authentication

         For WAS v7, from the admin console on the process server...

         Security | Global security | RMI/IIOP Security | CSIv2 inbound authentication

         

      2. Enter the Single Sign-On domain suffix.

      3. Enable Use identity assertion

      4. In the Trusted Identities field, type the user name of the WAS administrative user.

   2. Activate CSIv2 outbound authentication.

      1. For WAS v6.1, from the admin console on the portal server, view all tasks and click...
         Security | Secure Administration, applications, and infrastructure | RMI/IIOP Security | CSIv2 outbound authentication

         For WAS v7, from the admin console on the portal server, view all tasks and click...

         Security | Global security | RMI/IIOP Security | CSIv2 outbound authentication

      2. Enable Use identity assertion

      3. Make sure that Specify an alternative trusted identity is enabled.

         This setting displays a check mark.

      4. Type the username and password of the WebSphere Administrative user.

      5. Click Apply and OK.

3. Enable single sign-on (SSO) between the WebSphere Process Server and the stand-alone WebSphere Portal server or portal cluster by...
   • Setting an appropriate SSO domain
   • Exchanging the LTPA keys between the servers
   • Adjusting user registry configuration as appropriate

   Here is one way to exchange the LTPA keys:

   1. For WAS v6.1, click...
      Security | Secure Administration, applications, and infrastructure | Web Security | Single Sign-On

      For WAS v7, click...

      Security | Global security | Web and SIP security | Single Sign-On

   2. Enter the Single Sign-On domain suffix.

   3. Depending on your version of WAS, click the appropriate option:

   4. For WAS v6.1, from the admin console on the process server, view all tasks and click...
      Security | Secure Administration, applications, and infrastructure | Authentication mechanisms and expiration

      For WAS v7, from the admin console on the process server, view all tasks and click...

      Security | Global security | Authentication | Authentication mechanisms and expiration

   5. Under Cross-cell single sign-on define a password and file location and click Export Keys.

   6. Disable automatic LTPA key generation on all servers of the SSO domain:

      1. Log in to the administrative console.

      2. Depending on your version of WAS, select the appropriate options:

         • For WAS v6.1:

           Select Security > Secure administration, applications, and infrastructure. Under Authentication click Authentication mechanisms and expiration.

         • For WAS v7:

           Select Security > Global Security. Under Authentication mechanisms and expiration, click LTPA.

      3. Under Key generation select Key set groups.

      4. Click NodeLTPAKeySetGroup.

      5. Under Key generation disable the checkbox Automatically generate keys.

      6. Click OK.

      7. Click Save to save your changes to the master configuration.

      8. Log out from the administrative console.

   7. Depending on your version of WAS, click the appropriate option:

      • For WAS v6.1:

        Click Security > Secure Administration, applications, and infrastructure > Web Security > Single Sign-On.

      • For WAS v7:

        Click Security > Global security > Web and SIP security > Single Sign-On.

   8. Depending on your version of WAS, click the appropriate option:

      • For WAS v6.1, from the admin console on the process server, view all tasks and click Security > Secure Administration, applications, and infrastructure > Authentication mechanisms and expiration.

      • For WAS v7, from the admin console on the process server, view all tasks and click Security > Global security > Authentication > Authentication mechanisms and expiration.

   9. Under Cross-cell single sign-on specify the same password used in Step c and point to the file that you exported in Step c. Click Import Keys.

4. Establish Secure Sockets Layer (SSL) trust between the WebSphere Process Server and WebSphere Portal. There are different ways to achieve this depending on your security environment. One way is to import the SSL signer certificate of the process server into the SSL trust store of the portal server and vice versa. The next two steps describe this method for the process server and the portal server, respectively. For more information, refer to the IBM WAS Information Center topics for Secure applications and their environment, Secure Communications.

5. Import the SSL signer certificate of the WebSphere Process Server into the SSL trust store of the WebSphere Portal server:

   1. From the admin console on the process server, view all tasks and click Security > SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates.

      Alternatively, you can choose Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates.

   2. Select the signer certificate that belongs to the node that hosts the process server to which the portal is connected. You can determine the right one by comparing the node name with the entry in the column Issued to.

   3. Click Extract to export the WebSphere Process Server certificate or certificates, if the process server uses a cluster.

   4. Specify the name of the files that will store the WebSphere Process Server signer certificates. Use different names for the files that hold the certificates extracted from the cluster nodes and the file that holds the certificate extracted from the WebSphere Process Server Deployment Manager, for example:

      • /tmp/wpsDM for the process server Deployment Manager

      • /tmp/wpsDef1 for the primary node of the process server cluster

      • /tmp/wpsDef2 for the secondary node of the process server cluster, if it exists

   5. Add the signer certificates that you extracted from the process server to the WebSphere Portal server: From the admin console on your stand-alone portal server or the deployment manager of your managed cell, view all tasks and click Security > SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates.

      Alternatively, you can choose Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates.

   6. Click Add to add the process server signer certificates to the portal server.

   7. For each certificate that you add, specify an alias. The alias allows you to use a signer certificate on more than one server machine.Tip: To help keep track of signer certificates, consider creating aliases with the same or similar names as the file names, for example:

      • wpsDM for the certificate for the process server Deployment Manager

      • wpsDef1 for the certificate for the primary node of the process server cluster

      • wpsDef2 for the certificate for the secondary node of the process server cluster, if it exists

   8. Specify the name of the file or files where you stored the extracted process server signer certificates in Step e, for example:

      • /tmp/wpsDM for the process server Deployment Manager

      • /tmp/wpsDef1 for the primary node of the process server cluster

      • /tmp/wpsDef2 for the secondary node of the process server cluster, if it exists

   9. Click Apply.

   10. If the portal is connected to a process server cluster, repeat the preceding steps for all WebSphere Process Server nodes and the WebSphere Process Server Deployment Manager that host servers that are part of the cluster.

   11. Restart the portal server.

6. Import the SSL signer certificate of the WebSphere Portal into the SSL trust store of the WebSphere Process Server:

   1. From the admin console on the portal server, view all tasks and click Security > SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates.

      Alternatively, you can choose Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates.

   2. Select the signer certificate that belongs to the node that hosts the portal server to which the process server is connected. You can determine the right one by comparing the node name with the entry in the column Issued to.

   3. Click Extract to export the WebSphere Portal certificate or certificates, if the portal uses a cluster.

   4. Specify the name of the files that will store the WebSphere Portal signer certificates. Use different names for the files that hold the certificates extracted from the cluster nodes and the file that holds the certificate extracted from theWebSphere Portal Deployment Manager, for example:

      • /tmp/portalDM for the portal Deployment Manager

      • /tmp/portalDef1 for the primary node of the portal cluster

      • /tmp/portalDef2 for the secondary node of the portal cluster, if it exists

   5. Add the signer certificates that you extracted from the portal server to the WebSphere Process Server server: From the admin console on your stand-alone process server or the deployment manager of your managed cell, view all tasks and click Security > SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates.

      Alternatively, you can choose Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates.

   6. Click Add to add the portal server signer certificates to the process server.

   7. For each certificate that you add, specify an alias. The alias allows you to use a signer certificate on more than one server machine.Tip: To help keep track of signer certificates, consider creating aliases with the same or similar names as the file names, for example:

      • portalDM for the certificate for the portal server Deployment Manager

      • portalDef1 for the certificate for the primary node of the portal server cluster

      • portalDef2 for the certificate for the secondary node of the portal server cluster, if it exists

   8. Specify the name of the file or files where you stored the extracted portal server signer certificates in Step e, for example:

      • /tmp/portalDM for the portal server Deployment Manager

      • /tmp/portalDef1 for the primary node of the portal server cluster

      • /tmp/portalDef2 for the secondary node of the portal server cluster, if it exists

   9. Click Apply.

   10. If the process server is connected to a portal server cluster, repeat the preceding steps for all WebSphere Portal nodes and the WebSphere Portal Deployment Manager that host servers that are part of the cluster.

   11. Restart the process server.

7. On the portal server or on all nodes of the portal cluster, run the tasks to adapt the WebSphere Portal to the newly installed WebSphere Process Server Client:

   1. Verify that the following properties are set in wkplc.properties, located in...
      profile_root/ConfigEngine/properties
      • PortalAdminId
      • PortalAdminPwd
      • WasUserid
      • WasPassword

      Alternatively, specify those properties using the corresponding command line parameters.

   2. On the stand-alone portal server or primary node of the portal cluster, open the wkplc_comp.properties file in...
      profile_root/ConfigEngine/properties

      verify that the value of the property pi.IsCrossCell is set to true, and set the values for the properties pi.ProcessServerHostAddress and pi.ProcessServerBootstrapPort. You do not need to update the file on all secondary nodes.

      To change the server address and/or port after you finished the configuration ...

      1. From the Administrative Console of WebSphere Portal, click Environment > Naming > Name Space Bindings.

      2. Open the entry _BFM_Binding and update the value for the Provider URL.

      3. Open the entry _HTM_Binding and update the value for the Provider URL.

   3. Optional: On the stand-alone portal server and all nodes of a cluster, open the wkplc_comp.properties file in the directory profile_root/ConfigEngine/properties and set the value of the pi.ProcessArtifactsLocation property that defines the folder where you can place your remote process artifacts .jar files, as explained in the topic Using generic process integration portlets in a cross-cell setup.

   4. On the WebSphere Portal single server or all nodes of the portal cluster, open a command prompt.

   5. If you are enabling process integration on a portal cluster, make sure the corresponding WAS node agents are started and automatic synchronization is enabled.

   6. Change the directory to profile_root/ConfigEngine

   7. Type the following command:

      Windows: ConfigEngine.bat wps-client-post-install-wp.processintegration.config -DWasPassword=password

      UNIX: ConfigEngine.sh wps-client-post-install-wp.processintegration.config -DWasPassword=password

   8. Determine which setup task to run:

      • To set up process integration with the portal-provided Process Integration pages and you are not migrating a process portal environment, type the following command:

        Windows: ConfigEngine.bat setup-wp.processintegration.config -DWasPassword=password

        UNIX: ConfigEngine.sh setup-wp.processintegration.config -DWasPassword=password

      • To set up process integration without the portal-provided Process Integration pages or if you have migrated the process portal environment, type the following command:

        Windows: ConfigEngine.bat setup-base-wp.processintegration.config -DWasPassword=password

        UNIX: ConfigEngine.sh setup-base-wp.processintegration.config -DWasPassword=password

      If you run the setup command on a portal cluster, you will have to manually activate the newly deployed portlets processtemplates.war and tasklistportlet.war using the Manage Web Modules portlet.

8. To add secondary nodes for WebSphere Process Server server failover...

   1. From the admin console on the portal server, view all tasks and click Environment > Naming > Name Space Bindings.

   2. Click _BFM_Binding and change the Provider URL to specify the second node of the process server cluster: corbaloc:iiop:host_name.domain.name:boot.strap_Port,:host_name.domain.name: boot.strap_Port You have already specified the primary node for the process server cluster; now you are simply adding the remaining nodes using comma-separated values.

   3. Change the JNDI Name to cell/clusters/process.server_cluster.name/com/ibm/bpe/api/BusinessFlowManagerHome.

   4. From the admin console on the portal server, view all tasks and click Environment > Naming > Name Space Bindings.

   5. Click _HTM_Binding and change the Provider URL to accommodate the second node of the WebSphere Process Server cluster using the following format: You will already have primary node info for Process Server Cluster, you are just adding the remaining nodes using comma separated values. corbaloc:iiop:host_name.domain.name:boot.strap_Port,:host_name.domain.name :boot.strap_Port You have already specified the primary node for the process server cluster; now you are simply adding the remaining nodes using comma-separated values.

   6. Change the JNDI Name to cell/clusters/process.server_cluster.name/com/ibm/task/api/HumanTaskManagerHome.

9. Restart the process server and the portal server or cluster. All objects and properties required for working with business process applications managed by the process server are configured for display and use in the portal environment.

   • The My Processes and the My Tasks pages are available as default pages under the Process Integration page.

   • The default task page (ibm.portal.DefaultTaskPage) is created and the generic Task Processing portlet is placed on this page.

   Until install and deploy a business process application, the default Process Integration pages, My Processes and My Tasks, are empty.

In addition to the Process Integration pages and portlets, the following configuration artifacts are created on the WebSphere Portal server or cluster nodes:

• Shared libraries
  • BPElib
  • BPEJSFlib

• Indirect name space bindings for the process server Human Task Manager and the Business Flow Manager

  • The names under which the indirect binding is available in the portal namespace are...
    • cell/persistent/pi/BFMHome
    • cell/persistent/pi/HTMHome

  • The Provider URL specifies the value you defined when running the configuration task: For example...
    corbaloc:iiop:host_name.domain_name:port

  • Default JNDI Names for the EJBs in the process server namespace:
    • com/ibm/bpe/api/BusinessFlowManagerHome
    • com/ibm/task/api/HumanTaskManagerHome

  These bindings are used by the Task List portlet and the generic process integration portlets (Manage Processes and Task Processing) to communicate with the WebSphere Process Server.

• Custom properties for process integration that are added to the resource environment provider entries in the WP ConfigService:General properties
  • processintegration.htmJndiName
  • processintegration.bfmJndiName
  • processintegration.htmVersion

  Properties specific to the Task Notifier Tag

  • processintegration.myTasksPageUniqueName
  • processintegration.pendingtasks.lifetime

  Properties specific to the Task List portlets

  • processintegration.filtersetresourcebundle
  • processintegration.filterset.default.allTasks
  • processintegration.filterset.default.claimedTasks
  • processintegration.filterset.default.unclaimedTasks
  • processintegration.filterset.default.order

Using the Task Processing portlet and the Manage Processes portlet in a cross-cell setup requires manual copying of process artifacts, for example, required class libraries, into the portal installation. Now you can verify that business process integration is enabled in the portal environment.

Parent topic:

Understand cross-cell deployment scenarios

Related tasks

Use generic process integration portlets in a cross-cell setup
Verify the setup of process integration

Related information

Installing the WebSphere Process Server Client interactively
WebSphere Developer Technical Journal: Expand the user registry options with a federated repository in WAS V6.1
WAS (Distributed platforms and Windows) v6.1 Information Center, Securing communications