Skip to main content

Snapshot generation in HR reporting with ADSOs

Particularly in the environment of HCM and Infotype tables, full loads are often used for supplying SAP BW because clear detection of changes (CRUD - create, read, update and delete) in the source system is not possible. For example, deadlines (Infotype 0019) are not furnished with a full validity, so that a deletion does not lead to creation of a new data record which overwrites this period. In the source system, SLT/RS (SAP landscape transformation/replication server) with its trigger-based detection of changes at the database level could be used to monitor each individual data modification. Due to the relatively small amounts of data, however, use is not absolutely necessary, and change-tracking at this point would be "overkill". It should be noted that SLT/RS is sometimes included in current SAP BW license packages, and can therefore often be used, but requires an installation on the source system.

Among the data integration possibilities, normal full loads of HR Infotypes in the data acquisition layer of SAP BW therefore remain an adequate means, as also very often realized in HR reporting projects. Use of HANA for SAP BW (from 7.5 SP4) results in a new possibility: The ability to utilize an ADSO with a snapshot function. Similar to SLT/RS or a HANA-based change data capture, this ADSO setting fills the change log table based on a full load, and makes it possible to also consider deletions during further delta processing. In this way, changes to data can be clearly detected and saved on a persistent basis in the corporate memory layer for later evaluation. In addition, filling of time-dependent attributes of InfoObjects can be accelerated, because this process continues to running wholly or partly in the ABAP stack, and is therefore not the fastest loading type.

Activating the snapshot function

The following screenshot shows how snapshot support can be activated in the modeling attributes (it should be noted that ADSO must then always be loaded completely).

 

aktivierung-der-snapshot-intersützung-in-den-modellierungseigenschaften

 

Delta behavior (RECORDMODRE) in the change log

The appropriately set ADSO with snapshot support generates entries in the change log. However, a problem is that after a data record has been deleted, no entry is created with RECORDMODE 'D' for deletion in the change log, but instead a reverse image with RECORDMODE 'R'. This contains all the information of the original data record, and would thus not reset the attributes of an InfoObject. For this reason, the data record with the reverse image must be modified to a deletion when filling an InfoObject. For this, all non-key columns - with the exception of the start date of validity - must be deleted. This is needed in order to overwrite the correct time range from the InfoObject. This is because if transaction data are present, master data can no longer be deleted. The records need to be "emptied".

Case study: Time-dependent master data posting with snapshot support

Here is an example of which data records an ADSO with snapshot support creates, and how the reverse images for an InfoObject must be adapted.
 

1. New employee is created

PERSNR (key)

 

ENDDA
(key)

BEGDA
(key)

EMAIL

RECORDMODE

1234

 

31.12.9999

01.01.2017

employee@btelligent.com

N

 

2. Employee receives a new e-mail address

Row

PERSNR (key)

ENDDA
(key)

BEGDA
 

EMAIL

RECORDMODE

1

1234

31.12.9999

01.01.2017

employee@btelligent.com

R

2

1234

31.10.2017

01.01.2017

employee@btelligent.com

N

3

1234

31.12.9999

01.11.2017

boss@btelligent.com

 

 

An InfoObject would now see the reverse image as a normal data record, and not delete it. Because the full time period of validity is described in this case, however, it would ultimately lead to the correct result. However, this is not guaranteed with all Infotypes, such as deadlines. Based on the example, the behavior there would be as follows:
 

1. New employee is created

Row

PERSNR (key)

ENDDA
(key)

BEGDA
 

EMAIL

RECORDMODE

1

1234

31.12.9999

01.01.2017

employee@btelligent.com

N

 

2. Employee receives a new e-mail address with a limited end

Row

PERSNR (key)

ENDDA
(key)

BEGDA
 

EMAIL

RECORDMODE

1

1234

31.12.9999

01.01.2017

employee@btelligent.com

R

2

1234

31.10.2017

01.01.2017

employee@btelligent.com

N

3

1234

31.12.2018

01.11.2017

boss@btelligent.com

N

 

Result in the time-dependent attributes of the InfoObject

 

PERSNR (key)

ENDDA
(key)

BEGDA
 

EMAIL

1234

31.10.2017

01.01.2017

employee@btelligent.com

1234

31.12.2018

01.11.2017

boss@btelligent.com

1234

31.12.9999

01.01.2019

employee@btelligent.com

 

Because the InfoObject evaluates time dependence, the e-mail address employee@btelligent.com would remain valid from 01.01.2019 on processing of these data records, as this time period was not booked out. For correct processing, each reverse image must therefore be converted into a deletion. The attributes of the originally booked time period are set to 'empty', which corresponds to a deletion. Via a later reorganization of the InfoObject, also required with the use of HANA, unnecessary entries in the time-dependent tables of the InfoObject can be cleaned up again.
 

3. Correct delta processing from an ADSO snapshot with a start routine

Row

PERSNR (key)

ENDDA
(key)

BEGDA
 

EMAIL

RECORDMODE

1

1234

31.12.9999

01.01.2017

 

D

2

1234

31.10.2017

01.01.2017

employee@btelligent.com

N

3

1234

31.12.2018

01.11.2017

boss@btelligent.com

N

 

Result in the time-dependent attributes of the InfoObject

 

PERSNR (key)

ENDDA
(key)

BEGDA
 

EMAIL

1234

31.10.2017

01.01.2017

employee@btelligent.com

1234

31.12.2018

01.11.2017

boss@btelligent.com

1234

31.12.9999

01.01.2019

 

The data record valid until 31.12.9999 still exists, but was correctly set to empty. The time-dependent master data therefore correspond again to the correct state. Master data which are not time-dependent would also be correctly booked out in this manner, because they are overwritten again with an "empty" data record.

Munich
b.telligent Group Holding GmbH
Walter-Gropius-Straße 17
80807 Munich


Zurich
b.telligent Schweiz GmbH
Kanzleistrasse 57
8004 Zurich