Replace a Model in the Optimized (Unified) Experience

[Tunir]

Dashboards are essential for tracking the performance of an organization as they show the key metrics in one place. It is achieved by following a detailed step-by-step process. For instance, a dashboard lifecycle will have various stages such as planning, requirements gathering, prototyping, build and validation, and then go-live and maintenance.

For the design process to be successful, it is crucial to have the right features. With the integration of Stories and Analytic Applications into a single asset artifact, we simplified the process for users by giving them a platform to design and enhance dashboards with scripting, custom widgets, and other developer capabilities.

However, there is a downside to this flexibility and vast feature set. It makes it difficult for customers when transitioning from the prototyping to build and validation stage. For most customers, it means having to rebuild the dashboard widget by widget.

With this pain point in mind, we are pleased to announce that the initial release of model replacement within the Optimized (Unified) Experience will be possible in the 2024 Q2 QRC (Quarterly Release Cycle) or 2024.06 for Fast Track customers. It will be limited to a per model basis and the replacement model must be of the same data source type (i.e. SAP BW, SAP HANA, SAP Datasphere, and so on) and structure (i.e. SAP BW 1-Structure Query, SAP BW 2-Structure Query, Model with Accounts and Measures, and so on).

Let’s explore more about the functionality that will be included with the first release of replacing a model in a story.

Supported Replacement Models

With the initial release, we will support the replacing models that have the same data source type and same number and type of structure dimensions.The original model and replacement model do not need to share the same connection nor have the same number of objects (accounts, measures, dimensions, or properties). However, the version level of the system where the replacement model is located is meant to be the same or higher than that of the system on which the original model is located.

Let’s look at a few examples of valid versus invalid replacements:

