ADVANCED DSO

NUTS & BOLTS

ADVANCED
DSO

POSITIONING
ADSO – SALIENT POINTS
 ADSO IS THE CENTRAL OBJECT FOR PERSISTENT STORAGE IN B4H.

 ADSO COMBINES THE FEATURES OF DSO AND CUBE.

 CAN USE INFOOBJECTS OR JUST FIELDS.

 CREATED AND MAINTAINED IN ECLIPSE – BW MT.

 FIELD BASED ADSO ARE USUALLY USED IN STAGING/CORP MEM LAYER FOR FASTER LOADING.

 THE VARIOUS ADSO USE CASES ARE SPECIFIED BY SETTING THE KEY MODELING PROPERTIES IN THE HEADER OF
THE MODELING UI

 HAVE SETTINGS TO HANDLE INVENTORY LOADS.

 HAVE SETTINGS TO HANDLE PLANNING.

 HAVE SETTINGS TO HANDLE WRITE INTERFACE (E.G. FROM DATA SERVICES OR PUSH FROM SAP CPI).
ADSO – SALIENT POINTS
 The 3 main tables
 Inbound:
/BIC/A<technical_name>1

 Active Data
/BIC/ A<technical_name>2

 Change Log
/BIC/ A<technical_name>3
ADSO – SALIENT POINTS
 IN ADDITION TO THESE THREE CORE TABLES, THREE MORE
SQL VIEWS ARE PROVIDED:
1. /BIC/A<TECHNICAL NAME>6
2. /BIC/ A<TECHNICAL NAME>7
3. /BIC/ A<TECHNICAL NAME>8
WHICH OF THE THREE CORE TABLES THEY REFER TO
DEPENDS ON THE MODELING PROPERTIES SELECTED.

 THE VIEW FOR EXTERNAL ACCESS IS USED FOR LOOKUPS IN

TRANSFORMATIONS OR AMDP AND IS NEW IN BW4HANA 2.0.

 THE VIEW FOR EXTERNAL ACCESS DOES NOT PROVIDE

FEATURES SUCH AS ANALYSIS AUTHORIZATIONS.

 FOR USING ANALYSIS AUTHORIZATIONS, THE EXTERNAL CALC

VIEW SHOULD BE USED.

 FOR ADSOS THAT WERE ACTIVATED PRIOR TO THE

INTRODUCTION OF THE EXTERNAL SAP HANA SQL VIEW
FEATURE IN RELEASE 2.0, YOU CAN CREATE THE MISSING
VIEWS USING REPORT RSDG_ADSO_ACTIVATE.
TYPES OF ADSO
1. DATAMART ADSO
2. STND ADSO
3. STAGING ADSO
4. DIRECT UPDATE ADSO
MAPPING TO PREVIOUS TYPES
1. WRITE-OPTIMIZED DSO 1. STAGING ADSO
2. STND ADSO 2. STND ADSO
3. INFOCUBE 3. DATAMART ADSO
4. DIRECT UPDATE ADSO 4. DIRECT UPDATE ADSO
5. INVENTORY INFOCUBE 5. INVENTORY ADSO
6. SPO (SEMANTICALLY 6. SEMANTIC GROUP
PARTITIONED OBJECT)
B4H 1.0 VS B4H 2.0
LSA++ LAYERS
AND ADSO
ADSO
MODELING
& SPECIAL
PROPERTIES
DATAMART
VS
STND ADSO –
PURPOSE AND USAGE
DATAMART ADSO
 PURPOSE AND STRUCTURE

 THE DATA MART ADSO IS USED FOR REPORTING AND ANALYSIS.

 BEHAVIOR = CUBE

DATA  THREE CORE TABLES.

INBOUND TABLE (UNCOMPRESSED FACT TABLE ) – F TABLE
TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>1

MART TABLE OF ACTIVE DATA (COMPRESSED FACT TABLE ) – E TABLE

TECHNICAL NAME: /BIC/A <ADSO TECHNICAL NAME>2

ADSO CHANGE LOG (NOT USED FOR DATA MART ADSO)

TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>3 .

 THIS ADSO CAN CONTAIN INFOOBJECTS AND FIELDS. THIS ALLOWS YOU TO LOAD DATA INTO
THE BW WITHOUT ASSIGNING INFOOBJECTS.

 IN THIS ADSO, INFOOBJECTS THAT ARE ONLY DISPLAY ATTRIBUTES ARE NOT ALLOWED TO BE
USED.

 ALSO, NO FIELDS WITH THE FOLLOWING DATA TYPES ARE ALLOWED: STRING,
RAW,RAWSTRING, DF16_RAW UND DF34_RAW.
 DATA LOAD & ACTIVATION

 THE DATA IS INITIALLY LOADED INTO THE INBOUND TABLE.

 WHEN YOU ACTIVATE THE DATA, THE DATA IS COPIED TO THE TABLE OF ACTIVE DATA AND
GROUPED ACCORDING TO THE AGGREGATION BEHAVIOR. SIMILAR TO CUBE COMPRESSION.

DATA  AFTERWARD, THE DATA IS DELETED FROM THE INBOUND TABLE.

MART
 THE CHANGE LOG IS NOT FILLED. BUT THE TABLE STILL EXISTS.

 NO ADDITIONAL KEYS CAN BE SPECIFIED FOR THIS DATASTORE OBJECT TYPE, BUT THE

ADSO
RECORDS ARE TREATED AS IF ALL CHARACTERISTICS ARE IN THE KEY (LOGICAL KEY). THIS IS
CUBE-LIKE BEHAVIOR.

 ONLY ADDITIVE DELTAS CAN BE LOADED (FOR KEY FIGURES ONLY THE AGGREGATIONS
MAXIMUM (MAX), MINIMUM (MIN), AND SUMMATION (SUM) ARE ALLOWED). THEREFORE,
KEY FIGURES CANNOT BE OVERWRITTEN.

 WHEN YOU CREATE THIS ADSO, YOU CAN ASSIGN CHARACTERISTICS AND KEY FIGURES TO
GROUPS. THE GROUPS ARE ONLY USED AS A SORT CRITERION TO PROVIDE A CLEARER
OVERVIEW WHEN CREATING A QUERY IN THE QUERY DESIGNER.

 FOR THIS ADSO, REQUESTS CAN ONLY BE DELETED IF THE REQUEST HAS NOT YET BEEN
ACTIVATED
DATA
MART
ADSO
DATA
MART
ADSO
 EXTRACTION

 THE FULL AND INITIAL DELTA EXTRACTION READS THE DATA FOR THE UPDATE INTO A FURTHER
DATA TARGET FROM UNION OF INBOUND TABLE AND ACTIVE DATA TABLE.

DATA
 THE DATA FOR THE DELTA EXTRACTION IS READ FROM THE INBOUND TABLE.

 IF A DELTA EXTRACTION IS CONNECTED AND ACTIVE, A REQUEST CAN ONLY BE ACTIVATED ONCE
ALL ACTIVE DELTA EXTRACTORS HAVE RETRIEVED THE REQUEST.

MART  THIS ADSO CAN BE USED AS SOURCE OR TARGET OF TRANSFORMATIONS.

ADSO REPORTING

 REPORTING READS DATA FROM THE INBOUND AND ACTIVE DATA TABLES USING A UNION.

 THE QUERY READS DATA FROM THE INBOUND TABLE AND FROM THE TABLE OF ACTIVE DATA.
THEREFORE, IT IS NOT NECESSARY TO ACTIVATE THE DATA TO BE ABLE TO SEE ALL THE DATA.

 THE DATA READ IS CONSISTENT, SINCE DATA IS ONLY INCLUDED UP TO THE FIRST INCONSISTENT
