In wave 2023.06, Data Actions (DA) and Multi Actions (MA) will be integrated into the file repository. This 2-part blog series will elaborate on the changes and provide answers to some common questions.
Part 1 focuses on the changes in permission setting and the migration, while part 2 provides helpful hints and a list of FAQs.
Part I Content:
Why file repository integration?
What is different now
Noteworthy Details for Migration & Beyond
Previously for SAP Analytics Cloud, all created DA/MA are centrally stored in a designated list respectively, both accessible via the toolbar. While this offers a holistic view of all DA/MA, it is not that easy to separate artifacts belonging to different business units or projects. With the move of DA/MA into the file repository in wave 2023.06, a structural approach for their storage will be possible, enabling in turn a better overview and allocation of administrative responsibilities.
With wave 2023.06, users will notice that the list containing all DA and MA will appear to be empty. This is because the list will no longer list all entities but just the recently opened DA/MA by current user.
All previously created DA/MA could be found under Files/My Files/Public, and in the folder “Data Actions” or “Multi Actions”.
Previously, access for all DA/MA and their individual instances were managed via the role permissions settings. Now, with the integration into the file repository, only the general settings for all DA/MA can be configured via the role permission. Settings for individual DA/MA are moved into the file repository share dialog.
Note that the Execute permission for individual DA/MA does not appear among the share options. It is managed via the role permission setup. The Read permission in the file repository share dialog will influence the Execute permission as follows:
The integration now into the file repository means that DA/MA permissions are also subjected to workspace constraints and public/private files access.
The final resulting access is an aggregation of permissions in all areas, and hence they should be kept in mind when administrating access for DA/MA creators and trigger execution for planning users.
For more details, refer to the “Helpful Hints” section in part 2 of this blog series.
Creators are now file Owners
Previously, DA/MA creators can bypass restrictions and possess full privilege to their created artifacts. Now with the file repository integration, creators will be the file owners of their artifacts. Their permissions will be subjected to the configurations of their role permissions, and on top of that they are able to share their created DA/MA.
“Create files” permission required for folder
When creating DA/MA, they will need the Create Files permission for the target folder where the DA/MA will be stored under.
Look under "Files" instead of "Data Action" or "Multi Action"
With the file repository integration, DA/MA will no longer exist as unique item in the list of object types for content network storage and file system (soon deprecated). Instead, they are considered as "Files".
Permissions required to read and update
Care needs to be taken to assign content importers Read and Update in the role permission setup to ensure that they can find imported artifacts and also overwrite those if necessary. Further details and FAQs could be found in in part 2 of this blog series.
For DA/MA it has always been possible to assign Create without Read in the overall DA/MA setting under role permission. While this has not hindered users from finding their own DA/MA after creation, with the integration of DA/MA into the file repository in wave 2023.06, the assignment of permissions needs to be precise to avoid unintended withdrawal of file access, just like for any other repository entity. Hence care should be taken here to also assign the Read permission to DA/MA creators, for them to be able to find the files after creation and also resume editing if they refresh browser during design time.
Noteworthy for migration: If user has Execute permission for at least one individual DA/MA before the migration, this Execute permission will be included in his role after migration. This will result in him/her being able to execute DA/MA for which he has Read permission, including those for which the Execute permission has not been assigned to him/her before the migration.
This is a one-time technical adjustment, necessary for the migration. However, note that the security setup for publishing remains intact. This means that the existing setup of data access control, validation rules, data locking, and permission setup for the target model will still prevent unauthorized publishing of data.
If there is a need to continue blocking the execution for certain users, withdraw this permission for individual DA/MA via the share dialog by removing Read from the options (see “Role Permissions and File Repository Share Options”). To restrict execution for all DA/MA, remove Execute from the role permission.
Keep in mind that:
As mentioned earlier, permissions for individual DA/MA will be moved out of the role permissions setting. Access to individual DA/MA is configured now via the file repository share dialog (see “Read & Execute Permission”).
This means that upon migration, a new team will be created per role with the hitherto assigned permissions for each individual DA/MA to retain the current existing access. This will be done only for roles with at least 2 assigned individual users. For roles with single user or only team(s), the permissions will be attached to the individual or team(s). For roles with no user/team, the permissions will not be attached to anyone.
It is easy to identify those new teams which are created for this purpose. The naming convention is as follows:
Example: The team created for the role “Planners” to grant access to Data Actions will be “DataActionRole_Planners”.
The new team created allows the admin to add new users easily who require the same permissions to the same individual DA/MA.
It is also possible to apply the same permissions to another existing team if preferred. The easier way to do this would be to note down the permission setup for the individual DA/MA in the role permission before the migration, and share the same permissions with the desired existing team after the migration. After migration, the sharing of permissions would still be possible, but one would have to go to each individual DA/MA and check the permission setup (as the information is no longer visible centrally under the role permission), which is more cumbersome.
Remember that the folder can be used to share or unshare permissions to many artifacts at one go. Just take care to not just share the folder but also select the option to share/unshare all files within the folder too.
Part 2 of this blog will give an overview of permission setup and points to keep in mind for the aggregation of permissions across all areas. A FAQ list will provide quick reference to common questions.
The latest details to the file repository integration of DA/MA will be available in the in-app help in wave 2023.06. Navigate to the information by:
Part 1 focuses on the changes in permission setting and the migration, while part 2 provides helpful hints and a list of FAQs.
Part I Content:
Why file repository integration?
What is different now
- Recent Files
- Data Action / Multi Action as Shareable Object in the File Repository
- Role Permissions & File Repository Share Options
- Changes for DA/MA Creators
Noteworthy Details for Migration & Beyond
- Create & Read Permissions (For Creators)
- Read & Execute Permission (For Trigger Execution)
- Impact of Public (And Private) File Access
- New Teams Created
Why file repository integration?
Previously for SAP Analytics Cloud, all created DA/MA are centrally stored in a designated list respectively, both accessible via the toolbar. While this offers a holistic view of all DA/MA, it is not that easy to separate artifacts belonging to different business units or projects. With the move of DA/MA into the file repository in wave 2023.06, a structural approach for their storage will be possible, enabling in turn a better overview and allocation of administrative responsibilities.
What is different now
Recent Files
With wave 2023.06, users will notice that the list containing all DA and MA will appear to be empty. This is because the list will no longer list all entities but just the recently opened DA/MA by current user.
Only recent files will be listed here
Data Action / Multi Action as Sharable Objects in the File Repository
All previously created DA/MA could be found under Files/My Files/Public, and in the folder “Data Actions” or “Multi Actions”.
Data Actions and Multi Actions will be moved to their respective folder in the public folder
Role Permissions and File Repository Share Options
Previously, access for all DA/MA and their individual instances were managed via the role permissions settings. Now, with the integration into the file repository, only the general settings for all DA/MA can be configured via the role permission. Settings for individual DA/MA are moved into the file repository share dialog.
Note that the Execute permission for individual DA/MA does not appear among the share options. It is managed via the role permission setup. The Read permission in the file repository share dialog will influence the Execute permission as follows:
- If Execute is granted for the role, withdrawing Read in the file repository share dialog will also withdraw Execute permission for the individual DA/MA
- If Execute is not granted for the role, assigning Read in the file repository share dialog will not grant Execute permission for the individual DA/MA
To configure permissions for individual Data Action or Multi Action, use the share dialog.
The integration now into the file repository means that DA/MA permissions are also subjected to workspace constraints and public/private files access.
The final resulting access is an aggregation of permissions in all areas, and hence they should be kept in mind when administrating access for DA/MA creators and trigger execution for planning users.
For more details, refer to the “Helpful Hints” section in part 2 of this blog series.
Changes for DA/MA Creators
Creators are now file Owners
Previously, DA/MA creators can bypass restrictions and possess full privilege to their created artifacts. Now with the file repository integration, creators will be the file owners of their artifacts. Their permissions will be subjected to the configurations of their role permissions, and on top of that they are able to share their created DA/MA.
“Create files” permission required for folder
When creating DA/MA, they will need the Create Files permission for the target folder where the DA/MA will be stored under.
Import/Export
Look under "Files" instead of "Data Action" or "Multi Action"
With the file repository integration, DA/MA will no longer exist as unique item in the list of object types for content network storage and file system (soon deprecated). Instead, they are considered as "Files".
Permissions required to read and update
Care needs to be taken to assign content importers Read and Update in the role permission setup to ensure that they can find imported artifacts and also overwrite those if necessary. Further details and FAQs could be found in in part 2 of this blog series.
Noteworthy Details for Migration & Beyond
Create & Read Permission (for Creators)
For DA/MA it has always been possible to assign Create without Read in the overall DA/MA setting under role permission. While this has not hindered users from finding their own DA/MA after creation, with the integration of DA/MA into the file repository in wave 2023.06, the assignment of permissions needs to be precise to avoid unintended withdrawal of file access, just like for any other repository entity. Hence care should be taken here to also assign the Read permission to DA/MA creators, for them to be able to find the files after creation and also resume editing if they refresh browser during design time.
Remember to assign Read permission to the intended role for Data Action / Multi Action creators
Read & Execute Permission (for Trigger Execution)
Noteworthy for migration: If user has Execute permission for at least one individual DA/MA before the migration, this Execute permission will be included in his role after migration. This will result in him/her being able to execute DA/MA for which he has Read permission, including those for which the Execute permission has not been assigned to him/her before the migration.
This is a one-time technical adjustment, necessary for the migration. However, note that the security setup for publishing remains intact. This means that the existing setup of data access control, validation rules, data locking, and permission setup for the target model will still prevent unauthorized publishing of data.
If there is a need to continue blocking the execution for certain users, withdraw this permission for individual DA/MA via the share dialog by removing Read from the options (see “Role Permissions and File Repository Share Options”). To restrict execution for all DA/MA, remove Execute from the role permission.
Impact of Public (and Private) Files Access
Keep in mind that:
- Role permission settings for public and private files can overrule file repository share permissions.
- The migration will move all DA/MA from the central lists into My Files / Public / Data Actions (or Multi Actions)
Assign at least Read permissions to public files to give users access to migrated DA/MA
New Teams Created
As mentioned earlier, permissions for individual DA/MA will be moved out of the role permissions setting. Access to individual DA/MA is configured now via the file repository share dialog (see “Read & Execute Permission”).
This means that upon migration, a new team will be created per role with the hitherto assigned permissions for each individual DA/MA to retain the current existing access. This will be done only for roles with at least 2 assigned individual users. For roles with single user or only team(s), the permissions will be attached to the individual or team(s). For roles with no user/team, the permissions will not be attached to anyone.
It is easy to identify those new teams which are created for this purpose. The naming convention is as follows:
- DataActionRole_<role name>, or
- MultiActionRole_<role name>
Example: The team created for the role “Planners” to grant access to Data Actions will be “DataActionRole_Planners”.
The new team created allows the admin to add new users easily who require the same permissions to the same individual DA/MA.
It is also possible to apply the same permissions to another existing team if preferred. The easier way to do this would be to note down the permission setup for the individual DA/MA in the role permission before the migration, and share the same permissions with the desired existing team after the migration. After migration, the sharing of permissions would still be possible, but one would have to go to each individual DA/MA and check the permission setup (as the information is no longer visible centrally under the role permission), which is more cumbersome.
Remember that the folder can be used to share or unshare permissions to many artifacts at one go. Just take care to not just share the folder but also select the option to share/unshare all files within the folder too.
Part 2 of this blog will give an overview of permission setup and points to keep in mind for the aggregation of permissions across all areas. A FAQ list will provide quick reference to common questions.
Further Reading
The latest details to the file repository integration of DA/MA will be available in the in-app help in wave 2023.06. Navigate to the information by:
- In SAP Analytics Cloud, select Data Actions or Multi Actions from the side navigation and select Help from the shell bar.
- Select Help again within the pop-up.
- SAP Managed Tags:
