SAP Knowledge Base Article - Public

3431993 - SAC Story Filter is not working as expected for some dimensions in linked Live and Import Models

Symptom

Both Models Live and Imported data model have identical data. Models Linked. For some filters if Value selected for one Model it should show the same selection on both charts, but it shows :No data is available to render"  

Environment

SAP ANALYTICS CLOUD 2024.3.2 

Reproducing the Issue

Open the story with two Charts based on linked Live and Imported data Models

Add filters based on both Models

Select a value in the first Filter

Selection should be reflected in both Charts, but we observe “No data is available to the chart to render” on the second Chart

Cause

Background information
When two models have one or more dimensions linked this enables two features in SAP Analytics Cloud (SAC) stories: blending and filtering across models (FAM).

Filtering Across Models (FAM)
Involves linking two models on one or more dimensions and then creating source filters on dimensions of one model which are then propagated to the other model using the most performant technical solution available.

Blending
Involves linking two or more models on one or more dimensions and then selecting accounts/measures and dimensions from two or more models in a single widget (e.g. a chart or table).

Resolution

1. Update the process by which you acquire the data for the "Import Model" to modify the linked dimension members so their ID will match the corresponding model's dimension internal key values.
2. Remove the secondary linked model from the "Data Source" section of all your widgets unless you truly intended to use Blending.

Review this influence portal idea and vote for it as it should make the necessary data acquisition workflow for the import model easier: https://influence.sap.com/sap/ino/#/idea/270359

See Also

Filtering Across Models - Linking Compound Dimensions

Problem
There is no guarantee that filtering across models (FAM) can work out of the box when linking (BW) compound dimensions with non-compound dimensions.

If we have an acquired dimension with "ID" or "Description" attributes whose members match the DISPLAY_KEY of a linked (BW) compound dimension it may not be obvious why a (BW) compound dimension filter results in no matches found on the SAC acquired data model side, or vice versa. The challenge comes from the attributes used for filtering and displaying values:

  • SAC filters on (BW) compound dimensions based on the KEY attribute, and the DISPLAY_KEY attribute is used as the "ID" attribute for all other purposes.
  • Even when a member selector is showing "ID" or "ID and Description" the DISPLAY_KEY value is shown as the "ID" and the default text attribute (if it exists) is shown as the "Description".

Compound dimensions may have more than one compounding parent and the conversion of KEY to DISPLAY_KEY is a black box from SACs perspective so it cannot automatically adapt. On the server side, per dimension, there are conversion functions that do the conversion from KEY to DISPLAY_KEY and vice versa. Customers can even implement these conversion functions (called conversion exits in the ABAP world).

Solution
The way to help end users in SAC to compare (BW) compound dimension values and SAC acquired dimension values would be to create the SAC acquired dimension "ID" attribute based on the (BW) compound dimension KEY.

If the acquired data model is created by importing data directly from a BW query it should be possible to map the KEY attribute to the SAC acquired dimension "ID" during the data acquisition (DA) or wrangling step. If, however, the data is coming from another source like a csv then the conversion steps would need to be derived by looking at the (BW) compound dimension definition.

Depending on the situation there should be multiple options to look up the KEY values of a compound dimension:

  • The easiest way is just to use the SAPGUI and display the DB table contents of the master data tables (or the SID tables if the dimension has no master data table).
  • The compound dimension might not be owned by BW (i.e. the values are read by BW on the fly via APIs or dimension values might come from HANA views). In this case one might use the ABAP development tools (ADT) or HANA Studio.

For example, if a compound dimension with 2 compounding parents had the following set of DISPLAY_KEY and KEY tuples:

|----------------------------|-------------------------------|
| DISPLAY_KEY (External Key) |       KEY (Internal Key)      |
|----------------------------|-------------------------------|
| "AA0009/#"                 | "AA0009"                      |
| "AB0009/02581"             | "AB0009            02581"     |
| "AC000313/ZZ000313"        | "AC000313          ZZ000313"  |
| "XY235944/#"               | "XY235944"                    |
| "XY235944/1899600"         | "XY235944          1899600"   |
| "XY235944/XYDE"            | "XY235944          XYDE"      |
| "YZ236120/165700402"       | "YZ236120          165700402" |
| "UV2092/1900402"           | "UV2092            1900402"   |
| "WV99605/1940402"          | "WV99605           1940402"   |
|----------------------------|-------------------------------|

DISPLAY_KEY to KEY conversion steps would be:

  • Split the DISPLAY_KEY value on "/" into left string and right string
    • If right string is "#" then KEY is equal to the left string
    • Otherwise
      • Take left string and pad it to 18 characters by appending spaces
      • Then append right string to get the final KEY value

These steps can be expressed as transforms/formulas on any import of data that may only include the DISPLAY_KEY information, but needs the "ID" attribute set to the corresponding KEY value so features like FAM and blending can work.

Keywords

KBA , LOD-ANA-DES , Story Design & Visualizations , Problem

Product

SAP Analytics Cloud 1.0