1. Installation Guide
  2. Cluster Considerations

6 Cluster Considerations

Modern business application requirements are classified by the abilities that the system must provide. This list of abilities such as availability, scalability, reliability, audit ability, recoverability, portability, manageability, and maintainability determine the success or failure of a business.

With a clustered system many of these business requirement abilities gets addressed without having to do lots of development work within the business application. Clustering directly addresses availability, scalability, recoverability requirements which are very attractive to a business. In reality though it is a tradeoff, clustered system increases complexity, is normally more difficult to manage and secure, so one should evaluate the pros and cons before deciding to use clustering.

Oracle provides many clustering solutions and options; those relevant to BDI are Oracle database cluster (RAC) and WebLogic Server clusters.

Scaling BDI

BDI needs to be scaled horizontally to handle large number of concurrent jobs. Single instances of Process Flow can be used since they are not resource intensive. Job Admin can be very resource intensive. To handle large number of concurrent jobs, multiple instances of Job Admin can be used to distribute jobs. WebLogic Server cluster that consists of multiple managed server instances provide horizontal scalability for Job Admin.

BDI on Cluster

As recommended above, for scaling BDI for large number of jobs, BDI components should be deployed to cluster. Following are some considerations to be taken into account when deploying BDI on cluster.

Logging

Issue

The "System Logs" tab in Process Flow and Job Admin UIs show only logs from the server that UI is connected to.

Solution

Use a common log directory for each of the BDI components.

BDI components use the following directory structure for creating log files.

$DOMAIN_HOME/logs/<server name>/<app name>

Example

$DOMAIN_HOME/logs/server1/rms-job-admin.war

$DOMAIN_HOME/logs/server2/rms-job-admin.war

  1. Create a common log directory (e.g. /home/logs/jobadmin) for each BDI application.

  2. Create symbolic links to the common log directory for each server using the below command from $DOMAIN_HOME/logs directory.

    ln -s  /home/logs/jobadmin
       server1/rms-job-admin.war
ln -s /home/logs/jobadmin
       server2/rms-job-admin.war

  3. If the directory $DOMAIN_HOME/logs/<server>/<app> already exists, it needs to be deleted before symbolic link is created.

  4. App needs to be restarted after symbolic link is created.

When WebLogic managed servers are in different machines a shared network disk has to be used.

Update Log Level

Issue

When log level is updated through UI or REST end point, it updates the log level only on the server it is connected to.

Solution

Log level needs to be updated through the URL of all the nodes in the cluster using UI or REST endpoint.

Example

http://server1:port1/bdi-rms-batch-job-admin/resources/system-setting/system-logs

http://server2:port2/bdi-rms-batch-job-admin/ resources/system-setting/system-logs

Create/Update/Delete System Options

Issue

When system options are created/updated/deleted using UI or REST end point, the changes are reflected only on the server that client is connected to.

Solution

The reset-cache REST endpoint needs to be invoked on the other nodes in the cluster for that application in BDI.

Example

http://server1:port1/bdi-rms-batch-job-admin/ resources/system-setting/reset-cache

Use curl command to reset cache as:

curl --user userId:password -i -X POST -H "Cot-Type:application.json"  	
http://server1:port1/rms-batch-job-admin/resources/system-setting/reset-cache

Create/Update/Delete System Credentials

Issue

When system credentials are created/updated/deleted using REST endpoint, the credentials are created/updated/deleted only on the server that client is connected to.

Solution

The REST endpoint that creates/updates/deletes credentials need to be invoked on all the nodes in the cluster for that application in BDI.

Example

http://server1:port1/rms-batch-job-admin/resources /system-setting/system-credentials
http://server2:port2/rms-batch-job-admin/resources /system-setting/system-credentials
 
	Use curl command to create credentials on other nodes in the cluster as:
 
	curl --user userId:password -i -X PUT -H "Content-Type:application/json" 
	http://server1:port1/bdi-rms-batch-job-admin/resources/system-setting/system-credentials  
	-d '{"userAlias":"rmsappJobAdminBaseUrlUserAlias", "userName":"rmsjobadmin" , 	"userPassword":"xyzxyz"}'

Use curl command to update credentials on other nodes in the cluster as:

	curl --user userId:password -i -X POST -H "Content-Type:application/json" 	http://server1:port1/bdi-rms-batch-job-admin/resources/system-setting/system-credentials
	 -d '{"userAlias":" reimappJobAdminBaseUrlUserAlias", "userName":"reimjobadmin" , 	"userPassword":"wwwqqqq"}'

Use curl command to delete credentials on other nodes in the cluster as:

	curl --user userId:password -i -X DELETE  -H "Content-Type:application/json" 
	http://server1:port1/bdi-rms-batch-job-admin/resources/system-setting/system-credentials
	 -d '{"key":"rmsappJobAdminBaseUrl"}'

Auto Purge Process Flow Infra Data

A thread runs every hour to purge data from Process Flow infra tables which have crossed configured purge delay.

Below steps are followed to purge data from BDI Process Flow tables:

  1. Check if the "autoPurgeProcessFlowInfraData" flag is available and is set to true. If yes, continue with the next step. Default "autoPurgeProcessFlowInfraData" to true if it is missing in the System options table.

  2. Get the value of "autoPurgeProcessFlowInfraDataDelay" from the System option table. Default delay to 60 days if it is missing in the System Options table.

  3. Query the table BDI_PROCESS_EXEC_INSTANCE to get PROCESS_EXECUTION_ID whose PROCESS_EXEC_START_TIME has exceeded the delay configured and is in completed state. This list decides records that can be purged from Process flow table.

  4. Purge data from BDI_PROCESS_CALL_STACK whose INVOCATION_TIME has exceeded the delay configured.

  5. Purge data from BDI_ACTIVITY_EXEC_INSTANCE whose ACTIVITY_EVENT_TIME TIME has exceeded the delay configured.

  6. Purge data from BDI_EMAIL_NOTIFICATION whose EMAIL_NOTIFICATION_DATETIME has exceeded the delay configured.

Follow below steps to update auto purge configurations.

  1. Turn OFF/ON auto purge:

  2. Login to BDI Process Flow admin UI with valid Credentials.

  3. Navigate to "Manage Configurations" tab. Select "System Options".

  4. Update the value of "autoPurgeProcessFlowInfraData" to true/false to turn off/on auto purge.

  5. If "autoPurgeProcessFlowInfraData" is not available, add it using the "Create New System Options" option.

Update delay:

  1. Login to the BDI batch job admin UI with valid Credentials.

  2. Navigate to the "Manage Configurations" tab. Select "System Options".

  3. Update the value of "autoPurgeProcessFlowInfraDataDelay" to the desired delay.

  4. If "autoPurgeProcessFlowInfraData" is not available, add it using the "Create New System Options" option.