Introduction
Welcome to the next instalment of this blog series. In this post, I will address the question: “Will DAC settings be preserved when sending data from SAC back to Datasphere?” Just to recap, in the previous blog we spoke about the following:
What is Data Access Control (DAC) in SACThe different type of DACs – dimension-based and role basedBenefits & drawbacks for both dimension-based and role-based controlsWhich Type of Data Access Control Is Best for Different Situations
Throughout this blog, I will discuss the following in relation to data access control coming from SAC to Datasphere:
Why would you send data from SAC to Datasphere?Scenario 1 – will DACs be preserved when sending data from SAC back to Datasphere?Scenario 2 – will DACs be preserved when sending data from Datasphere to SAC?
Why would you send data from SAC to Datasphere?
Typically, we consider Datasphere as the backend and SAC as the frontend for reporting. However, in this scenario, SAC is used as the backend to store planning data in a planning model. We then aim to send this data from SAC to Datasphere. But why? Here are several reasons:
Advanced Data Processing and Transformation – Datasphere provides advanced data transformation capabilities. By sending data from SAC, users can use Datasphere’s tools for complex data processing that might not be possible directly within SAC. You can also enrich data with additional information from other sources stored in Datasphere. This can enhance the value, and insights derived from SAC data.
Enhanced Analytical Capabilities – Datasphere offers advanced analytics tools that can be used to analyse planning data in more depth. This includes predictive analytics and machine learning capabilities that can provide more insightful planning forecasts.
Scalability and Performance – Datasphere is designed to handle large volumes of data efficiently, ensuring that data can be processed and analysed without performance bottlenecks. Offloading heavy data processing tasks to Datasphere can improve the performance of SAC, ensuring that both planning, and analytics tasks are carried out efficiently.
Let’s consider 2 scenarios:
DACs are applied in SAC for User 1 to only see the Soft Drinks data – will user 1 be able to only see the Soft Drinks data when they log into Datasphere?DACs are applied in Datasphere for User 1 to only see the Soft Drinks data – will user 1 be able to only see the Soft Drinks data when they log into SAC?
Scenario 1
In the first scenario, we aim to confirm that DAC settings applied to user 1 within SAC do not carry over when the data from SAC is imported to Datasphere for the same user. Specifically, within the SAC tenant, a manager will assign DAC to user 1, restricting their view to only Soft Drinks data in SAC. Since the DACs are managed within SAC, they will not be enforced in Datasphere when previewing the imported data, as Datasphere does not directly handle the data with these DAC configurations.
Steps
Setting up DACs in SAC & setting up the connectionImport the fact dataResult
1. Setting up DACs in SAC & setting up the connection
Setting up DAC in SAC has been discussed here in part 1 of this blog series. The detailed steps for setting up a connection between the two tenants can be found here. For a quick overview, refer to the following steps:
Create an OAuth Client in SAC: Make sure to note the relevant information.Create a CDI Connection to SAC in Datasphere: Use the information noted in the previous step to complete this process.
2. Import the fact data
Once the connection is created, I imported the fact data from a remote table in Datasphere from SAC. Once imported, you can add a graphical view on top of this remote table.
3. Result
We can then preview the data from this view. To our surprise, my user can see all drink departments. This shows that the DACs that were created in SAC have not followed through to Datasphere. You can see below all drink departments coming through from SAC.
Scenario 2
In the second scenario, we want to verify that DACs applied within the Datasphere tenant are still enforced when the user accesses the data through SAC. Specifically, when a manager assigns a DAC to user 1, restricting their view to only Soft Drinks data in Datasphere, this restriction should persist when the user accesses the same data in SAC. The SAC story will access the data directly from Datasphere, bypassing any internal SAC models. Therefore, the DACs configured in Datasphere will remain effective, ensuring that user 1 can still only view the Soft Drinks data within SAC.
Steps
Setting up DACs in Datasphere & setting up the connectionImport Actual Data from Datasphere via an OData ConnectionResult
1. Setting up DACs in Datasphere & setting up the connection
Setting up DAC in Datasphere has been discussed here. For this example, In Datasphere, we assigned DACs to user 1 so that they can only view the Soft Drinks data. See data preview below.
The detailed steps for setting up a connection between the two tenants can be found here & here. For a quick overview, refer to the following steps:
Create an OAuth Client in Datasphere: Make sure to note the relevant information.Create an OData Connection to Datasphere in SAC: Use the information noted in the previous step to complete this process.
2. Import Actual Data from Datasphere via an OData Connection
We have discussed the steps to import the actual data from Datasphere via an OData connection here. Just to give a quick summary you must first start by creating a new model in the Modeler and select “Start with data.” Choose “OData Services” and select the connection you previously created. Create a new query, add the necessary query details, and select the desired table with up to 100 columns. After importing the data, you can clean and finalize your model. Finally, create a story to test and ensure everything is functioning correctly.
3. Result
When user 1 accesses the story within SAC, the DACs will maintain its effectiveness. This means that user 1 can only see the data related to the Soft Drinks department. This data is stored in Datasphere, the Data Access Controls (DAC) are, therefore, managed by Datasphere. The story in SAC accesses this data directly from Datasphere, not from an internal SAC model. Therefore, any DAC configured in Datasphere remains effective when the data is viewed through an SAC story.
See the diagram below to see how the DACs work between the SAC and Datasphere tenants.
Conclusion
In this final part of our series, we explored whether Data Access Controls (DAC) follow through when sending data from SAC back to Datasphere. We examined the setup of DAC in SAC and discussed the steps for establishing a connection between SAC and Datasphere. Our findings reveal that when data is stored in Datasphere, DACs are managed by Datasphere and remain effective when accessed via SAC. However, if data from an SAC model is imported into Datasphere, the DACs configured in SAC do not apply in Datasphere, as the data is not accessed directly within SAC. Understanding these distinctions is key to managing data effectively across platforms.
IntroductionWelcome to the next instalment of this blog series. In this post, I will address the question: “Will DAC settings be preserved when sending data from SAC back to Datasphere?” Just to recap, in the previous blog we spoke about the following:What is Data Access Control (DAC) in SACThe different type of DACs – dimension-based and role basedBenefits & drawbacks for both dimension-based and role-based controlsWhich Type of Data Access Control Is Best for Different Situations Throughout this blog, I will discuss the following in relation to data access control coming from SAC to Datasphere:Why would you send data from SAC to Datasphere?Scenario 1 – will DACs be preserved when sending data from SAC back to Datasphere?Scenario 2 – will DACs be preserved when sending data from Datasphere to SAC? Why would you send data from SAC to Datasphere?Typically, we consider Datasphere as the backend and SAC as the frontend for reporting. However, in this scenario, SAC is used as the backend to store planning data in a planning model. We then aim to send this data from SAC to Datasphere. But why? Here are several reasons:Advanced Data Processing and Transformation – Datasphere provides advanced data transformation capabilities. By sending data from SAC, users can use Datasphere’s tools for complex data processing that might not be possible directly within SAC. You can also enrich data with additional information from other sources stored in Datasphere. This can enhance the value, and insights derived from SAC data. Enhanced Analytical Capabilities – Datasphere offers advanced analytics tools that can be used to analyse planning data in more depth. This includes predictive analytics and machine learning capabilities that can provide more insightful planning forecasts. Scalability and Performance – Datasphere is designed to handle large volumes of data efficiently, ensuring that data can be processed and analysed without performance bottlenecks. Offloading heavy data processing tasks to Datasphere can improve the performance of SAC, ensuring that both planning, and analytics tasks are carried out efficiently. Let’s consider 2 scenarios:DACs are applied in SAC for User 1 to only see the Soft Drinks data – will user 1 be able to only see the Soft Drinks data when they log into Datasphere?DACs are applied in Datasphere for User 1 to only see the Soft Drinks data – will user 1 be able to only see the Soft Drinks data when they log into SAC? Scenario 1 In the first scenario, we aim to confirm that DAC settings applied to user 1 within SAC do not carry over when the data from SAC is imported to Datasphere for the same user. Specifically, within the SAC tenant, a manager will assign DAC to user 1, restricting their view to only Soft Drinks data in SAC. Since the DACs are managed within SAC, they will not be enforced in Datasphere when previewing the imported data, as Datasphere does not directly handle the data with these DAC configurations. StepsSetting up DACs in SAC & setting up the connectionImport the fact dataResult 1. Setting up DACs in SAC & setting up the connectionSetting up DAC in SAC has been discussed here in part 1 of this blog series. The detailed steps for setting up a connection between the two tenants can be found here. For a quick overview, refer to the following steps:Create an OAuth Client in SAC: Make sure to note the relevant information.Create a CDI Connection to SAC in Datasphere: Use the information noted in the previous step to complete this process. 2. Import the fact dataOnce the connection is created, I imported the fact data from a remote table in Datasphere from SAC. Once imported, you can add a graphical view on top of this remote table. 3. ResultWe can then preview the data from this view. To our surprise, my user can see all drink departments. This shows that the DACs that were created in SAC have not followed through to Datasphere. You can see below all drink departments coming through from SAC. Scenario 2In the second scenario, we want to verify that DACs applied within the Datasphere tenant are still enforced when the user accesses the data through SAC. Specifically, when a manager assigns a DAC to user 1, restricting their view to only Soft Drinks data in Datasphere, this restriction should persist when the user accesses the same data in SAC. The SAC story will access the data directly from Datasphere, bypassing any internal SAC models. Therefore, the DACs configured in Datasphere will remain effective, ensuring that user 1 can still only view the Soft Drinks data within SAC. StepsSetting up DACs in Datasphere & setting up the connectionImport Actual Data from Datasphere via an OData ConnectionResult 1. Setting up DACs in Datasphere & setting up the connectionSetting up DAC in Datasphere has been discussed here. For this example, In Datasphere, we assigned DACs to user 1 so that they can only view the Soft Drinks data. See data preview below. The detailed steps for setting up a connection between the two tenants can be found here & here. For a quick overview, refer to the following steps:Create an OAuth Client in Datasphere: Make sure to note the relevant information.Create an OData Connection to Datasphere in SAC: Use the information noted in the previous step to complete this process. 2. Import Actual Data from Datasphere via an OData ConnectionWe have discussed the steps to import the actual data from Datasphere via an OData connection here. Just to give a quick summary you must first start by creating a new model in the Modeler and select “Start with data.” Choose “OData Services” and select the connection you previously created. Create a new query, add the necessary query details, and select the desired table with up to 100 columns. After importing the data, you can clean and finalize your model. Finally, create a story to test and ensure everything is functioning correctly. 3. ResultWhen user 1 accesses the story within SAC, the DACs will maintain its effectiveness. This means that user 1 can only see the data related to the Soft Drinks department. This data is stored in Datasphere, the Data Access Controls (DAC) are, therefore, managed by Datasphere. The story in SAC accesses this data directly from Datasphere, not from an internal SAC model. Therefore, any DAC configured in Datasphere remains effective when the data is viewed through an SAC story. See the diagram below to see how the DACs work between the SAC and Datasphere tenants. ConclusionIn this final part of our series, we explored whether Data Access Controls (DAC) follow through when sending data from SAC back to Datasphere. We examined the setup of DAC in SAC and discussed the steps for establishing a connection between SAC and Datasphere. Our findings reveal that when data is stored in Datasphere, DACs are managed by Datasphere and remain effective when accessed via SAC. However, if data from an SAC model is imported into Datasphere, the DACs configured in SAC do not apply in Datasphere, as the data is not accessed directly within SAC. Understanding these distinctions is key to managing data effectively across platforms. Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
