DSO & its types, Creation of DSO

1. DATA STORE
OBJECTS
- Yasmin Banu A

2. INTRODUCTION

3. WHAT IS A DSO?
 Data Store Object (DSO) is a two-dimensional storage unit
 It mainly stores consolidated and cleansed transaction data
 Data is stored at detailed level
 With DSO’s, its also possible to overwrite data fields
 Detailed level reporting can be obtained from DSO
 DSO contains:
 Key fields - Such as document number & document item
number
 Data fields – Can have key figures & character fields such
as Customer, Sales Quantity, Order Status
 Data in DSO is stored in transparent flat database tables

4. TYPES OF DSO

5. TYPES OF DSO:
TYPE OF
DSO
STRUCTURE SUPPLY
OF DATA
SID
GENERATION
Standard Consists of 3 tables :
 New table
 Active table
 Change Log table
From data
transfer
process
Yes
Write-
Optimized
Consists of the table
of active data only
From data
transfer
process
No
Direct
Update
Consists of the table
of active data only
From APIs No

6. TYPE 1: STANDARD
DSO

7. STRUCTURE OF STANDARD DSO
 Standard DSO contains the following 3 tables:
a) New data table – Holds the records that
are to be updated, not yet been
activated. After activation, this data is
deleted if all requests in the new table have
been activated
b) Active table – A table containing the active
data (A table)
c) Change log table – Holds the change
history for delta loads

8. STRUCTURE OF STANDARD DSO (CONTD.)
 The tables of active table are built according to the
DSO definition.
 This means that key fields and data fields are
specified when the DataStore object is defined
 The new table & change log are identical in
structure:
 New table – has SID as its key, package ID and the
record number
 Change Log – has request ID as its key, the package ID
and Record Number
 Data arrives in the change log from the new table
and is written to the table for active data upon
activation

9. EXAMPLE OF ACTIVATING & UPDATING DATA:
Staging Engine
Req1 Req2 Req3
New data table
Active table
Change Log table
REQU1 | P1 | Rec. 1 | 3511 | 10
REQU2 | P1 | Rec. 1 | 3511 | 30
3511 | 10
3511 | 30
Req. ID | Pack. ID | Rec. No.
DSORx | P1 | Rec. 1 | 3511 | 10
DSORy | P1 | Rec. 1 | 3511 | -10
DSORy | P1 | Rec. 1 | 3511 | +30
Activation

10.  Request 1 with amount 10 and Request 2 with
amount 30 are loaded parallel into the DSO. It take
us to the new data table. We are given a unique
Request ID
 When activation is performed, the requests are
sorted by key, transferred into the table containing
the active data, and immediately deleted from the
new data table. In Active table, the amount 10 is
replaced by 30 (Since Overwrite is set as the
Update type)
 When we activate the data, the change log is also
notified. The old record from the active table is
saved as a negative (-10) and the new record is
stored as a positive (+30)

11. 0RECORDMODE :
 When activation is done over the standard DSO,
SAP Netweaver BW adds the 0RECORDMODE
Info object to the definition of the Standard DSO
and to all the three tables (New, Change & Active
tables)
 This Info Object is used internally by SAP
Netweaver BW
 Delta is a feature of extractor, which refers to
changes (new/modified entries)
 Record Mode is used in Delta process
 The record mode describes the type of change that
a data record contains
 If a datasource is delta capable, the field
ROCANCEL which is part of the datasource, holds
the changes from R/3 side

12. 0RECORDMODE (CONTD.):
 This field for the DataSource is assigned to the Info
Object 0RECORDMODE in the BW system
 ROCANCEL serves the same purpose at R/3 side
which its counterpart 0RECORDMODE does at BW
side
 The values for 0recordmode are:
VALUE MEANING
Blank The record provides an after image
X The record provides a before image
A The record provides an additive image
D The record must be deleted
R The record provides a reverse image
N The record provides a new image

13. DESIGNING OF
STANDARD DSO

14. DESIGNING A STANDARD DSO:
 Step 1: Create the flat file in csv format
 Step 2: Create Data Source

15. DESIGNING A STANDARD DSO (CONTD.):
 Step 3: Give the name for data source & the data
source type as transaction data

16. DESIGNING A STANDARD DSO (CONTD.):
 Step 4: In the ‘General’ tab, give the short, medium
& long descriptions

17. DESIGNING A STANDARD DSO (CONTD.):
 Step 5: In the ‘Extraction’ tab, specify the file name,
header rows to be ignored, data format & data
separator

18. DESIGNING A STANDARD DSO (CONTD.):
 Step 6: In ‘Proposal’ tab, click on ‘Load Example
Data’ to have view of how the loaded data will
appear

19. DESIGNING A STANDARD DSO (CONTD.):
 Step 7: In the ‘Fields’ tab, the list of fields available
in the flat file gets added automatically

20.  Step 8: In ‘Preview’ tab, first check & activate the
data source. Then choose the ‘Read Preview Data’

21. DESIGNING A STANDARD DSO (CONTD.):
 Result appears as below

22. DESIGNING A STANDARD DSO (CONTD.):
 Step 9: Now, we have to create the Info Package to
load data into the PSA

23. DESIGNING A STANDARD DSO (CONTD.):
 Give the description for Info Package & continue

24. DESIGNING A STANDARD DSO (CONTD.):
 Step 10: Go to ‘Schedule’ tab & click on Start.
Monitor the load to PSA

25. DESIGNING A STANDARD DSO (CONTD.):

26. DESIGNING A STANDARD DSO (CONTD.):
 Step 11: Create the DSO by giving the technical
