While part 1 of this FAQ series deals with basic questions regarding the handling of versions in SAP Analytics Cloud, this second part here aims to tackle questions often faced by administrators and power users when dealing with versions within the context of security checks, data action and version size control:
- What kind of security checks governs the publishing process?
- I have appointed a user to be “person responsible” for a member of a dimension. Does this mean that only he can publish to this member now?
- On which version is the data action actually running?
- I am planning across multiple cost centers and triggering data actions in-between to run in the background. Why do I sometimes get error messages and am blocked from entering data?
- Should I use multiple browser tabs during planning to work on the same version?
- Is there no way to work quickly across multiple cells for the same version?
- What can I do as an admin to discourage users from creating huge versions unknowingly?
- What can I do to control sizes of all new versions created from a particular model?
- Which method is better for the version size – defining planning area based on data locks or data access control?
- Why is my defined planning area appearing as not planning enabled?
- I am using analytical applications. Can I still use the planning area to optimize version sizes for my planners?
Q: What kind of security checks governs the publishing process?
A: At the point of publishing, that the data is checked against:
- Data Access Control (DAC)
- Data Locking
- Validation Rules
Only data that passes through all checks will be merged into the public version. This check is done for the publishing of both pubic version edit mode changes and private versions.
If the check detects any invalid entries, an error message will inform you of the affected versions and the discard of those entries if you proceed.
At this point, if desired, you can choose to save your changes in another private version before returning to publish your edit mode changes and merge only the valid changes into the public version.
Message informing invalid changes due to validation rules.
If using a data action and coupling it with a concluding publish step, do note that the data action itself will execute without the security checks, but these will kick in as the last gate before publishing. This means that if invalid member combinations are included, the data action will still run, but fail at the end (no publish). In such cases the results of the data action processing are retained in the edit mode, and likewise here, partial publishing is still possible. After partial publishing, the invalid changes will be discarded.
back to top
Q: I have appointed a user to be “person responsible” for a member of a dimension. Does this mean that only he can publish to this member now?
A: No.
The setting of person responsible has no influence on the data access control (DAC). If a particular user is set up as person responsible in the model, it does not eliminate the need to set up the DAC for him. The definition as “person responsible” for a member merely helps the system to (a) generate a task automatically when triggered to do so within the SAC Calendar, or (b) set up data locking owners along a desired driving dimension.
It is also noteworthy to mention that while working with SAC Calendar tasks, when you submit your entries, publishing will be initiated, and the same security check will kick in upon publishing. If DAC is set up and no rights are granted to you, you will not be able to publish to that member.
back to top
Q: On which version is the data action actually running?
A: A data action runs on the defined target version. (If it is a public version, it will be running in the edit mode.) No technical or other implicit versions are created for this purpose.
Note that the results are not published automatically unless the data action is setup to do so. Upon publishing, only valid data context corresponding to the user’s rights which also lie within the defined member scope will be processed. Note that the scope is also confined further if (a) a planning area definition is already established for the current edit mode version, or (b) the data action trigger is configured to trigger an edit mode version with the planning area definition.
back to top
Q: I am planning across multiple cost centers and triggering data actions in-between to run in the background. Why do I sometimes get error messages and am blocked from entering data?
A: A data action does not execute immediately after trigger; a preparation phase precedes it.
During the preparation phase the version is not blocked, hence data entry is still possible. But once the preparation phase is concluded, the version is blocked for the execution. Hence depending on the point in time when the subsequent data entries are performed, they might be blocked by the data action execution, or not.
Furthermore, version management actions (revert, delete or publish) cannot be performed concurrently with data action execution. If you perform any of those while a data action is running on the same version, you will need to choose between waiting for the execution to conclude first or to abort it.
back to top
Q: Should I use multiple browser tabs during planning to work on the same version?
A: SAC does not support the simultaneous operation across multiple tabs
back to top
Q: Is there no way to work quickly across multiple cells for the same version?
A: Depending on model complexity, one possible way to achieve this is to utilize the Fluid Data Entry within the table, allowing user to plan quickly across multiple cost centers but processing those entries at one go, when the user pauses, instead of after every entry. This could be a good fit for simple calculations and straightforward scenarios. Defining a recommended planning area is also beneficial in many cases.
back to top
Q: What can I do as an admin to discourage users from creating huge versions unknowingly?
A: Admins, or power users with the necessary permissions, can configure the version limit in the model preferences. A warning will be thrown if this size limit is exceeded by a user (e.g. by entering edit mode for a large version or creating a huge version copy without filters).
In the model preferences it is possible to set the version size limit that will throw a warning if exceeded.
Data Actions are not confined by this limit though, and hence care should be taken while scripting/configuring to ensure that the smallest necessary scope is established via member set definition. Turning on the calculation scope check is helpful here.
Calculation scope option in the data action design time
back to top
Q: What can I do to control sizes of all new versions created from a particular model?
A: Defining a recommended planning area for large models is a good method to control the size of a version. The scope of such an area is based on the data access control, data locks, or both, and can be used as reference to restrict the data to only user specific plannable slices when (a) copying a version, (b) triggering public edit mode, or (c) triggering data actions.
back to top
Q: Which method is better for the version size – defining planning area based on data locks or data access control?
A: There are cases where the data access control definition will be a bigger driver than the data lock definition to reduce the recommended planning area. This usually happens when most data are unlocked and the users have much more read than write permissions (e.g. in planning processes with iterative data entry between management and regional planning levels to consolidate high level target with regional planning). In cases where the users have more write permissions, such as admins or model owners, or when most data are locked, the data locking definition will be a more effective reference to reduce the recommended planning area.
back to top
Q: Why is my defined planning area appearing as not planning enabled?
A: Often this is due to not having included all required dimensions and/or hierarchies.
There are three factors to keep in mind when working with the planning area:
- Hierarchy
- Dimension
- Table setup
For a cell to be defined as within the planning area and plannable, all members aggregating into it and all dimensions constituting the cell context must be within the area definition. In addition, the dimensions and hierarchy involved must also be included in the planning table layout, either explicitly in the row/column, or in the filter (note that range and exclude filters are not considered here). Forgetting to include a dimension in the table will lead to unplannable cells, despite the planning area definition.
back to top
Q: I am using analytic applications. Can I still use the planning area to optimize version sizes for my planners?
A: Yes.
Do note that with analytic applications you will need to pay attention during scripting to ensure that all involved dimensions and hierarchies in the planning area are also included in the table layout/filter, in order for the planning area to be correctly rendered in runtime (see also FAQ above).
back to top
In case you missed it, here is part I of the FAQ series:
