An Overview of Simplified Modeling with SAP BW on SAP HANA (Part 2)
In this follow-up to my first article, “An Overview of Simplified Modeling with SAP BW on SAP HANA (Part 1),” I focus on the details of the advanced DataStore object (DSO) and how to use it. As the name suggests, the advanced DSO has a lot in common with the original DSOs from SAP BWs not running on SAP HANA. However, it is a much more flexible object. This flexibility is an improvement over the prior DSOs, and includes the ability to selectively control how, or even if, all of the three tables (which are the technical underpinnings of the advanced DSO) are used. This flexibility, combined with additional features such as support for planning applications, means that this one object can simplify your SAP BW architecture by replacing all your existing DSOs, InfoCubes, and even persistent staging areas (PSAs).
Positioning and Architecture of the Advanced DSO
Figure 1 shows the older SAP BW InfoProviders and the newer ones that can replace them, but only when for companies running SAP BW on SAP HANA, The advanced DSO, the subject of this article, is a replacement for all objects in SAP BW that have persistent storage. This includes all the previous types of DSOs, as well as PSAs.
Explore related questions
Like its predecessor, the older style DSOs (called classic DSOs in the remainder of this article), the advanced DSO uses one to three tables as its technical underpinnings. Also, the advanced DSO is also a queryable object. This means that you can directly write a BEx query with an advanced DSO as a source.
(Note: Although a query can be directly written against an advanced DSO, SAP recommends that you use a CompositeProvider for all BEx Queries instead, to add flexibility for changes into the future. Your advanced DSO, however, can be the underlying object to a CompositeProvider.)
Almost everything else about the advanced DSO versus the classic DSO is either new or different and, in my opinion, better than the old type. Although the structure of an advanced DSO upon activation creates three tables, it does not always use all three. How many tables the advanced DSO needs to use depends on the settings you use when deploying them. The decisions you make about which settings to use are based on how you want to use the advanced DSO as part of your larger data warehouse’s Layered Scalable Architecture (LSA) or, more accurately, LSA++, when you’re architecting your data warehouse running on SAP HANA.
How the Advanced DSO Replaces So Many Other Objects
I address the specifics later in the article, but for now, looking at Figure 1, you see that the advanced DSO can replace PSAs and InfoCubes as well as the older classic DSOs. This is a significant accomplishment and one that warrants some discussion.
The main reason advanced DSOs can replace PSAs and the older DSOs is due to their flexible settings. These setting change the way that the object uses the underlying tables because both fields, and InfoObjects, can be used to create an advanced DSO.
The main reasons an advanced DSO can replace an InfoCube has to do with why InfoCubes exist in the first place, and also due to the power of SAP HANA. InfoCubes are, under the covers, star schemas of tables joined together to form an object designed for storing summarized data (e.g., part number/customer ID/month level). This star schema design was needed and is used by most traditional disk-based data warehouses because reporting against objects that store the details (order- or transaction-level data) for millions of records was too slow. With SAP HANA as the underlying database, in-memory data access is so fast that the need to summarize data, and thus the need for InfoCubes, goes away. Now, with SAP HANA, to mimic the way InfoCubes handled new and changed records, all you need is one setting that is provided by this new advanced DSO.
Although the development of SAP HANA as the underlying database facilitated the replacement of InfoCubes with advanced DSOs, the other objects that were eliminated by advanced DSOs (the classic DSO and the PSA) is a not a result of being on SAP HANA, but rather due to the variety of options, settings, and features offered by advanced DSOs. This means that you may deploy many advanced DSOs using your LSA++ warehouse. However, with each use of an advanced DSO, the settings you use to create the object drastically changes both the way it is processing and storing the data, as well as how—and if—all three tables underlying the advanced DSO are used.
The point is that the purposes of the older PSAs and the classic DSOs have not changed and, in certain LSA++ scenarios, they are still absolutely needed. However, the advanced DSO’s settings let it function in so many different ways that this one new flexible object can replace the purpose of older objects. In the following section, I describe these settings and features in more detail.
Settings and Features of the Advanced DSO
As mentioned above, the settings and features provided by the advanced DSO make the structure and the functionality of each advanced DSO very different. When building the advanced DSO you need to think about what position it is holding in your warehouse. Once that’s been determined, you then choose the settings that make the advanced DSO behave in the way you need.
Figure 2 shows the General tab of an advanced DSO. This is where 95 percent of the settings are made.
(Note: The screenprint in Figure 2 shows the settings in the newer Eclipse-based SAP BW modeling tools.)
(Note: For the sake of transparency, I want to mention the External SAP HANA View option, highlighted in Figure 2. When selected, this automatically creates an SAP HANA information view when the advanced DSO is activated. This view can then be used by SAP HANA-based modelers and developers to combine this object with other views in the SAP HANA modeling toolset. Also for completeness, the Extended tables option (Figure 2) sets the advanced DSO not to use memory-based tables in SAP HANA, but rather to use disk-based tables in a product add-on to SAP HANA called Dynamic Tiering. When you use this option (the Extended tables option) you are trading the high performance of in-memory tables for the reduced cost of disk-based ones. Although there is some cost to the Dynamic Tiering option, it is a cheaper way to store data versus SAP HANA RAM. That said, not every query needs to be blazingly fast, so you may save some money by using Dynamic Tiering.)
Here, I want to focus on the modeling properties of advanced DSOs. These drive what kinds of tables are created and how they are used when the advanced DSO is activated. These settings are under the Modeling Properties section in Figure 2, and each has a significant impact on the overall use and behavior of the advanced DSO as part of your LSA++. I should mention that in the past, the different settings of the different types of DSOs determined how many tables were ultimately created (for example, while the classic DSO has three tables, a Write-Optimized DSO has only one). In the case of this new advanced DSO, activation always creates three tables, with the following naming convention:
/BIC/A…….1 = New data
/BIC/A…….2 = Active data
/BIC/A…….3 = Changelog
However, depending on the settings in Figure 2, the advanced DSO does not use all these tables. In addition, the advanced DSO, under the covers, creates views upon activation—but how these are used depends on the settings made in the screen in Figure 2. Depending on these settings, one of these views could be used during extraction from the advanced DSO to follow on targets and another could be used for reading data in a query.
In a similar way to the classic DSO, the first setting in Figure 2, Activate/Compress Data, determines if a job that processes the data from the new table and moves it to the change log needs to be run, or if it needs to be moved to an active data table. However, what exactly happens is driven by the settings nested in the boxes below this setting: Write Change Log; Keep Inbound Data, Extract from Inbound Table; and Unique Data Records. For example, if your advanced DSO needs to process the incoming changes from an extractor and behave like the classic DSO standard type, you would select the Activate/Compress Data and then the Write Change Log check boxes.
If, on the other hand, your goal is to use the advanced DSO in your new LSA++ like an InfoCube-structured data warehouse, you would set the Activate/Compress Data check box and the All Characteristics are Key, Reporting on Union of Inbound and Active Table option.
The rest of the settings in Figure 2 allow the new advanced DSO to behave like a classic DSO of the write-optimized type. In addition (although not shown here in this SAP BW 7.4 screenprint in Figure 2), in SAP BW 7.5 on SAP HANA there are two additional new options. The first is a Direct Update check-box option that allows the advanced DSO to be used like the classic DSO of the type Direct Update. The second option, the Planning Mode check box, allows the advanced DSO to support planning like the older transactional InfoCube.
As you can gather from this discussion, by selecting the appropriate check boxes you can create a flexible object that covers all the bases for physical storage of data in SAP BW. These options create an advanced DSO that can be used to cover the use cases of all the classic InfoProviders of the classic DSO, but not of the PSA. What allows the advanced DSO to function as a PSA is its ability to use fields and InfoObjects in its definition.
As you should be aware, nearly all the old InfoProviders used InfoObjects in their definitions. This includes InfoCubes and all the classic DSO types. You should also know that the PSA was designed to temporarily store detailed data in the format of the source system—as fields. The new advanced DSO is very flexible—it allows both fields and InfoObjects and gives you more options for how long data is retained. Figure 3 shows a field being added to define the tables of an advanced DSO, while Figure 4 shows an InfoObject being used.
If the advanced DSO uses all the fields in its definition, combined with the other settings you use, the advanced DSO is used the same way as a PSA was previously (e.g., making it a target for replicated but untransformed data).
More traditionally, the advanced DSO can be defined with InfoObjects as the structure for the underlying tables. One interesting note is that although advanced DSOs can be used to provide data to queries like classic DSOs, SAP is pushing the use of CompositeProviders for this purpose, by only offering the ability to enable navigational attributes on the CompositeProvider. (In a future BI Expert article, I will cover the basics of CompositeProviders.) Previously, with classic DSOs, the enable option for navigational attributes was on the DSO itself, not in the advanced DSO settings.
How to Simplify the Advanced DSO Settings Selection Process
Now, as you read this article you might love the idea of the flexibility provided by the new advanced DSO, but you might be apprehensive about making the wrong settings for the advanced DSO, and thus have it not work the way you need it to. SAP has thought of that.
Take a look at the screen in Figure 5. This BW Modeling – SAP HANA Studio screen is the first screen used to create the advanced DSO.
Right-click and, from the context-menu options that open, select Mandatory Information. This opens the Mandatory Information pop-up window in Figure 5. Look at the Create from Template section at the bottom. When any option in this section is chosen, the system makes the settings you need to mimic the behavior of the object chosen in the template property. For example, if you choose the DataSource radio button, the settings are defaulted to behave like a PSA. If you put an existing InfoCube in as the InfoProvider (in the Name and Source System fields), the settings are set to make the advanced DSO behave like an InfoCube. Finally, if you choose the last radio-button option, Model, once you click the Finish button, a list of SAP-supplied templates appears (Figure 6).
Choosing any option under Enterprise data warehouse architecture (shown in Figure 6) sets the default settings of the advanced DSO to meet the needs of your LSA++ scenario. However, choosing any of the Classic objects folder options allows the advanced DSO to mimic older classic DSOs of whatever type is selected. This makes the process of deciding on settings more simple, for those just wanting pure replacements of existing objects.
