ADSO Scenario Description

 Acquisition Layer
 Data Acquisition Layer (including corporate memory)
 Corporate memory with compression feature
 Corporate memory with reporting option
 Propagation Layer
 Reporting Layer
 V-Layer

Planning (BW 7.50 only)

Acquisition Layer
With the DataStore object (advanced) (also known as ADSO), you can create objects that
cover the "write-optimized" use cases for classic DataStore objects (ODSOs).

Data Acquisition Layer (including corporate memory)

The first figure shows a typical corporate memory. Requests will be loaded into and extracted
from the inbound table. The data doesn't get aggregated, neither by the transformation nor by
the ADSO.
Take Example as Below
After the data loaded into the Provider, it can be found in the Inbound table:

The data doesn't get aggregated, neither by the transformation nor by the ADSO.

Used tables:

Inbound table /BIC/A*1 - /BIC/AGA_ADSO31 in our particular case

Corporate memory with compression feature

The second figure shows a corporate memory with compression feature. Requests will still
be loaded into the inbound table. Old requests that are no longer needed on detailed level can
be compressed (aggregated according to the semantically key) into the active data table.
Take Example as Below
ADSO Scenario Description

Corporate memory with compression feature

After the data loaded into the Provider, it can be found in the Inbound table:

The requests that are no longer needed on detailed level, can be compressed by activating the
request itself:
After the request activation, the data can be found in the Active table:

Used tables:
Inbound table /BIC/A*1 - /BIC/AGA_ADSO61 in our particular case

Active table /BIC/A*2 - /BIC/AGA_ADSO62 in our particular case

Corporate memory with reporting option

The third picture shows an corporate memory with reporting option. The loaded requests can
be activated but will remain in the inbound table on detailed level. This enables the user to
report on data of the inbound layer without losing the detailed information.
Take Example as Below

Corporate memory with reporting option

After the data loaded into the Provider, it can be found in the Inbound table:

The requests can be activated:

Then the request can be found in the Active table:

The request will remain in the inbound table on detailed level:

Used tables:
Inbound table /BIC/A*1 - /BIC/AGA_ADSO71 in our particular case

Active table /BIC/A*2 - /BIC/AGA_ADSO72 in our particular case

Propagation Layer

The following figure shows an ADSO covering the "Standard" use-case of ODSOs. Requests will
be loaded into the inbound table. To report on the data, the user has to activate the loaded
requests. The data is then transferred into the active data table and the history (delta) is
stored in the change log. The change log is also used to rollback already activated request
(recovery of the active data table).
Take Example as Below

Standard DSO

After the data loaded into the Provider, the request can be found in the Inbound table:

The request needed to be activated:

The data is then transferred into the active table:

And to the Change Log table:

Used tables:

Inbound table /BIC/A*1 - /BIC/AGAADSO11 in our particular case

Active table /BIC/A*1 - /BIC/AGAADSO12 in our particular case

Change log table /BIC/A*1 - /BIC/AGAADSO13 in our particular case

Reporting Layer

The next figure shows an ADSO covering use-cases where InfoCubes were used
before. The inbound table acts as "F"-table and the active data table as "E"-table. This is the
only ADSO which provides consistent and stable reporting (e.g. red requests won't show up in
the query) but requires a delta upload (no record-mode handling). The user reports on a union
of (a part of) the inbound table and the active data table.
Take Example as Below

ADSO InfoCube

After the data loaded into the Provider, the request can be found in the Inbound table (The
Inbound table acts as "F" table):

The request activation acts like the compression in case of an InfoCube:

 It means that after the Activation, the request can be found in the Active table (The Active table acts
as "E" table) and not in the Inbound table anymore:

Planning (BW 7.50 only)

The next figure shows an ADSO for direct update. This is the only ADSO representation which
can be used to load into the active data table via DTP or API. In contrast to the ODSO, all
consistency checks like SID handling or time consistency check will be applied.
Take Example as Below

ADSO InfoCube

After the data loaded into the Provider, the request can be found in the Inbound table (The
Inbound table acts as "F" table):

The request activation acts like the compression in case of an InfoCube:

 It means that after the Activation, the request can be found in the Active table (The Active
table acts as "E" table) and not in the Inbound table anymore:

==========================================================
==========================================================

Corporate memory with compression feature

After the data loaded into the Provider, it can be found in the Inbound table:

The requests that are no longer needed on detailed level, can be compressed by activating the
request itself:
After the request activation, the data can be found in the Active table:

Used tables:
Inbound table /BIC/A*1 - /BIC/AGA_ADSO61 in our particular case

Active table /BIC/A*2 - /BIC/AGA_ADSO62 in our particular case

==============================================

Corporate memory with reporting option

After the data loaded into the Provider, it can be found in the Inbound table:

The requests can be activated:

Then the request can be found in the Active table:

The request will remain in the inbound table on detailed level:

Used tables:
Inbound table /BIC/A*1 - /BIC/AGA_ADSO71 in our particular case

Active table /BIC/A*2 - /BIC/AGA_ADSO72 in our particular case

l==========================================================

Direct Update DSO

==========================================================

Standard DSO

After the data loaded into the Provider, the request can be found in the Inbound table:
The request needed to be activated:

The data is then transferred into the active table:

And to the Change Log table:

Used tables:
Inbound table /BIC/A*1 - /BIC/AGAADSO11 in our particular case

Active table /BIC/A*1 - /BIC/AGAADSO12 in our particular case

Change log table /BIC/A*1 - /BIC/AGAADSO13 in our particular case

 ==========================================================

Typical corporate memory

After the data loaded into the Provider, it can be found in the Inbound table:

The data doesn't get aggregated, neither by the transformation nor by the ADSO.

Used tables:

Inbound table /BIC/A*1 - /BIC/AGA_ADSO31 in our particular case

==========================================
==========================================

Creating an InfoCube-Based ADSO

The first ADSO we will create is an InfoCube-based aDSO using the InfoCube created
in Section 3.1. We will use all the artifacts that we created in Section 3 as well. Proceed with the
following steps:
Log on to the SAP BW Modeling perspective of SAP HANA Studio.
Right-click the development folder (the placeholder where you want all your development work to be
saved, for example, we have used a separate demo folder [0D_NW_DEMO], but you can name it as
per your project) and select New • DataStore Object (advanced) (see Figure 36).
Figure 36Create aDSO Based on InfoCube

On the New DataStore Object (advanced) screen, provide the BW Project, InfoArea, Name (of your
aDSO), and Description. In our example, the name of our aDSO is INFADSO. In the Create from
Template section, select InfoProvider and choose DEMOCUBE, which we created in Section 3, Creating
Artifacts and Loading Data (see Figure 37).
When you click Finish, the aDSO is created but it is inactive, as shown by the inactive sign
(see Figure 38). To activate the aDSO, click the Activate button at the top of the General:
INFOADSO screen.

Figure 37Fill in Details and Choose InfoProvider as Template

Figure 38Activate aDSO
When the aDSO has been activated sucessfully, the inactive icon disappears (see Figure 39).

Figure 39Activated aDSO with Inactive Icon Removed

With the InfoCube-based aDSO activated, go back to SAP GUI (in the SAP BW backend system) and
create a data flow from the existing Z_E_CDSO (classic DSO for purchase order;
see Section 3, Creating Artifacts and Loading Data) to your new InfoCube-based aDSO (INFADSO).
Make a copy of the existing transformation between the Z_E_CDSO and the DEMOCUBE (SAP HANA-
optimized InfoCube for a purchase order; see Section 3, Creating Artifacts and Loading Data) as a
template by right-clicking ODSO Z_E_CDSO -> CUBE DEMOCUBE and selecting Copy.
On the Copy Transformation screen, in the Target of the Transformation section, select DataStore
Object (advanced) in the Object Type field, and provide the name of the new aDSO (INFADSO) in
the Name field. In the Source of the Transformation section, select DataStore Object (classic) in
the Object Type and enter your classic DSO for purchase orders (Z_E_CDSO) in the Name field. Click
the Confirm button (see Figure 40).

Figure 40Mark Target of Transformation as Newly Created aDSO

Note
There are two ways to create a transformation: creating one from scratch or copying from an existing
transformation. In this example, we are making a copy of an existing
transformation. Section 3 showed you how to create a transformation from scratch.
The transformation mapping should look like Figure 41.
Figure 41Mapping in Transformation
Once the transformation is created with the right mapping, our next step is to create the DTP in the
SAP GUI (in the SAP BW backend system) and load the data into the new aDSO (INFADSO). We can
then evaluate the data model in SAP HANA Studio.
The steps for creating a DTP here are the same as with traditional BI data and SAP BW. Create a DTP
for the transformation created previously and keep all the default settings. Proceed with the following
steps:
Right-click the Data Transfer Process folder and select Create Data Transfer Process….
On the Create Data Transfer Process screen, you can change the name of the DTP. However, leave
the default settings as they are (see Figure 42). Click the Confirm button.

Figure 42Finalize DTP

Now load the data via DTP. To do so, double-click the DTP you just created to display the DTP in
detail. Select the Execute tab and then click the Execute button (see Figure 42). This starts the data
load.

Figure 43Execute DTP for Data Load

When the execution is complete, go to Transaction RSA1 to see the new aDSO (INFADSO), manage
the functions, and look at the new request overview. In the context menu of your aDSO,
select Display data and generate an aggregate view on all the key figures at the calendar year/month
level. The result should be similar to that shown in Figure 44.

Figure 44Result after Data Load via DTP

To see what’s happening on the SAP HANA Studio side, go to SAP HANA Studio and right-click
the Catalog folder. In the context menu, select Find Table. Enter “INFADSO1” in the Enter table or
column name field. Under Matching items, notice it’s present in /BIC (see Figure 45) . BI Consumer
Services (BIC) is a standard system-defined schema. Whenever you activate an SAP HANA
information model, it is stored here.

Figure 45Filter on INFADSO1 in Catalog Node

Go to the schema and put a filter on the Tables-Filter: *INFADSO* folder by right-clicking the folder
and selecting Filter from the context menu to see all the tables that were created (see Figure 46).

Figure 46Tables Created with aDSO

To check the consistency in the number of data records, compare the data in SAP HANA Studio
(see Figure 47) and SAP BW (via SAP GUI; see Figure 48).
Figure 47Check Number of Entries in AINFADSO1 in SAP HANA Studio

Figure 48Check Number of Data Records Inserted

As you can see, the number of records from SAP HANA Studio and SAP BW are the same, which
means the data is consistent and all of the records have been transferred.
Now we will compress the data and see how the data compression process works. To do so, proceed
with the following steps:
Go to Transaction RSA1 and right-click the aDSO. Choose Manage from the context menu.
The screen shown in Figure 49 appears. On this screen, select the Activate button to activate the
aDSO.

Figure 49Activate aDSO to See Compression

Go back to SAP HANA Studio. Note the three following tables:
Inbound Table (/BIC/A<ADSO technical name>1 )
Table of Active Data (/BIC/A<ADSO technical name>2)
Change Log (BIC/A<ADSO technical name>3)
We see that after activation the data is compressed and moved from the Inbound Table
(/BIC/A<ADSO technical name>1) to the Table of Active Data (/BIC/A<ADSO technical
name>2). Figure 50 further explains the process.
Figure 50Compression after Activation

===============================================================
===============================================================

Creating an aDSO Based on a Classic DSO

In this section, we will create an aDSO based on a classic DSO. The process of creating an aDSO here
is similar to the process discussed in the previous section. However, changes must be made to the
modeling properties. Proceed with the following steps:
Log on to the SAP BW Modeling perspective of SAP HANA Studio. Right-click the parent folder (where
you have been placing all the artifacts) and from the context menu select New • DataStore Object
(advanced).
On the New DataStore Object (advanced) screen, provide the information for the BW Project (for our
example, we use CIA_003_DEMO_en), InfoArea, Name (of your aDSO; we use 0D_NW_DEMO_EPM),
and Description fields (ADSO based on classical purchase order DSO Z_E_CDSO). In this example,
the name of the aDSO based on a classic DSO is CDSOADSO. In the Create from Template section,
select InfoProvider and choose Z_E_CDSO, which you created in Section 3, Creating Artifacts and
Loading Data.
Click Finish. Then activate the aDSO. Figure 51 shows the activated aDSO. In this case,
under Modeling Properties, select the Activate/Compress Data and Write Change Log checkboxes.
Figure 51Finalize aDSO after Activation
Go back to SAP GUI (SAP BW backend system) to create a data flow from your existing data source
(Z_EPM_PO) to the newly created aDSO (CDSOADSO). Make a copy of the existing transformation
between the Z_E_CDSO and CDSOADSO as a template by right-clicking ODSO Z_EPM_PO -> CUBE
CDSOADSO and selecting Copy.
On the Copy Transformation screen, under the Target of Transformation section, select DataStore
Object (advanced) in the Object Type field, and provide the name (CDSOADSO) in the Name field. In
the Source of the Transformation section, select DataSource in the Object Type field,
enter Z_EPM_PO in the DataSource field, and enter the correct system in the Source System field.
Click the Confirm button. The mapped transformation should look similar to the one in Figure 52.

Figure 52Transformation with Field Mapping from Z_EPM_PO to CDSOADSO

Once the transformation is created, our next step is to create the DTP in the SAP GUI (in the SAP BW
backend system) and load the data into the new aDSO (CDSOADSO). We will then evaluate the data
model in SAP HANA Studio. Proceed with the following steps:
Right-click the Data Transfer Process folder and select Create Data Transfer Process….
On the Create Data Transfer Process screen, you can change the name of the DTP. Keep the default
settings (see Figure 53).

Figure 53Create Data Transfer Process for CDSOADSO

You could also change the DTP Type. As indicated in the type name, if you want to schedule a DTP,
you should select Standard (Can Be Scheduled). However, if you want a real-time data acquisition,
you need to choose the DTP for Real-Time Data Acquisition type. Just keep in mind that you can only
use the DTP for Real-Time Data Acquisition option when the DataSource is delta-enabled and
supports real-time data acquisition. Execute the DTP by clicking the Confirm button.
When the execution is complete, go to the new aDSO (INFADSO) via Transaction RSA1 to manage
the functions and look at the new request overview. In the context menu of your aDSO,
select Display data and generate an aggregate view on all the key figures at the calendar year/month
level. You can repeat the steps to activate the data as shown in the Creating an InfoCube-Based
aDSO section to see the effect of repetitive activation on your data models. Make note that all the
data has been moved to both the Table of Active Data /BIC/CDSOADSO2 as well as the Change
Log /BIC/CDSOADSO3.
The Table of Active Data /BIC/CDSOADSO2 appears as shown in Figure 54, and the Change
Log /BIC/CDSOADSO3 appears as shown in Figure 55.

Figure 54Table of Active Data in CDSOADSO2

Figure 55Change Log in CDSOADSO3

============================================================

Creating a Write-Optimized ADSO

The creation process for a write-optimized aDSO is similar to the processes
described in the previous two sections. In this case, we have to take into consideration changes in the
modeling properties. Proceed with the following steps:
As before, log on to the SAP BW Modeling perspective of SAP HANA Studio. Right-click the parent
folder and select New • DataStore Object (advanced).
On the New DataStore Object (advanced) screen, provide information for the BW Project (we used
CIA_003_DEMO_en), InfoArea (we used 0D_NW_DEMO_EPM), Name (of your aDSO),
and Description fields (Write Optimized Purchase Order ADSO based on Z_E_CDSO). In this example,
the name of your write-optimized aDSO is WOPADSO. In the Create from Template section,
select InfoProvider and choose Z_E_CDSO, which you created in Section 3.2.
Click Finish. Then activate the aDSO. Figure 56 shows the activated aDSO. In this case,
under Modeling Perspectives, select the Write Change Log checkbox and uncheck
the Activate/Compress Data checkbox. When the warning message appears, select Yes.

Figure 56Ignore Warning That Appears When You Uncheck the Activate/Compress Flag
Now you need to write-optimize the model before activating it. To do this, you will have to add a new
field to the aDSO key. To add new fields, go to the Details tab and click the Add Field button
(see Figure 57).
Provide the information for the new field. This includes completing the Name, Description, Data Type,
and Length fields, and most importantly, the Properties section (see Figure 58).

Figure 57Add Fields from Details Tab

Figure 58Add Details for New Field to Be Added

Activate the aDSO and create the transformation as shown in the previous sections. Again, use the
transformation from data source Z_EPM_PO to the classic DSO (Z_E_CDSO) as a template and make
a copy of it, changing the Target of the Transformation name to “WOPADSO.” See Figure 59.
Since you added a new field (REQUESTID), you need to modify the transformation and add a routine
for the REQUESTID field.
Figure 59Change Target of Transformation after Copy
In the transformation, you added a routine for the new field. Now assign the logic by making the
result equal to the request as shown in Figure 60.

Figure 60Add Logic to Routine

You can now activate the transformation and then create the DTP. Load the data in Full Mode. Then
repeat the load and analyze the new request overview in the context of the previous load. We are
repeating the load to see if the subsequent load is optimized.
Let’s check the data we loaded into the tables related to WOPADSO (write-optimized aDSO). To do
so, we will go to the Catalog folder in SAP HANA Studio and look for table /BIC/WOPADSO1. This
table contains all the records that we just loaded. We will also see other aDSO tables, but they are
generally empty until we change the behaviors of this one. We can check the content of the key
field REQUESTID by using the Data Preview function.
Creating Field Groups and Assigning InfoObjects
In Section 1, we discussed how aDSOs enable us to perform modeling via fields. A field group is an
extension to that concept. In this section, we will store fields into groups for aDSOs. We can use
fields via simple data types or InfoObjects.
Since we want to work with field groups as a separate topic, we will create a different aDSO. The
steps for creating this aDSO are similar to those performed in the three previous sections. However,
this aDSO is based on an InfoCube for actual cost. Follow the same steps as in previous sections until
you get to the New DataStore Object (advanced) window, and fill in the details as shown in Figure 61.
Click Finish when complete.
Figure 61aDSO for Actual Cost Details
We can now begin creating the field groups. Proceed with the following steps:
Select the Details tab and choose Add Group, as shown in Figure 62.

Figure 62Add Group to aDSO

Now that you’ve created the groups, you need to add them. Figure 63 shows the information for a
cost center. You can use a similar method to add other InfoObjects and groups.
Figure 63Add InfoObjects to Group

Repeat the process for each group. When you have finished, activate the aDSO.