The legacy VDT will be, after co-existing with the new VDT in stories for some time, deprecated in SAP Analytics Cloud.
The planned deprecation timeline will be as follow:
Legacy VDT:
Of course, this does not mean that legacy VDTs should be discarded – a manual migration into the new VDT in stories is still possible before the deprecation in story and boardroom in QRC2 2023. Generally, the migration method consists of first bringing the legacy VDT into a classic story (as VDT widget) and the subsequent adjustments of specific calculations there.
(Note: After the migration, do not convert the classic story into optimized view mode just yet, to continue copy/pasting the migrated VDT into further artefacts. It is planned to also enable this ability for stories in optimized view mode for future releases.)
In this blog post we’re going through the migration of a sample VDT together. So let’s get started!
We’re starting out with this legacy VDT:
We shall now transform it into a new VDT widget that looks and behaves exactly like the original but enables us to benefit from latest innovations in SAP Analytics Cloud, such as the new model and optimized design experience.
The initial migration step will already trigger automatic migration for all nodes possible. This initial step is carried out by bringing a VDT widget into a classic story, selecting Display Existing Value Driver Tree, opening the builder panel and triggering the Transform button. The result already looks familiar, but you will spot differences, which we will tackle manually in the following steps.
One of the main differences between new and legacy VDT is that the new VDT doesn’t allow to explicitly trigger a simulation like it was done before. Instead, all calculations are performed instantly after data has changed. We’ll use model calculations and story calculations to achieve this. In our example we will set our new VDT widget to show a version without the data that was previously written by legacy VDT simulation, so it’s easier to spot the gaps requiring calculation input/adjustments. With the simulation data removed, our VDT looks like this:
You will notice that all nodes have been converted to data source nodes. All nodes that have already been data source nodes before should work as expected and do not require manual rework.
So, now let’s tackle the gaps one by one. We’ll start with the volume node. It was a year-over-year node in the legacy VDT. We will now create the year-over-year calculation with the new iterate formula in the model. So let’s head over to the modeler and add a new account volume_yoy. We add the iterate formula like shown in the screenshot below. The formula takes the value from the first year of the calculation from the Volume account and then grows it year over year by applying Market Share Growth as growth factor to the value of the previous year.
The formula above also utilizes the inverse function to enable the calculated account for data entry. If you enter data here – whether in a VDT or table widget – it will modify the Market Share Growth account then. When we set this new volume_yoy account on the volume node in our VDT, this gives us the data we want:
The expense node in this sample VDT can be treated in a similar fashion.
The revenue node in our VDT was previously a simple calculation node that calculated price times volume. We can simply mirror this calculation in the model by entering a matching formula. Note that you can create much more complex calculations here than was possible with simple calculation nodes in VDTs alone. Also note that if your legacy VDT node used to calculate on details instead of aggregate, you need to set up exception aggregation dimensions correctly for the account in the modeler as well. Very likely you did this already, so your sums show up correctly in grids. In this example case we set the product and date dimension as exception aggregation, so that the price*volume calculation for each product is done before the aggregation. See this help article for details on when and how to use exception aggregations if your calculations need to be performed on details.
Last one left is the Balance node. In our legacy VDT this was a union node that united the revenue and expense nodes. The best way to do this with new VDTs is to set up your accounts in a hierarchy, so they automatically sum up properly. Of course you could again use any calculation that sums up individual accounts. In our example, we introduce a new balance account and set it as the parent for the Revenue and Expenses accounts, so they sum up automatically.
Check out additional information on migration of legacy VDTs and the VDT widget:
A big thank you to André Seiffert for a great collaboration and providing most of the input to this blog post!
The planned deprecation timeline will be as follow:
Legacy VDT:
- 2022 QRC4:
- Can be opened, viewed, and executed in VDT designer
- Can no longer be created, copied, or edited, but will remain functional in stories and boardroom
- 2023 QRC2:
- Can be opened, viewed, and executed in VDT designer
- Can no longer be viewed in stories and boardroom (Replaced by placeholders)
- 2023 QRC3:
- Legacy VDT designer will be completely removed, meaning there will be no more access to legacy VDT
Of course, this does not mean that legacy VDTs should be discarded – a manual migration into the new VDT in stories is still possible before the deprecation in story and boardroom in QRC2 2023. Generally, the migration method consists of first bringing the legacy VDT into a classic story (as VDT widget) and the subsequent adjustments of specific calculations there.
(Note: After the migration, do not convert the classic story into optimized view mode just yet, to continue copy/pasting the migrated VDT into further artefacts. It is planned to also enable this ability for stories in optimized view mode for future releases.)
In this blog post we’re going through the migration of a sample VDT together. So let’s get started!
We’re starting out with this legacy VDT:
Example of legacy VDT before migration
We shall now transform it into a new VDT widget that looks and behaves exactly like the original but enables us to benefit from latest innovations in SAP Analytics Cloud, such as the new model and optimized design experience.
Partial Automatic Migration
The initial migration step will already trigger automatic migration for all nodes possible. This initial step is carried out by bringing a VDT widget into a classic story, selecting Display Existing Value Driver Tree, opening the builder panel and triggering the Transform button. The result already looks familiar, but you will spot differences, which we will tackle manually in the following steps.
Check your VDT after the partial automatic migration for nodes requiring adjustments
One of the main differences between new and legacy VDT is that the new VDT doesn’t allow to explicitly trigger a simulation like it was done before. Instead, all calculations are performed instantly after data has changed. We’ll use model calculations and story calculations to achieve this. In our example we will set our new VDT widget to show a version without the data that was previously written by legacy VDT simulation, so it’s easier to spot the gaps requiring calculation input/adjustments. With the simulation data removed, our VDT looks like this:
Remove simulation results to spot gaps requiring calculation input/adjustments
Data Source Nodes
You will notice that all nodes have been converted to data source nodes. All nodes that have already been data source nodes before should work as expected and do not require manual rework.
YoY Node
So, now let’s tackle the gaps one by one. We’ll start with the volume node. It was a year-over-year node in the legacy VDT. We will now create the year-over-year calculation with the new iterate formula in the model. So let’s head over to the modeler and add a new account volume_yoy. We add the iterate formula like shown in the screenshot below. The formula takes the value from the first year of the calculation from the Volume account and then grows it year over year by applying Market Share Growth as growth factor to the value of the previous year.
The iterate formula
The formula above also utilizes the inverse function to enable the calculated account for data entry. If you enter data here – whether in a VDT or table widget – it will modify the Market Share Growth account then. When we set this new volume_yoy account on the volume node in our VDT, this gives us the data we want:
Year over year calculation results
The expense node in this sample VDT can be treated in a similar fashion.
Simple Calculation Node
The revenue node in our VDT was previously a simple calculation node that calculated price times volume. We can simply mirror this calculation in the model by entering a matching formula. Note that you can create much more complex calculations here than was possible with simple calculation nodes in VDTs alone. Also note that if your legacy VDT node used to calculate on details instead of aggregate, you need to set up exception aggregation dimensions correctly for the account in the modeler as well. Very likely you did this already, so your sums show up correctly in grids. In this example case we set the product and date dimension as exception aggregation, so that the price*volume calculation for each product is done before the aggregation. See this help article for details on when and how to use exception aggregations if your calculations need to be performed on details.
The price*volume calculation is an example requiring exception aggregation
Union node
Last one left is the Balance node. In our legacy VDT this was a union node that united the revenue and expense nodes. The best way to do this with new VDTs is to set up your accounts in a hierarchy, so they automatically sum up properly. Of course you could again use any calculation that sums up individual accounts. In our example, we introduce a new balance account and set it as the parent for the Revenue and Expenses accounts, so they sum up automatically.
A way to unite two nodes is to create a new parent node for both
Check out additional information on migration of legacy VDTs and the VDT widget:
A big thank you to André Seiffert for a great collaboration and providing most of the input to this blog post!
- SAP Managed Tags:
