How to read/write/delete from/to DSO objects

Update: for the latest versions of SAP BW (7.5+) or BW4/HANA use dedicated APIs to work with aDSO object, See blogpost here: How to read/write/delete from/to aDSO objects

Sometimes it is needed to store data into DSO objects from ABAP. Either from BW’s transformation or for some reason from regular ABAP programs. Therefore some kind of API needed to be developed by SAP to allow this. There in classing (non BW4H) BW an several DSO types are available: standard/direct update/write optimized. The DSO type is needed to be considered and scenario of the DSO type shall be respected. Normally it makes no sense to write data to write optimized or standard DSO. Regular BW flows shall be used instead. The only DSO type is designed to be updated programically from custom code is Direct Update DSO. That’s why full API is only available for this type of the DSO.

 

DSO types                        methods of accessing

Standard    Open SQL SELECT / INSERT or UPDATE / BAPI_ODSO_READ_DATA_UC /SDRD_SEL_DELETION

Direct Update           Open SQL SELECT statement / BAPI_ODSO_READ_DATA_UC / RSDRI_ODSO_INSERT, RSDRI_ODSO_MODIFY_RFC, RSDRI_ODSO_UPDATE_RFC / RSDRI_ODSO_DELETE_RFC

Write-Optimized        Open SQL SELECT statement / BAPI_ODSO_READ_DATA_UC

 

Note that in earlier versions of BW the FM BAPI_ODSO_READ_DATA was available but it is obsolete (as of version NW2004s) and BAPI_ODSO_READ_DATA_UC should be use instead.

RSDRI* FM are also available as non RFC enabled ones.

More information:

DataStore Object APIs

APIs of the DataStore Object for Direct Update

A little about InfoPackage / DTP prefixes and BW data request's prefixes

In this post I try to sum up brief information on topic of different InfoPackage and DTPs prefixes. In addition I’m also providing information on BW’s data request numbers prefixes.

InfoPack prefixes:

ZPAK_* - custom developed InfoPack

0PAK_* - InfoPackage activated from BI Content

0GRU_* - BI Content InfoPackage groups, assignment of InfoPacks into Group is in table RSPAKPOS

0GRU_* - custom InfoPackage groups

PRNR_* - automatic update from the PSA into the data targets

INFO_* - InfoPackage for BW-WHM runtime statistics, used on old BW systems(below version 3.x)

DTP prefixes:

DTP_* - regular DTP, has corresponding DTP request ID with naming convention: DTPR_*     

D* - in general any the DTP ID can start with just D prefix

DTPR_SIMULATION    - not real the DTP run, only debug run of the DTP = debugging DTP

Request numbers prefixes:

- General prefixes:

REQU_* - generic request ID created by run of InfoPackage, any request that can be displayed in tcode RSRQ

DTPR_* - generic request ID created by run of the DTP

REBU_* - rebuilding request, it is not real (independent) request, it is the request that has not yet written any RSSELDONE entry, it cannot be displayed in monitor, because it is only number under which an additional rebuilding monitor log for normal load requests is stored.

APO_R* or APO_* - request for APO Demand Planning data, InfoProvider is switched to transactional behavior

- DSO/ODS relevant prefixes:

ODSR_* - ODS activation request or the request loaded from change log of an upstream ODS object using a "Reconstruction" function

ODSA_* - change log activation prefix

ODSU_* - change log update prefix

- Other request prefixes: 

STOR_* - reversal of a request

ARCH_* - requests generated by Data Archiving Processes (tcode RSDAP)

- Request prefixes not more used anymore (as of BW version 3.0B) prefixes:

MDMT_* - generated by master data maintenance functions of BW

R3RD_* - similar as above

RNDI_* - load of master data or text for characteristic using 'RSNDI API' functions

SPOK_* - looks like it was related to InfoSpoke functions

Inserting data into InfoProviders manually

Usually in case of need for manual input of data we speak about planning applications in BW area. There are technologies like BW-SEM (Strategic Enterprise Management), BPS (Business Planning and Simulation) BW-IP (Integrated Planning) where those applications are being developed for specific needs of business users. Of course there are more planning offering from SAP I just mentioned here a few.

Although it is quite rare situation BW developers sometimes face situation where customers are demanding function to enter the data into InfoProviders manually even application is completely not related to planning. In this case it means to have a possibility to insert the data into BW’s InfoProvider w/o any InfoPackage/DTP any transformation/update rule. The requirement like this may sound strange. To name few situations where this can be applicable can be: lack of data in development/test/QA environment and no time to develop regular BW flow to populate the data. Also one could create planning function to the manual entry but again we do not want anything from planning be involved in here.

So given this there are following options available in BW to insert the data manually:

1. TA RSINPUT (Manual Data Entry) – supports cube and DSO objects but cube must be type of real-time and DSO must be type of direct update. There are 2 steps that need to be carried out. First you can configure which fields will be marked as for selection, maintenance, no entry, mandatory and as default value.  This is done on CONFIGURE screen. On next screen which is CHANGE/CREATE screen we can actually enter the data. ALV type layout is displayed for convenient entering of the data.