REQUEST.

 THE DATA READ IS ALSO STABLE, SINCE THE QUANTITY OF DATA INCLUDED FROM THE DATASTORE
OBJECT DOES NOT CHANGE DURING THE NAVIGATION STEPS IN THE QUERY.
DATA
MART
ADSO
STANDARD ADSO
 PURPOSE AND STRUCTURE

 A STANDARD ADSO IS USED TO STORE CONSOLIDATED AND CLEANSED DATA (TRANSACTION DATA
OR MASTER DATA) ON A DOCUMENT LEVEL (ATOMIC LEVEL).

 THREE CORE TABLES.

INBOUND TABLE
TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>1

STND TABLE OF ACTIVE DATA

TECHNICAL NAME: /BIC/A <ADSO TECHNICAL NAME>2

CHANGE LOG (OPTIONAL)

ADSO 
TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>3 .

THIS ADSO CAN CONTAIN INFOOBJECTS AND FIELDS. THIS ALLOWS YOU TO LOAD DATA INTO THE
BW WITHOUT ASSIGNING INFOOBJECTS.

DATA LOAD & ACTIVATION

 THE DATA IS INITIALLY LOADED INTO THE INBOUND TABLE.

 ACTIVATION TRANSFERS THE DATA FROM THE INBOUND TABLE TO THE TABLE OF ACTIVE DATA.

 IF THE PROPERTY WRITE CHANGE LOG IS SELECTED, THE DIFFERENCE OF THE ACTIVATION IS
WRITTEN TO THE CHANGE LOG. CHANGE LOG SUPPLIES DELTA TO FURTHER TARGETS.
 EXTRACTION

 DATA USED FOR THE UPDATE TO A FURTHER DATA TARGET IS EXTRACTED FROM THE TABLE OF
ACTIVE DATA FOR INITIAL AND FULL EXTRACTION

 CHANGE LOG IS USED FOR DELTA EXTRACTION.

STND
REPORTING

 WHEN A QUERY IS EXECUTED, THE TABLE OF ACTIVE DATA IS ACCESSED AND THEREFORE ONLY
DATA THAT WAS PREVIOUSLY ACTIVATED IS VISIBLE.

ADSO
 FOR STANDARD DATASTORE OBJECTS, THERE IS NO STABLE NAVIGATION REPORTING, AS IS THE
CASE WITH DATA MART DATASTORE OBJECTS.
STND ADSO
W/
CHANGE
LOG
 SIMILAR TO STND DSO IN OLDER
VERSION.
STND ADSO
W/O
CHANGE
LOG
 NEW OPTION OF NOT HAVING
CHANGE LOG.
 NOT HAVING CHANGE LOG SAVES
RESOURCES.
 USEFUL WHEN THERE’S NO DELTA
EXTRACTION REQUIRED.
 DATA LOAD & ACTIVATION

 CHARACTERISTICS THAT ARE NOT PART OF THE RECORD IDENTIFIER (KEY) ALWAYS
OVERWRITE.

 KEY FIGURES (FOR EXAMPLE, SALES AMOUNT OR NUMBER OF DOCUMENT LINES)

CAN BE SET TO OVERWRITE, ADD, OR NOT UPDATE.

STND ADSO
W/
CHANGE
LOG
STND
ADSO
 Special Properties

For the Standard DataStore Object, you can select the following properties:

 Write Change Log:

The delta (new, deleted, and changed records) is saved in the change log. The change log is used
to extract the delta. Only if the DataStore object has a change log can requests be rolled back
from the DataStore object, that is, the status before the activation of the request can be

STND
restored. Without change log, ‘Snapshot support’, ‘Inventory’ & ‘Planning’ are not supported,
Only ‘Unique data record’ & ‘Write enabled’ are supported.

 Snapshot Support:

ADSO
If your DataSource only delivers the current dataset as a FULL, ADSO cannot decide by itself if
records not supplied in full load, but which are existing in active table needs to be deleted or
not. Therefore, by setting this indicator, we are instructing the ADSO that the deleted data
records needs to be identified and updated. Upon activation, the system recognizes records that
are in the table of active data but not in the Load request. These are written to the change log as
reverse images (Recordmode: R).

 Unique Data Records:

If you only load unique data records (data records with nonrecurring key combinations) into the
DataStore object, you can select this property. If the indicator is selected, during activation the
system checks whether unique records exist. If a record already exists, the activation is canceled
with an error.
 STND ADSO –
Data load & Activation
SNAPSHOT SUPPORT
Full Load
STND ADSO
Data load & Activation
Full Load (Snapshot Support checked vs not-checked)

Scenario: Mat 222 deleted and not part of full load.

STAGING ADSO
 PURPOSE AND STRUCTURE

 A STAGING ADSO ACTS AS A FIRST LAYER IN THE EDW AND IS USUALLY USED FOR CORP MEM
LAYER.

 THREE CORE TABLES.

INBOUND TABLE
TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>1

TABLE OF ACTIVE DATA (OPTIONAL)

TECHNICAL NAME: /BIC/A <ADSO TECHNICAL NAME>2

STAGING CHANGE LOG (NOT USED)

TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>3 .

ADSO  THIS ADSO CAN CONTAIN INFOOBJECTS AND FIELDS. THIS ALLOWS YOU TO LOAD DATA INTO THE
BW WITHOUT ASSIGNING INFOOBJECTS.
 STAGING
ADSO
INBOUND
QUEUE ONLY
 USUALLY USED AS A CORP MEM
LAYER ADSO (ALSO USUALLY FIELD
BASED).

 REQ-BASED DELETION POSSIBLE.

 NOT SUITABLE FOR REPORTING.

 NO KEYS NEED TO BE DEFINED.

 CANNOT BE PART OF COMP-PROV.

 STAGING ADSO
COMPRESS DATA
(INBOUND QUEUE
+ ACTIVE TABLE)
 TO REDUCE THE STORAGE SPACE.

 SUPPORTS ONLY FULL EXTRACTION.

 KEYS NEED TO BE DEFINED.

 ONLY SELECTIVE DELETION

SUPPORTED.

 CANNOT BE PART OF COMP-PROV.

 STAGING ADSO
REPORTING ENABLED
(INBOUND QUEUE +
ACTIVE TABLE)
 DATA RETAINED IN INBOUND QUEUE
AFTER ACTIVATION.

 FULL AND DELTA EXTRACTION BOTH

FROM INBOUND TABLE.

 CAN BE ADDED AS PART OF COMP-PROV.

 REPORTING VIA ACTIVE TABLE ONLY.

 ACTIVE TABLE, IF DELETED, CAN BE

REBUILT FROM INBOUND QUEUE.
 Data load & Activation

 For DataStore objects with the properties Reporting-Enabled and Compress data,
activation/compression is possible.

 For DataStore objects with the property Inbound Queue Only, it is not.

 For DataStore objects with the property Compress Data, the term “compression” is
used for activation, since in this case the data is moved from the inbound table to the
STAGING active data table, and all records with the same key values are merged in accordance
with the default aggregation.

ADSO  For DataStore objects with the property Reporting-Enabled the term “activation” is
used, since in this case the relevant data is replicated from the inbound table to the
active data table and only then is visible for reporting.

 Records with the same key are merged in accordance with the aggregation here too
however.

 The data can only be deleted at request level if it is not contained in the inbound
table yet, i.e. hasn't been activated yet
 Extraction

 For DataStore objects with the properties Inbound Queue Only and Reporting-
Enabled, full extraction only goes to the inbound table.

 For DataStore objects with the property Compress Data meanwhile, the inbound
table and the table with the active data are accessed for full.

 Delta extraction is always performed from the inbound table.

STAGING  For DataStore objects with the property Compress Data, a request must first be
ADSO updated to all active delta DTPs before it can be compressed (activated)

Reporting

 Staging ADSO with the properties Inbound Queue Only and Compress Data cannot be
added to a CompositeProvider.

 For DataStore objects with the property Reporting-Enabled, reporting only takes place
on the table containing the active data, meaning that the data is only visible after
activation. DataStore objects of this type can be added to a CompositeProvider.
DIRECT UPDATE ADSO
 PURPOSE AND STRUCTURE

 A STAGING ADSO, USED TO STORE CONSOLIDATED AND CLEANSED DATA (TRANSACTION DATA OR
MASTER DATA) ON A DOCUMENT LEVEL (ATOMIC LEVEL).

 THREE CORE TABLES.

INBOUND TABLE (NOT USED)

DIRECT
TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>1

TABLE OF ACTIVE DATA

UPDATE TECHNICAL NAME: /BIC/A <ADSO TECHNICAL NAME>2

CHANGE LOG (NOT USED)

ADSO 
TECHNICAL NAME: /BIC/A<ADSO TECHNICAL NAME>3 .

THIS ADSO CAN CONTAIN INFOOBJECTS AND FIELDS. THIS ALLOWS YOU TO LOAD DATA INTO THE
BW WITHOUT ASSIGNING INFOOBJECTS.
 DIRECT
UPDATE ADSO
(ACTIVE
TABLE)
 DIRECT UPLOAD INTO ACTIVE TABLE.

 INCLUDES STANDARD CONSISTENCY

CHECKS (FOR EXAMPLE, SID
PROCESSING, CONSISTENCY OF TIME
CHARACTERISTICS, AREAS LOCKED
BY COLD STORE, OR NLS).
 DATA LOAD & ACTIVATION

 THE DATA IS DIRECTLY LOADED INTO ACTIVE TABLE.

 THE DATA IS WRITTEN EITHER USING A DTP OR AN API.

 DATA CAN BE LOADED BY STANDARD DTP/TRANSFORMATION OR BY THE FOLLOWING APIS:

DIRECT RSDSO_DU_WRITE_API / RSDSO_DU_WRITE_API_RFC:

LOADS DATA FROM AN INTERNAL TABLE TO THE TABLE OF ACTIVE DATA.

UPDATE RSDSO_DU_DELETE_API_RFC:
DELETES DATA FROM THE TABLE OF ACTIVE DATA. THIS ONE CAN BE TRUNCATED OR SELECTIVELY

ADSO DELETED.

RSDSO_DU_CLEANUP_API_RFC:
DELETES API REQUESTS WITH ERRORS. RED REQUESTS BLOCK FURTHER LOAD REQUESTS BY
DTP/TRANSFORMATION OR BY API.

 ACTIVATION IS NOT POSSIBLE WITH THIS TYPE.

 DELETIONS CAN BE MADE USING REQUESTS.

 EXTRACTION

 ONLY FULL EXTRACTION IS POSSIBLE. THE DATA IS READ FROM THE TABLE OF ACTIVE DATA..

REPORTING

DIRECT
 ALL DATA OF THE ACTIVE DATA TABLE IS VISIBLE IN REPORTING IMMEDIATELY AFTER THE DATA IS
LOADED.

UPDATE  USAGE:
PLANNING – FOR DEFINING THE DATA SLICES
HAP – TARGET FOR HAP (HANA ANALYSIS PROCESS)
ADSO
 P
WRITE INTERFACE-ENABLED
 FEATURES

 THIS ADSO IS THE SUCCESSOR FOR THE OBSOLETE BW SOURCE SYSTEM TYPES SAP DATA SERVICES
AND WEB SERVICE.

 THE INTERFACE CAN BE INTEGRATED WITH FOLLOWING SAP SOLUTIONS:

1. SAP DATA SERVICES ON PREMISE (REQUIRES 4.2 SP11 PATCH 4)
2. SAP CLOUD PLATFORM INTEGRATION (CPI)

WRITE
3. SAP NETWEAVER PROCESS INTEGRATION (PI) (PLANNED FOR SAP NETWEAVER 7.50 SP15)
4. SAP DATA HUB (PLANNED FOR END OF 2019)
5. SAP CPI-DATA SERVICES (PLANNED FOR END OF 2019)
INTERFACE  THIS PROPERTY CAN BE USED FOR ALL TYPES OF STANDARD DATASTORE OBJECT AND STAGING

-ENABLED
DATASTORE OBJECT, BUT NOT TOGETHER WITH INVENTORY ENABLED OR PLANNING ENABLED .

 THE DATA IN THIS DATASTORE OBJECT CAN BE MOVED TO THE INBOUND TABLE USING A TOOL
SUCH AS DATA SERVICES OR VIA SAP CLOUD PLATFORM INTEGRATION (CPI) BY PUSH.

 THE API FOR WRITING TO DATASTORE OBJECTS IS NOT RELEASED FOR THIRD-PARTY TOOLS.

 YOU CAN USE RFC OR HTTP DATA TO LOAD DATA INTO THE DATASTORE OBJECT. THERE ARE TWO
POSSIBLE PROCEDURES:
SENDING DATA WITHOUT A REQUEST: FOR EVERY CALL, A NEW INTERNAL REQUEST IS OPENED
SENDING DATA WITH A REQUEST: THE FOLLOWING SEQUENCE IS USED TO DO THIS: OPEN
REQUEST, N TIMES SEND DATA (WITH REQUEST AND PACKAGE), CLOSE REQUEST
 WRITE
INTERFACE-
ENABLED
W/ STND ADSO
 WRITE
INTERFACE-
ENABLED
W/ STAGING ADSO
 FEATURES

 THE FOLLOWING PROPERTIES APPLY:

1. THE DATA IS TRANSFERRED IN THE INTERNAL FORMAT.
EXAMPLE
A DATE (DATA TYPE DATS) IS TRANSFERRED AS “20101231”, A TIME (TIMS) AS “235959”.

2. ONLY AFTER-IMAGE DELTAS CAN BE LOADED.

WRITE 3. THE RFC FUNCTION MODULES ARE IN THE FUNCTION GROUP OF RSO_PUSH.

INTERFACE 4. YOU CAN FIND THE URLS SPECIFIC TO EACH ADVANCED DATASTORE OBJECT TO CALL THE
FUNCTIONS USING HTTP (JSON OR XML) IN THE BW MODELING TOOLS,
UNDER PROPERTIES –>TEMPLATE URL .
-ENABLED 5. AFTER THE DATA IS WRITTEN TO THE ADSO INBOUND TABLE, THE PROCESSING AFTERWARD,
LIKE COMPRESSION/ACTIVATION OR REPORTING, REMAINS UNCHANGED.

 FIELDS OF TYPE CURRENCY (CURR) ARE TRANSFERRED IN THE STANDARD FORMAT.

 DURING THE LOADING PROCESS THE DECIMAL PLACE IS CHANGED TO THE SAP STANDARD FORMAT.
EXAMPLE
1234 JPY IS TRANSFERRED -> DUE TO THE CURRENCY JAPANESE YEN THE VALUE IS SAVED IN
INTERNAL FORMAT AS 12.34.
 FIELD-BASED
OR
INFOOBJECT-BASED?
FIELD VS INFOOBJECT – DECISION CRITERIA
 ADSO:
