Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

With the introduction of Analytical Models back in March 2023, SAP started to amend a well known limitation experienced by Datasphere customers using SAC as the consumption tool. This was the lack of multidimensional/analytical capabilities built in Datasphere models.

When it comes to the integration between DSP and SAC, this used to be a big problem because live DSP models could not be tweaked/customized in SAC in any way shape or form. This means there were no options to create measures at model level, therefore things like Exception Aggregation, or calculation after aggregation were simply a dream. 

Also, given that Analytical Datasets simply act as relational datasets, SAC auto-generated models, via the MDS engine, could not really push down many of the user actions, rather, it was some sort of SELECT, WHERE and GROUP BY. Essentially bringing all the data and only then using MDS to perform the logic defined by the SAC modeler. 

Analytical models, though still have a long way before they provide all the possibilities we have when using HANA as live data source (I.E all the options available in calculation views), they establish a break point from which customers do not need to use Analytical Datasets anymore. 

The issue comes when we start thinking about a migration strategy and realize there is no migration tool available. Creating an Analytical Model from an Analytical Dataset is very easy, but the Analytical model is a new object, which means the data source in SAC has to be changed at widget level, resulting in the loss of Filters, Calculated measures/dimensions, and formatting. 

Depending on the level of customization on a widget, this may take even hours, and it's not risk free, since we are essentially rebuilding something that was already tested and deployed in the production environment, requiring further test cycles, etc. 

What if there was a way to convert Analytical Datasets to Analytical Models, without having to change the data source in SAC?

This approach is not effortless, so it's still worth balancing how much effort it would take to simply generate the AM out of the ADS, re-point and rebuild the widget in SAC, and then edit the ADS to convert to a "Fact Model" (remember that the recommended and supported approach is Relational Dataset -- Fact Model -- Analytical Model). 

Essentially, the idea is as follows:

DSP Conversionç.png

To avoid having to modify the SAC widget, we need the new AM to replace the ADS, and we need it to have the same technical name so SAC does not lose the reference.

This can be achieved by following these steps (object names refer to the diagram above):

  1. Download the CSN definition of Model_3 (just to have a backup)
  2. Copy Model_3 and save it as Model_4. At this stage, keep it as ADS (Analytical Dataset). 
  3. Create an AM (analytical Model) from Model_4 and name it Model_5. 
  4. Download the CSN definition of Model_5.
  5. Edit the CSN file and replace all occurrences of "Model_5" with "Model_3".
  6. Delete Model_3 from the system.
  7. Upload the CSN definition previously modified and deploy the resulting object (Model_3). At this point we have an Analytical Model with the same Technical Name as the original Analytical Dataset. 
  8. Test your SAC widget.
  9. If everything is fine, proceed with the last step which is to convert Model_4 from ADS to FM (Fact Model). 

Please note that certain things might need manual adjustment after following this process. So far, that I could identify, associations in the underlying Fact Model will be identified in SAC by the name of the dimension used in the association join after moving to AM, whereas before, SAC was reading the custom name assigned to the Association itself. 

3 Comments
Labels in this area