Security configuration in TaskFlows (EPMA 11.1.2) - Cookbook style
TaskFlows in Enterprise Performance Management Architect (EPMA) can be used to sequence any number of EPMA operations such as dimension updates, application deployments, and data synchronisations. They are also able to execute batch jobs and send emails, all of which makes them potentially useful for automation and integration of EPMA applications.
TaskFlows can be scheduled by a built-in scheduler in TaskFlow Management, but there is also the option to run task flows ‘interactively’ (i.e. on-demand). For one particular client application, this was an attractive approach to delivering a capability to kick-off processes in-day on an ad-hoc basis, but we needed to ensure that some kind of security could be applied to the different task flows so that ‘run’ permissions could be assigned to the correct people for the correct TaskFlow.
Our client system was based on 11.1.2, and the procedure below is based on 220.127.116.11. I could not find much documentation around doing this on 11.1.2, and it appears that the controls around TaskFlow security have changed since 18.104.22.168. Therefore I decided to set up a simple PoC as described below.
The summary approach is as follows:
- Set up several simple TaskFlows
- Set up security roles (Create the aggregated HSS roles)
- Modify the Access Control to the TaskFlows
- Set up several users & provision them to have access to different roles
- Demonstrate the effect of these different levels of access
Set up some simple TaskFlows
TaskFlows can be created to run many different EPM processes such as cube deployment, data import/export, but for our example we are just going to get the TaskFlows to execute a simple batch file, which will write to an output file, which indicates that our TaskFlow has successfully run.
The administrator should have, as a minimum, the following roles provisioned in Shared Services, to be able to create TaskFlows:
TaskFlow administration is then accessed in EPMA, via ‘Navigate’ > ‘Application Library’, and then choose menu ‘Administration’ > ‘Manage Task Flows’, which will bring up the following screen:
From here, new TaskFlows can be created, and existing ones can be edited, deleted, scheduled and executed.
Below I have set up TaskFlow TF_1 to execute a batch job in Stage1.
This is done by selecting the processing tab & choosing ‘Hub’ from the ‘Application’ drop-down, ‘Execute’ from the ‘Action’ drop-down, and specifying the name of the batch file to execute.
(by default batch files are located in %HYPERION_HOME%\Common\Utilities, and output is routed to Oracle\Middleware\user_projects\domains\EPMSystem folder).
(Note, the example has Stage2 in it – TaskFlows can contain any number of Stages – this example has 2 stages purely as a result of experimentation – each stage simply executes a basic batch file to create an output file)
For the purposes of testing access control, I created the following 4 TaskFlows (by using the ‘Save As’ control) :
Now that we have set up several TaskFlows, we will set up some users to demonstrate access control. The first step is to create ‘aggregated roles’ in Shared Services (HSS) to allow each TaskFlow to have a different level of access, by associating it with different roles.
Set up security roles (Create the aggregated HSS roles)
The pre-defined HSS Administrator roles of ‘Manage TaskFlows’ & ‘Run TaskFlows’ will give default access to a user to run manage / run a new TaskFlow, until the access control of that TaskFlow is edited.
To satisfy our requirement to have differing levels of access we create different ‘aggregated’ roles in HSS, with different access levels. There are 2 access levels for TaskFlows
- ‘Manage’ access allows the user to create, delete, schedule & run TaskFlows
- ‘Run’ access allows the user to only run TaskFlows.
(Having no access, simply means that a user will only be able to ‘View’ TaskFlow status.)
For our example, we want to achieve the following access to TaskFlows TF_1 -> TF_4:
This requires us to create the following aggregated roles, which will eventually be associated with the specific TaskFlows :
Creation of aggregated roles is simple.
1. Log into HSS as admin, expand the ‘User Directories’, ‘Native Directories’ tree in the explorer and right-mouse-click on ‘Roles, and choose ‘New’:
2. This brings up the ‘Create Role’ dialog – we enter a Role name, and choose ‘HUB-11.1.2’ as the product group (each product group has its own list of relevant ‘Available Roles’, but TaskFlow related roles exist in the ‘HUB…’ group):
3. Select ‘Next’ and from the left hand list, select ‘Manage TaskFlows, and move it to the right hand list, and ‘Save’ :
4. For the Roles which will have Run access, we simply choose the ‘Run TaskFlows’ role from the left-hand list instead.
5. When we have finished creating all the new aggregated roles we should have a list in HSS like this:
The next task is to edit our TaskFlows to utilise these new roles.
Modify the Access Control to the TaskFlows
As admin, log into EPMA & navigate to the ‘Manage TaskFlows’ screen.
Select the TaskFlow TF_1 & choose ‘Access Control’:
Each TaskFlow has the option to set the role allowed for ‘Manage’ access and the role allowed for ‘Run’ access:
The drop-down for the ‘Manage Permission Role’ displays all roles (pre-defined and aggregated) that have ‘Manage TaskFlow’ level access:
The drop-down for the ‘Execute Permission Role’ displays all roles (predefined and aggregated) that have ‘Run TaskFlow’ level access:
You can see the Aggregated roles that we created earlier are available. The ‘Administrator…….Taskflow’ roles correspond to the predefined ‘Manage..’ and ‘Run..’ roles directly under the Administrator node in HSS:
So we can now associate our task flows with the different aggregated roles available, for both the ‘Manage’ & the ‘Run’ access level.
So for TaskFlow TF_1, we set the roles as follows:
The TaskFlows TF_2, 3 & 4 are configured as per the following table:
Now we need to provision our users to give then the correct level of access.
Set up several users & provision them to have access to different roles
Set up the example users (User1 -> User5) in HSS & provision them in the usual way as follows :
I have found that a user must be provisioned with ‘Create Integrations’ role as well as the ‘Manage’ or “Run’ roles, in order to get access to the ‘Manage TaskFlows’ screen.
(These are the roles required for each user in order to achieve the required access to the TaskFlows – it will be necessary to assign users to additional roles to achieve access rights to other parts of the product !)
Running a ‘Provisioning Report’ from HSS on the 5 users for Shared Services applications, we can see what their provisioning is:
Now we can login to EPMA for each of the 5 users and we can see the combined effect of the role creation, user provisioning & ‘Access Control’ configuration:
The pre-defined Shared Services roles ‘Manage TaskFlows’ and ‘Run TaskFlows’ apply by default to any new TaskFlows that are created, because new TaskFlows have the access control roles of ‘Administrator Manage Taskflow’ and ‘Administrator Execute Taskflow’ set by default. Any new TaskFlows with these default access control settings will only be available to users provisioned with the pre-defined Shared Services roles ‘Manage TaskFlows’ and ‘Run TaskFlows’. Conversely, any users provisioned only with these pre-defined Shared Services roles, would have access only to TaskFlows with these default access control settings
The ‘Create Integrations’ role that is required to give any user access to the ‘Manage Taskflows’ screen can be embedded into the aggregated roles, rather than provision the role to the user separately:
I found that If a user has roles with 'Manage TaskFlow' access to TaskFlow A, and 'Run TaskFlow' to TaskFlow B, when the user logs in they appear to have 'Manage TaskFlow' access to both TaskFlow A & B. This means that that user can delete TaskFlows that they were not intended to have ‘Manage TaskFlow’ rights to , so it would be best to avoid this scenario.
Finally I found that logging out of one user session and logging back in as another user, without closing down the browser session, had the effect that the second user’s privileges appeared to be the same as the first, even if their access was lower. I worked around this by exiting all browser sessions & clearing the browser cache in between logins. This could have been a local environment issue.
The Oracle library has the following guidance on TaskFlows and security relating to them:
http://docs.oracle.com/cd/E17236_01/epm.1112/hss_admin_1112200.pdf chapter 6 - Managing Roles, chapter 8 -Managing TaskFlows
http://docs.oracle.com/cd/E17236_01/epm.1112/epma_admin.pdf part IV, Using Task Automation