RECOMMENDATIONS AND
RESTRICTIONS REGARDING
REPORTING
 PURPOSE AND REPORTING VISIBILITY

 AN ADSO IS MAINLY DESIGNED AS AN OBJECT OF THE PERSISTENCE LAYER AND TO A LESSER

DEGREE AS AN OBJECT OF THE REPORTING LAYER. THEREFORE IT'S RECOMMENDED NOT TO BE
USED FOR EXECUTING QUERIES DIRECTLY ON AN ADSO; INSTEAD, FOR THE REPORTING, ALWAYS
EXECUTE THEM ON A COMPOSITEPROVIDER (HCPR) THAT CONTAINS THE ADSO AS A
RECOMMENDATIONS PARTPROVIDERS.

 NAVIGATION ATTRIBUTES CANNOT BE ACCESSED DIRECTLY USING THE ADSO. IF NAVIGATION

ATTRIBUTES ARE TO BE READ FROM AN ADSO, YOU MUST ALWAYS CREATE A COMPOSITEPROVIDER
(HCPR) USING THE ADSO. THERE, YOU CAN ACTIVATE THE REQUIRED NAVIGATION ATTRIBUTES.

 INFOOBJECTS ARE VISIBLE IN THE REPORTING ONLY IF THE PROPERTY "MASTER DATA CHECK" ON
THE UI IS SET TO A VALUE UNEQUAL TO "NO MASTERDATA CHECK/NO REPORTING".

 FOR THE REPORTING ON THE ADSO, FIELDS ARE DIRECTLY VISIBLE ONLY UNDER CERTAIN
CONDITIONS. (FOR FIELDS THAT ARE DIRECTLY VISIBLE, TRANSIENT INFOOBJECTS ARE CREATED.
THE NAMING CONVENTION FOR SUCH OBJECTS IS "4<PROVIDER NAME>-<FIELD NAME>".)

 IF FIELDS ARE NOT DIRECTLY VISIBLE, IT IS POSSIBLE TO DEFINE AN OPEN ODS VIEW ON THE ADSO
IN WHICH THE REQUIRED COMPILATIONS OF THE DATA TYPES AND FIELD NAMES FOR THE BW
REPORTING CAN BE CARRIED OUT. THIS OPEN ODS VIEW CAN THEN BE INCLUDED IN A
COMPOSITEPROVIDER AGAIN.
 RESTRICTIONS FOR FIELDS

 THE FOLLOWING RESTRICTIONS APPLY FOR FIELDS:

1. ONLY FIELDS NAMES NOT LONGER THAN 20 CHARACTERS ARE VISIBLE DIRECTLY IN THE
REPORTING.
2. ONLY FIELDS WITH THE FOLLOWING TYPES ARE VISIBLE DIRECTLY IN THE REPORTING:
RECOMMENDATIONS CHARACTERISTICS:
CHAR: LENGTH 1 - 250
NUMC: LENGTH 1 - 250
CUKY: LENGTH 5
UNIT: LENGTH 3
LANG: LENGTH 1
DATS: LENGTH 8
TIMS: LENGTH 6
KEY FIGURES:
INT4
FLOAT
DEC: LENGTH 16 - 31; DECIMAL PLACES 0 - 14
CURR: LENGTH 1 - 31; DECIMAL PLACES 1 - 14 (THERE MUST BE AN ASSIGNMENT TO A CUKY
CHARACTERISTIC, AND THE LENGTH MUST BE GREATER THAN OR EQUAL TO THE NUMBER OF
DECIMAL PLACES).
QUAN: LENGTH 1 - 31; DECIMAL PLACES 0 - -14 (THERE MUST BE AN ASSIGNMENT TO A UNIT
CHARACTERISTIC, AND THE LENGTH MUST BE GREATER THAN OR EQUAL TO THE NUMBER OF
DECIMAL PLACES).
 RESTRICTIONS FOR FIELDS

 FOR THE MODELING OF KEY FIGURES WITH UNITS/CURRENCY REFERENCE, THERE ARE THREE DIFFERENT
APPROACHES IN THE ADSO:

 INFOOBJECT-BASED:
RECOMMENDATIONS IN THIS CASE, THE REFERENCE BETWEEN THE KEY FIGURES AND THE RELEVANT CURRENCIES IS ENSURED
USING THE INFOOBJECT.
OF COURSE, THIS IS ALSO RECOGNIZED BY A COMPOSITEPROVIDER ON-TOP. THE OBJECT ITSELF, AND ALSO
THE ASSIGNED CURRENCY CHARACTERISTIC, MUST BE VISIBLE IN THE REPORTING.

 PURELY FIELD-BASED:
THE KEY FIGURES AND THE CURRENCIES CAN BE STORED IN A FIELD OF ANY TYPE.
IF THE TYPES ARE CONFORMING TO REPORTING (SEE ABOVE), THE FIELDS ARE VISIBLE DIRECTLY IN A
COMPOSITEPROVIDER.
OTHERWISE, FOR THE MAPPING, YOU MUST POSITION AN OPEN ODS VIEW OVER THE ADSO.
IN THE COMPOSITEPROVIDER, ASSOCIATIONS CAN BE MAINTAINED. AS A RESULT, THE ASSIGNMENT
BETWEEN THE KEY FIGURE AND THE CURRENCY FIELD CAN BE SET UP.

 FIELD-BASED BUT WITH METADATA KNOWLEDGE:

IN THIS CASE, THE KEY FIGURE ON THE UI WITH THE DATA TYPE CURR AND THE CURRENCY OF THE TYPE
CUKY MUST EACH BE CREATED IN A MANNER CONFORM TO REPORTING.
IN THIS CASE, THE INPUT FIELD "UNIT/CURRENCY" IS ENABLED FOR THE KEY FIGURE, AND A FIELD OF THE TYPE
CUKY MUST BE SPECIFIED THERE.
FOR THE CURRENCY FIELD, AN ASSOCIATION WITH 0CURRENCY IS ADDED IN THE BACK END (IMPLICITLY).
THE RELATIONSHIP BETWEEN THE KEY FIGURE AND THE CURRENCY IS THEN STORED IN THE METADATA, AND
THE COMPOSITEPROVIDER CAN DERIVE THE ASSIGNMENT FROM IT.
(THE SAME APPLIES FOR KEY FIGURES WITH UNIT REFERENCE: QUAN KEY FIGURE WITH ASSIGNED UNIT
CHARACTERISTIC.)
 MODELING RESTRICTIONS

 NUMBER OF KEY FIELDS:

AN ADVANCED DSO CAN CONTAIN UP TO 120 KEY FIELDS, WHICH IS A MAJOR IMPROVEMENT COMPARED
TO THE PAST WHERE DSOS (CLASSIC) HAD A MAXIMUM OF 16 KEY FIELDS. THE ADSO KEY CAN CONSIST
OF INFOOBJECTS OR FIELDS, OR ANY COMBINATION OF BOTH.
LIMITATIONS  NUMBER OF FIELDS:
AN ADVANCED DSO CAN CONTAIN UP TO 745 FIELDS (KEY FIELDS/INFOOBJECTS + DATA FIELDS/
INFOOBJECTS). IF NON-CUMULATIVE KEY FIGURES ARE MODELED WITHIN THIS OBJECT,
THE NUMBER IS 744.

 NAVIGATION ATTRIBUTES:
