With SAP Datasphere, SAP is consistently developing its data platform towards the cloud future. For many BW users, the question arises: How do I map familiar BW concepts such as customer exit variables in the new world? The answer: derived variables in SAP Datasphere. But is this answer valid?
In this article, we look at the new so-called derived variables (Derived Variables) by demonstrating a typical customer exit use case in SAP Datasphere and try to test this answer in practice.
What are customer exit variables in SAP BW?
In SAP BW, customer exit variables (type "Customer Exit") allow the dynamic determination of variable values at runtime. ZFor example, the first day of the current month, the current user or a complex hierarchy level. The logic is implemented in ABAP via the user exit include ZXRSRU01 (or BADI_RSR_VARIABLES_EXIT) and offers great flexibility.
Typical application scenarios:
- Automatic selection of time periods
- Restriction of data depending on user role
- Logic-controlled filter values in queries
Derived variables in SAP Datasphere - What are they?
SAP Datasphere offers a comparable concept with derived variables. These are defined within an analytical model. Unlike in BW, the logic is not mapped in ABAP, but in the graphical user interface or using SQL script.
A derived variable is a variable whose value is not entered directly by the user but is determined automatically by the system via a lookup table (lookup entity). This lookup entity can be e.g.For example, this lookup entity can be a table or a view in which the relevant information is stored.
The derivation works in such a way that, based on a known input value (such as a country), a corresponding other value (such as a country) is automatically derived.currency) is automatically found and set. This derived value is not displayed in the input dialog because the user does not see or change it directly. It is determined by the system in the background.
Derived variables: An application example:
Derived variables are ideal for use cases in which standardized filter values are required dynamically, such as
- Automatic filtering to the current day/week/month
- Filtering to the logged-in user for data restriction
- Dynamic calculation of time periods without user input
In the following example, we will demonstrate a use case by dynamically defining date fields of a fact source using self-defined time intervals. Intervals should not be defined by manually entering date values, but by simply selecting an interval definition.
Implementation steps:
So that the input variables have a dynamic derivation from a lookup entity instead of manual input, three views with the semantic usage "Dimension" are required:
1st dimension:
Dimension tag can be generated with little effort in the Space configuration.
2nd dimension: Time intervals
The dimension of the time intervals is a view behind which there is SQL logic that determines the definition of the selection list with dynamic date assignment in this use case. Irrespective of this demo case, this view does not necessarily only have to support the processing of data. It can define any input object.
3rd dimension: Lookup entity.
This view is necessary for association with the analytic model and it must always return only one value after the input parameter has been entered.
The following graphic shows the interaction of all three dimensions:
1st dimension Time intervals:
For our use case, we need two dynamic selection values: Current Month & Last Month. To realize these values through a view, we build an SQL query that returns the following columns:
Assuming today is 22.05.2025, the return would be as follows:
| Description | Start date | End date |
|---|---|---|
| Current Month | 01.05.2025 | 01.04.2025 |
| Last Month | 31.05.2025 | 30.04.2025 |
The following SQL query is used for this purpose:
2nd dimension lookup entity:
The lookup entity is the object that is later associated with the analytic model in order to transfer values to the parameters. This view has the task of filtering and outputting individual data entries based on dynamic variables.
The following steps make the lookup entity available for use; the following points must be observed:
- A filter node needs this view to be able to return single values
- This filter is based on input variables that uniquely recognize and return the start and end date
- The Variable input guides the selection list through a logical association to the dimension in step 1 (see screenshot).
3. fact source and analysis model:
Now the fact source, whose date values need to be filtered, also requires dynamic input variables. All created input variables are later brought together like a puzzle:
Finally, all objects and variables are linked. The input variables of the fact view must be set so that they derive their values from the lookup entity.
The previous use case is a small demonstration of what is possible with dynamic lookup variables in Datasphere. This scenario can be executed with any values (cost centers, organizational units, etc.).
Does this replace the functionalities of the customer exit variables?
Alled variables in SAP Datasphere are not at all known as "Customer Exit Datasphere Edition". They replace therefore not the customer exit variables from SAP BW completely, form however part of the functionality and can be used for many standardscenarios scenarios.
Here is a brief comparison:
| Feature | SAP BW Customer Exit | SAP Datasphere Derived Variable |
|---|---|---|
| Technology | ABAP based | No ABAP - graphical or expression-based |
| Flexibility | Very high (programmable) | More limited, but growing |
| Runtime | When executing the query | When executing the analytical model |
| Context dependency | Complete (users, roles etc.) | Restricted (user name, date, possibly more) |
| Implementation | EXIT_SAPLRRS0 or BAdI | Within the analytical model, if necessary centrally via lookup entities |
| Maintainability / upgrade friendliness | Maintenance-intensive, sometimes complex | More intuitive UI, cloud centric |
Conclusion
Derived variables ("Derived Variables") offer a modern approach to analyze typical use cases of BW exit variables in the cloud world. As part of a migration, it is therefore worth analyzing exactly which tasks were previously solved via customer exits and how these requirements can be met today with the possibilities of SAP Datasphere can be mapped. This shows that some functions can be implemented directly via Derived Values, while others require alternative solutions within the new data model.
Our SAP technologies at a glance
Do you have any questions? Please feel free to contact us!
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
