Guidelines for configuring WSO2 API-Manager workflows in a clustered environment

1) Work flow server URLs of site.json file should be updated with the correct port of the Business Process Server considering its port offset.(Work flow related configuration files by default contain port values assuming that the BPS port offset is 2.)

If BPS and API-Manager are required to be pointed to the same user store,  the workflow admin of the publisher node can be used, thus eliminating the need for a dedicated workflow node.
Since in a typical scenario the workflow admin will be from the same user store as APIM, we can use the workflow admin residing in the publisher node instead of having it separately.
Publisher node is recommended to be used here since it is an administrative level task and the publisher node is meant to reside within a private network.

In this case the URLs of <APIM_PUBLISHER_HOME>/repository/deployment/server/jaggeryapps/admin-dashboard/site/conf/site.json need to be updated.

If work flow admins are not from the API-Manager user store, have a seperate node for the workflow admin.
A dedicated node is only required if workflow admin users reside in a separate user store. In this case APIM and BPS will be pointed to different user store.

In this case the URLs of  <APIM_WORKFLOW_HOME>/repository/deployment/server/jaggeryapps/admin-dashboard/site/conf/site.json need to be updated.

If a workflow admin user role needs to be defined, add it under 'allowedRoles'.
eg:  "allowedRoles":"wfadmin"
Once this change is done, only users with the given role will be allowed to log in to the work flow admin dashboard.

2) Copy <APIM_HOME>/business-processes/epr folder to <BPS_HOME>/repository/conf

3) Make the following changes in the .epr files of <BPS_HOME>/repository/conf/epr

Change the following in case the default admin user has been changed.
<authorization-username>
<authorization-password>

The WorkFlowCallBackService endpoints of the following files should be pointed to the gateway :
<BPS_HOME>/repository/conf/epr/ApplicationCallbackService.epr  
<BPS_HOME>/repository/conf/epr/RegistrationCallbackService.epr  
<BPS_HOME>/repository/conf/epr/SubscriptionCallbackService.epr  
<BPS_HOME>/repository/conf/epr/UserSignupProcess.epr


The Service endpoints of the following files should be pointed to the Business Process Server :
<BPS_HOME>/repository/conf/epr/ApplicationService.epr          
<BPS_HOME>/repository/conf/epr/RegistrationService.epr          
<BPS_HOME>/repository/conf/epr/SubscriptionService.epr         
<BPS_HOME>/repository/conf/epr/ UserSignupService.epr

4) Update the port of the WSDL files of <API_MANAGER_HOME>/business-processes/<relevent workflow>/HumanTask with the correct port of the Business Process Server.

5) Upload the HumanTasks located in <API_MANAGER_HOME>/business-processes/<Relevent workflow>/HumanTask to the Business Process Server (Main -> Manage -> Human Tasks).
Alternatively you can copy it to <BPS_HOME>/repository/deployment/server/humantasks folder.

6) Upload the BPEL processes located in <API_MANAGER_HOME>/business-processes/<Relevent workflow>/BPEL to the Business Process Server. (Main -> Manage -> Processes).
Alternatively you can copy it to <BPS_HOME>/repository/deployment/server/bpel folder.

7) Point the endpoint of proxy service <APIM_GATEWAY_HOME>repository/deployment/server/synapse-configs/default/proxy-services/WorkflowCallbackService.xml of the gateway node to the 'Store' node of the cluster.

This proxy service is used to convert SOAP messages received by the Business Process Server  (which is unable to send JSON messages directly) to JSON, in order to call a rest endpoint.

8) Enable the executer relevant to the required workflow in the following file, by logging into the management console (the node does not matter since the  governance registry is shared)
Main -> Resources -> _system --> governance -> apimgt -> applicationdata -> workflow-extensions.xml.

Point the 'serviceEndpoint' to the Business Process Server.
Point the 'callbackURL' to the Gateway Node of the cluster.

The reason for pointing the callbackURL to the gateway node here is the fact that proxy service changes (eg: Security policy) are usually done in the gateway node. The store node does not get updated when such changes are concerned.