THE FOCUS OF THE ADVANCED DATASTORE OBJECT IS THE MANAGEMENT OF TRANSACTIONAL DATA WITH ITS
OWN PERSISTENCE. ENHANCED REPORTING FEATURES SUCH AS THE AVAILABILITY OF NAVIGATION ATTRIBUTES ARE
NOT AVAILABLE IN THIS DATA MODEL (SEE ALSO SAP NOTE 2215947). HOWEVER, YOU CAN DEFINE THOSE IN THE
COMPOSITEPROVIDER ON TOP OF THE ADVANCED DSO, AND THEN THEY ARE FULLY AVAILABLE FOR REPORTING.

NAVIGATIONAL ATTRIBUTES OF INFOOBJECTS CAN BE SWITCHED ON FOR TRANSFORMATIONS IN ORDER TO

AVOID SETTING UP MANUAL LOOKUPS. IN THE DETAILS TAB OF AN ADSO DEFINITION, SELECT THE INFOOBJECT THAT
SHOULD PROVIDE ITS NAVIGATION ATTRIBUTES TO THE SOURCE STRUCTURE OF A BW/4HANA TRANSFORMATION
RULE; THEN SWITCH ON THE PROPERTY 'USE NAVIGATION ATTRIBUTES IN EXTRACTION'
 TO USE NAVIGATION ATTRIBUTES OF AN ADSO IN A QUERY, YOU NEED:

METHOD 1:
 CREATE A NEW HCPR OF TYPE UNION AND PUT THE ADSO INTO THE HCPR. THEN ASSIGN THE CHARACTERISTIC
OF WHICH YOU WANT TO USE NAVIGATION ATTRIBUTES TO THE OUTPUT OF THE HCPR. IN THE FOLLOWING
EXAMPLE 0MATERIAL IS USED:
NAV ATTRIBUTES

 THEN YOU NEED TO SWITCH ON THE NAVIGATION ATTRIBUTES

IN THE HCPR(TAB OUTPUT): RIGHT CLICK ON THE
CHARACTERISTIC AND CHOOSE 'NAVIGATION ATTRIBUTES’
  THEN YOU CAN SWITCH ON THE NAVIGATION ATTRIBUTES IN THE DIALOG BOX

NAV ATTRIBUTES

 THIS WAY YOU CAN USE NAVIGATION ATTRIBUTES OF CHARACTERISTICS OF ADSOS(BY CREATING A PROPER
HCPR).

METHOD 2:

 OR ASSIGN THE NAVIGATION ATTRIBUTE TO

ANOTHER CHARACTERISTIC OF AN HCPR IN THE
FOLLOWING WAY:
 PERFORMANCE

 IN AN ADSO, NORMALLY ONLY THE CHARACTERISTIC VALUES ARE SAVED, AND NOT THE CORRESPONDING
SID VALUES. AS A RESULT, JOINS WITH THE CORRESPONDING SID TABLES MUST BE EXECUTED FOR MANY
QUERIES. THIS CAN HAVE A NEGATIVE EFFECT ON QUERY PERFORMANCE.

 FOR CHARACTERISTICS THAT ARE QUERIED EXTREMELY FREQUENTLY IN QUERIES AND THAT HAVE A
RECOMMENDATIONS HIGH CARDINALITY, WE THEREFORE RECOMMEND THAT YOU SET THE MASTER DATA CHECK FOR THESE
CHARACTERISTICS TO "MASTER-DATA CHECK DURING STAGING/ACTIVATION AND PERSIST SID IN
DATASTORE".

 YOU CAN USE THE REPORT SAP_ADSO_DESIGNS (SAP NOTE 2511639) TO DETERMINE THE CARDINALITY.

 THIS MASTER DATA CHECK CAN ALSO RESULT IN AN ACCELERATION WHEN READING ATTRIBUTE VALUES,
SINCE THE JOIN WITH THE ATTRIBUTES TABLE VIA AN INTERNAL COMPARISON IS GENERALLY FASTER
THAN THE JOIN VIA THE CHARACTERISTIC VALUES.

 THIS PARTICULARLY APPLIES FOR COMPOUND CHARACTERISTICS.

 DUE TO THE GENERALLY LOW CARDINALITY OF TIME CHARACTERISTICS, UNITS, AND CURRENCIES, THE
SIDS OF CHARACTERISTICS OF THESE TYPES ARE NOT PERSISTED.
 MODELING INVENTORY SCENARIOS

 PRECONDITION: THE INVENTORY-ENABLED FLAG IN THE CORE MODELING PROPERTIES IS

SWITCHED ON.

 IF YOU ADD A NON-CUMULATIVE KEY FIGURE INFOOBJECT TO THE DATA MODEL, THE SYSTEM ALSO DISPLAYS
INVENTORY THE INVENTORY TAB. WHEN THE NON-CUMULATIVE KEY FIGURE IS ADDED, THE KEY FIGURES FOR NON-
CUMULATIVE CHANGES (THAT IS, FOR INFLOWS AND OUTFLOWS), ARE ALSO ADDED TO THE ADVANCED DSO.
HANDLING
 IN THIS CASE, TWO ADDITIONAL TABLES ARE CREATED: /BIC/A<TECHN.NAME>4 = VALIDITY TABLE AND
/BIC/A<TECHN.NAME>5 = REFERENCE POINT TABLE.

 THE REFERENCE POINTS REQUIRED FOR CALCULATION OF THE NON-CUMULATIVES ARE UPDATED WITH
THE CHANGE LOG DATA. THE DATA MODEL MUST THEREFORE HAVE A CHANGE LOG, AND A KEY MUST
ALSO HAVE BEEN DEFINED.

 THE FOLLOWING PROPERTIES ARE REQUIRED:

(1) STANDARD ADSO WITH 'WRITE CHANGE LOG' OR
(2) DATAMART ADSO

 INFOOBJECTS MUST BE USED AS KEY FIGURES, NON-CUMULATIVE KEY FIGURES, AND VALIDITY
CHARACTERISTICS. FIELDS ARE NOT SUPPORTED FOR THIS SCENARIO.
 PARTITIONING

HANDLING
LARGE DATA
VOLUME
 PARTITIONING

 YOU CAN USE PARTITIONING TO DIVIDE THE ENTIRE DATASET OF A DATASTORE OBJECT INTO SEVERAL
SMALLER UNITS THAT ARE INDEPENDENT AND REDUNDANCY-FREE.
HANDLING  PARTITIONING CAN IMPROVE SYSTEM PERFORMANCE DURING DATA ANALYSIS.
LARGE DATA
 PARTITIONING CAN ALSO BE NECESSARY IF YOU ARE LOADING A LARGE VOLUME OF DATA, BECAUSE AN SAP
VOLUME HANA TABLE OR AN SAP HANA TABLE PARTITION CAN CONTAIN A MAXIMUM OF TWO THOUSAND MILLION
RECORDS (EXACTLY 2^31 = 2.147.384.648 RECORDS).

 PARTITIONING MAY ALSO BE NEEDED IF YOU USE DATA TIERING OPTIMIZATION (DTO).

PRIMARY LEVEL PARTITIONING

 REFERS TO ALL ADSO TABLES AND IS AVAILABLE AT GENERATION OF THE ADSO. THIS MEANS EACH DATA
MODEL HAS ONE HASH PARTITION BY DEFAULT. THE PRIMARY FOCUS IS TO DISTRIBUTE THE DATA TO VARIOUS
SCALE-OUT NODES IN THE SAP HANA DATABASE. THERE'S A CUSTOMIZING TABLE CALLED TABLE_PLACEMENT
IN SAP HANA. BASED ON THESE RULES, A SO-CALLED LANDSCAPE REDISTRIBUTION RUN WITHIN SAP HANA
WILL PARTITION THE ADSO TABLES ACCORDINGLY.

