ADSO Scenario Description

Skip to end of metadata

Created by Attila Giesz, last modified on Aug 02, 2016
Go to start of metadata

Acquisition Layer
Data Acquisition Layer (including corporate memory)
Corporate memory with compression feature
Corporate memory with reporting option
Propagation Layer
Reporting 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. Test Example

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 semantical key)
into the active data table. Test Example

Corporate memory with

compression feature
Skip to end of metadata

Created by Attila Giesz, last modified on Dec 07,

2015
Go to start of metadata
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. Test Example

Corporate memory with

reporting option
Skip to end of metadata

Created by Attila Giesz, last modified on Dec 07,

2015
Go to start of metadata
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). Test Example

Standard DSO
Skip to end of metadata

Created by Attila Giesz, last modified on Dec 07,

2015
Go to start of metadata
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 recordmode handling). The user reports on a union of
(a part of) the inbound table and the active data table. Test Example

ADSO InfoCube
Skip to end of metadata

Created by Attila Giesz, last modified on Dec 07,

2015
Go to start of metadata
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 consisteny checks like SID handling or time consistency check
will be applied. Test Example