Recently at a customer site we saw the following issue with a user trying to run a FR report. The user was unable to run a report or connect to Smart view via an Essbase connection. However, the user could enter data using planning web forms. The user was getting the following error, “Cannot open cube view. Essbase Error(1054060)”. We looked into the provisioning and confirmed that the user had all the right groups assigned and was also provisioned with “Server Access” role in Essbase. Moreover, another user with exactly the same access had no issues running the report. Next, we logged into the EAS console and could see the filter had been created with the user id, still the user wasn’t able to connect via an Essbase connection.
Solution: While researching the issue, we found that sometimes when you refresh security filters in planning, even though filters get created correctly, they do not get assigned to the user id correctly. You can check this by logging into the EAS console, expand Security node. Right click the “Users” node and select display users table.
Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.
Once the users table opens, select the user and double click/edit. Once the user properties open, in the App/Db access tab drill down to the lowest level in planning application- >Databases(cube) and make sure you see filter assigned. If you see (None), this implies the filter did not get assigned.
Steps to resolve the issue:
1) Deprovision the user from Shared Services console.
2) Copy and paste the following maxl command in the maxl editor from EAS console to Drop user from security file as shown below
drop user “Planner2@Native Directory” from security_file;
Click Execute.
3) Provision the user again and refresh security filters from Planning.
4) To verify, login to EAS console and check the user properties again and make sure the filter has been assigned
Thanks for the explanation and workaround. I’ve been deleting an affected user’s filters manually though EAS when faced with the problem. The MAXL command will be useful when there are multiple users with the same problem. Do you know why it does this? Is there a bug in the software? We had it in 11.1
2.2, and we still occasionally get it in 11.1.2.4. We provision our Planning users through MAXL. Are we doing something wrong to get this error message?
Thank you for your comments. I want to say for us it was the sequence that mattered. I am not sure what sequence affects this. But you may want to try to Provision users first, do a refresh, then assign user to group and then again refresh.
The above steps will help to resolve the issue, but it will take significant time if user is provisioned to multiple Planning applications. The “Drop user” command will drop user from entire Essbase cluster, so all Planning application need to be refreshed for that cluster.
There is one another way to Reassign security filters in Planning application. Please follow following steps:
1. Copy and paste the following maxl command in the maxl editor from EAS console to Drop user from security file as shown below
drop user “Planner2@Native Directory” from security_file;
2. Delete filter of user for Planning application from EAS console.
3. Re-create filter in Planning application (Click on “+” to re-create it)
4. If user is having Admin access to Planning cube, then ignore step 3 and do full refresh for the respective cube.