AUTOMATIC SECONDARY LEVEL PARTITIONING

 REFERS TO A RANGE PARTITIONING OF BW/4HANA REQUEST TSNS IN THE INBOUND TABLES AND CHANGE
LOGS OF THE ADSOS. PREREQUISITE: PROPER CUSTOMIZING AS DESCRIBED IN SAP NOTE 2081135.
 PARTITIONING

MANUAL SECONDARY LEVEL PARTITIONING

 REFERS TO A RANGE PARTITIONING THAT CAN BE DEFINED IN THE MODELING UI OF ADSOS ( SETTINGS TAB).
HANDLING  DEVELOPERS CAN SELECT ONE OF THE KEY INFOOBJECTS (OR FIELDS) TO BE THE PARTITION CRITERIA.
LARGE DATA
 AFTERWARD, MANUAL RANGES NEED TO BE SET UP.
VOLUME
 TYPICAL PARTITIONING CRITERIA OBJECTS ARE A TIME CHARACTERISTICS (FOR EXAMPLE, 0CALYEAR AND
ALL INFOOBJECTS RELATED TO ITS TIME HIERARCHY) OR FIELDS DESCRIBING ORGANIZATIONAL UNITS
(LIKE 0COUNTRY).

 TAKE INTO ACCOUNT THAT ONLY THE TABLE OF ACTIVE DATA IS IN SCOPE IN THIS CONCEPT. THAT MEANS, FOR
INSTANCE, THAT THE DATA IN AN ADSO OF TYPE “DATA MART” WILL NOT BE PARTITIONED UNTIL YOU
ACTIVATE (COMPRESS) IT.

SAP RECOMMENDATION

 SAP RECOMMENDS EVALUATING OTHER CONCEPTS TO CONTROL DATA GROWTH AS WELL.

INSTEAD OF PHYSICALLY DIVIDING THE TABLES ON DATABASE LEVEL, THERE ARE OPTIONS TO SEMANTICALLY
PARTITION THE DATA INTO DIFFERENT ADSOS (AKA SEMANTIC GROUP )
OR YOU CAN USE DATA TIERING OPTIMIZATION TO STORE LESS USED OR HISTORICAL DATA AT
OTHER LOCATIONS. REFER TO SAP NOTE 2374652 - HANDLING VERY LARGE DATA VOLUMES WITH ADVANCED
DATASTORE OBJECTS IN BW/4HANA.
 INDEXES
 YOU CAN CREATE ADDITIONAL SECONDARY INDEXES FOR ADSOS, IF REQUIRED
(FOR EXAMPLE, FOR A VERY COMPLEX LOOKUP).

 AN INDEX IS CREATED ON THE ACTIVE TABLE OR, IF NO ACTIVE TABLE IS FOUND, THE INDEX IS CREATED ON
HANDLING THE INBOUND TABLE.
LARGE DATA
 TAKE INTO ACCOUNT THE RESOURCE REQUIREMENTS AN INDEX REQUIRES IN TERMS OF SAP HANA MEMORY
VOLUME AND INDEX UPDATE PROCESSING;

 USE INDEXES ONLY IF PERFORMANCE EXPECTATIONS CANNOT BE MET WITHOUT THEM.

REMODELING

 REQUIRED WHEN CHANGES ARE NEEDED ON ADSO WITH DATA POPULATED.

 DURING ACTIVATION, THE SYSTEM CHECKS WHETHER THE OBJECT CAN BE ACTIVATED IMMEDIATELY, OR
WHETHER IT NEEDS TO BE REMODELED FIRST. IF REMODELING IS REQUIRED, A WARNING APPEARS.

 THE OBJECT IS NOT ACTIVATED AND A REMODELING REQUEST IS CREATED. WHEN YOU ARE EDITING THE
OBJECT, A MESSAGE INFORMS YOU THAT REMODELING HAS NOT BEEN COMPLETED.

 IF YOU HAVE MADE TWO OR MORE CHANGES TO YOUR OBJECT, THESE CHANGES ARE COMPILED INTO ONE
REMODELING REQUEST.

 YOU CAN CONTINUE TO USE THE ADVANCED DSO VERSION THAT YOU HAVE USED UP UNTIL NOW, PROVIDED
THAT THE REMODELING REQUEST HAS NOT BEEN EXECUTED.
 REMODELING

 OPEN THE REMODELING MONITOR IN YOUR SAP BW SYSTEM USING TRANSACTION RSMONITOR
(REPORT RSCNV_MONITOR). MANUALLY START THE EXECUTION OF THE REMODELING REQUEST.

 IF YOU WANT TO TRANSPORT A REMODELED ADVANCED DSO FROM THE TEST SYSTEM TO THE PRODUCTIVE
HANDLING SYSTEM, AND THE ADSO ALREADY EXISTS IN THE PRODUCTIVE SYSTEM, THE SYSTEM CHECKS WHETHER
LARGE DATA REMODELING IS NECESSARY, AND THE REQUIRED REMODELING REQUEST IS CREATED IN THE TARGET
SYSTEM.
VOLUME
 IF YOU WANT TO TRANSPORT AN ADVANCED DSO FOR WHICH A REMODELING REQUEST HAS BEEN CREATED
BUT NOT YET EXECUTED, A WARNING INFORMS YOU THAT THE M VERSION AND A VERSION ARE DIFFERENT.
YOU CAN ONLY TRANSPORT THE A VERSION (WITHOUT THE CURRENT CHANGES).

 SAP BW/4HANA 2.0 PROVIDES ADDITIONAL REMODELING FEATURES TO CHANGE AN EXISTING ADSOS WITH
DATA. SELECT REMODELING ON THE DETAILS TAB, THE FOLLOWING OPTIONS WILL BE AVAILABLE:

REPLACE INFO OBJECT BY ANOTHER ONE

REPLACE INFOOBJECT BY A FIELD
REPLACE FIELD BY ANOTHER ONE
REPLACE FIELD BY AN INFO OBJECT
FILL WITH VALUE OF INFO OBJECT
FILL WITH VALUE OF FIELD
FILL WITH CONSTANT VALUE
 NEW REQUEST MANAGEMENT (TSN)

 ONE OF THE STRIKING FEATURES OF THE NEW BW/4HANA WORLD IS THE NEW FORM OF REQUEST ID, CALLED
TSN (TRANSACTION SEQUENCE NUMBER). THE BATON HAS NOW BEEN PASSED ON FROM OUR WELL-KNOWN
REQUEST TO REQTSN….

ADSO
ADMINISTRATION
 NEW MANAGE SCREEN :

 GROUPING BY CALENDAR OR REQUEST LIST:

 NEW REQUEST MANAGEMENT (TSN)

 ONE HERE WE CAN SEE THAT NEW REQ TSN HAS FORMAT: <YYYYMMDD HH:MM:SS> <NUMBER> <TIMEZONE>

ADSO
ADMINISTRATION
 NEW REQUEST MANAGEMENT (TSN)

 WE CAN ALSO SEE THE PREVIOUSLY LOADED REQUESTS IN THE 'HISTORY' TAB

ADSO
ADMINISTRATION
 ECLIPSE & BW/4 COCKPIT

 WE HAVE MULTIPLE WAYS TO ACCESS THE MANAGE FUNCTIONALITY FOR AN ADSO.

MANAGING ADSO

 REQUEST MANAGEMENT OF LOADING

AND ACTIVATION PROCESSES
INCLUDING THEIR LOGS

 SELECTIVE OR FULL DELETION

 DISPLAY DATA

 FILTER BY TIME OR STATUS

 DISPLAY METADATA INCLUDING ALL

