This was a key feature that had been absent from the start of the REST API operations using groovy. Currently, when a planner performs a REST job, it executes so without using the planner’s access and instead uses the user id (Admin Access) that is linked with the REST Connection.

This helps us most of the time when we want to use the admin user’s access privileges instead of the current user’s access. particularly, while performing privileged Groovy functions like running data maps and many other jobs.

This creates few basic gaps:

• The current user does not have access to user variables or any other user-specific data.
• Following existing application user security despite using REST Jobs for execution

Impersonation can be carried out using either the current user who initiates the job or any other accessible constant user id.

EXECUTING A BUSINESS RULE

I created a custom function which allows impersonate ID as an optional input. If not specified, the system automatically gets the user id from the connection manager.

void executeJob (String job, String impersonateId = null) {		 
	Connection connection = operation.application.getConnection('localHost')
	if (impersonateId) {
		connection.impersonate(impersonateId)
	}
	String latestVersion = getLatestVersion(connection)
	String appName = getApplicationName(connection, latestVersion)
	String targetUrl = "/HyperionPlanning/rest/$latestVersion/applications/$appName/jobs"         
	HttpResponse<String> jsonResponse = connection.post(targetUrl).header("Content-Type", 'application/json').body(job).asString()
	validateJobCompletion(connection,targetUrl,jsonResponse)   	  	      
}

Please take note that I built the custom functions getLatestVersion() and getApplicationName(). I oppose hard-coding values because they frequently change.

I am executing the below rule using the executeJob function as mentioned above.

CASE 1 – EXECUTING ‘LAUNCH’ ACCESS BUSINESS RULE

Execution code:

executeJob('{"jobType":"Rules", "jobName" : "Sample Groovy Rule",   "parameters": {}}', operation.user.name)

Output from Job Console:

CASE 2 – EXECUTING ‘NO LAUNCH’ ACCESS BUSINESS RULE

I made ‘No Launch’ for few users on the business rule security and tried to execute the same rule again by using impersonation.

Output from Job Console:

The REST end point is not available for the current user and it returns as a bad request during execution.

CONCLUSION:

When working with multiple pods, this functionality is useful because it allows us to execute business rules from one instance into multiple instances without compromising the security of the application artefacts. Additionally, this facilitates in transferring user preferences from one instance to another for the current user and much more. I hope you find this information useful.