Transaction data usually contains master data keys that represent different characteristics of an entity, such as a product. The texts (short/medium/long) of the various products together with the attributes and hierarchies form the master data associated with the characteristic.
In classic SAP BW, this information is usually stored in InfoObjects. In (SAP) reporting tools, InfoObjects offer the convenient option of switching between the display of texts or keys/IDs or displaying both. With SAP BW/4 HANA, it is also possible to model texts using Open ODS views.
Table of contents
2. Modeling texts with InfoObjects
3. Modeling texts with Open ODS Views
4. Creation of the Open ODS view (texts)
5. Interim result for the 1:1 use of Open ODS View texts
6. Workaround: Modeling texts as attributes of Open ODS Views and creating Reporting Calculation Views
6.1 Modeling Open ODS View with "text attributes"
6.2 Creation of Reporting Calculation Views and Labeling
8. Conclusion
Depending on which technical object is used for master data modeling and how frontends access SAP BW data, there are functional restrictions and special features. In this blog entry, we provide an insight into the different types of modeling and the consequences from a front-end perspective. Our investigation was carried out with SAP BW/4 HANA 2.0 SP03 and Analysis Office as the frontend.
Types of access
For our analysis, we look at four scenarios of how a front end accesses SAP BW data:
- Composite provider via the BW server
- Query via the BW server
- Calculation view based on the composite provider
- Calculation view based on the query
Modeling texts with InfoObjects
In our first scenario, we use an InfoObject to model the product texts.
Our analysis shows that in this constellation there are no restrictions on the use of texts in frontends:
| Short title | Object for front-end access | Texts available |
|---|---|---|
| A | Composite Provider / ADSO with associated InfoObject (including texts) | ✔ |
| B | Query on the composite provider A | ✔ |
| C | generated calculation view on the composite provider of A | ✔ |
| D | generated calculation view for the query from B | ✔ |
| Legend | |
|---|---|
| ✔ | Front-end tool receives the typical key/text semantics of an InfoObject |
| ✘ | Front end only receives keys |
Modeling texts with Open ODS Views
An Open ODS View is used in this scenario - everything else is identical to the InfoObject scenario.
Creation of the Open ODS view (texts)
Open ODS views can be created in the BW Modeling Tools using a wizard. The wizard is opened by right-clicking / New / Open ODS View.
The technical name and semantics must then be defined. In our case, this is the semantic text.
In the next step, the source type for the texts must be defined.
A specific object must be selected.
Additional master data sources can now be connected if necessary.
A representative key field must be defined under the Texts tab. This serves as a key field for the assignment of texts in the association.
Interim result for the 1:1 use of Open ODS View texts
If an Open ODS View is modeled as described, there are considerable restrictions for HANA-side access. If SAP frontends can also access the BW data very well via the BW server, most nonSAP frontends use the MDX interface with its disadvantages (functional & performance). From the point of view of nonSAP frontends, access to HANA Calculation Views to access SAP BW data is usually better on balance. It is therefore important to note the restriction in the modeling. Open ODS views cannot be used without further ado.
| Short title | Object for front-end access | Texts available |
|---|---|---|
| E | Composite Provider/ ADSO with associated open ODS View (including texts) | ✔ |
| F | Query on E | ✔ |
| G | generated Calculation View from E | ✘ |
| H | generated Calculation View from F | ✘ |
| Legend | |
|---|---|
| ✔ | Front-end tool receives the typical key/text semantics of an InfoObject |
| ✘ | Front end only receives keys |
Workaround: Modeling texts as attributes of Open ODS Views and creating Reporting Calculation Views
In this chapter, we would like to show you a workaround for these restrictions.
The workaround consists of two components:
1) Modeling Open ODS View with "text attributes"
These "text attributes" can then be added to the association as navigation attributes in the composite provider.
2) Creation of reporting calculation views and labeling
A separate calculation view is created, which contains the respective generated calculation view. The generated calculation view must be connected in a projection. A separate calculation view is necessary as changes in the generated calculation view would be lost if the composite provider is activated. The necessary settings are made in the semantics node of the calculation view.
- Hiding the text attribute
- Adding the text attribute as a "Label Column"
Results of the workaround
The workaround also allows Open ODS views to be used for HANA-side access. Due to the limitations of pure "text" Open ODS views, we recommend modeling the texts additionally as attributes.
| Short title | Object for front-end access | Texts available |
|---|---|---|
| I | Composite provider with associated Open ODS View (including texts as attributes & texts) | ✔ |
| J | Query on I | ✔ |
| K | generated Calculation View from I | ✔ |
| L | generated Calculation View of L | ✔ |
| M | Mapping of key-text relationship through join in Calculation View (no association on BW side) | ✔ |
| Legend | |
|---|---|
| ✔ | Front-end tool receives the typical key/text semantics of an InfoObject |
| ✘ | Front end only receives keys |
| ✔ | Requires own Reporting Calculation View |
Conclusion
The association of master data in composite providers is a very important and positive change brought about by SAP BW/4 HANA. While everything still works in classic SAP BW scenarios, the details are very important in mixed scenarios. In our experience, these details include not only the modeling but also the BW release used. SAP continues to optimize the BW and it has been shown that the system behavior can change depending on the SP level.
Due to the front-end solution used, it may be necessary to access SAP BW data via HANA Calucation Views despite this complexity. In our article, we show a way to overcome the functional limitations of Open ODS Views. The decisive factor for the choice of modeling is therefore not whether texts can be displayed or not, but other functional aspects (e.g. stability vs. agility and development speed).
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
