Extend an existing installation

After you install and configure the runtime environment on your system in BPM, you might want to customize your configuration. For example, you might want to customize settings, set up an additional security provider, set up user accounts, and change and encrypt passwords.


Customizing the Process Server settings used to connect to Process Center

After you install and configure IBM Business Process Manager, you can use the wsadmin command to change the Process Server settings that are used for connecting to the Process Center.

Restriction: The BPMAuthor role must point to the same user in both the Process Center and the Process Server, and must have the same password.

Use the following procedure to customize the Process Server connection settings:

For example, you can complete the following tasks:

To customize the settings that are used by Process Server to connect to a Process Center.

For network deployment Process Server environments on the deployment manager node, synchronize the nodes, and restart the application cluster member.

  1. Stop the Process Server environment. In a network deployment environment, stop the deployment manager and the nodes.
  2. To update the server settings with the WebSphere command-line administration tool (wsadmin) AdminConfig commands.

    1. Start the wsadmin scripting tool. To start wsadmin...

      PROFILE_HOME/bin:

        wsadmin -conntype NONE -lang jython

    2. Get the process server configuration of the application cluster.

        wsadmin> ps = AdminConfig.getid("/Cell:/ServerCluster:application_cluster_name/BPMClusterConfigExtension:/BPMProcessServer:/")

    3. Update the processCenterUrl variable.

        wsadmin> AdminConfig.modify(ps, [['processCenterUrl', 'https://new_server_name/ProcessCenter’]])

    4. If you are using BPM V8.5.0.1, update the processCenterInternalUrl variable, which is the same as ProcessCenterUrl but with the literal string Internal appended at the end for the context root.

        wsadmin> AdminConfig.modify(ps, [['processCenterInternalUrl', 'https://new_server_name/ProcessCenterInternal’]])

    5. To change the state of an offline Process Server to online, update the heartBeatInterval value to a number that is larger than 0 (zero). The heartbeat interval is the polling interval, in seconds, used by the Process Server to communicate its location and characteristics to the Process Center. For example, to set the value to 60 seconds, enter the following command:

        wsadmin> AdminConfig.modify(ps, [['heartBeatInterval', '60']])

      To bring the server offline, disable polling by setting the heartBeatInterval value to a negative number:

        wsadmin> AdminConfig.modify(ps, [['heartBeatInterval', '-1']])

      -1 is the special value to use for an offline server.

    6. Verify your updates.

        wsadmin> print AdminConfig.show(ps)

      Save the changes and exit. 

      wsadmin> AdminConfig.save()
wsadmin> exit

  3. Review the Business Process Manager security roles by navigating in the WAS administrative console to Servers > Deployment Environments > Deployment Environment Name > Related Items > Authentication Aliases. See IBM Business Process Manager security roles.
  4. Note the authentication alias for the ProcessCenterUser and BPMAuthor roles.

  5. If it does not exist, create the ProcessCenterUserAlias. See Modify authentication aliases. For ProcessCenterUserAlias, use a valid user name and password from the Process Center environment. The user does not need any special authorization in Process Center.

  6. To use a user other than DeAdmin (the default) to deploy snapshots from Process Center to the runtime Process Server, create a new BPMAuthorAlias. For BPMAuthorAlias, use a valid user name and password from the Process Server environment that has the authority to access and deploy snapshots to the runtime Process Server. This user is saved in the LSW_SERVER table in the Process Center database, and used when the process application is deployed to this Process Server.

  7. In the Business Process Manager security roles screen, map the ProcessCenterUser role to ProcessCenterUserAlias and the appropriate alias to the BPMAuthor role.

  8. Verify your updates.

      wsadmin> print AdminConfig.show(ps)

    The output looks something like this example: 

    ...
[heartBeatInterval 60]
...
[processCenterUrl https://hostname:9082/ProcessCenter]

    Save the changes and exit. 

    wsadmin> AdminConfig.save()
wsadmin> exit
  9. If you are using BPM V8.5.0.1, you must verify the Process Server root signer SSL certificate is imported into Process Center because Process Center connects to Process Server by HTTPS by default. If you configure the processCenterUrl variable or the processCenterInternalUrl variable to use HTTPS, then you also must verify the Process Center root signer certificated is imported in Process Server. Follow the steps in Configure SSL communication in a network deployment environment.

    To change the Process Center to connect to Process Server by HTTP. Then you do not need to import the Process Center root signer certificates into Process Server. Note that this change reverts back to the 8500 behavior of calculating unencrypted URLs for many scenarios, not only online deployment.

    1. Stop the Process Center environment. In a network deployment environment, stop the deployment manager and the nodes.

    2. Update the following server settings with the wsadmin AdminConfig commands.

      1. Start the wsadmin scripting tool. To start wsadmin using the Jython language, run from the bin directory of the deployment manager profile:

          wsadmin -conntype NONE -lang jython

      2. Get the Process Center configuration of the application cluster:

          wsadmin> pc = AdminConfig.getid("/Cell:/ServerCluster:application_cluster_name/BPMClusterConfigExtension:/BPMProcessCenter:/")

      3. Update the useHTTPSURLPrefixes variable:

          wsadmin> AdminConfig.modify(pc, [['useHTTPSURLPrefixes', 'false’]])

      4. Verify your updates:

          wsadmin> print AdminConfig.show(pc)

        Save the changes and exit: 

        wsadmin> AdminConfig.save()
wsadmin> exit

    3. Stop the Process Server environment. In a network deployment environment, stop the deployment manager and the nodes.

    4. Update the following server settings with the wsadmin AdminConfig commands.

      1. Start the wsadmin scripting tool. To start wsadmin using the Jython language, run from the bin directory of the deployment manager profile:

          wsadmin -conntype NONE -lang jython

      2. Get the Process Server configuration of the application cluster:

          wsadmin> pc = AdminConfig.getid("/Cell:/ServerCluster:application_cluster_name/BPMClusterConfigExtension:/BPMProcessServer:/")

      3. Update the useHTTPSURLPrefixes variable:

          wsadmin> AdminConfig.modify(pc, [['useHTTPSURLPrefixes', 'false’]])

      4. Verify your updates:

          wsadmin> print AdminConfig.show(pc)

        Save the changes and exit: 

        wsadmin> AdminConfig.save()
wsadmin> exit

  10. Restart the Process Server cluster or server. For network deployment Process Server environments, synchronize the nodes and restart the application cluster member.

The settings that are used to connect Process Server to Process Center are customized and the same changes are to the custom nodes.



Related tasks:

Change IBM Business Process Manager passwords

WebSphere Common Configuration Model

Security configuration properties

WAS syncNode command

Stop and restart a cluster member


Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.0

After you install and configure IBM Business Process Manager, you must customize the environment so that it can function properly as a cluster with a web server.

Verify the Process Server has been installed and configured, and that you have created and configured the servers and clusters. You cannot start the cluster until you complete the procedures in this topic. The method used in BPM V8.5.0.0 to configure web servers has been replaced in BPM V8.5.0.1 by a more generic way of configuring endpoints. Perform the appropriate actions that are described in Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.1.

The procedures in this topic describe how to:

The host name and port number to access the servers are stored in two places. The first place is the BPMVirtualHostInfo configuration object. The second place is in one of the XML configuration files (99Local.xml, 100Custom.xml, etc.) at the profile configuration root. Step 1 deals with changing the BPMVirtualHostInfo configuration object. Step 2 deals with editing the XML files. Because you should use 100Custom.xml for all editing purposes, copy the properties that are stored in other XML files into 100Custom.xml, and then edit them to have correct values.

Complete the following steps:

  1. Configure the Process Server and the Process Center to point to a web server. If there is no web server, then all URLs point to the cluster member host name and port. If there is no web server, the cluster server member does not need to be changed. If you have a web server, change all values to point to the web server host name and port with the actual host name and port of the web server. If you are using the default port for http (80) or https (443), the port is an optional part of the URL.

    1. Start the wsadmin scripting tool. To start wsadmin using the Jython language, run from the bin directory of the deployment manager profile: 
      Deployment Manager Profile/bin
wsadmin -conntype NONE -lang jython
      After running this command, synchronize all the nodes in the Process Admin console.
    2. Extract the object properties. 
      wsadmin> virtualhosts = AdminConfig.list('BPMVirtualHostInfo')
wsadmin> print virtualhosts

    3. If the wsadmin print command shows multiple results, pick the server by counting from zero. In the following example, the print command shows two virtual hosts: 
      (cells/WIN-E6GDL89KDJDCell01/clusters/DE1.AppCluster|cluster-bpm.xml#BPMVirtualHostInfo_1369035785708)
(cells/WIN-E6GDL89KDJDCell01/clusters/DE2.SingleCluster|cluster-bpm.xml#BPMVirtualHostInfo_1369039814544)
      To work with the first server that represents cluster 2 enter the following command:

        wsadmin> vh = virtualhosts.split()[0]

      To verify your selection, print the result again:

        wsadmin> print vh

      The output confirms the server is selected: 

      (cells/WIN-E6GDL89KDJDCell01/clusters/DE1.AppCluster|cluster-bpm.xml#BPMVirtualHostInfo_1369035785708)

wsadmin> print AdminConfig.show(vh)
    4. Change the host to be the web server host name. The host name must be the same as the host name in the IHS SSL certificate.

        wsadmin> AdminConfig.modify(vh, [['hostname', 'bpmihs']])

    5. Change the port to the value of the web server port.

        wsadmin> AdminConfig.modify(vh, [['port', '443']])

    6. Change the transport protocol.

        wsadmin> AdminConfig.modify(vh, [['transportProtocol', 'https']])

    7. Verify your update.

        wsadmin> print AdminConfig.show(vh)

      Save the changes and exit. 

      wsadmin> AdminConfig.save()
wsadmin> exit

  2. Edit 100Custom.xml.

    1. Locate and open the Process Center or Process Server 100Custom.xml file so you can overwrite the values that are there with values from 99Local.xmls. The path takes this form:

        WAS_HOME\profiles\deployment manager profile name\config\cells\cell name\nodes\node name\servers\server name\process-center\config\100Custom.xml

      or

        WAS_HOME\profiles\deployment manager profile name\config\cells\cell name\nodes\node name\servers\server name\process-server\config\100Custom.xml

      Here is an example of an actual path:

        C:\IBM\BPM\v8.5\profiles\DmgrProfile\config\cells\Cell1\nodes\Node1\servers\SingleClusterMember1\process-center\config\100Custom.xml

    2. Locate and open the Process Center or Process Server 99Local.xml file so you can extract the values that are there.

        WAS_HOME\profiles\deployment manager profile name\config\cells\cell name\nodes\node name\servers\server name\process-center\config/system/99local.xml

      or

        WAS_HOME\profiles\deployment manager profile name\config\cells\cell name\nodes\node name\servers\server name\process-server\config/system/99local.xml

      Here is an example of an actual path:

        C:\IBM\BPM\v8.5\profiles\DmgrProfile\config\cells\Cell1\nodes\Node1\servers\SingleClusterMember1\process-center\config/system/99local.xml

    3. Copy all occurrences of http://hostname:port, including the enclosing XML tags, and paste them into 100Custom.xml.

    4. Add merge="mergeChildren" to the parent XML tags that contain the http://hostname:port statements.

    5. Add merge="replace" to the XML tag that contains the http://IHS/proxy server_hostname:IHS/proxy unsecure-port or https://IHS/proxy server_hostname:IHS/proxy secure-port statement.

    6. Edit the host name and port values that should be changed.

      Save and close 100Custom.xml.

    The following example shows part of a Process Center 100Custom.xml file. 

    <properties>
   <webservices merge="mergeChildren">
      <!-- <override-default-settings webservice-name="TeamWorksQueryServices" merge="mergeChildren">
      <schema-namespace merge="replace">https://lombardisoftware.com/webservices/TeamWorksQueryServices</schema-namespace>
      </override-default-settings> -->
   </webservices>

</common>
   <server merge="mergeChildren">
      <email merge="mergeChildren">
      <mail-template merge="mergeChildren">
        <portal-link merge="replace">https://bpmihs/ProcessPortal</portal-link>
        <!-- Add port numbers if you have not used the default ports of 443 for https or 80 for http. -->
        <portal-run-task-link merge="replace">https://bpmihs/ProcessPortal/dashboards/TWP/BPM_WORK?tw.local.view=taskcompletion&amp;tw.local.taskid={2}</portal-run-task-link>
        <portal-process-info-link merge="replace">https://bpmihs/ProcessPortal/dashboards/TWP/Process+Performance?tw.local.selectedInstanceId={6}</portal-process-info-link>
        <gadget-link merge="replace">https://bpmihs/ProcessPortal/gadgets/OpenSocial/BPMOpenSocialGadget.xml</gadget-link>
     </mail-template>
     </email>
     <connections-task-notification merge="mergeChildren">
        <task-notification-template merge="mergeChildren">
        <server-link merge="replace">https://bpmihs</server-link>
        <activity-stream-image-link merge="replace">https://bpmihs/ProcessPortal/com/ibm/bpm/social/img/Bpm_connections_48x48.png</activity-stream-image-link>
        <gadget-link merge="replace">https://bpmihs/ProcessPortal/gadgets/OpenSocial/BPMOpenSocialGadget.xml</gadget-link>
        </task-notification-template>
     </connections-task-notification>
   </server>
</properties>
  3. To synchronize the changes, log in to the WebSphere Application Server admin console as an administrative user, click System administration > Nodes, click Full Resynchronize. Make sure to only work in the file system of the deployment manager profile. These changes are not replicated by using the usual syncNode command or by using the Synchronize button in the WebSphere Application Sserver admin console. You need to use a full resynchronize to copy all files from the deployment manager to the nodes, including changes that WAS does not track.
  4. Stop the deployment manager and the cluster or server.

  5. Restart the deployment manager and the cluster or server.
  6. To set the Process Center to Process Server communication to work with HTTP over SSL or HTTP Secure (HTTPS), use the procedure described in Configure SSL communication for a network deployment environment



Related tasks:

Change IBM Business Process Manager passwords

WAS syncNode command

Stop and restart a cluster member


Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.1

After you install and configure IBM Business Process Manager, you must customize the environment so that it can function properly as a cluster with a web server.

This page describes only the additional BPM configuration that is required after configuring a web server in your WebSphere Application Server cell as described in Implementing a web server plug-in.

Verify the Process Server has been installed and configured, and that you have created and configured the servers and clusters. You cannot start the cluster until you have completed the procedures in this topic. The method used in BPM V8.5.0.0 (see Customizing the Process Server or Process Center cluster to work with a web server on V8.5.0.0) was replaced in BPM V8.5.0.1 by a more generic way of configuring endpoints. If you use a web server as an entry point into the network, configure virtual host information about the web server so that BPM generates URLs that are based on the host name of the web server.

The following procedure describes the steps to follow for a simple configuration. For an advanced configuration, refer to the topic "Configuring BPM endpoints to match the topology."

  1. Stop the deployment manager.

  2. Start the wsadmin scripting client from the deployment manager profile /bin directory:

      wsadmin -conntype none -lang jython

  3. Get the deployment environment object.

    The sample below assumes a deployment environment name of De1 . This should be adapted to the deployment environment name you chose during configuration. 

    dePath = '/Cell:/BPMCellConfigExtension:/BPMDeploymentEnvironment:De1/'
de = AdminConfig.getid(dePath)
print de

  4. Create the virtual host object for your web server: 
    webserver_vh = AdminConfig.create('BPMVirtualHostInfo',de, [['name','webserver_vh'],
['transportProtocol','https'],['hostname','webserver.example.com'],['port','443']], 'virtualHosts')
  5. Point to the newly created BPMVirtualHostInfoObject object from either:

    • The defaultVH property of the deployment environment (this causes all traffic to use the web server):

        AdminConfig.modify(de,[['defaultVH',webserver_vh]])

      OR

    • The EXTERNAL_CLIENT endpoint scenario (this causes all user traffic to use the web server, while internal traffic continues to connect to the current server's web container):

      Find the BPMURL object for the EXTERNAL_CLIENT endpoint scenario: 

      for item in AdminUtilities.convertToList(AdminConfig.getid(dePath+'BPMURLS:/BPMURL:/')):
 if AdminConfig.showAttribute(item,'scenario') == 'EXTERNAL_CLIENT': bpmurl= item; break;

print bpmurl
      An external client ( a web portal or an enterprise information system) is outside the server but interacts with an application installed in the server.

      Because Jython relies on indentation to identify the contents of a loop, the space character before the if statement is required, and pressing enter twice is necessary to execute the loop.

      Set the web server virtual host for the EXTERNAL_CLIENT BPMURL and save your changes:

        AdminConfig.modify(bpmurl, [['virtualHost',webserver_vh]])

    Save changes.

      AdminConfig.save()

  6. Restart the deployment manager.



Related tasks:

Change IBM Business Process Manager passwords

WAS syncNode command

Stop and restart a cluster member

Configure BPM endpoints to match the topology

Configure the web server plug-in for Secure Sockets Layer

Securing communications

Selecting a web server topology diagram and roadmap


Configure a virtual host

In IBM Business Process Manager (BPM), if you have more than one deployment environment in the same cell, you need a script and instructions to configure a virtual host.

To configure the virtual host:

  1. Start the Deployment Manager.
  2. Run one of the following commands to view the usage instructions:

    • -help
    • dmgr_profile\bin\updateVirtualHost -?

  3. Run the updateVirtualHost command with the deployment environment names and the virtual host name:

      updateVirtualHost -d Deployment Environment Name 1,Deployment Environment Name 2 -v virtual_host_name

    The updateVirtualHost command is located in the dmgr_profile/bin directory.



Customizing Business Process Choreographer

Business Process Choreographer supports enterprise applications that contain BPEL processes or human tasks. Business Process Choreographer is configured by default when you use BPMConfig or the deployment environment wizard to create your Business Process Manager Advanced environment. Depending on your requirements, you might need to perform further customization.

  1. Optional: Verify the basic Business Process Choreographer configuration works: Perform Verifying that Business Process Choreographer works.

  2. Optional: The Business Process Choreographer configuration includes a Business Process Choreographer Explorer configuration. To view or modify the Business Process Choreographer Explorer settings using the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Business Process Choreographer Explorer.

  3. To create the Human Task Manager to be able to send escalation emails, use the administrative console to configure the settings for the Human Task Manager.

    • Set the email sender address and email URL link prefixes, click Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Human Task Manager, and complete the settings for the sender address and the prefixes for link URLs that are included in escalation emails.
    • To set the email server address, port number, the user ID, and password for the email server, click Resources > Mail > Mail sessions, select Cell scope, then click HTM mail session_suffix, where suffix is either node_name_server_name or cluster_name, depending on where Business Process Choreographer is configured. Enter your settings.

  4. Set the context roots and endpoints.

    1. If using the Business Process Choreographer Explorer, Business Process Archive Manager, the Business Space, or a client that uses the REST API, change the default context roots for the REST API so they are unique for each combination of host name and port. To set the context roots perform the following actions:

      1. To set the context roots for the Business Flow Manager, click Applications > Application Types > WebSphere enterprise applications then application_suffix > Context Root for Web Modules, where application is BPEContainer for a Business Process Choreographer configuration or BPArchiveMgr for a Business Process Archive Manager configuration, and suffix is the name of the cluster where Business Process Choreographer or Business Process Archive Manager is configured. Then make sure the context roots for the following web modules and are correct and unique.

        • BFMIF_scopeWeb
        • BFMJAXWSAPI
        • BFMRESTAPI

      2. To set the context roots for the Human Task Manager, click Applications > Application Types > WebSphere enterprise applications then application_suffix > Context Root for Web Modules, where application is TaskContainer for a Business Process Choreographer configuration or TaskArchiveMgr for a Business Process Archive Manager configuration, and suffix is the name of the cluster where Business Process Choreographer is configured. Then make sure the context roots for the following web modules and are correct and unique.

        • HTMIF_scopeWeb
        • HTMJAXWSAPI
        • HTMRESTAPI

      3. To change the REST URLs the Business Process Choreographer Explorer uses:

        1. Click Servers > Clusters > WebSphere application server clusters > cluster_name . On the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer and click Business Process Choreographer Explorer. Update the Business Flow Manager and Human Task Manager REST API URLs.

        2. Update the endpoints in config-rest.xml using a command similar to the following example, which uses PS.AppTarget as the cluster name: 
          wsadmin>AdminTask.updateRESTServiceProvider(['-clusterName',  'PS.AppTarget', '-appName', 'BPEContainer_PS.AppTarget', '-webModuleName','bfmrestapi.war', '-contextRoot', '/rest/bpm/bfmPS2/'])

wsadmin>AdminTask.updateRESTServiceProvider(['-clusterName',  'PS.AppTarget', '-appName', 'TaskContainer_PS.AppTarget', '-webModuleName','taskrestapi.war', '-contextRoot', '/rest /bpm/htmPS2/'])

        .

    2. If you changed any of the context roots for the Business Flow Manager or Human Task Manager also modify the corresponding endpoints:

      1. If using the Business Process Choreographer Explorer or Business Process Archive Explorer: Change the REST endpoint to match the new context roots by clicking Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Business Process Choreographer Explorer, select the BPCExplorer_scope or BPCArchiveExplorer_scope instance to modify, and set the new value. For example, if the context root for the Business Flow Manager REST API is /rest/bpm/bfm then the full URL might be something like http://system7.mycompany.com:9080/rest/bpm/bfm.

        If you mapped the modules to an HTTP server, proxy server, IP sprayer, load balancer, or similar server, the URL should be based on the hostname and port number for that server.

      2. If using the Business Space: Change the REST endpoints to match the new context roots by clicking Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and either Business Flow Manager or Human Task Manager, then under Additional Properties click REST Service Endpoint, and set the new value.

        If you mapped the modules to an HTTP server, proxy server, IP sprayer, load balancer, or similar server, the URL should be based on the hostname and port number for that server.

  5. Optional: Update your virtual host configuration. By default, the web modules of the Business Process Choreographer applications are configured for the default_host virtual host. Verify the ports associated with the host alias are correct. You might need to add host aliases for the host names and ports of additional cluster members or for the web server used. For more details about virtual hosts, refer to Virtual hosts.

  6. Depending on the type of people directory provider that you use for people assignment, you might need to configure it:

  7. If you configured VMM, and you want to use people substitution, perform Configure people substitution.

  8. To use group work items, use the administrative console to enable them. Click Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Human Task Manager, then select Enable group work items.

  9. If you have WebSphere application security enabled and you have a long-running process that calls a remote EJB method, make sure that your Common Secure Interoperability Version 2 (CSIv2) inbound authentication configuration has CSIv2 identity assertion enabled. For more information about this, refer to Configure Common Secure Interoperability Version 2 inbound communications.

Business Process Choreographer is customized to your requirements.


Related tasks:

Troubleshooting the Business Process Choreographer configuration


Configure the people directory provider

Business Process Choreographer can use one of four people directory providers to determine who can start processes or claim activities or tasks. Two providers can be used in their default configurations (Local operating system user registry, WebSphere Application Server user registry). The Virtual Member Manager and LDAP people directory providers can usually be used in its default configuration, but in some cases, it must be configured.

Each type of supported people directory service requires a corresponding people directory provider plug-in. Table 1 lists the supported people directory providers and corresponding plug-ins, which are installed by default.

Supported people directory providers and their plug-ins

People directory provider People directory provider plug-in name
Virtual Member Manager (VMM) VMM people directory provider
LDAP directory LDAP people directory provider
Local operating system user registry System people directory provider
WebSphere Application Server user registry User Registry people directory provider


Related concepts:

Authorization and people assignment for human tasks

People resolution


Related tasks:

Troubleshooting people assignment


Configure the Virtual Member Manager people directory provider

You configure the Virtual Member Manager (VMM) people directory provider so that Business Process Choreographer can perform people assignment, which determines who can start processes or claim activities or tasks. The default configuration of the VMM people directory provider is ready to use, and only needs to be configured if you introduce custom people assignment criteria.

To configure the VMM people directory provider, you must have a configured federated repository, as described in Manage the realm in a federated repository configuration

If you created a customized version of the VMM transformation file and Business Process Choreographer is configured on a cluster, place your version of the transformation file in the ProcessChoreographer/Staff directory to make it available on each Process Server installation that hosts members of the cluster.

  1. In the administrative console, click Resources > People directory provider.

  2. Select the appropriate node. Configure the people directory provider (perform step 3) on every node that hosts members of the cluster. Select the first node, configure the people directory provider on that node, then repeat the configuration (step 3) for all of the other nodes that host members of the cluster.
  3. To create a new VMM people directory configuration:

    1. Click VMM People Directory Provider.

    2. In the Additional Properties, select People directory configuration.

    3. Click New > Browse, and select your copy of the VMM transformation file. If the node agent is running, you can browse the file system of remote nodes to select the file.

    4. Click Next to copy the file to the ProcessChoreographer/Staff directory on the selected node.

    5. Enter an administrative name for the new people directory configuration, and optionally, a description

    6. Enter a unique Java™ Naming and Directory Interface (JNDI) name to identify this configuration to the system, for example, bpe/staff/myvmmconfiguration.

      There are no other configuration parameters

    7. Click OK, then click Save.

  4. To activate the provider configuration, stop and start the cluster where you configured the provider.

The VMM people directory provider is configured. If you have problems with this procedure, refer to Troubleshooting people assignment.



Related tasks:

Configure people substitution

Selecting a registry or repository

Selecting a registry or repository

Set up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands

Set up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands

Configure a property extension repository in a federated repository configuration

Configure a property extension repository in a federated repository configuration

Building human tasks with the Virtual Member Manager and LDAP


Configure the LDAP people directory provider

You configure the LDAP people directory provider so that Business Process Choreographer can perform people assignment, which determines who can start processes or claim activities or tasks.

To configure LDAP, you must plan for it, as described in Plan for the people directory provider. The LDAP people directory provider configuration is initialized with a URL that points to a local LDAP server. You must change the URL later to point to the actual LDAP server, which is normally remote to the application server. The LDAP people directory provider is configured for an LDAP server that allows anonymous access.

  1. Make a copy of the standard transformation file for LDAP, and give it another name. For example, myLDAPTransformation.xsl. Copy it from the following location:

    • install_root/ProcessChoreographer/Staff/LDAPTransformation.xsl.
    • install_root\ProcessChoreographer\Staff\LDAPTransformation.xsl.

    The standard XSL transformation for LDAP is stored in install_root/ProcessChoreographer/Staff/LDAPTransformation.xsl.

  2. Adapt the copy of the transformation file to suit the schema for your organization, as described in Adapting the LDAP transformation file.

    CAUTION:

    Do not modify the original version of the transformation file because it can be overwritten without warning when you apply a service pack or fix pack.

  3. If Business Process Choreographer is configured on a cluster, place the copy of the transformation file in the ProcessChoreographer/Staff directory to make it available on each Process Server installation that hosts members of the cluster.

  4. In the administrative console, click Resources > People directory provider.

  5. Select the appropriate node. Configure the people directory provider (complete step 6) on every node that hosts the cluster members. Select the first node, configure the people directory provider on that node, then repeat the configuration (step 6) for all the other nodes that host the cluster members.

  6. Create an LDAP configuration on the selected node.

    1. Click LDAP People Directory Provider.

    2. Under Additional Properties, click People directory configuration.

    3. Click New > Browse, and select the copy of the XSL transformation file that you adapted in step 2. If the node agent is running, you can browse the file system of remote nodes to select the file.

    4. Click Next to copy the file to the ProcessChoreographer\Staff directory on the selected node.

    5. Enter an administrative name for the new people directory configuration, and optionally, a description

    6. Enter a unique Java™ Naming and Directory Interface (JNDI) name for human tasks to use to reference this provider. For example, bpe/staff/ldapserver1.

    7. Click Apply, then click Custom Properties.

    8. For each of the required properties and for any optional properties that you planned in 2, choose whichever option applies and complete the following steps:

      • To change an existing property, click the name of the property, enter a value, and click OK.
      • To create an additional property, edit one pair of additionalParameterName<number> and additionalParameterValue<number> custom properties as required, for example:

        • Set the value of additionalParameterName1 to java.ldap.referral.

        • Set the value of additionalParameterValue1 to follow.

    9. To apply the changes, click Save.

  7. To activate the provider configuration, stop and start the cluster where you configured the provider.

Human tasks and processes can now use the people assignment services to resolve people assignment queries and to determine which activities can be performed by which people.



Adapting the LDAP transformation file

Describes how to adapt the LDAP transformation XSL file to suit your organization's LDAP schema.

The default LDAPTransformation.xsl file maps predefined people assignment criteria to LDAP queries, which make use of elements of the default LDAP schema. The following assumptions apply to the this schema:

If your LDAP schema uses name for object class and attribute names that are different from those listed, you perform the following steps.

  1. Make a copy of the standard transformation file for LDAP, and give it another name, for example, myLDAPTransformation.xsl. The standard XSL transformation for LDAP is located in:

    • install_root/ProcessChoreographer/Staff/LDAPTransformation.xsl.
    • install_root\ProcessChoreographer\Staff\LDAPTransformation.xsl.

    install_root/ProcessChoreographer/Staff/LDAPTransformation.xsl.

  2. In the copy of the file, change the names of the object classes and attributes to match the names used by your LDAP schema. For most situations, you can change the settings for all people assignment criteria by editing the variable declaration part of the file: 
     <xsl:variable name="DefaultGroupClass">groupOfNames</xsl:variable>
  <xsl:variable name="DefaultGroupClassMemberAttribute">member</xsl:variable>
 
  <xsl:variable name="DefaultPersonClass">inetOrgPerson</xsl:variable>
  <xsl:variable name="DefaultUserIDAttribute">uid</xsl:variable>
  <xsl:variable name="DefaultMailAttribute">mail</xsl:variable> 
  <xsl:variable name="DefaultManagerAttribute">manager</xsl:variable>

    CAUTION:

    Do not modify the original version of the standard transformation file because it might be overwritten without warning when you apply a service pack or fix pack.

    You can apply changes within the XSL templates that transform the individual staff assignment criteria, as illustrated in the following examples.


Example: GroupMembers

Change the object class for group entries to groupOfUniqueNames, the group entry attribute containing the member DN list to uniqueMember, and the person entry attribute containing the login in to cn: 

<sldap:usersOfGroup>
...

<sldap:attribute>
<xsl:attribute name="name">uniqueMember</xsl:attribute>
<xsl:attribute name="objectclass">groupOfUniqueNames</xsl:attribute>
<xsl:attribute name="usage">recursive</xsl:attribute>
</sldap:attribute>

...
<sldap:attribute>
<xsl:attribute name="name">cn</xsl:attribute>
<xsl:attribute name="objectclass">inetOrgPerson</xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>
</sldap:attribute>
...
<sldap:resultObject>
<xsl:attribute name="objectclass">groupOfUniqueNames</xsl:attribute>
<xsl:attribute name="usage">recursive</xsl:attribute>
<sldap:resultAttribute>
<xsl:attribute name="name">uniqueMember</xsl:attribute>
<xsl:attribute name="destination">intermediate</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>

<sldap:resultObject>
<xsl:attribute name="objectclass"><xsl:value-of select="$DefaultPersonClass"/></xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>

<sldap:resultAttribute>
<xsl:attribute name="name">cn</xsl:attribute>
<xsl:attribute name="destination">userID</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultMailAttribute"/></xsl:attribute>
<xsl:attribute name="destination">eMailAddress</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultLocaleAttribute"/></xsl:attribute>
<xsl:attribute name="destination">preferredLocale</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>

</sldap:usersOfGroup>


Example: GroupMembersWithoutFilteredUsers

Change the LDAP filter operator to >=. 

<sldap:StaffQueries>
<sldap:usersOfGroup>
...
</sldap:usersOfGroup>

<sldap:intermediateResult>
<xsl:attribute name="name">filteredusers</xsl:attribute>
<sldap:search>
<xsl:attribute name="filter">
<xsl:value-of select="staff:parameter[@id='FilterAttribute']"/>
  >=
<xsl:value-of select="staff:parameter[@id='FilterValue']"/>
</xsl:attribute>
...
<sldap:search>
...

</sldap:intermediateResult>
...
</sldap:StaffQueries>


Example: GroupSearch

Change the search attribute to MyType, the object class to mypersonclass, and the attribute containing the login ID to myuid. 

<sldap:StaffQueries>
...
<sldap:search>
<xsl:attribute name="filter">
(&
...
<xsl:if test="staff:parameter[@id='MyType']!="">
(<xsl:value-of select="$GS_Type"/>=
<xsl:value-of select=staff:parameter[@id='Type']"/>)
</xsl:if>
)
...
</xsl:attribute>

<sldap:attribute>
<xsl:attribute name="name">myuid</xsl:attribute>
<xsl:attribute name="objectclass">mypersonclass</xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>
</sldap:attribute>
...
<sldap:resultObject>
<xsl:attribute name="objectclass">mypersonclass</xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>

<sldap:resultAttribute>
<xsl:attribute name="name">myuid</xsl:attribute>
<xsl:attribute name="destination">userID</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultMailAttribute"/></xsl:attribute>
<xsl:attribute name="destination">eMailAddress</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultLocaleAttribute"/></xsl:attribute>
<xsl:attribute name="destination">preferredLocale</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>

<sldap:search>
</sldap:StaffQueries>


Example: Manager of Employee

Change the attribute containing the manager DN to managerentry and the source of the manager login ID attribute to name. 

<sldap:StaffQueries>

<sldap:intermediateResult>
...
<sldap:user>
...
<xsl:attribute name="name">managerentry</xsl:attribute>
...
<sldap:resultObject>
<xsl:attribute name="objectclass"><xsl:value-of select="$DefaultPersonClass"/></xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>

<sldap:resultAttribute>
<xsl:attribute name="name">managerentry</xsl:attribute>
<xsl:attribute name="destination">intermediate</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>
</sldap:user>
</sldap:intermediateResult>

<sldap:user>
...
<xsl:attribute name="name">name</xsl:attribute>
...
<sldap:resultObject>
<xsl:attribute name="objectclass"><xsl:value-of select="$DefaultPersonClass"/></xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>

<sldap:resultAttribute>
<xsl:attribute name="name">name</xsl:attribute>
<xsl:attribute name="destination">userID</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultMailAttribute"/></xsl:attribute>
<xsl:attribute name="destination">eMailAddress</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultLocaleAttribute"/></xsl:attribute>
<xsl:attribute name="destination">preferredLocale</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>

</sldap:user>
</sldap:StaffQueries>


Example: PersonSearch

Change the search attribute to MyAttribute, the object class to mypersonclass, and the source of the return attribute to myuid. 

<sldap:StaffQueries>
...
<sldap:search>
<xsl:attribute name="filter">
(&
...
<xsl:if test="staff:parameter[@id='MyAttribute']!="">
(<xsl:value-of select="$PS_UserID"/>=
<xsl:value-of select=staff:parameter[@id='UserID']"/>)
)
</xsl:if>
...
</xsl:attribute>

<sldap:attribute>
<xsl:attribute name="name">myuid</xsl:attribute>
<xsl:attribute name="objectclass">mypersonclass</xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>
</sldap:attribute>
...
<sldap:resultObject>
<xsl:attribute name="objectclass">mypersonclass</xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>

<sldap:resultAttribute>
<xsl:attribute name="name">myuid</xsl:attribute>
<xsl:attribute name="destination">userID</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultMailAttribute"/></xsl:attribute>
<xsl:attribute name="destination">eMailAddress</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultLocaleAttribute"/></xsl:attribute>
<xsl:attribute name="destination">preferredLocale</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>
</sldap:search>
</sldap:StaffQueries>


Example: Users

Change the source of the return attribute to myuid and the object class to mypersonclass. 

<sldap:user>
...
<xsl:attribute name="attribute">myuid</xsl:attribute>
<xsl:attribute name="objectclass">mypersonclass</xsl:attribute>

<sldap:resultObject>
<xsl:attribute name="objectclass">mypersonclass</xsl:attribute>
<xsl:attribute name="usage">simple</xsl:attribute>

<sldap:resultAttribute>
<xsl:attribute name="name">myuid</xsl:attribute>
<xsl:attribute name="destination">userID</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultMailAttribute"/></xsl:attribute>
<xsl:attribute name="destination">eMailAddress</xsl:attribute>
</sldap:resultAttribute>
<sldap:resultAttribute>
<xsl:attribute name="name"><xsl:value-of select="$DefaultLocaleAttribute"/></xsl:attribute>
<xsl:attribute name="destination">preferredLocale</xsl:attribute>
</sldap:resultAttribute>
</sldap:resultObject>

</sldap:user>



Configure people substitution

This topic describes how to configure people substitution for Business Process Choreographer.

You have configured WebSphere security for Federated Repositories, and if you introduce custom people assignment criteria, you have also performed Configure the Virtual Member Manager people directory provider. You know whether use a file registry, property extension registry, or an existing LDAP schema to store the property extensions.

To use people substitution in a production environment, use the Virtual Member Manager (VMM) property extension repository as described in this topic. If however, you only want to use people substitution in a single-server test environment, you can use the file registry that is associated by default with federated repositories, without having to configure VMM.

  1. Add the attributes, "isAbsent", "substitutes", "substitutionStartDate", and "substitutionEndDate" to the VMM definition for PersonAccount:

    1. Locate the wimxmlextension.xml file:

      • profile_root/config/cells/cell_name/wim/model/wimxmlextension.xml
      • profile_root\config\cells\cell_name\wim\model\wimxmlextension.xml

      It is located in profile_root/config/cells/cell_name/wim/model

    2. Make a backup copy of the wimxmlextension.xml file.

    3. Edit the original copy of the wimxmlextension.xml file, and make sure that it contains the following definitions, which add the two attributes needed for user substitution to the PersonAccount entity type: 
      <wim:propertySchema nsURI="http://www.ibm.com/websphere/wim"
     dataType="STRING" multiValued="false" propertyName="isAbsent">
   <wim:applicableEntityTypeNames>PersonAccount
   </wim:applicableEntityTypeNames>
</wim:propertySchema>

<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim"
     dataType="STRING" multiValued="true" propertyName="substitutes">
   <wim:applicableEntityTypeNames>PersonAccount
   </wim:applicableEntityTypeNames>
</wim:propertySchema>
<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim"
     dataType="STRING" multiValued="false" propertyName="substitutionStartDate">
   <wim:applicableEntityTypeNames>PersonAccount
   </wim:applicableEntityTypeNames>
</wim:propertySchema>

<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim"
     dataType="STRING" multiValued="false" propertyName="substitutionEndDate">
   <wim:applicableEntityTypeNames>PersonAccount
   </wim:applicableEntityTypeNames>
</wim:propertySchema>
      If you are using a file registry, fileRegistry.xml, skip to step 4.

  2. Set up the property extension repository. For more information about setting up a property extension repository, see Configure a property extension repository in a federated repository configuration.

    1. Make sure that a database is available to store the property extensions.
    2. Verify the JDBC driver class is available on the server class path. Click Environment > WebSphere variables to check. If necessary, add the DataServer JDBC driver to the class path. For DB2 , add db2jcc4.jar , db2jcc_license_cu.jar, and db2jcc_license_cisuz.jar to the server's class path, and click Apply > Save
    3. Verify the JDBC driver class is available on the server class path. Click Environment > WebSphere variables to check. If necessary, add the Universal JDBC driver to the class path. For DB2, add db2jcc.jar , db2jcc_license_cu.jar, and db2jcc_license_cisuz.jar to the server's class path, and click Apply > Save

    4. Configure a DB2 Universal JDBC driver provider and type-4 data source for VMM using the administrative console. Set the webSphereDefaultIsolationLevel custom property for the data source to the value 2. For more information about changing the default isolation level, see Change the default isolation level for non-CMP applications and describing how to do so using a new custom property webSphereDefaultIsolationLevel.

    5. Restart the server.

    6. Make a backup copy of the wimlaproperties.xml file.

      • install_root/etc/wim/setup/wimlaproperties.xml
      • install_root\etc\wim\setup

      It is located in install_root/etc/wim/setup\wimlaproperties.xml

    7. Edit the original copy of the wimlaproperties.xml file, and add the following definitions: 
      <wimprop:property wimPropertyName="isAbsent" dataType="String"
     valueLength="128" multiValued="false">
    <wimprop:applicableEntityName>
  <wimprop:entityName>PersonAccount</wimprop:entityName>
    </wimprop:applicableEntityName>
</wimprop:property>

<wimprop:property wimPropertyName="substitutes" dataType="String"
     valueLength="128" multiValued="true">
    <wimprop:applicableEntityName>
  <wimprop:entityName>PersonAccount</wimprop:entityName>
    </wimprop:applicableEntityName>
</wimprop:property>
<wimprop:property wimPropertyName="substitutionStartDate" dataType="String"
     valueLength="128" multiValued="false">
    <wimprop:applicableEntityName>
  <wimprop:entityName>PersonAccount</wimprop:entityName>
    </wimprop:applicableEntityName>
</wimprop:property>

<wimprop:property wimPropertyName="substitutionEndDate" dataType="String"
     valueLength="128" multiValued="false">
    <wimprop:applicableEntityName>
  <wimprop:entityName>PersonAccount</wimprop:entityName>
    </wimprop:applicableEntityName>
</wimprop:property>

    8. Verify the application server (or in a network deployment environment, the deployment manager) is running. Be aware not to use the -conntype NONE option for the wsadmin utility.

    9. Use the VMM administrative task setupIdMgrPropertyExtensionRepositoryTables to create the substitution properties in the Property Extension Repository database. For more details, see Set up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands. For example: 
      $AdminTask setupIdMgrPropertyExtensionRepositoryTables {
-reportSqlError true
-schemaLocation install_root/etc/wim/setup
-laPropXML  install_root/etc/wim/setup/wimlaproperties.xml
-databaseType db2
-dbURL jdbc:DB2://host:port/name
-dbDriver com.ibm.db2.jcc.DB2Driver
-dbAdminId userID
-dbAdminPassword password }
      For example, using a DB2 database on a Windows platform: 
      $AdminTask setupIdMgrPropertyExtensionRepositoryTables {
-reportSqlError true
-schemaLocation install_root\etc\wim\setup
-laPropXML  install_root\etc\wim\setup\wimlaproperties.xml
-databaseType db2
-dbURL jdbc:DB2://host:port/name
-dbDriver com.ibm.db2.jcc.DB2Driver
-dbAdminId userID
-dbAdminPassword password }
      For example, using a DB2 database on a Linux or UNIX platform: 
      $AdminTask setupIdMgrPropertyExtensionRepositoryTables {
-reportSqlError true
-schemaLocation install_root/etc/wim/setup
-laPropXML  install_root/etc/wim/setup/wimlaproperties.xml
-databaseType db2
-dbURL jdbc:DB2://host:port/name
-dbDriver com.ibm.db2.jcc.DB2Driver
-dbAdminId userID
-dbAdminPassword password }
      Where host is the host name of the database server, port is the service port for the DB2 instance, and name is the name of the database, and userID and password provide database administrator rights.

    10. If you are using a LDAP user repository, locate the wimconfig.xml file.

      • profile_root/config/cells/cellName/wim/config/wimconfig.xml
      • profile_root\config\cells\cellName\wim\config\wimconfig.xml

      Edit the file and add the following entries to exclude the substitution attributes from the LDAP repository: 

      <config:repositories xsi:type="config:LdapRepositoryType"
      adapterClassName="com.ibm.ws.wim.adapter.ldap.LdapAdapter"
       ...>
      ...
      <config:attributeConfiguration>
         <config:propertiesNotSupported name="isAbsent"/>
         <config:propertiesNotSupported name="substitutes"/>
         <config:propertiesNotSupported name="substitutionEndDate"/>
         <config:propertiesNotSupported name="substitutionStartDate"/>
      </config:attributeConfiguration>
    11. Activate the extension property repository:

      1. Use the setIdMgrPropertyExtensionRepository command. For more details, see Set up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands. For example, using a DB2 database named VMMDB, a data source named VMMDS: 
        $AdminTask setIdMgrPropertyExtensionRepository {
-dataSourceName jdbc/VMMDS
-databaseType db2
-dbURL jdbc:DB2://host:port/VMMDB
-dbAdminId userID
 -dbAdminPassword password  -JDBCDriverClass com.ibm.db2.jcc.DB2Driver
-entityRetrievalLimit 10 }

      2. Verify the wimconfig.xml file contains an entry similar to the following example: 
        <config:propertyExtensionRepository
   adapterClassName="com.ibm.ws.wim.lookaside.LookasideAdapter"
   id="LA"
   databaseType="db2"
   dataSourceName="jdbc/VMMDS"
   dbAdminId="userID"
   dbAdminPassword="{xor}PasswordXOR"
   dbURL="jdbc:DB2://host:port/VMMDB"
   entityRetrievalLimit="10"
   JDBCDriverClass="com.ibm.db2.jcc.DB2Driver"/>>

  3. If you use an LDAP schema to hold the substitution information: It may or may not already have definitions for "isAbsent", "substitutes", "substitutionStartDate", and "substitutionEndDate" (possibly with different names). Whether you have existing definitions, or you will create new ones, make sure the following items are set:

    1. The LDAP directory must allow write operations.
    2. The attribute for absence information ("isAbsent") must be of type Boolean or a String.
    3. The attribute that defines who the person can substitute for ("substitutes") must be of type String, multi-valued, and permit a length up to 128 characters.

    4. If your existing or chosen attribute names are not "isAbsent", "substitutes", "substitutionStartDate", and "substitutionEndDate", you must define your attribute names in the administrative console by clicking Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Human Task Manager, on the Configuration tab select Custom properties then set the names for the custom properties Substitution.SubstitutesAttribute, Substitution.AbsenceAttribute, Substitution.StartDateAttribute, and Substitution.EndDateAttribute.

  4. Restart the server.

  5. Enable substitution in the Human Task Manager:

    1. Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Human Task Manager, and click Human Task Manager, then either Runtime or Configuration.
    2. To enable substitution, select Enable substitution.

    3. If non-administrators are allowed to perform substitution for other users, clear the Restrict substitute management to administrators option.

      This settings does not affect the ability of users to change substitution for themselves.

    4. Click Apply.

    5. If you selected Configuration in step 5.a, restart the server to activate the substitution settings.

  6. If you have problems with any of these steps, refer to Troubleshooting people assignment.

The people assignment service is configured to support user substitution for absent users.


Related tasks:

Configure the Virtual Member Manager people directory provider

Selecting a registry or repository

Selecting a registry or repository

Set up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands

Set up an entry mapping repository, a property extension repository, or a custom registry database repository using wsadmin commands

Configure a property extension repository in a federated repository configuration

Configure a property extension repository in a federated repository configuration


Verifying that Business Process Choreographer works

Run the Business Process Choreographer installation verification application.

  1. Use either the administrative console or the wsadmin command, deploy the application in install_root/installableApps/bpcivt.ear.

    Restriction: In a network deployment environment, you can only deploy one instance of the Business Process Choreographer installation verification application. For example, if you have two Business Process Choreographer clusters in the same network deployment cell, you can deploy the bpcivt.ear application only on one of the clusters. Later, to deploy it on the second cluster, you must first undeploy it from the first cluster. After the enterprise application is deployed, it is in the state stopped, and any process and task templates that it contains are in the state started. No process or task instances can be created until the application is started.

  2. Make sure that at least one member of the cluster is running.

  3. Verify the database system, and messaging service are running.

  4. Select the application BPCIVTApp and click Start to start the application.

  5. Verify the application works. Using a web browser, open the following page:

      http://app_server_host:port_no/bpcivt

    Where app_server_host is the network name for the host of the application server and port_no is the port number used by the virtual host to which you mapped the IVT web module when installing the file bpcivt.ear. The port number depends on your system configuration. You should see a message indicating success.

  6. Optional: Stop and remove the bpcivt application.

    For more information about undeploying BPEL process and human task applications, see Undeploy BPEL process and human task applications, using the administrative console.

  7. If an error occurs, it can be caused by any of the following situations:

    • If Business Process Choreographer cannot access the database, check the database system is running, that all database clients are correctly configured, and the data source is defined correctly. Verify the user ID and password for the data source are valid.

    • If Business Process Choreographer cannot read the input queues, check the messaging service is running, and make sure the JMS provider and JMS resources are defined correctly.

    • For further help, see Troubleshooting the Business Process Choreographer configuration.

The basic functionality of your Business Process Choreographer configuration works.


If you have configured the people directory provider, it will need to be tested separately.


Understanding the startup behavior of Business Process Choreographer

This topic explains why Business Process Choreographer is unavailable until all enterprise applications are started.

When the Business Process Choreographer is started or restarted, no messages in the internal queues are processed until all enterprise applications have started. It is not possible to change this behavior. The time the Business Flow Manager and Human Task Manager are unavailable during a restart depends on how long it takes until all enterprise applications are started. This behavior is necessary to avoid navigating any processes with associated enterprise applications that are not running.

Start to process messages in the internal queue before all applications are started would result in ClassNotFound exceptions.


Configure Oracle Real Application Cluster (RAC) for use with BPM

Oracle Real Application Clusters (RAC) is an option of an Oracle database that brings together two or more computers to form a clustered database that behaves as a single system. In a RAC database, Oracle processes that run in separate nodes access the same data from a shared disk storage.

There are two scenarios to consider:

IBM Business Process Manager always creates the JDBC URL in the following format

which can be edited to the following format to use Oracle RAC: 

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
                  (ADDRESS=(PROTOCOL=TCP)(HOST=rac-node1)(port=1521))
                  (ADDRESS=(PROTOCOL=TCP)(HOST=rac-node2)(port=1521)))
                  (FAILOVER=on)(LOAD_BALANCE=on)
                  (CONNECT_DATA=(SERVER=DEDICATED)
                  (SERVICE_NAME=<service_name>)))

If a Oracle RAC node failover occurs, IBM Business Process Manager stops processing and you might need to restart all of the BPM nodes. If you experience process-recovery issues, refer to Process recovery issues in certain situations in BPM V7.5.

  1. Set the RAC URL as the Oracle URL when you define the relevant Oracle JDBC data sources.

    1. In the administrative console, select Resources > JDBC > Data sources.

    2. Edit all the data sources using Oracle with the JDBC URL to use one of the preceding formats.

    Refer to Configure a data source using the administrative console.

  2. Update the Authentication Alias Configuration page and run the administrative task to update the URL to use the Oracle RAC. See Modify authentication aliases.
  3. In a network deployment environment, you must synchronize the nodes that contain Process Center, Process Server, or Performance Data Warehouse cluster members.

    1. In the administrative console, click System administration > Nodes.

    2. Select all of the nodes and click Full Resynchronize.
    3. Stop and restart all of the clusters and servers.



Mapping IBM Business Process Manager configuration parameters to Oracle setup parameters

About this task

To understand how to specify the correct information during the Oracle RAC database configuration, review the following parameter mapping information to ensure the JDBC URL is created correctly.

The format of the JDBC URL that is generated during configuration is

where

For example, an Oracle RAC setup with a RAC scan name of rac1.mycompany.com, a SCAN port of 1521, and a cluster-managed database service of MYSERVICE is specified with the following JDBC URL: jdbc:oracle:thin:@//rac1.mycompany.com:1521/MYSERVICE.mycompany.com


Configure a proxy server for Process Portal

If you use Process Portal in a three cluster topology with Process Server and Process Portal on different clusters, they must both be accessible using the same domain and port number. The configureProxyServer script provides a simple way to create the routing server functionality that is mandatory for BPM Process Portal configuration.

If you prefer, you can use any other proxy server or HTTP server. This information describes how to configure the WebSphere proxy server by using the administrative console. For information about configuring a different proxy server or an HTTP server, see the documentation for the product that you use.

If you have an existing server that can be used to route requests, decide whether you want to use that server. If using the WebSphere proxy server, decide whether you want to configure it manually or by running a script.

The script uses defaults that are suitable for creating a proxy server in a simple environment. The script is not suitable for more complex environments, for example if the proxy must run in a DMZ without normal access to the rest of the cell, or if you do not want to use the default values that are used by the script.

The reason why you need a routing server for three cluster configurations is because Process Portal uses web components that are distributed across two clusters. If you do not configure a suitable server to redirect requests to the appropriate clusters, the web browser's same origin policy will prevent Process Portal from working correctly. In a three cluster configuration, Process Portal relies on applications on both the application deployment target cluster and the support cluster.

  1. To configure a WebSphere proxy server by running a script, perform the following actions.

    1. Change to the directory were the proxy scripts are located.

      • cd install_root/BPM/Lombardi/tools/proxy
      • cd install_root\BPM\Lombardi\tools\proxy

      This directory contains the following scripts.

      • configureProxyServer.py
      • configureProxyServer.sh
      • configureProxyServer.bat

      The .sh and .bat files provide a convenient way to run the .py script. The .sh file provides a convenient way to run the .py script.

    2. Create and configure the WebSphere proxy server by running one of the following commands.

      • wsadmin -f configureProxyServer.py options
      • configureProxyServer.sh options
      • configureProxyServer.bat options

      Where options can include any of the following parameters:

      -d, --deployment-environment environment_name

      Optionally specifies the name of the deployment environment to configure a proxy server for. If you do not specify a deployment environment, a proxy server will be created for each deployment environment.

      -n, --node node_name

      Optionally specifies the name of the node to deploy the proxy servers to. If you do not specify a node, one will be selected for you.

      --no-save

      Optionally specifies not to save changes to the configuration.

      --no-sync

      Optionally specifies not to synchronize changes across all nodes.

      Tip: If you require a non-interactive session without prompts for a user ID and password, or if the installation uses non-standard symbolic links, use the wsadmin -f configureProxyServer.py options command syntax to create and configure the proxy server.

    3. You must restart all clusters in the deployment environment after running the configureProxyServer script.

  2. To configure a WebSphere proxy server manually, perform the following actions.

    1. Decide which node will host the proxy server. If necessary, create and federate a new managed node. Make a note of the node's host name as proxy_host_name.

    2. Create the proxy server using the administrative console by clicking Servers > Server types > WebSphere proxy servers > New.

    3. Identify the proxy server's port numbers. Click Servers > Server types > WebSphere proxy servers > your_proxy_server > Ports and note the port values proxy_http_port and proxy_https_port that correspond to the port values of the end points named PROXY_HTTP_ADDRESS and PROXY_HTTPS_ADDRESS.

    4. If proxy_http_port and proxy_https_port are using the default values 80 and 443, skip to step 2.h.

    5. Add the following host aliases to the default_host virtual host:

      • Host name: * Port: proxy_http_port
      • Host name: * Port: proxy_https_port

    6. For each cluster member in the application deployment cluster in the deployment environment, note the port value of the end point named WC_defaulthost_secure as cluster_member_https_port.

    7. Add rewrite rules. Click Servers > Server types > WebSphere proxy servers > your_proxy_server > HTTP Proxy Server Settings > Rewriting rules, then for each value of cluster_member_https_port that you noted in step 2.f, add the following re-writing rule to the proxy server that you created in step 2.b:

      • From URL Pattern: https://proxy_host_name:cluster_member_https_port/*
      • To URL Pattern: https://proxy_host_name:proxy_https_port/*

    8. Set the cache.query.string custom property. Click Servers > Server types > WebSphere proxy servers > your_proxy_server > HTTP Proxy Server Settings > Proxy settings > Custom properties, and add the following custom property to the proxy server settings:

      • Name: cache.query.string
      • Value: true

    9. Restartall the clusters in the deployment environment.

    10. Start the proxy server.

  3. If you will configure a different type of routing server or an existing routing server, such as a web server, proxy server, or reverse proxy server, use the following resources to plan the routing changes necessary for Process Portal.

    • The documentation for the product that you are using for routing requests.
    • Verifying Process Portal provides a list of the applications that Process Portal depends on and the clusters on which they normally run.

  4. If you are using a third-party authentication product, make sure that it works correctly with the new proxy. See Configure third-party authentication products.

You have a suitably configured routing server to support Process Portal in a three cluster topology.



Delete a proxy server

To remove a proxy server, delete the proxy server, remove host aliases, and delete the virtual host.

  1. In the administrative console, click Servers > Server Types > WebSphere proxy servers, and delete the proxy server.

  2. Click Environment > Virtual hosts > default_host > Host Aliases and remove the following host aliases:

    • Host name: * Port: proxy_http_port
    • Host name: * Port: proxy_https_port

  3. Click Environment > Virtual hosts and delete the virtual host.



Verifying Process Portal

After configuring Process Portal, use the Process Portal verification page to make sure the applications used by Process Portal are all accessible and that Process Portal is working.

  1. Verify that all the applications used by Process Portal are accessible.

    1. Use a web browser, open the URL for the BPM Process Portal verification page.

      Process Portal URLs for HTTP and HTTPS

      Protocol Port Process Portal URL
      HTTP Default (80) http://BPM_host/ProcessPortal/web_test
      HTTP Non-default http://BPM_host:port/ProcessPortal/web_test
      HTTPS Default (443) https://BPM_host/ProcessPortal/web_test
      HTTPS Non-default https://BPM_host:port/ProcessPortal/web_test

      Where BPM_host is the host name or IP address of the BPM server or routing server and port is the port number used for the Process Portal service.

    2. If you are prompted for them, enter a valid user ID and password.

    3. If you cannot log on to Process Portal, perform the following actions:

      1. Make sure that you are using the correct URL. Try using an IP address instead of a host name.

      2. If you get no logon window, or you get an HTTP error 404, page not found, or WebGroup/Virtual Host error, try the following actions.

        • If you use a proxy server:

          • Check the proxy server's SystemOut.log file. Any messages similar to the following message: TCPC0003E: TCP Channel TCP_7 initialization failed. The socket bind failed for host * and port 80. The port may already be in use. probably indicate that another service is using the same port number. If there is a conflict, change the proxy port number and virtual host port number manually to avoid any possible conflicts.

            To check or change the virtual host settings for the proxy server, in the administrative console, click Environment > Virtual Hosts.

            If you change the proxy server port number, also check whether step 1.c.iv applies.

          • Check the /ProcessPortal context root for the Process Portal web application is correctly mapped.

        • If you are using an HTTP server as a routing server, check the web module mapping.

      3. Make sure that you are using a valid user ID and password to access Process Portal.

      4. If you use a proxy server and are not using the default ports for http and https (80 or 443) perform the following actions:

        1. Verify the non-default ports that you are using for HTTP and HTTPS are redirected. Using the administrative console, click Environment > Virtual Hosts, and add the non-default host aliases for your servers to the default_host list. For example if you use port 81 for HTTP and port 444 for HTTPS, add *:81 and *:444 .

        2. If you use host names for the proxy servers rather than IP addresses, for each proxy server, make sure that host name of the proxy server is in the host files for the deployment manager and the proxy server itself.

        3. Restart the deployment manager.

        4. Configure the proxy server to add a rewriting rule for the application server SSL host name and port. On the admin console, Servers > WebSphere proxy servers > server_nameProxy Settings > HTTP Proxy Server Settings > Rewriting rules > New, for From URL pattern enter the protocol, host, port, and wildcard for the application server SSL service, for example https://app_server_host_name:9483/* . For To URL pattern enter the protocol, host, port, and wildcard for the proxy server SSL service, for example, https://proxy_server_host_name:444/*.
        5. Synchronize the managed nodes with the deployment manager using the syncNode command from the profile_root/bin directory or from the Quick start console for the profile. Use the following syntax:

          • syncNode.sh deployment_manager port
          • syncNode.bat deployment_manager port

          Where deployment_manager is the host name or IP address of the deployment manager, and port is the port number. For more information about the syncNode command, see syncNode command in the WebSphere Application Server information center.

      5. Try to open the Process Portal URL again.

    4. If the BPM Process Portal verification page is displayed, verify that each application listed on the page has a check mark next to it. If any applications are marked with an x, there is a problem that must be resolved with that application before Process Portal can work fully. If there are problems, consider the following.

      • Click the application name for more information about it.

      • For the applications that have a problem, perform the corresponding checks listed in the following table.

      Troubleshooting problems shown on the BPM Process Portal verification page

      Application Application name prefix Things to check
      Process Portal IBM_BPM_Process_Portal_

      • Verify that Process Portal is configured.
      • Check the EAR files are available on the routing server.

      Process Portal Notification IBM_BPM_Process_Portal_Notification_
      Process Portal Theme (WebDAV) mm.was_
      WLE REST Services IBM_BPM_Teamworks_

      • Make sure that application deployment target cluster is available.

      • Verify the IBM_BPM_Teamworks_ application is installed.

      • Verify the web modules in the EAR file are available on the routing server.

      Business Space BSpaceEAR_

      • Verify that Business Space is configured.

      • Verify the EAR files are available on the routing server.

      Business Space Theme (WebDAV) mm.was_
      Mashups mm.was_

  2. Verify that Process Portal works.

    1. Open Process Portal. Using a web browser to access the URLs for the Process Portal.

      Process Portal URLs for HTTP and HTTPS

      Protocol Port Process Portal URL
      HTTP Default (80) http://BPM_host/portal
      HTTP Non-default http://BPM_host:port/portal
      HTTPS Default (443) https://BPM_host/portal
      HTTPS Non-default https://BPM_host:port/portal

      Where BPM_host is the host name or IP address of the BPM server or routing server and port is the port number used for the Process Portal service.

      If you use HTTP and HTTPS protocols, verify both URLs.

    2. Verify the Process Portal is displayed and can be used.

Process Portal is working and users can use a web browser to interact with processes.



Configure the Business Space component and registering REST endpoints on the administrative console

You can install and configure the Business Space component using the administrative console.

Complete the following tasks:

If you are using deployment environments or other advanced profile configuration, use the administrative console to configure the Business Space component to work with Process Portal in the runtime environment.

  1. Ensure the administrative console is running.

  2. In the navigation pane click Servers > Server Types > WebSphere application servers or Servers > Clusters > WebSphere application server clusters.

  3. Select the name of your server or cluster target.

  4. On the Configuration page, in the Business Integration section, click Business Space Configuration. The Business Space Configuration page opens. If Business Space has already been configured, you can view this page, but you cannot edit the fields.

  5. Select Install Business Space service.

  6. In the Database schema name box, type the name of the database schema to use for the Business Space database.

    In Oracle, the schema is the same as the user name set on the authentication alias on the data source.

  7. If no data source is designated in the Existing Business Space data source field, go to the Create Business Space data source using section and select a data source that connects to the database you want to use with Business Space.

    Designating a data source in the Create Business Space data source using section creates a data source for Business Space with a JNDI name of jdbc/mashupDS that is modeled on the data source you selected.

    The Business Space data source is created on the server or cluster on which you are configuring Business Space, even if the product data source is on a different server or cluster.

    If you do not see an existing data source to use, you must cancel the Business Space Configuration page, set up the database, and the data source to use, and then restart the Business Space Configuration page to complete the configuration. See the Before you begin section.

  8. Click OK.

  9. To register the proper deployment target (cluster or server) for the system REST endpoints for each of the widgets you are using in Business Space, click REST service endpoint registration.

    The target that you select for a REST service endpoint type can set the scope of the data displayed in some widgets. Or, you might want to select a particular cluster or server for better performance or availability.

    If you are using Human Task Management widgets, you can select more than one REST service provider for a server or a cluster in the row for the Process Services and Task Services types. Select the provider with Name=Federated REST Services, the provider with Name=Business Process Choreographer REST services, or the provider with Name=BPD engine REST services. If you have tasks and processes running in both Business Process Choreographer and the business BPD engine, select the federated REST services. If you are using only processes and tasks running in the Business Process Choreographer (modeled in Integration Designer), select the Business Process Choreographer REST services. If you are using only processes and tasks running in the BPD engine (modeled in Process Designer), select the BPD engine.

    If you do not specify the target, the REST endpoint of this type is not registered with Business Space, and any widgets that need the REST service endpoint of this type will not be visible in Business Space.

    Save the configuration.

  10. Run the scripts to configure the Business Space database tables before starting the deployment environment or the clusters. The scripts were generated when you completed the configuration. See Configure the Business Space database.


If you are using Oracle, the password of the authentication alias of the Business Space data source is set to same as the Business Space schema name. The default value of the schema is IBMBUSSP. When you configure the Business Space component, you can specify a different schema on the administrative console or on the command line. In that case, the default password is the same as the schema you specify. To use a different password for the Business Space user name, use the administrative console to updated JDBC Resources: Find the data source jdbc/mashupsDS. Modify the value of the authentication alias to make it match the password of the Business Space schema name. Save changes and restart the server.

The Business Space component uses a proxy component to connect to your REST services. When REST services are not responsive, sometimes update the connection timeout settings to your REST services, depending on the performance of the REST service servers. See Change the timeout settings for the Business Space Ajax proxy.



Configure the Business Space Ajax proxy

You might want to modify the Business Space Ajax proxy for special considerations in Process Portal, such as changing timeout settings or blocking IP addresses for secure production environments. The Ajax proxy file, proxy-config.xml, is located in the following location if you are using the environment that is shipped with BPM:

profile_root/BusinessSpace/node_name/server_name/mm.runtime.prof/config/proxy-config.xml.

For issues with the Ajax proxy, see IBM Mashups tech notes at http://www-01.ibm.com/support/search.wss?tc=SSWP9P.

The Ajax proxy is configured to be closed by default but provides a default policy that allows access to all Business Space endpoints for Process Portal. Follow the steps in Adding proxy polices to the Business Space Ajax proxy to allow access for additional URLs, and follow the steps in Blocking IP addresses using the Business Space Ajax proxy to restrict access to specific IP addresses.

  1. Modify the proxy-config.xml file as needed.

    For example, if you are changing the timeout settings for the Business Space Ajax proxy, you modify the proxy:value for socket-timeout.

  2. Run the updateBlobConfig command using the wsadmin scripting client, designating the -serverName and -nodeName parameters for a stand-alone server or -clusterName for a cluster, -propertyFileName with the value of the path for the proxy-config.xml file, and -prefix with the value Mashups_.

    The following example uses Jython:

    AdminTask.updateBlobConfig('[-serverName server_name -nodeName node_name -propertyFileName "profile_root/BusinessSpace/node_name/server_name/mm.runtime.prof/config/proxy-config.xml" -prefix "Mashups_"]')

    AdminConfig.save()

    The following example uses Jacl:

    $AdminTask updateBlobConfig {-serverName server_name -nodeName node_name -propertyFileName "profile_root/BusinessSpace/node_name/server_name/mm.runtime.prof/config/proxy-config.xml" -prefix "Mashups_"}

    $AdminConfig save



Add proxy policies to the Business Space Ajax proxy

Add additional proxy policies to the proxy-config.xml file so that Process Portal works properly in a distributed environment. The Business Space Ajax proxy contains predefined policies to some IBM URLs, but is not open to all URLs. If you use resources from remote sites in Business Space, add new policies in the proxy-config.xml file following the formatting of one of the predefined policies, such as the <proxy:policy url="http://www-03.ibm.com/*" acf="none" basic-auth-support="true">, to allow content from the remote sites to work properly in the Web Feed widget and the Google Gadgets widget.

If you had a previous version of Business Space, and you want the Ajax proxy to continue to be open to all URLs as it was in the previous version, change <proxy:policy url="endpoint://*" acf="none" basic-auth-support="true"> to <proxy:policy url="*" acf="none" basic-auth-support="true">.

  1. Open the proxy-config.xml file. For information about where to find the Ajax proxy file, see Configure the Business Space Ajax proxy.
  2. To restrict the Ajax proxy so that it allows access to only specific endpoints, make sure the proxy-config.xml file contains <proxy:policy url="endpoint://*" acf="none" basic-auth-support="true"> instead of <proxy:policy url="*" acf="none" basic-auth-support="true">.

  3. Add policies for remote content.

    The following predefined policies allow access to web feeds from specific remote sites so they work properly in the Web Feed widget. 

    <proxy:policy url="http://www.ibm.com/*" acf="none" basic-auth-support="true">
<proxy:actions>
<proxy:method>GET</proxy:method>
</proxy:actions>
</proxy:policy>

<proxy:policy url="http://www-03.ibm.com/*" acf="none" basic-auth-support="true">
<proxy:actions>
<proxy:method>GET</proxy:method>
</proxy:actions>
</proxy:policy>

<proxy:policy url="http://www.redbooks.ibm.com/*" acf="none" basic-auth-support="true">
<proxy:actions>
<proxy:method>GET</proxy:method>
</proxy:actions>
</proxy:policy>

    To allow access to additional web feeds, Google Gadgets, or other remote content, add a policy like the following example: 

    <proxy:policy url="http://your_URL" acf="none" basic-auth-support="true">
<proxy:actions>
<proxy:method>GET</proxy:method>
</proxy:actions>
</proxy:policy>

  4. Complete the Ajax proxy configuration to fit the environment. See Configure the Business Space Ajax proxy.



Change the timeout settings for the Business Space Ajax proxy

Process Portal uses a proxy component to connect to your REST services. If REST services are not responsive, update the connection timeout settings to your REST services, depending on the performance of the REST service servers. If the REST service connections are timing out, update the following settings.

If you are using the Business Space environment that is shipped with your business process management product, the socket-timeout value is set to 30 seconds by default. Change it to an appropriate value for your situation.

If you are using Business Space with WebSphere Portal, the socket-timeout value is set to 10 seconds by default. Change it to an appropriate value for your situation (30 seconds, if you are using IBM Business Process Manager administration widgets).

  1. Open the proxy-config.xml file. For information about where to find the Ajax proxy file, see Configure the Business Space Ajax proxy.
  2. Change the proxy:value for socket-timeout. The time is specified in milliseconds. 
    <proxy:meta-data>
 <proxy:name>socket-timeout</proxy:name>
 <proxy:value>30000</proxy:value>
</proxy:meta-data>

  3. Complete the Ajax proxy configuration to suit the environment. For information, see Configure the Business Space Ajax proxy.



Blocking IP addresses using the Business Space Ajax proxy

The Ajax proxy forwards requests from widgets to BPM and target servers, if the servers are remote from the BPM server. The Ajax proxy is configured to be closed by default but provides a default policy that allows access to all endpoints. You can configure the Ajax proxy to restrict access to specific IP addresses. The Ajax proxy is configured to be closed by default but provides a default policy that allows access to all Business Space endpoints. Follow the steps in Add proxy polices to the Business Space Ajax proxy to allow access for additional URLs, and follow the steps below to restrict access to specific IP addresses.

To restrict access to specific IP addresses, you can edit the Ajax proxy to filter IP addresses to allow or deny access. You define blacklist or whitelist rules in the proxy-config.xml file.

  1. Open the proxy-config.xml file. For information about where to find the Ajax proxy file, see Configure the Business Space Ajax proxy.

  2. Add filter rules that allow or deny access.

    To define a blacklist rule for a particular IP address or set of addresses, use a proxy:deny element. To define a whitelist rule for a particular IP address or set of addresses, use a proxy:allow element. The filter rules are applied in order, with the last applicable filter rule taking precedence over previous filter rules.

    Add the <proxy:ipfilter> information under the proxy rules of the proxy-config.xml file (after proxy policies and before </proxy-rules>). 

    <proxy:ipfilter>
<proxy:deny>9.6.0.0/255.255.0.0</proxy:deny>
<proxy:allow>9.6.1.0/255.255.255.0</proxy:allow>
<proxy:deny>9.6.1.4</proxy:deny>
</proxy:ipfilter>

    In this example, the IP filter performs the following filters:

    • blocks all 9.6.*.* IP addresses
    • allows 9.6.1.* but blocks the specific IP address 9.6.1.4

    So, in this case, the proxy would not allow access to IP address 9.6.2.5 or 9.6.120.7 and would respond with the following message: BMWPX0018E: The specified target hosts IP-address is prohibited by rule.

    The proxy would allow access to 9.6.1.5 or 9.6.1.120 but would deny access to 9.6.1.4.

    As you add new filter rules, you can combine them in several ways, but the proxy always handles them in order. The last matching rule will always take effect, regardless of any allow and deny rules that come before it.

  3. Complete the Ajax proxy configuration to suit the environment. For information, see Configure the Business Space Ajax proxy.


10. Extend a network deployment environment

After creating the network deployment environment, you can extend the environment using BPMConfig or by using the Deployment Environment wizard.

You can isolate user access for multiple deployment environments in your IBM Business Process Manager configuration. See Isolating user access for multiple deployment environments.


Extend a network deployment environment for a DB2 database server

Extend the network deployment environment to work with a DB2 database server.


Use the Deployment Environment wizard

After performing the installation and creating the deployment manager, custom (managed node) profiles, and a deployment environment, you can extend a network deployment configuration based on the topology pattern templates packaged with the software. You can also extend the deployment by adding cluster members to a cell or adding multiple deployment environments.

To extend the deployment environment:

  1. Log on to the administrative console. Ensure the user has appropriate privileges to update the deployment environment.

  2. Click Servers > Deployment Environments > Deployment_Environment_Name.

  3. Use the various options in the administrative console to extend the deployment environment.


Create the Advanced Process Center deployment environment

Create a Process Center deployment environment to store, run and administer process applications and toolkits that are developed in Process Designer and Integration Designer. You can create more than one deployment environments in the same cell using the Deployment Environment wizard. However, you can create only one Process Center-based deployment environment in a single cell.

Ensure that you have completed the following tasks: