It is not an unusual FDMEE requirement for a user to be able to load data to a target application and have their access permissions honoured.
FDMEE is a data management product after all so it should not be a problem, well you would think so, if your target application is Financial Management then this is not an issue as security classes are checked when loading data so data can only be loaded to a member combination that the user has access to.
When the target is Essbase or Planning then things get a little more interesting, if you compare on-premise, hybrid and cloud then it can all get a little confusing.
I thought it would be a good idea to try and clear up any confusion and go through some examples of what happens when loading data at user level compared to admin level and what options are available to overcome these differences.
I am going to break this into two posts and in this first post look at the current situation with on-premise and hybrid and then in the next part concentrate on EPM cloud.
The examples I will be providing in terms of on-premise will be based on the latest 11.1.2.4 patches for FDMEE, Essbase and Planning. I am fully aware that the functionality in the cloud will be pushed down to on-premise at some point but you never know when that will happen and it is good to get an understanding of where we are currently at.
I will try to update this post to highlight any changes when they do occur.
So, let us start with Essbase and before even going near FDMEE I want to set the scene with simple examples of a user loading data and the security setup behind this.
First, we start with the Shared Services provisioning and the user has been granted the Filter role for the Essbase Sample application
A filter has been created that will only allow write access to the member combination 'Sales,100-10, Florida, Actual', there will no access to any other part of the database.
The filter is then applied to the provisioned user.
To show the filter is in operation I created a simple retrieve in Smart View.
The user should be able to submit data to the Sales member but not COGS.
Once submitted the data for Sales has been loaded and as expected no data has been loaded to COGS.
The user can also load data using a load rule and the same member combination is in the data load file.
The information window confirms data has been loaded to 1 cell and there were errors.
The data load error file has rejected the row containing the COGS member as the user has no access to it.
A quick retrieve in Smart View confirms this.
Now this is what you would expect to be possible in FDMEE but let us see.
A data load rule has been created to load data to the same member combination as the previous example.
The load method has been set to file.
The options available for ‘Load Method’ are either ‘File’ or ‘SQL’, if file is selected then a flat file is generated from the FDMEE database repository and then the file is loaded to the target Essbase database using an Essbase load rule, if SQL is chosen then data is loaded to Essbase directly from the FDMEE database repository using an Essbase SQL data load rule.
Let us first test the data load process using an admin user.
The full process run through without any problems and in the process log you can what is happening.
INFO [AIF]: Creating data file: \\fileshare\EPMSHARE\FDMEE\outbox\Sample_2682.dat
INFO [AIF]: Data file creation complete
DEBUG [AIF]: Created rule file: AIF0062
DEBUG [AIF]: Locked rule file: AIF0062
INFO [AIF]: Saved rule file to essbase server
DEBUG [AIF]: Unlocked rule file: AIF0062
The data load file is created in the FDMEE outbox location and then an Essbase data load rule is created so the file can be loaded to the Essbase database.
Further down the log you can see the process to load the data using the load rule.
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: admin
DEBUG [AIF]: Obtained connection to essbase cube: Basic
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0062
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0062
DEBUG [AIF]: Locked rule file: AIF0062
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: AIF0062
Another retrieve shows the data has been successfully loaded.
Now on to using the same user as earlier which we know can load data to the Essbase database.
There is no problem loading and mapping the file and in theory if FDMEE worked liked we should expect it to work then the Sales record should load and the COGS record should fail.
Running the export indicates there was a failure.
Investigating the process logs provides the reason for the failure.
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
ERROR [AIF]: com.essbase.api.base.EssException: Cannot open cube outline. Essbase Error(1022002): User [lhowlett@FUSIONAD] Does Not Have Correct Access for Command [OpenOutlineEdit]
At the point where the data load rule is created the error is generated due to incorrect access permissions, it is correct the user does not have access to create rules and open the outline in edit mode, the user only needs to load the data.
The errors can be replicated in EAS when a user tries to save a rules file or open the outline in edit mode.
To me the answer would be that an admin user would create the rule behind the scenes in FDMEE and then the standard user would then load the data using the rule, I have shown it is possible to do this earlier on in this post, I don’t quite know why it has been developed this way but I am sure there must be a reason.
I thought maybe a possible workaround would be to use a custom Essbase load rule so the load rule would not be created.
The Essbase load rule was added to target options in the FDMEE load rule
The export failed again.
In the message panel the following error is generated.
Error: 1051041 Insufficient privilege for this operation
The user should not have to lock and unlock the rule, the admin user could lock the rule then the user could load the data using the rule, the rule could then be unlocked by the admin user.
Once again I am not sure why it has been developed in this way in FDMEE but to me it should be possible to load data at user level and honour the security filter.
What about a workaround, well up to 11.1.2.3.520 the user would need to be provisioned with at least the ‘Database Manager ‘role for the Essbase application.
You wouldn’t want to be giving out that role to users that just want to load data but that is the way it goes before that release, luckily most should be running a newer release by now.
From 11.1.2.3.520 there is the property called 'Global User for Application Access which can be set at target application level in FDMEE.
If I provision a user with the ‘Database Manager’ role for the Sample application in Shared Services.
Now the user can be added to target application options in FDMEE.
Let us run the export again in the workbench with the same user as before.
This time the outcome is more positive and in the process logs:
DEBUG [AIF]: GlobalUserForAppAccess from Profile: SampleDBManager
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: SampleDBManager
DEBUG [AIF]: Obtained connection to essbase cube: Basic
INFO [AIF]: The default rule file will not be used as a custom rule file has been specified: FDMEE
DEBUG [AIF]: Resolved essbase rule file name for loading: FDMEE
DEBUG [AIF]: Fetching rule file from essbase server for data loading: FDMEE
DEBUG [AIF]: Locked rule file: FDMEE
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: FDMEE
We can see that the loading of data has now been overridden by the global user, this user has the permissions to create rules and lock and unlock so the data load runs through successfully.
The issue we have here is that the global user can load data to any member combination so we have lost that filter restriction we set earlier.
Unfortunately, that is the best that can be offered presently which I know is not ideal.
Moving on to planning and let us take a similar example with the same user.
The user is provisioned with the ‘Planner’ and ‘Essbase Write Access’ role for the sample Vision application.
Access permissions have been applied within the planning application and for direct Essbase access a filter has been automatically created for the user.
This time write access has been defined for the member combination ‘1110,110,Actual,Working’ and read access for ‘1150’.
The access permissions for the planning layer are confirmed to be working with a form.
A retrieve using an Essbase connections confirms the filters are working as expected.
On to FDMEE, a load rule was created which will load two rows of data from a flat file to the above member combination.
The load method was set to ‘Numeric Data only – File'
The property values available for a target planning application are:
I will go through the ‘All Data Types’ option shortly.
The load process was first tested with a user that is an administrator of the planning application.
The process log shows that the method of loading data is the same as when the target is an Essbase application.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: null
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: admin
DEBUG [AIF]: Obtained connection to essbase cube: Plan1
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0069
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0069
DEBUG [AIF]: Locked rule file: AIF0069
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: AIF0069
I think you know what is coming when we try to run the FDMEE export with a user provisioned as a planner.
Yes, it failed and no surprises with the error message.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: null
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
DEBUG [AIF]: Obtained connection to essbase cube: Plan1
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0069
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0069
ERROR [AIF]: com.essbase.api.base.EssException: Cannot lock olap file object. Essbase Error(1051041): Insufficient privilege for this operation
We are in the same position as when loading directly to Essbase target applications.
Just like with Essbase there is the option to set a global user.
A global user was added that has the administrator role assigned for the planning application.
The export was run again.
This time the export was successful and the process log confirms what is happening.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: planadmin
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: planadmin
DEBUG [AIF]: Obtained connection to essbase cube: Plan1
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0069
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0069
DEBUG [AIF]: Locked rule file: AIF0069
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: AIF0069
The global user overrides and loads the data, as it is an administrator loading the data the access permissions are ignored and all member combinations can be loaded.
There is another data load method available at data load rule level and that is ‘All Data Types’ which uses the outline load utility to load data through the planning layer.
The global user was removed and the export run again with the standard user.
Failed again, the process logs provide the reason behind the failure.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: null
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
DEBUG [AIF]: loadMethod: OLU
Unable to obtain dimension information and/or perform a data load: java.lang.RuntimeException: You must be an Administrator to use the Hyperion Planning Adapter.
Back to square one again as you need to be an administrator to operate the outline load utility.
If the planning application administrator is added back in as the global user, then the export is successful.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: planadmin
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: planadmin
DEBUG [AIF]: loadMethod: OLU
INFO [AIF]: Number of rows loaded: 2, Number of rows rejected: 0
The global user overrides and loads the data but once again you lose out on the member level security so not great, in the next post you will see how this load method differs quite considerably in the cloud.
Finally, I want to quickly cover off the user requirements for hybrid which means any integrations between on-premise FDMEE and EPM Cloud.
When you add a cloud application as a target the cloud user credentials are entered and whenever authentication is required with the cloud these credentials are called upon.
As an example, I added a user which has been provisioned with the power user role for the cloud application.
I ran a simple integration which will which extracts data from an on-premise application and loads to a cloud application, the process failed and the logs contained the following information.
INFO [AIF]: Uploading data file to PBCS: \\fileshare\EPMSHARE\FDMEE\outbox\Vision_1991.dat
ERROR [AIF]: java.io.FileNotFoundException: Response: 401: Unauthorized for url: https://cloudinstance/interop/rest/11.1.2.3.600/applicationsnapshots/Vision_1991.dat/contents?q={chunkSize:63,isFirst:true,isLast:true,extDirPath:"inbox"}
The process failed at the point where the on-premise extracted file is uploaded to the cloud instance using the REST API, the 401 error gives an indication it might be user related.
Uploading a file using EPM Automate with the same user returns an error that the user has insufficient privileges.
The documentation states the following.
“EPM Automate Utility enables Service Administrators to automate many repeatable tasks”
So, to be able to upload the file from on-premise to cloud requires the service administrator role.
After updating the cloud user to one that has the service administrator role the hybrid integration was successful.
The process logs show that once the file has been loaded to the cloud instance the remaining steps are performed by the default cloud admin account so overrides the user configured in FDMEE.
INFO [AIF]: Cloud Mode: CLOUD, Resolved user name for application access: epm_default_cloud_admin
Well that about covers all I wanted to in this post, in summary if you are looking to implement user defined security for data loading to Essbase and Planning then you’re going to be disappointed, this is no doubt going to change in the future and in the next post I will cover how EPM cloud currently differs from on-premise in this respect.
FDMEE is a data management product after all so it should not be a problem, well you would think so, if your target application is Financial Management then this is not an issue as security classes are checked when loading data so data can only be loaded to a member combination that the user has access to.
When the target is Essbase or Planning then things get a little more interesting, if you compare on-premise, hybrid and cloud then it can all get a little confusing.
I thought it would be a good idea to try and clear up any confusion and go through some examples of what happens when loading data at user level compared to admin level and what options are available to overcome these differences.
I am going to break this into two posts and in this first post look at the current situation with on-premise and hybrid and then in the next part concentrate on EPM cloud.
The examples I will be providing in terms of on-premise will be based on the latest 11.1.2.4 patches for FDMEE, Essbase and Planning. I am fully aware that the functionality in the cloud will be pushed down to on-premise at some point but you never know when that will happen and it is good to get an understanding of where we are currently at.
I will try to update this post to highlight any changes when they do occur.
So, let us start with Essbase and before even going near FDMEE I want to set the scene with simple examples of a user loading data and the security setup behind this.
First, we start with the Shared Services provisioning and the user has been granted the Filter role for the Essbase Sample application
A filter has been created that will only allow write access to the member combination 'Sales,100-10, Florida, Actual', there will no access to any other part of the database.
The filter is then applied to the provisioned user.
To show the filter is in operation I created a simple retrieve in Smart View.
The user should be able to submit data to the Sales member but not COGS.
Once submitted the data for Sales has been loaded and as expected no data has been loaded to COGS.
The user can also load data using a load rule and the same member combination is in the data load file.
The information window confirms data has been loaded to 1 cell and there were errors.
The data load error file has rejected the row containing the COGS member as the user has no access to it.
A quick retrieve in Smart View confirms this.
Now this is what you would expect to be possible in FDMEE but let us see.
A data load rule has been created to load data to the same member combination as the previous example.
The load method has been set to file.
The options available for ‘Load Method’ are either ‘File’ or ‘SQL’, if file is selected then a flat file is generated from the FDMEE database repository and then the file is loaded to the target Essbase database using an Essbase load rule, if SQL is chosen then data is loaded to Essbase directly from the FDMEE database repository using an Essbase SQL data load rule.
Let us first test the data load process using an admin user.
The full process run through without any problems and in the process log you can what is happening.
INFO [AIF]: Creating data file: \\fileshare\EPMSHARE\FDMEE\outbox\Sample_2682.dat
INFO [AIF]: Data file creation complete
DEBUG [AIF]: Created rule file: AIF0062
DEBUG [AIF]: Locked rule file: AIF0062
INFO [AIF]: Saved rule file to essbase server
DEBUG [AIF]: Unlocked rule file: AIF0062
The data load file is created in the FDMEE outbox location and then an Essbase data load rule is created so the file can be loaded to the Essbase database.
Further down the log you can see the process to load the data using the load rule.
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: admin
DEBUG [AIF]: Obtained connection to essbase cube: Basic
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0062
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0062
DEBUG [AIF]: Locked rule file: AIF0062
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: AIF0062
Another retrieve shows the data has been successfully loaded.
Now on to using the same user as earlier which we know can load data to the Essbase database.
There is no problem loading and mapping the file and in theory if FDMEE worked liked we should expect it to work then the Sales record should load and the COGS record should fail.
Running the export indicates there was a failure.
Investigating the process logs provides the reason for the failure.
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
ERROR [AIF]: com.essbase.api.base.EssException: Cannot open cube outline. Essbase Error(1022002): User [lhowlett@FUSIONAD] Does Not Have Correct Access for Command [OpenOutlineEdit]
At the point where the data load rule is created the error is generated due to incorrect access permissions, it is correct the user does not have access to create rules and open the outline in edit mode, the user only needs to load the data.
The errors can be replicated in EAS when a user tries to save a rules file or open the outline in edit mode.
To me the answer would be that an admin user would create the rule behind the scenes in FDMEE and then the standard user would then load the data using the rule, I have shown it is possible to do this earlier on in this post, I don’t quite know why it has been developed this way but I am sure there must be a reason.
I thought maybe a possible workaround would be to use a custom Essbase load rule so the load rule would not be created.
The Essbase load rule was added to target options in the FDMEE load rule
The export failed again.
Checking the logs this time shows that the process got further and the data file was created.
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
INFO [AIF]: The default rule file will not be used as a custom rule file has been specified: FDMEE
INFO [AIF]: Creating data file: \\fileshare\EPMSHARE\FDMEE\outbox\Sample_2687.dat
INFO [AIF]: Data file creation complete
Later in the log the reason for the failure is clear.
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
DEBUG [AIF]: Obtained connection to essbase cube: Basic
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0062
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0062
ERROR [AIF]: com.essbase.api.base.EssException: Cannot lock olap file object. Essbase Error(1051041): Insufficient privilege for this operation
This time it fails due the user not have access to lock and unlock Essbase load rules, this error can be replicated in EAS by trying to lock a rule.
In the message panel the following error is generated.
Error: 1051041 Insufficient privilege for this operation
The user should not have to lock and unlock the rule, the admin user could lock the rule then the user could load the data using the rule, the rule could then be unlocked by the admin user.
Once again I am not sure why it has been developed in this way in FDMEE but to me it should be possible to load data at user level and honour the security filter.
What about a workaround, well up to 11.1.2.3.520 the user would need to be provisioned with at least the ‘Database Manager ‘role for the Essbase application.
You wouldn’t want to be giving out that role to users that just want to load data but that is the way it goes before that release, luckily most should be running a newer release by now.
From 11.1.2.3.520 there is the property called 'Global User for Application Access which can be set at target application level in FDMEE.
If I provision a user with the ‘Database Manager’ role for the Sample application in Shared Services.
Now the user can be added to target application options in FDMEE.
Let us run the export again in the workbench with the same user as before.
This time the outcome is more positive and in the process logs:
DEBUG [AIF]: GlobalUserForAppAccess from Profile: SampleDBManager
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: SampleDBManager
DEBUG [AIF]: Obtained connection to essbase cube: Basic
INFO [AIF]: The default rule file will not be used as a custom rule file has been specified: FDMEE
DEBUG [AIF]: Resolved essbase rule file name for loading: FDMEE
DEBUG [AIF]: Fetching rule file from essbase server for data loading: FDMEE
DEBUG [AIF]: Locked rule file: FDMEE
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: FDMEE
We can see that the loading of data has now been overridden by the global user, this user has the permissions to create rules and lock and unlock so the data load runs through successfully.
The issue we have here is that the global user can load data to any member combination so we have lost that filter restriction we set earlier.
Unfortunately, that is the best that can be offered presently which I know is not ideal.
Moving on to planning and let us take a similar example with the same user.
The user is provisioned with the ‘Planner’ and ‘Essbase Write Access’ role for the sample Vision application.
Access permissions have been applied within the planning application and for direct Essbase access a filter has been automatically created for the user.
This time write access has been defined for the member combination ‘1110,110,Actual,Working’ and read access for ‘1150’.
The access permissions for the planning layer are confirmed to be working with a form.
A retrieve using an Essbase connections confirms the filters are working as expected.
On to FDMEE, a load rule was created which will load two rows of data from a flat file to the above member combination.
The load method was set to ‘Numeric Data only – File'
The property values available for a target planning application are:
I will go through the ‘All Data Types’ option shortly.
The load process was first tested with a user that is an administrator of the planning application.
The process log shows that the method of loading data is the same as when the target is an Essbase application.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: null
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: admin
DEBUG [AIF]: Obtained connection to essbase cube: Plan1
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0069
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0069
DEBUG [AIF]: Locked rule file: AIF0069
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: AIF0069
I think you know what is coming when we try to run the FDMEE export with a user provisioned as a planner.
Yes, it failed and no surprises with the error message.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: null
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
DEBUG [AIF]: Obtained connection to essbase cube: Plan1
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0069
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0069
ERROR [AIF]: com.essbase.api.base.EssException: Cannot lock olap file object. Essbase Error(1051041): Insufficient privilege for this operation
We are in the same position as when loading directly to Essbase target applications.
Just like with Essbase there is the option to set a global user.
A global user was added that has the administrator role assigned for the planning application.
The export was run again.
This time the export was successful and the process log confirms what is happening.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: planadmin
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: planadmin
DEBUG [AIF]: Obtained connection to essbase cube: Plan1
DEBUG [AIF]: Resolved essbase rule file name for loading: AIF0069
DEBUG [AIF]: Fetching rule file from essbase server for data loading: AIF0069
DEBUG [AIF]: Locked rule file: AIF0069
INFO [AIF]: Loading data into cube using data file...
INFO [AIF]: The data has been loaded by the rule file.
DEBUG [AIF]: Unlocked rule file: AIF0069
The global user overrides and loads the data, as it is an administrator loading the data the access permissions are ignored and all member combinations can be loaded.
There is another data load method available at data load rule level and that is ‘All Data Types’ which uses the outline load utility to load data through the planning layer.
The global user was removed and the export run again with the standard user.
Failed again, the process logs provide the reason behind the failure.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: null
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: lhowlett
DEBUG [AIF]: loadMethod: OLU
Unable to obtain dimension information and/or perform a data load: java.lang.RuntimeException: You must be an Administrator to use the Hyperion Planning Adapter.
Back to square one again as you need to be an administrator to operate the outline load utility.
If the planning application administrator is added back in as the global user, then the export is successful.
DEBUG [AIF]: GlobalUserForAppAccess from Profile: planadmin
INFO [AIF]: Cloud Mode: NONE, Resolved user name for application access: planadmin
DEBUG [AIF]: loadMethod: OLU
INFO [AIF]: Number of rows loaded: 2, Number of rows rejected: 0
The global user overrides and loads the data but once again you lose out on the member level security so not great, in the next post you will see how this load method differs quite considerably in the cloud.
Finally, I want to quickly cover off the user requirements for hybrid which means any integrations between on-premise FDMEE and EPM Cloud.
When you add a cloud application as a target the cloud user credentials are entered and whenever authentication is required with the cloud these credentials are called upon.
As an example, I added a user which has been provisioned with the power user role for the cloud application.
I ran a simple integration which will which extracts data from an on-premise application and loads to a cloud application, the process failed and the logs contained the following information.
INFO [AIF]: Uploading data file to PBCS: \\fileshare\EPMSHARE\FDMEE\outbox\Vision_1991.dat
ERROR [AIF]: java.io.FileNotFoundException: Response: 401: Unauthorized for url: https://cloudinstance/interop/rest/11.1.2.3.600/applicationsnapshots/Vision_1991.dat/contents?q={chunkSize:63,isFirst:true,isLast:true,extDirPath:"inbox"}
The process failed at the point where the on-premise extracted file is uploaded to the cloud instance using the REST API, the 401 error gives an indication it might be user related.
Uploading a file using EPM Automate with the same user returns an error that the user has insufficient privileges.
The documentation states the following.
“EPM Automate Utility enables Service Administrators to automate many repeatable tasks”
So, to be able to upload the file from on-premise to cloud requires the service administrator role.
After updating the cloud user to one that has the service administrator role the hybrid integration was successful.
The process logs show that once the file has been loaded to the cloud instance the remaining steps are performed by the default cloud admin account so overrides the user configured in FDMEE.
INFO [AIF]: Cloud Mode: CLOUD, Resolved user name for application access: epm_default_cloud_admin
Well that about covers all I wanted to in this post, in summary if you are looking to implement user defined security for data loading to Essbase and Planning then you’re going to be disappointed, this is no doubt going to change in the future and in the next post I will cover how EPM cloud currently differs from on-premise in this respect.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.