2. ABAP report CUBE_SAMPLE_CREATE – works with the cube regardless of its type. It can be “Standard InfoCube” or “Real-Time InfoCube” However the report works only for cubes no other infoproviderrs (e.g. DSOs are supported).

Values can be populated into the cube in following modes:

A) Generated Values – all values are randomly generated just to fit the type of infoobjects used.

B) Vales from Master Data Table – values from corresponding Master Data tables are used to fill up the data.

C) Ready-For-Input ALV – Only values that are entered by user are saved in the cube. User gets ALV input screen and can freely add the data as he/she wishes.

3. Custom ABAP report – One can create custom report similar to option no 2. This can be tailored only for specific cube and can be designed to run in background. You can use FM CUBE_SAMPLE_CREATE_NEW to see how data should be processed and FM RSDRI_CUBE_WRITE_PACKAGE to insert the data.

Additional info:

Step by Step Procedure: Creating Sample Data for InfoCube

Technical IOs for w-o DSO

There are many technical infoobjects in SAP BW. Basically they are not supposed to be used by BW developers while modeling the infoproviders. Instead they are needed to make BW functioning from technical perspective. 

Let’s take example of 0DATAPAKID IO. The IO is part of technical key in Write Optimized (w-o) DSO. Among this IO there are two more which combinations created technical key of w-o DSO:

Request GUID field (0REQUEST)

Data Record Number field (0RECORD)

The 0DATAPAKID or so called Data Package field is used to carry data package ID for particular record of data which is stored in the DSO. The package ID is calculated within the load to the DSO.

If you have very fresh BW system installation you may encounter following errors while loading the data:

Error in BW: error getting datapakid cob_pro

Message no. RS_EXCEPTION105

Error while extracting from source C9_MGATP (type DataStore)

Message no. RSBK242

Issue is caused by not active IO related to technical IOs in your system. In this case it was related to 0DATAPAKID. All that needs to be done is to activate the IO from business content.

Grouping of InfoObjects in InfoProviders

This post to is to remember one nice functionality available in RSA1. It is related to InfoProviders and grouping of key figures. It comes very handy in case of huge InfoProviders with hundreds of KPIs.

In case of InfoCube/MultiProvider/VirtualProvider/HybridProvider objects - only for Key figures, characteristrics are grupped already through dimensions:

Here how does it look like:

 In case of DSO objects – available for grouing of Data Fields:

 

How to look for DSO’s tables?

There is a nice and useful functionality available in TA RSA1 to access data in DSO across its all 3 tables (in case of normal DSO): New, Active and Change Log. If you navigate into InfoProviders section in Modeling area and you choose right mouse click on particular DSO you select Manage menu. There is a tab strip called Content. 
Here you can specify particular data you are interested in:

New data - contents of the activation queue

Active data – contents of A table = active data

Change log – contents of change log table

So this is easy part. But what to do in case you need to determine DSO table via runtime in your custom ABAP? In this case we can use information stored in field ODSNAME_TECH in table RSTSODS. Or there is a nice tiny standard ABAP method provided called get_tablnm from class cl_rsd_odso.

And what about I just want to quickly see DSO data in data dictionary transactions like SE11 or SE16? Here’s hint: put a prefix /BIC/A or /BI0 in front of DSO and you get active table. Here you need to recognize either you looking for table of Business Content DSO or custom created one:

 


for Business Content DSO replace /BIC/ with /BI0/.

Further checking of broken DSO objects

You might experience following error while loading data to DSO:

System error in program SAPLRS_EXCEPTION and form RS_EXCEPTION_TO_MESSAGE (see long text) Message no. BRAIN299

Unknown error in SQL interface Message no. DBMAN259

Error while extracting from source DSOXXX (type DataStore) Message no. RSBK242

Package 2 / 16.01.2009 15:28:21 / Status 'Processed with Errors' Message no. RSBK257

This is purely linked with technical problem with your ODS object. Solution is to recreate DDIC objects behind you DSO. Normal option would be to delete DSO object and create it again from scratch. Since usually there is no so much time to proceed like this you may try to fix it like following:

1. TA RSRV (Analyses and Repair of BI Objects) -> All Elementary Tests -> ODS Objects -> Foreign Key Relationship of Reporting-Relevant ODS Object and SID Table Characteristics -> put your DSO here -> Execute

Then you get message like:

Error: Too many specifications missing for InfoObject IOXXX         Message no. RSRV503

SID values missing for 2.097 specifications of characteristic IOXXX Message no. RSRV501

Moreover system generates for you an ABAP report called: GP_ERR_RSODSO_ACTIVATE. You can browse this report in TA SE38 and via ABAP syntax Check functionality you easily explore which DDIC object is broken.

2. To fix this broken DDCI object use the report RSDG_ODSO_ACTIVATE which activates the DataStore object. Run it in Activate mode. Note that this result in the creation of a new change log table and that existing data from the inconsistent change log table may be lost.

You may be able to determine from executing the report in check mode whether further inconsistent DataStore objects exist.