MODELING AND DATA TIERING
PROPERTIES

 UPLOAD DATA (FROM A FLAT FILE)

 PROCESS CHAIN
PROCESS TYPES
RELATED TO ADSO
ADSO SUPPORT
TOOLS
THERE ARE SEVERAL ADDITIONAL TOOLS TO
ANALYZE ADSOS AND REPAIR THEIR INCONSISTENCY:

 REPORT RSDG_ADSO_ACTIVATE TO ACTIVATE

THESE OBJECTS AND REPAIR CERTAIN ISSUES
IN THEIR DATA MODEL DEFINITION

 REPORT SAP_ADSO_DESIGNS TO ANALYZE THE

SIZE OF ADSOS AND PLAN HOUSEKEEPING
ACTIVITIES

 BW MODELING TOOLS SUPPORT FUNCTIONS

(TRANSACTION RSOADSO), INCLUDING A
FUNCTION TO DISPLAY THE DATA AND THE
DATA MODEL, CHECK AND ACTIVATE IT,
MANAGE THE OBJECT DIRECTORY ENTRY,
WRITE A TRANSPORT REQUEST, AND
GENERATE A WHERE-USED LIST
 PHASES OF DELTA MERGE FOR A HANA COLUMN TABLE

DELTA MERGE
W/ ADSO
 COLUMN-STORE TABLES ARE GOOD AT
READING PERFORMANCE, BUT POOR AT
WRITING OR RECEIVING NEW, UPDATED
DATA.

 FOR THIS REASON, IN-MEMORY COLUMN-

STORE TABLES CONSIST OF A MAIN
STORAGE (READ-OPTIMIZED), AS WELL AS
A SMALL DELTA STORAGE (WRITE-
OPTIMIZED).

 WHEN READING SUCH A TABLE, BOTH THE

MAIN AND DELTA PARTS ARE RELEVANT.
THIS SPLIT IS FULLY TRANSPARENT FOR
THE APPLICATION AND ITS USERS AND IS
NORMALLY MANAGED BY THE SAP HANA
DATABASE.

 SAME IS TRUE FOR THE DELTA MERGE.

THE TRANSFER OF DATA FROM DELTA TO
MAIN IS NORMALLY MANAGED BY THE
DATABASE.
 DELTA MERGE W/ ADSO
 A DELTA MERGE IS USED TO TRANSFER MODIFICATIONS FROM THE DELTA STORAGE TO THE MAIN STORAGE.

 FIRST, AN ASYNCHRONOUS CHECK IS PERFORMED TO SEE WHETHER A DELTA MERGE IS REQUIRED. IF A

THRESHOLD VALUE IS EXCEEDED, THE MERGE IS CARRIED OUT IN THE DELTA STORAGE. WHEN A READ ACCESS IS
EXECUTED, THE DATA IS READ FROM THE MAIN STORAGE AND THE DELTA STORAGE AND THE RESULTS ARE
MERGED TOGETHER.

 BECAUSE SAP BW/4HANA NORMALLY PROCESSES MASS DATA IN ADVANCED DSOS, THE DELTA MERGE IS MANAGED
BY THE APPLICATION IN THIS CASE AND NOT BY THE DATABASE, IN ORDER TO BE ABLE TO PROCESS IT AT THE
BEST SUITED MOMENT. YOU HAVE TWO OPTIONS TO PERFORM THIS:

1. SETTING IN DATA TRANSFER PROCESS : THE DATA TRANSFER PROCESS (DTP) HAS AN UPDATE TAB THAT
CONTAINS A TRIGGER DATABASE MERGE CHECKBOX. ONCE THE DTP REQUEST HAS BEEN
SUCCESSFULLY PROCESSED, THIS SETTING CONTROLS THE DELTA MERGE. THE CHECKBOX IS SELECTED BY
DEFAULT.

2. IN EXCEPTIONAL CASES, PERFORMING A DELTA MERGE AFTER PROCESSING A DTP REQUEST IS NOT
RECOMMENDED BECAUSE OF LOAD BALANCING ISSUES. IN THESE SITUATIONS, THE TRIGGER DELTA
MERGE PROCESS TYPE CAN BE USED WITHIN A PROCESS CHAIN TO EXECUTE THE DELTA MERGE.

 MAKE SURE THAT THE DELTA MERGE IS TRIGGERED BY EITHER THE DTP OR THE PROCESS TYPE. OTHERWISE,
DATA REMAINS IN THE DELTA STORAGE TABLE. OVER TIME, THIS LEADS TO SUBOPTIMAL MEMORY USE AND READ
PERFORMANCE.

 NOTE THAT THE LIMIT OF TWO BILLION ROWS PER PARTITION ALSO APPLIES TO THE SAP HANA DELTA STORAGE.
DELTA MERGE W/ ADSO
 SEMANTIC GROUPS
