Completing configuration for Business Process Choreographer

1. Check the Business Flow Manager properties. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer and click Business Flow Manager > Configuration. In particular, check the properties that are listed in the following table. For more information about the settings on this panel, see Business Flow Manager settings.

   Table 1. Business Flow Manager settings

   Property	Description
   Retry limit	Specifies the maximum number of times to try to process a message. When the limit is reached, the message is sent to the hold queue.
   Retention queue limit	The maximum number of messages that can be stored in the retention queue. When the limit is reached, the messages are sent to the queue for internal messages again and the Business Flow Manager switches into quiesce mode.
   Enable Common Event Infrastructure logging	Common Event Infrastructure logging (CEI) logging. Enable this setting if you want to emit CEI events.
   Enable audit logging	Audit logging for this Business Flow Manager. Enable this setting to log audit events
   Business Process Navigation Performance	A long-running process spans multiple transactions. Before WebSphere Process Server Version 7.0, the default was for transactions to trigger by a Java™ Messaging Service (JMS) message. Since version 7.0, the default is to use work-manager-based navigation, which provides better performance. If you are using JMS-based navigation, you can improve the performance of process navigation, by configuring Business Flow Manager to use the work-manager-based implementation for triggering transactions. If you were already using work-manager-base-navigation make sure that your settings match the source environment.

2. Check the cleanup service settings for the Business Flow Manager. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Business Flow Manager, then in the Additional Properties section, click Cleanup Service Settings > Configuration.

   It is important to configure the cleanup service in the new environment. Otherwise, if completed instances are not deleted and the database fills up, there is the risk of performance issues.

3. Check the Business Flow Manager custom properties. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Business Flow Manager, then in the Additional Properties section, click Custom properties.

   Ensure that the new environment contains all the custom properties that are in the migration source environment, and make sure that they have the same values.

1. Check the Human Task Manager properties. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Human Task Manager > Configuration. In particular, check the properties that are listed in the following table. For more information about the settings on this panel, see Human Task Manager settings.

   Table 2. Human Task Manager settings

   Properties	Description
   Email service	These settings are used to customize escalation emails. You might need to change the URLs to match the new environment, for example, if the host name changed.
   State observers	These settings enable CEI events, log audit events, and task history events to be emitted.
   People resolution section	If you use people resolution, re-create all the settings for people resolution.
   People query refresh schedule	The schedule for refreshing people queries.
   Timeout for people query result	The duration in seconds that the results of a people query are considered to be valid. After this duration, the people query results will expire.
   Enable group work items	Enable this setting if you want Human Task Manager queries and API methods to consider group work items. Queries are faster if group work items are not enabled.
   Enable substitution	Enable this setting if people are allowed to perform a substitution action for a user ID that is not their own.
   Restrict substitute management to administrators	Enable this setting if only administrators can perform staff substitution. If this option is selected, an exception is generated if a non-administrator attempts to perform a substitution action to a different user.
   Enable work basket-based people assignment and routing	Enable this setting to use work baskets to assign tasks to people.
   Shared work item management section	If you use shared work items, re-create the settings for shared work item management.
   Shared work item cleanup schedule	The schedule for deleting shared work items and unused cached people query results. Do not use the same schedule as the people query refresh schedule.
   Duration until deletion of unused shared work items	The duration in hours that a shared work item must be unused before it is eligible for deletion.
   Shared work item cache size	The size of the cache for shared work items.

2. Check the cleanup service settings for the Human Task Manager. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer and click Human Task Manager, then in the Additional Properties section, click Cleanup Service Settings > Configuration.

   It is important to configure the cleanup service in the new environment. Otherwise, if completed instances are not deleted and the database fills up, there is the risk of performance issues.

3. Check the Human Task Manager custom properties. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer and click Human Task Manager, then in the Additional Properties section, click Custom properties.

   Ensure that the new environment contains all the custom properties that are in the migration source environment, and make sure that they have the same values.