name & description

27. DESIGNING A STANDARD DSO (CONTD.):

28. DESIGNING A STANDARD DSO (CONTD.):
 Step 12: Click on the Info Object Catalog
(Characteristics first & then Key Figures
Catalog),then choose the key fields & data fields

29. DESIGNING A STANDARD DSO (CONTD.):

30. DESIGNING A STANDARD DSO (CONTD.):

31. DESIGNING A STANDARD DSO (CONTD.):

32. DESIGNING A STANDARD DSO (CONTD.):

33. DESIGNING A STANDARD DSO (CONTD.):
 Step 13: Create the transformation. Check the
details in the pop up screen like object type & data
source

34. DESIGNING A STANDARD DSO (CONTD.):

35. DESIGNING A STANDARD DSO (CONTD.):
 Step 14: Create the mapping between data source
fields & target fields. Save & Activate

36. DESIGNING A STANDARD DSO (CONTD.):
 Step 15: Create the DTP (Data Transfer Process),
to load data from PSA to DSO. Click Continue

37. DESIGNING A STANDARD DSO (CONTD.):

38. DESIGNING A STANDARD DSO (CONTD.):
 Step 16: In order to press the ‘Execute’ button, we
will have to activate the DTP

39. DESIGNING A STANDARD DSO (CONTD.):

40. DESIGNING A STANDARD DSO (CONTD.):

41. DESIGNING A STANDARD DSO (CONTD.):
 Step 17: Now, check the status of the data load by
going to the Manage screen of the DSO

42. DESIGNING A STANDARD DSO (CONTD.):
 The reporting icon is not available, which means it
will not be available for reporting, hence, we have
to activate the data.

43. DESIGNING A STANDARD DSO (CONTD.):
 Step 18: The New data table will have the loaded
records, we can check by selecting the ‘New Data
Table’ in the contents tab

44. DESIGNING A STANDARD DSO (CONTD.):
 The New table data contents appear as below

45. DESIGNING A STANDARD DSO (CONTD.):
 Step 19: Since we have still not activated the
Request, the Active data will be empty. Let’s see
the contents of the Active table

46. DESIGNING A STANDARD DSO (CONTD.):

47. DESIGNING A STANDARD DSO (CONTD.):
 Step 20: Now, to activate the Request & make data
available for reporting, we follow the below steps to
activate
 Select the Request ID to be activated. Click
Activate

48. DESIGNING A STANDARD DSO (CONTD.):
 In the pop-up below, choose the Request ID &
press ‘Refresh’. Wait till the Request ID disappears
from this screen

49. DESIGNING A STANDARD DSO (CONTD.):

50. DESIGNING A STANDARD DSO (CONTD.):

51. DESIGNING A STANDARD DSO (CONTD.):
 Step 21: Press ‘Refresh’ button to see the reporting
icon in the Manage screen

52. DESIGNING A STANDARD DSO (CONTD.):

53. DESIGNING A STANDARD DSO (CONTD.):
 Step 22: Now, after Activation, if we check the New
Data table, it will have no records. The Active table
& Change Log table will have the loaded records in
them now

54. DESIGNING A STANDARD DSO (CONTD.):

55. DESIGNING A STANDARD DSO (CONTD.):

56. DESIGNING A STANDARD DSO (CONTD.):
 Data In Active Table

57. DESIGNING A STANDARD DSO (CONTD.):

58. DESIGNING A STANDARD DSO (CONTD.):
 Data In Change Log Table
0RECORDMODE has values
as ‘N’ which means New
records

59. TYPE 2: WRITE-
OPTIMIZED DSO

60. INTRODUCTION TO WRITE-OPTIMIZED DSO:
 Write Optimized DSO is used when DSO is
required for storing lowest granularity records
such as address & when overwrite functionality
is not needed
 It consists of Active data only, hence no need
for data activation which increases data
process
 It is used a temporary storage are for large set
of data
 Write Optimized DSO has been primarily
designed to be the initial staging of the source
system data from where the data could be
transferred to the Standard DSO or Info Cube

61. WRITE-OPTIMIZED DSO PROPERTIES:
 It is used for initial staging of source system
data
 Data stored is of lowest granularity
 Data loads can be faster since it doesn’t
have the separate activation step
 Every record has a technical key and hence
aggregation of records is not possible. New
records are inserted every time

62. DESIGNING OF
WRITE OPTIMIZED
DSO

63. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Step 1: Create the DSO by right clicking on the Info
Area & choosing the option ‘Create Data Store
Object’

64. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Step 2: Enter the Technical name, description. Click
on Create button

65. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Step 3: Click on the Edit button of ‘Type of Data
Store Object’

66. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Step 4: Choose the Type ‘Write-Optimized’ & click
on Continue

67. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Step 5: The following screen appears

68. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Technical keys
 Include Request ID, Data package, Data Record number. No
additional objects can be included under this.
 Semantic keys
 Are similar to key fields
 However, here the uniqueness is not considered for over write
functionality
 They are instead used in conjunction with setting ’Do not
check uniqueness of data’
 The purpose of Semantic Key is to identify error in incoming
records or Duplicate records
 If we do not check the Check Box “Allow Duplicate Record”, the
data coming from source is checked for duplication, i.e, if same
record (semantic keys) already exist in the DSO, then current
load is terminated
 If we select the check box, Duplicate records are loaded as a
new record. There is no relevance of semantic keys in this case

69. DESIGNING A WRITE-OPTIMIZED DSO (CONTD.):
 Step 6: After adding the Info Objects accordingly to
Semantic & Data fields, we Activate the DSO

70. THANK YOU