SUCCESSOR OF SPO
(SEMANTICALLY PARTITIONED
OBJECTS
 USING SAP HANA MEANS THAT THE
SEMANTIC GROUP HAS A SMALLER
NUMBER OF COMPONENTS WITH
 LARGE AMOUNTS OF DATA, AS THE
PERFORMANCE IS GREATLY
IMPROVED BY SAP HANA.

 YOU CAN GENERATE NEW

COMPONENTS FROM A SEMANTIC
GROUP.

 THE STRUCTURE IS TAKEN OVER

FROM AN ADSO TEMPLATE.

 IF CERTAIN CONDITIONS ARE MET,

EXISTING ADVANCED DSOS CAN ALSO
BE ADDED TO THE GROUP.

 THE ADVANCED DSOS REMAIN

OBJECTS IN THEIR OWN RIGHT.
 SEMANTIC GROUPS
 SEMANTIC GROUPS ARE AVAILABLE IN SAP BW/4HANA AS SUCCESSOR OBJECT TYPE OF SEMANTICALLY
PARTITIONED OBJECTS (SPO) OF THE PAST.

 HOWEVER, THE SEMANTIC GROUP IS NOT AN INFOPROVIDER IN ITS OWN RIGHT. IT IS A TOOL USED TO GENERATE
A GROUP FROM THE SEMANTICALLY RELATED ADVANCED DATASTORE OBJECTS.

 A COMPOSITEPROVIDER CAN BE GENERATED TO SIMPLIFY REPORTING AND ANALYSIS OVER ALL COMPONENTS OF
A SEMANTIC GROUP.

 USING SEMANTICALLY PARTITIONED DATA MODELS, GROUPS OFFER THE FOLLOWING ADVANTAGES WHEN
COMPARED WITH INDIVIDUAL ADVANCED DSOS:
1. BETTER PERFORMANCE WITH MASS DATA: SEMANTIC PARTITIONING MEANS THAT THE DATA SETS ARE
DISTRIBUTED OVER SEVERAL DATA CONTAINERS.
RUNTIMES ARE KEPT SHORT, EVEN IF THE DATA VOLUME IS LARGE.

2. ISOLATION OF THE DATA: ERROR HANDLING IS BETTER. IF A REQUEST FOR A REGION ENDS WITH AN ERROR,
FOR EXAMPLE,
THE ENTIRE INFOPROVIDER IS UNAVAILABLE FOR ANALYSIS AND REPORTING. WITH A SEMANTICALLY
PARTITIONED DATA MODEL, THE SEPARATION OF THE REGIONS INTO DIFFERENT PARTITIONS
MEANS THAT ONLY THE REGION THAT CAUSED THE ERROR IS UNAVAILABLE FOR DATA ANALYSIS.

3. WORKING WITH DIFFERENT TIME ZONES : AT MANY ORGANIZATIONS, DATA WAREHOUSING SCENARIOS
CROSS SEVERAL TIME ZONES.
WITH A SEMANTICALLY PARTITIONED DATA MODEL, THE TIME ZONES CAN BE SEPARATED BY THE PARTITIONS.
DATA LOADING AND ADMINISTRATIVE TASKS CAN THEREFORE BE SCHEDULED INDEPENDENTLY OF THE TIME ZONE.
 SEMANTIC GROUPS
DATA STAGING
 WHEN LOADING DATA TO AN ADVANCED DATASTORE OBJECT THAT IS PART OF A SEMANTIC GROUP, A FILTER IN
THE DTP REQUIRES THAT ONLY DATA THAT IS SUITABLE FOR THE DATASTORE OBJECT AS PART OF THE SEMANTIC
GROUP IS EXTRACTED.

 THE DTP IS GIVEN THE STATUS “GREEN” , EVEN IF RECORDS HAVE BEEN FILTERED OUT.

 THE PARTITION CRITERIA ARE ADDITIONALLY ENFORCED IN THE TRANSFORMATION. THIS PREVENTS THAT DATA
FROM BEING POSTED TO THE ADVANCED DSO THAT DOES NOT MATCH THE PARTITION CRITERIA.

REPORTING
 WHEN YOU CREATE THE SEMANTIC GROUP, YOU CAN GENERATE A COMPOSITEPROVIDER THAT CONTAINS ALL
ADVANCED DATASTORE OBJECTS IN THE SEMANTIC GROUP. IT ALSO ASSIGNS THEM TO ONE ANOTHER BY UNION.
THIS PROVIDES YOU WITH THE OBJECT FOR REPORTING AND ANALYSIS.

 THIS COMPOSITEPROVIDER IS OVERWRITTEN EVERY TIME A CHANGE IS MADE TO THE SEMANTIC GROUP.
IT SHOULD THEREFORE NOT BE CHANGED MANUALLY.

TRANSPORTING
 THE SEMANTIC GROUP ITSELF CANNOT BE TRANSPORTED.

 IN THE DEVELOPMENT SYSTEM, OBJECTS ARE GENERATED FROM THE SEMANTIC GROUP. THESE OBJECTS CAN BE
TRANSPORTED TO THE PRODUCTION SYSTEM.

 FOR THE TRANSPORT, ALL OBJECTS ARE IN THE SAME PACKAGE AND ALL OBJECTS ARE IN THE SAME TRANSPORT
REQUEST
 SEMANTIC GROUPS
 WHEN YOU ACCESS AN ADSO BELONGING TO A SEMANTIC GROUP, YOU CAN SEE THE MESSAGE DISPLAYED AT THE
TOP OF THE ADSO SCREEN:
 SEMANTIC GROUPS
MODIFYING THE SEMANTIC GROUP:

YOU CAN CHANGE A SEMANTIC GROUP, BUT NOTE THAT FOLLOWING RESTRICTIONS APPLY:

 ADDING AND DELETING FIELDS:

YOU CAN ADD OR DELETE ELEMENTS (INFOOBJECTS OR FIELDS) BY CHANGING THE REFERENCE STRUCTURE AND THEN
CREATING THE GROUP AGAIN. ALL COMPONENTS FOR WHICH THE APPLY REFERENCE STRUCTURE CHECKBOX IS SET ARE
ADJUSTED IN ACCORDANCE WITH THE NEW STRUCTURE.

 DELETING ELEMENTS:
WHEN DELETING ELEMENTS, THE REFERENCE CHARACTERISTIC MUST BE RETAINED.

 ADDING NEW COMPONENTS:

YOU CAN ADD A NEW COMPONENT TO THE SEMANTIC GROUP AT ANY TIME.

 DELETING COMPONENTS:
ACTIVE COMPONENTS CAN BE DELETED FROM THE GROUP. IN THIS CASE, ONLY THE REFERENCE TO THE GROUP IS
DELETED FROM THE METADATA OF THE ADVANCED DSO; THE ADSO ITSELF IS RETAINED. IF YOU WANT TO DELETE THIS,
EXECUTE THIS OPERATION DIRECTLY ON THE ADSO.

 DELETING THE SEMANTIC GROUP:

IF YOU DELETE A SEMANTIC GROUP, THE PARTICIPATING ADVANCED DSOS AND THE COMPOSITEPROVIDER ARE RETAINED.
ONLY THE REFERENCES IN THE INDIVIDUAL ADSOS TO THE GROUP ARE DELETED.

 CHANGING CRITERIA:
THE PARTITION CRITERIA CAN BE MODIFIED AT ANY TIME WITHOUT REMODELING. IF YOU RESTRICT THE CRITERIA SO
THAT THEY NO LONGER CORRESPOND TO THE LOADED DATA, THEN REMODELING IS OFTEN NECESSARY.
 SEMANTIC GROUPS
MODIFYING THE SEMANTIC GROUP:

 CHANGING AN ADVANCED DSO THAT IS THE

COMPONENT OF A GROUP:
AFTER ADDING COMPONENTS, YOU CAN
DIRECTLY CHANGE THE STRUCTURE OF
INDIVIDUAL COMPONENTS. YOU CAN MAKE
THE CHANGE IN THE EDITING SCREEN OF THE
ADVANCED DSO AS USUAL. THE EDITOR
INDICATES THAT THE ADVANCED DSO
BELONGS TO A GROUP. ONCE THIS TYPE OF
CHANGE IS MADE, THE STRUCTURE OF THE
ADVANCED DSO GENERALLY DEVIATES FROM
THE REFERENCE STRUCTURE OF GROUP.

IF THE KEEP STRUCTURE CHECKBOX IS NOT

SELECTED, THE NEXT ACTIVATION OF THE
SEMANTIC GROUP WILL UNDO THE CHANGE.
WHEN MAKING CHANGES, NOTE THAT THE
REFERENCE CHARACTERISTIC CANNOT BE
DELETED FROM THE ADVANCED DSO.
 SEMANTIC GROUPS
MODIFYING THE SEMANTIC GROUP:

 REMODELING AFTER CREATION:

IF COMPONENTS OF A SEMANTIC GROUP ALREADY CONTAIN DATA, THEN REMODELING MAY BE NECESSARY
AFTER GENERATION. DURING THE GENERATION PROCESS,

REMODELING JOBS ARE CREATED FOR THE AFFECTED COMPONENTS. THESE JOBS NEED TO BE MANUALLY
EXECUTED IN TRANSACTION RSCNV_MONITOR.

THE GENERATION OF THE SEMANTIC GROUP RUNS WITHOUT ERRORS AND A WARNING IS DISPLAYED ONLY
FOR THE AFFECTED COMPONENTS.

REMODELING IS OFTEN NECESSARY WHEN CRITERIA ARE RESTRICTED. IF REMODELING IS NOT SUCCESSFUL,
THEN YOU NEED TO EITHER ADJUST THE CRITERIA TO MATCH THE LOADED DATA, OR SELECTIVELY DELETE
THE NONMATCHING DATA FROM THE ADVANCED DSO. THEN YOU MUST RESTART THE REMODELING REQUEST
 SEMANTIC GROUPS

 CREATION

 DEFINING THE
INFOPROVIDERS
AS SEMANTIC
(LOGICAL)
PARTITIONS
 SEMANTIC GROUPS
 GENERATION OF THE
OBJECTS

 RESULTING BW OBJECTS
(CP, ADSO)
SUMMARY:
ADSO
SALIENT
FEATURES