1. Configure the same people directory provider that you used on the migration source.
   1. If you used the LDAP people directory provider, perform the actions described in Configuring the LDAP people directory provider.
   2. If you used the Virtual Member Manager people directory provider, perform the actions described in Configuring the Virtual Member Manager people directory provider
2. If you applied any changes to the default XSL transformation files (EverybodyTransformation.xsl, LDAPTransformation.xsl, SystemTransformation.xsl, VMMTransformation.xsl, and UserRegistryTransformation.xsl) that are in the install_root\ProcessChoreographer\Staff directory, then you must reapply your changes to the IBM Business Process Manager V8.5 versions of these files after migration.

   In a network deployment environment, the transformation files must be available on the deployment manager and on the managed nodes (if they are on different computers). Make sure that they all use the same version of the transformation files.

   To find the transformation files that you are using in the source environment, check the value of the transformation file path that is specified in the people directory configuration. If the transformation file path is install_root\ProcessChoreographer\Staff directory, you are using the default files. Otherwise, you are using custom transformation files that you must manually copy to the target environment and reconfigure in the people directory configuration.

   Note: Custom XSL transformation files must be copied manually, depending on the exact value of the transformation file path that is specified in the earlier version of the people directory configuration (previously known as the staff plug-in configuration).
3. If you used the substitution feature and substitution information is stored in one of the user repositories that are configured for VMM, you must add the new properties for substitutionStartDate and substitutionEndDate to your repository. The steps that you must perform depend on whether you store the substitution information in the VMM file registry or in the VMM property extension registry:

   For the VMM file registry:

   1. Add the substitutionStartDate and substitutionEndDate properties to the definition of the PersonAccount entity type in the wimxmlextension.xml file. In a network deployment environment, edit the file on the deployment manager.

      The file is in profile_root\config\cells\cellName\wim\model.

      Extend the file to include the new properties:

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

   2. The changes become effective after the deployment manager is restarted.

   For the VMM property extension registry:

   1. Check that the substitution properties isAbsent and substitutes are defined for the property extension repository. If they were not defined before migration, no substitution information was stored in the VMM property extension repository, and this migration step is not required.

      Change to the directory install_root\bin and enter the following commands in either local mode or connected mode. In a network deployment environment, enter the commands on the deployment manager.

      wsadmin -username admin -password adminPassWord
      $AdminTask listIdMgrPropertyExtensions

   2. Add the new properties substitutionStartDate and substitutionEndDate to the property extension repository configuration by entering the following commands:

      $AdminTask addIdMgrPropertyToEntityTypes 
         {-name substitutionStartDate 
          -dataType String 
          -isMultiValued false 
          -entityTypeNames PersonAccount 
          -repositoryIds LA}
      
      $AdminTask addIdMgrPropertyToEntityTypes 
         {-name substitutionEndDate 
          -dataType String 
          -isMultiValued false 
          -entityTypeNames PersonAccount 
          -repositoryIds LA}

   3. The changes become effective after the deployment manager is restarted.
   4. Verify that the new properties were added to the property extension repository configuration by entering the following command:

      $AdminTask
      listIdMgrPropertyExtensions