• Model A (a SAP BW 2-Structure Query on Connection A) to Model B (a SAP BW 2-Structure Query on Connection B) is a VALID replacement as the data source type and the number and type of structure dimensions is the same
• Model A (a SAP BW 2-Structure Query on Connection A) to Model B (a SAP BW 1-Structure Query on Connection A is an INVALID replacement as the number and type of structure dimensions is not the same
• Model A (SAP BW) to Model B (SAP HANA) is an INVALID replacement as the data source type is different

These are the list of data models that are supported as original and replacement models:

• SAP Datasphere Analytic Model
• New model type with measures, with or without accounts (Planning or Non-Planning)
• New model type with multiple account hierarchies
• New model type with user-managed Time dimension or Week pattern
• SAP HANA
• SAP BW (includes 2-Structure Queries)
• S4/HANA

Some data models cannot be used as replacement models because their feature set is superseded by alternative models for which further new features are being developed. These types of models can only be used as original models and can be replaced by their designated alternative models. For example:

• An SAP Datasphere Analytic Dataset can be replaced by an SAP Datasphere Analytic Model
• A Classic Model (Account Only) can be replaced by a New Model with accounts and measures
• A Public Dataset can be replaced by a New Model with measures (and no accounts)

Replacing a Data Model in Stories

Replacement within Stories is done on a per model basis. The workflow is accessible via the Story Toolbar - Tools Section - Add New Data dropdown, where each model in the story which supports replacement will have a new menu option called "Replace..

⚠️  NOTE the option Replace… will be disabled for models that are not supported with the initial release of model replacement. For example, SAP Cloud Application Models, SAP Universe, and so on…

Upon the selection of Replace..., the user is guided via the same workflow as changing the data source on a widget. You can either replace the model with one that is already used in the story or select a new one.

⚠️  NOTE for models that are used within the story, we automatically will hide models that are not compatible with the original model. 

Upon selection of the replacement model, a warning is displayed to inform the user about the risks of model replacement. It is a dismissible warning that is remembered for the same edit session. It means that refreshing the browser or navigating to another story will cause the warning to reappear.

As the next step, we will add the data model assuming it is not already used within the story and will analyze all the objects that are used by the original model. You are then in the Model Replacement experience which consists of two sections: Mapping and Summary.

Mapping

Within Mapping there are a few sections that we recommend a Designers to familiarize themselves with. These include: 

1. Replace Model Header and Global Settings
2. Replacement Objects
3. Mapped Objects and Original Objects in Use
4. Footer & Warnings

Let’s dive deeper into each section of the dialog.

1. Replace Model Header and Global Settings

These are settings that will impact all objects within the Mapping Dialog. For example, it includes Reset All Mapping, Display Options (ID, Description, or ID & Description), Filter Objects (All, Mapped, Unmapped), and Sort.

2. Replacement Objects 

It includes all objects from the Replacement Model. For example, in the screenshot we have selected the New Model Type with an Account Dimension as the Replacement Model. It means that there are three sections available: Accounts, Measures, and Dimensions. Within each header, we show the total number of objects that exist (includes Properties). We do not show hierarchies as these will be available within the Mapped Objects and Original Objects in Use section once a dimension is bound. 

⚠️  NOTE these sections will be different depending on the structure of the replacement model that is selected. For example, for an SAP BW Model with 1-Structure would have two sections: Measures and Dimensions.

There are a few objects that will appear in a disabled state. It is because these objects are either mapped or are unavailable until the grouping (parent) object has been mapped. For example, Location is an unmapped object that has several properties such as Area Code, Latitude, Long, and so on. These properties will remain in a disabled state until Location is mapped.

⚠️  NOTE there are some objects (i.e. Version) that are mandatory and do not have an option to reset the mapping as it is needed to ensure the replacement process does not break. 

For the various grouping dimensions, we also have icons to represent the dimension type as well as the types of enrichment and properties which are associated with the dimension. For example, the icons on the left side indicate the dimension type (e.g. general, version, time) and the icons on the right side indicate the enrichment and type of properties (e.g the presence of hierarchies, geo properties, image properties, and so on).

3. Mapped Objects and Original Objects in Use

It includes the original models objects that are bound to at least one data related object (i.e. Chart, Table, Geographical Visualization, Calculation, Threshold, and so on). We do not show unused objects from the original model as there is no added value to the user as mapping them would have no impact. 

You will also see the objects that have been auto mapped either because it is mandatory object or was because of our auto mapping detection logic. Our auto mapping detection logic makes it easier for users who are trying to replace a model with one that closely matches the original model - at least when it comes to the objects in use. In these cases, there would be little to no work required by the user as all objects would be automatically mapped. Some auto mapped selections cannot be overridden (e.g. the version dimension) because they are mandatory, but others are a best effort to match objects with the same type and id or description and could be updated as part of the mapping process.

For unmapped objects, there are two methods to map an object: Drag & Drop or Selection on Empty Unmapped Object.

Drag and Drop

With drag and drop, we will limit the user to mapping objects of the same object type. For example, a user cannot map a measure to account, a hierarchal dimension to non-hierarchical, and so on. 

For objects of the same type, we will do validation as soon as the drag object is mapped. It is because there are some objects that while they might appear the same, the semantic type is different (i.e. Parent Child Hierarchy versus Level Based Hierarchy).

 

Selection on the Empty Unmapped Object

With the selection on the empty unmapped object, users are provided a filtered dropdown list. It is limited to objects of the same type. We separate the list by supported vs unsupported objects depending on the semantic type. It provides customers a quick way to map the unmapped objects. 

Within this section there is additional system feedback that is available for mapped objects. Users are provided information, warnings, and errors depending on the mapped object.

• Information: is low impact context that is available to the user around differences in the formatting of the object. For example, number of decimal places, scale, account type, and so on. 
• Warning: is an indication that while the objects and semantic type match, there is a difference that is detected that could result in no data shown (i.e. difference in number of hierarchy levels defined)
• Error: is an indication that the semantic type of the object is different (i.e. Parent Child Hierarchy vs Level Based Hierarchy, Coordinate vs Area Enriched Geographical Dimension, and so on).

4. Footer & Warnings

Within the footer, we will show the consolidated list of all information, warnings, and errors that were displayed on each object token.

There is also a review and cancel button. We will also allow you to enter the summary page as long as there isn’t an error which represents an invalid mapping. We will allow you to enter the summary page even though all objects have not been mapped.  

Summary

Within Summary there are a few sections that we recommend a Designer to familiarize themselves with. These include: 

1. Summary Header
2. Mapping Issues
3. Story Asset Issues
4. Additional Impacts
5. Footer

Let’s dive deeper into each section of the dialog to familiarize ourselves with the Summary Dialog.

1. Summary Header

It provides an overview of the previous page by informing the Designer on which model is being replaced. It also includes a count of mapped objects.

There are additional settings that will apply to all sections such as Display Options (ID, Description, and ID & Description), Expand All, and Collapse All.

2. Mapping Issues

It will provide a summary of the unmapped objects from the previous page as well as any warnings or info tips that may have been missed. You will not see any of the errors from the previous page as we prevent you from entering this dialog when there is the detection of at least one error caused by invalid mapping.

3. Story Asset Issues

It provides a summary of the impacted assets and controls as a result of the mapping issues. We break it down into Story Assets such as Linked Dimension, Account Input Control, Color Sync, Thresholds, and so on.

We also then provide a detailed overview per page as well as each story component per page. While there might be some duplicate information, we wanted the Designer to understand the impact per story component.

4. Additional Impacts

These are a summary of controls that will not be remapped as these are existing limitations with Model Replacement. The list of items will dynamically update based on what is used within the Stories.

5. Footer

Within the footer, you will have the option to complete the model replacement, go back to edit any of the mapped objects or cancel the entire replacement.

Completing the Replacement

Once the Designer clicks on Replace Model we will reload the active page and replace the objects. It is not an undoable action and we leave the story as marked as dirty in case you want to discard the changes from the replacement.

For objects that were left unmapped, the individual story components that are impacted will remain in a broken state. There binding will remain and it would be up to the Designer to remove the broken object from the story component. For example, in the screenshot, the location dimension was not bound at the time of the model replacement and remains in a broken state.

It is through this enhancement, we continue to expand the feature set that is available in SAP Analytics Cloud and address a major gap when transitioning from the prototyping to build and validation stage. It makes it easier for Designer to replace an existing model within Stories.