In the first part of the blog we have seen the changes introduced with the file repository integration of Data Action (DA) and Multi Action (MA). this second part we will have at look at the permission setups required in different areas and the FAQs.
Part II Content:
Helpful Hints
FAQ
The integration of DA/MA into file repository means that the assignment of permissions for these two artifacts needs to be considered as well when setting up a business logic. Below is an overview of the required permissions, together with those of the related artifacts:
The permissions shown above need to be the results of aggregated permissions granted in the following areas:
This means that the required permission setup for DA/MA is as follows:
Remember to assign “Read” to content importers
As mentioned in part I of the blog, the Read permission does not come automatically with Create in the overall setting for DA/MA under role permissions, hence care should be taken to assign this to DA/MA creators. But do note that content importers, since they will become file owners of imported DA/MA, will require Read permission too to see the imported artifacts.
If the content importers should also be able to overwrite existing artifacts (for example in cases of re-importing) do remember to grant them Update permission.
If using workspaces, remember that moving artifacts from public into the workspace will reset the file repository permissions.
Hence, to avoid double configuration work, set up the permissions for individual DA/MA after having moved them into the designated workplace and conduct testing from there.
Folders are not workspaces
Unsharing Read permission to a folder containing shared DA/MA will not withdraw the access to those artifacts via default. To unshared those as well, remember to select the option “To the selected folder, its subfolders, and files” at the point of removing the access.
This is different for workspaces, where contained artifacts are not accessible to users with no authorization to the workspace itself.
Likewise, when moving shared DA/MA to an unshared folder, the existing access will not be withdrawn. To remove access, remove Read permission of the DA/MA from the file repository share dialog.
Q: Before migration, is there any recommended preparation for the administrators?
A: It is recommended to read through the blog to get familiar with the upcoming changes which will be useful in deciding for necessary preparation. For example, one of the approaching changes will be the moving of permission setup for individual DA/MA into the file repository share dialog. This means that administrators will no longer have a central view of all permission setup for all individual DA/MA per role after the migration. For administrators who would still like to have a single overview of all DA/MA permissions mapped to a role, the easiest way would be to note that information down before the migration. To attain this info after the migration would require checking the setup of each DA/MA individually in the file repository.
Another example would be to check whether the access to public files is granted to users (see the questions below.)
These are of course only some examples. Details to these and other examples are contained in the rest of the blog. Hence the recommendation to go through them.
Q: When the file repository integration of DA/MA has taken place, will the existing permissions assigned beforehand be retained? Do users still have access to the DA/MA?
A: When the integration has taken place, the permissions are retained and users will still have access IF they have been granted access to public files.
Reason: The migration will move the DA/MA into respective folders within the public folder, hence access to public files has also become a prerequisite for access to the DA/MA.
Note that after the migration you are of course free to move the DA/MA into another folder or even workspace of your choice. In such cases care needs to be taken that users are granted access to the new location of the artifacts (like with all file repository artifacts). For example, if the DA/MA is moved into a workspace, the user will need membership to the workspace to continue having access to the DA/MA.
Q: After migration, are there any to-dos for the administrators?
A: IF access to public files has been granted to the users, there are no extra to-dos to ensure that users can continue to execute the DA/MA (see question above).
But there are some recommended actions for certain cases:
Case 1: If the following is your setup:
Before the migration, you have users who have Execute permission for at least one individual DA/MA, and Read permission only for some others.
Effect after migration:
The above setup will result in the same group of users, after the migration, being also able to execute DA/MA for which they have only Read permission prior to the migration. (Note however, that the existing security for publishing will not be disrupted and will continue to safeguard against unauthorized data changes.)
Recommended Action After Migration:
In the file repository, you can unshare the DA/MA to which the users had - prior to migration - only Read but no Execute permission.
Case 2: Preference of existing teams over new teams
If after the migration, you do not want to keep the new teams created by the system but prefer to continue using your existing teams.
Recommended Action:
You can check which individual DA/MA is shared with the newly created team and share the same artifact(s) with your chosen existing team, applying the same permissions. When you have done this, you can remove the newly created team if desired.
Q: Why is the page listing all DA/MA now blank?
A: The list which used to contain all DA/MA is now showing only recently opened files by the current user. The previously created DA/MA before wave 20203.06 are not gone but integrated into the file repository.
Q: The user has created a DA/MA, but it cannot be found in the file repository?
A: Make sure the user has been granted Read for the overall DA/MA setting under the role permission setup.
Q: The user is creating a DA/MA and cannot return to editing after refreshing, because “File not found”. What is happening?
A: Similar to the above, the created DA/MA is not lost if it has been saved beforehand. Make sure the user has been granted Read for the overall DA/MA setting under the role permission setup.
Q: The user has started creating a DA/MA, but why can it not be saved?
A: Check if the user has been granted the Create Files permission for the target folder.
Q: The user has created a DA/MA, is file owner, but does not seem to have full access and cannot update or execute the DA/MA
A: File owners of DA/MA do not have full access as a default but are subjected to the permissions granted in their role permission setup. Grant the user all permissions there to enable full privilege.
Q: The user sees a DA/MA trigger in the story/app, but it is inactive and cannot be triggered?
A: Check the user's role permission setup for DA/MA and grant Execute permission if it is missing.
Q: The user sees a DA/MA trigger in the story/app; it appears to be active, but upon trigger an error appears stating that the DA/MA has been deleted or there is no permission to access it? (It is not deleted.)
A:Permissions for DA/MA are aggregated permissions granted via different areas. Check hence the following:
Q: After import, the DA/MA cannot be found?
A: Check the user's role permission setup for DA/MA and grant Read permission if it is missing.
Q: A user has imported a DA/MA but now cannot re-import and overwrite it?
A: Check the user’s role permission setup for DA/MA and grant Update permission if it is missing.
Q: Can DA/MA be exported from a tenant with the file repository integration (toggled on) into a tenant without the integration (toggled off)?
A: No, this is not possible. But it is possible the other way around: to export from a tenant with the file repository integration toggled off into another which has the integration toggled on.
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:
Questions to the DA/MA file repository integration can also be posted in the SAP community.
Part II Content:
Helpful Hints
FAQ
- General Questions
- Questions to DA/MA Creation
- Questions to DA/MA Trigger Execution
- Questions to DA/MA Import
Helpful Hints
Required Permissions for DA/MA and Related Artifacts
The integration of DA/MA into file repository means that the assignment of permissions for these two artifacts needs to be considered as well when setting up a business logic. Below is an overview of the required permissions, together with those of the related artifacts:
For User Triggering DA/MA
| Source Model | Target Model | Data Action | Multi Action | Story/App containing DA/MA | |
| Permission | Read | Read, Maintain | Read, Execute | Read, Execute | Read |
| Purpose | Reading Data | Write data, see results (To do planning) | Trigger | Trigger | Consume (To do planning) |
For User Creating DA/MA (and Frontend for Trigger)
| Source Model | Target Model | Data Action | Multi Action | Story/App containing DA/MA | |
| Permission | Read | Read, Maintain | Read, Execute, Create, Update, Delete | Read, Execute, Create, Update, Delete | Read, Update |
| Purpose | Reading Data | Write data, see results (Trigger Testing) | Creation and maintenance | Creation and maintenance | Consume (Testing) |
The permissions shown above need to be the results of aggregated permissions granted in the following areas:
- Role Permission
- Public/private file access (if used)
- Overall DA/MA permissions
- Workspace membership (if workspace is used)
- File repository share permissions
- Role Permission
This means that the required permission setup for DA/MA is as follows:
- For users triggering DA/MA
- Public/private file access (role permission): Read
- Overall DA/MA access (role permission): Read, Execute
- If the DA/MA is stored in a workspace, the user must be assigned as a member to the workspace
- Individual DA/MA Permission (File Repository Share Permission): Read (it includes Execute implicitly, when granted via role permission)
- For users creating DA/MA
- Public/private file access (role permission): Create, Read, Delete, Manage
- Overall DA/MA access (role permission): Create, Read, Delete, Update, Execute
- If the DA/MA should be stored in a workspace, the user must be assigned as a member to the workspace
- Individual DA/MA Permission (File Repository Share Permission): (They are file owners but also subjected to the role permission setup.)
Note: Creators will also need Create Files permission for the target folder where they wish to save the DA/MA.
Points to Remember
Remember to assign “Read” to content importers
As mentioned in part I of the blog, the Read permission does not come automatically with Create in the overall setting for DA/MA under role permissions, hence care should be taken to assign this to DA/MA creators. But do note that content importers, since they will become file owners of imported DA/MA, will require Read permission too to see the imported artifacts.
If the content importers should also be able to overwrite existing artifacts (for example in cases of re-importing) do remember to grant them Update permission.
If using workspaces, remember that moving artifacts from public into the workspace will reset the file repository permissions.
Hence, to avoid double configuration work, set up the permissions for individual DA/MA after having moved them into the designated workplace and conduct testing from there.
Folders are not workspaces
Unsharing Read permission to a folder containing shared DA/MA will not withdraw the access to those artifacts via default. To unshared those as well, remember to select the option “To the selected folder, its subfolders, and files” at the point of removing the access.
This is different for workspaces, where contained artifacts are not accessible to users with no authorization to the workspace itself.
Likewise, when moving shared DA/MA to an unshared folder, the existing access will not be withdrawn. To remove access, remove Read permission of the DA/MA from the file repository share dialog.
FAQ
General Questions:
Q: Before migration, is there any recommended preparation for the administrators?
A: It is recommended to read through the blog to get familiar with the upcoming changes which will be useful in deciding for necessary preparation. For example, one of the approaching changes will be the moving of permission setup for individual DA/MA into the file repository share dialog. This means that administrators will no longer have a central view of all permission setup for all individual DA/MA per role after the migration. For administrators who would still like to have a single overview of all DA/MA permissions mapped to a role, the easiest way would be to note that information down before the migration. To attain this info after the migration would require checking the setup of each DA/MA individually in the file repository.
Another example would be to check whether the access to public files is granted to users (see the questions below.)
These are of course only some examples. Details to these and other examples are contained in the rest of the blog. Hence the recommendation to go through them.
Q: When the file repository integration of DA/MA has taken place, will the existing permissions assigned beforehand be retained? Do users still have access to the DA/MA?
A: When the integration has taken place, the permissions are retained and users will still have access IF they have been granted access to public files.
Reason: The migration will move the DA/MA into respective folders within the public folder, hence access to public files has also become a prerequisite for access to the DA/MA.
Note that after the migration you are of course free to move the DA/MA into another folder or even workspace of your choice. In such cases care needs to be taken that users are granted access to the new location of the artifacts (like with all file repository artifacts). For example, if the DA/MA is moved into a workspace, the user will need membership to the workspace to continue having access to the DA/MA.
Q: After migration, are there any to-dos for the administrators?
A: IF access to public files has been granted to the users, there are no extra to-dos to ensure that users can continue to execute the DA/MA (see question above).
But there are some recommended actions for certain cases:
Case 1: If the following is your setup:
Before the migration, you have users who have Execute permission for at least one individual DA/MA, and Read permission only for some others.
Effect after migration:
The above setup will result in the same group of users, after the migration, being also able to execute DA/MA for which they have only Read permission prior to the migration. (Note however, that the existing security for publishing will not be disrupted and will continue to safeguard against unauthorized data changes.)
Recommended Action After Migration:
In the file repository, you can unshare the DA/MA to which the users had - prior to migration - only Read but no Execute permission.
Case 2: Preference of existing teams over new teams
If after the migration, you do not want to keep the new teams created by the system but prefer to continue using your existing teams.
Recommended Action:
You can check which individual DA/MA is shared with the newly created team and share the same artifact(s) with your chosen existing team, applying the same permissions. When you have done this, you can remove the newly created team if desired.
Questions to DA/MA Creation:
Q: Why is the page listing all DA/MA now blank?
A: The list which used to contain all DA/MA is now showing only recently opened files by the current user. The previously created DA/MA before wave 20203.06 are not gone but integrated into the file repository.
Q: The user has created a DA/MA, but it cannot be found in the file repository?
A: Make sure the user has been granted Read for the overall DA/MA setting under the role permission setup.
Q: The user is creating a DA/MA and cannot return to editing after refreshing, because “File not found”. What is happening?
A: Similar to the above, the created DA/MA is not lost if it has been saved beforehand. Make sure the user has been granted Read for the overall DA/MA setting under the role permission setup.
Q: The user has started creating a DA/MA, but why can it not be saved?
A: Check if the user has been granted the Create Files permission for the target folder.
Q: The user has created a DA/MA, is file owner, but does not seem to have full access and cannot update or execute the DA/MA
A: File owners of DA/MA do not have full access as a default but are subjected to the permissions granted in their role permission setup. Grant the user all permissions there to enable full privilege.
Questions to DA/MA Trigger Execution:
Q: The user sees a DA/MA trigger in the story/app, but it is inactive and cannot be triggered?
A: Check the user's role permission setup for DA/MA and grant Execute permission if it is missing.
An inactive DA/MA is an indication that the Execute permission is not granted.
Q: The user sees a DA/MA trigger in the story/app; it appears to be active, but upon trigger an error appears stating that the DA/MA has been deleted or there is no permission to access it? (It is not deleted.)
A:Permissions for DA/MA are aggregated permissions granted via different areas. Check hence the following:
- Workspace permission: Is the DA/MA stored in a workspace? If yes, check if user is assigned as a member to the workspace
- File repository permission: Is the specific DA/MA shared with the user? The user requires here Read permission for the execution.
When faced with an error message, check whether the Read permission has been assigned to the individual DA/MA in the file repository.
Questions to DA/MA Import/Export:
Q: After import, the DA/MA cannot be found?
A: Check the user's role permission setup for DA/MA and grant Read permission if it is missing.
Q: A user has imported a DA/MA but now cannot re-import and overwrite it?
A: Check the user’s role permission setup for DA/MA and grant Update permission if it is missing.
Q: Can DA/MA be exported from a tenant with the file repository integration (toggled on) into a tenant without the integration (toggled off)?
A: No, this is not possible. But it is possible the other way around: to export from a tenant with the file repository integration toggled off into another which has the integration toggled on.
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.
Questions to the DA/MA file repository integration can also be posted in the SAP community.
- SAP Managed Tags:
5 Comments