1. If you used Business Space to access Business Process Choreographer, and you have not configured it to use the federated REST APIs, you can do that configuration now. To register the new endpoints with Business Space, using the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, click Business Space Configuration, then under Additional Properties click REST service endpoint registration and for Service Endpoint Target verify that Process services and Task services are selected.
2. If you migrated to a different computer, you must make sure that the REST API endpoint references for Business Process Choreographer Explorer and Business Space point to the correct host name and port number of the server. In a clustered environment, if you use a proxy server or HTTP server in front of several application servers, you can achieve load balancing and high availability by directing the REST requests to that server.
   1. To change the context root for the REST API web modules, in the administrative console:
      1. Click Applications > Application Types > WebSphere enterprise applications > BPEContainer_suffix > Context Root for Web Modules, where suffix is the cluster_name where Business Process Choreographer is configured.
      2. Make sure that the context root for the web module BFMRESTAPI is correct and unique.
      3. Click Applications > Application Types > WebSphere enterprise applications > TaskContainer_suffix > Context Root for Web Modules
      4. Make sure that the context root for the web module HTMRESTAPI is correct and unique.

   2. To change the endpoint references for Business Process Choreographer Explorer, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Business Process Choreographer Explorer, then in the list of configured Business Process Choreographer Explorer instances, click one instance to edit it and change the values for Business Flow Manager REST API URL and Human Task Manager REST API URL. Repeat this step as necessary for the other instances.

   3. To change the endpoint references for Business Space:

      1. To change the endpoint for the Business Flow Manager, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Business Flow Manager, and under Additional Properties click REST Service Endpoint.
      2. To change the endpoint for the Human Task Manager, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Human Task Manager, and under Additional Properties click REST Service Endpoint.
3. The JAX web services APIs were configured during migration. You might want to map the web modules to a web server and change the context root for the web modules of the JAX web services APIs.
   To change the context root, in the administrative console:

   1. Click Applications > Application Types > WebSphere enterprise applications > BPEContainer_suffix > Context Root for Web Modules, where suffix is the cluster_name where Business Process Choreographer is configured.
   2. Make sure that the context root for the web module BFMJAXWSAPI is correct and unique.
   3. Click Applications > Application Types > WebSphere enterprise applications > TaskContainer_suffix > Context Root for Web Modules
   4. Make sure that the context root for the web module HTMJAXWSAPI is correct and unique.

1. To identify whether your system contains multiple versions of the predefined human tasks, in the administrative console, click Applications > Application Types > WebSphere enterprise applications.
2. Locate all applications with names of the following patterns:
   • HTM_PredefinedTasks_Vnnn_cluster_name.ear
   • HTM_PredefinedTaskMsg_Vnnn_cluster_name.ear
   Where

   nnn

   is the version number when the application was last updated, for example 700. If the newest version of these applications looks older than the current release, it just means that it did not change since that version. The important thing is whether there are multiple versions of these applications.

   cluster_name

   is the name of the cluster.

3. If there are multiple versions of the predefined human tasks, make a note of the old versions. When there are no old instances still running, you can delete all the old instances, and then undeploy the old version of the applications. Undeploying the old applications helps to reduce the server start time.

1. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Human Task Manager > Configuration.
2. Under Advanced people assignment and categorization, select the features that you want to enable.

1. Import your application.
2. Replace the following files in the WEB-INF/lib directory of your project:
   • bfmclientmodel.jar
   • htmclientmodel.jar
   • bpcclientcore.jar
   • bpcjsfcomponents.jar
   • bpeapi.jar
   • taskapi.jar
   In IBM Business Process Manager Advanced, all of these files are in the following directory:

   install_root\ProcessChoreographer\client

3. Optional: Remove the following unnecessary files from the WEB-INF/lib directory of your project if they are there:
   • bpe137650.jar
   • icu4j_3_4_1.jar
   • task137650.jar
4. Export your application.

If you want to maintain the previous behavior for both types of loop in migrated environments, you must add a new custom property manually. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name or Servers > Server Types > WebSphere application servers > server_name, then under Business Integration, expand Business Process Choreographer, and click Business Flow Manager > Custom Properties.. Then add a property named InlineHumanTasks.KeepOverMultipleWhileLoopIterations with the value true. When you no longer want the old behavior, you must delete the custom property.

1. In the administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name, then under Business Process Manager, expand Business Process Choreographer, and click Business Flow Manager > Custom Properties.
2. Click New to add a custom property.
3. Enter the name Compat.SCAMonitoringForBFMAPI and the value true.
4. Save the changes. The setting will be activated the next time that you restart the server or cluster where Business Process Choreographer is configured.