Skip to Content

DataStore Object – DataStore Object is used to store consolidated and cleansed transaction data in transparent, flat database tables.

 

DataStore Object Types:
1) Standard DataStore Object
2) Write-Optimized DataStore Object
3) DataStore Object for Direct Update

For detailed information on DataStore Object for Direct Update, please look into the following link….
http://help.sap.com/saphelp_nw70/helpdata/EN/f9/45503c242b4a67e10000000a114084/frameset.htm

 

DataStore Object for Direct Update
The following APIs exist for writing and deleting data in DataStore Object for Direct Update:
1) RSDRI_ODSO_INSERT
2) RSDRI_ODSO_INSERT_RFC
3) RSDRI_ODSO_MODIFY
4) RSDRI_ODSO_MODIFY_RFC
5) RSDRI_ODSO_UPDATE
6) RSDRI_ODSO_UPDATE_RFC
7) RSDRI_ODSO_DELETE_RFC

 

How to insert data into DataStore Object for Direct Update using RSDRI_ODSO_INSERT API

 

The below sample code shows how to transfer a small set of data in one RSDRI_ODSO_INSERT API call.

 

REPORT z_dso_insert_data.

* Technical Name for the DataStore Object – Direct Update: ZTESTDSO
* /bic/aztestdso00 is the technical name for the active table that is generated for DataStore Object – Direct Update

DATA:
t_dso_data TYPE TABLE OF /bic/aztestdso00 WITH DEFAULT KEY.

DATA:
i_count TYPE i.

* Assumptions – Based on your requirements…..
* 1) Internal table (t_dso_data) is populated from source data using appropriate logic
* 2) Data cleansing is also performed prior to inserting data into the internal table

  CALL FUNCTION ‘RSDRI_ODSO_INSERT’
    EXPORTING
      i_odsobject = ‘ZTESTDSO’
      i_t_insert = t_dso_data
    IMPORTING
      e_records = i_count
    EXCEPTIONS
      data_target_not_ods = 1
      ods_type_not_transactional = 2
      active_table_name_not_found = 3
      record_key_already_exists = 4
      array_insert_failed = 5
      internal_error = 6
      OTHERS = 7.

  IF sy-subrc = 0.
    WRITE: / ‘Successfully inserted data into the DSO’.
    WRITE: / ‘Number of records inserted into the DSO: ‘, i_count.

  ELSE.
    CASE sy-subrc.
      WHEN 1.
        WRITE: / ‘Error: data_target_not_ods’.
      WHEN 2.
        WRITE: / ‘Error: ods_type_not_transactional’.
      WHEN 3.
        WRITE: / ‘Error: active_table_name_not_found’.
      WHEN 4.
        WRITE: / ‘Error: record_key_already_exists’.
      WHEN 5.
        WRITE: / ‘Error: array_insert_failed’.
      WHEN 6.
        WRITE: / ‘Error: internal_error’.
      WHEN 7.
        WRITE: / ‘Error occurred while inserting records into DSO’.
    ENDCASE.

    STOP.
  ENDIF.

 

1) RSDRI_ODSO_INSERT API should be used, if the requirement is to insert new transaction data.
2) RSDRI_ODSO_UPDATE API should be used, if the requirement is to update existing transaction data.
3) RSDRI_ODSO_MODIFY API should be used, if the requirement is to either insert new transaction data or to update existing transaction data.

If you are inserting large amounts of transaction data into the DSO, then you would have to insert data in smaller sets so that you do not exceed the default limit on internal tables. You will have to analyze your data to find out what would be the approximate number of data records that would work best for your data transfer scenario.

In one of my requirements, transferring 100,000 records per each RSDRI_ODSO_INSERT API call – worked best for me.

 

How to delete data in DataStore Object for Direct Update using RSDRI_ODSO_DELETE_RFC API

 

1) Delete the entire data in the DSO – Direct update

 

OPTION A:

 

The below sample code shows how to delete the entire data in one RSDRI_ODSO_DELETE_RFC API call.

 

REPORT z_dso_delete_entire_data.

DATA:
t_data LIKE STANDARD TABLE OF bapi6116slio WITH HEADER LINE.

DATA:
i_count TYPE i.

* DELETE entire data in the DSO – Direct Update
* Technical Name for the DSO – Direct Update: ZTESTDSO

  CALL FUNCTION ‘RSDRI_ODSO_DELETE_RFC’
    EXPORTING
      i_odsobject = ‘ZTESTDSO’
      i_delete_all = ‘X’
    IMPORTING
      e_numrows = i_count
    TABLES
      i_t_range = t_data
    EXCEPTIONS
      data_target_not_ods = 1
      ods_type_not_transactional = 2
      conflicting_deletion_criteria = 3
      delete_failed = 4
      internal_error = 5
      OTHERS = 6.

  IF sy-subrc = 0.
    WRITE: / ‘Successfully deleted data in the DSO’.
    WRITE: / ‘Number of records deleted in the DSO: ‘, i_count.

ELSE.
    CASE sy-subrc.
      WHEN 1.
          WRITE: / ‘Error: data_target_not_ods’.
      WHEN 2.
        WRITE: / ‘Error: ods_type_not_transactional’.
      WHEN 3.
        WRITE: / ‘Error: conflicting_deletion_criteria’.
      WHEN 4.
        WRITE: / ‘Error: delete_failed’.
      WHEN 5.
        WRITE: / ‘Error: internal_error’.
      WHEN 6.
        WRITE: / ‘Error: unable_to_delete_data’.
    ENDCASE.

    STOP.
  ENDIF.

 

OPTION B: 

 

You can also delete the entire data in the DataStore Object – Direct Update using the following option which is available in T-Code RSPC (Process Chain Maintenance)….

 

image

 

 

2) Delete selective data in the DSO – Direct Update

 

The below sample code shows how to delete selective data in one RSDRI_ODSO_DELETE_RFC API call.

 

REPORT z_dso_delete_selective_data.

DATA:
t_data LIKE STANDARD TABLE OF bapi6116slio WITH HEADER LINE.

DATA:
i_count TYPE i,
d_calday TYPE /bi0/oicalday.

* DELETE data in the DSO – Direct Update based on a certain field like Calendar Day

* Example: The below code will delete all transactions in the DSO – Direct Update prior to 12/31/2009
* Technical Name for the DSO – Direct Update: ZTESTDSO
* Technical Name for the date field in the DSO – Direct Update: 0CALDAY

  d_calday = ‘20091231’.

  t_data-iobjnm = ‘0CALDAY’.
  t_data-sign = ‘I’.
  t_data-opt = ‘LE’.
  t_data-low = d_calday.
  t_data-high = ”.
  APPEND t_data.

  CALL FUNCTION ‘RSDRI_ODSO_DELETE_RFC’
    EXPORTING
      i_odsobject = ‘ZTESTDSO’
      i_delete_all = ”
    IMPORTING
      e_numrows = i_count
    TABLES
      i_t_range = t_data
    EXCEPTIONS
      data_target_not_ods = 1
      ods_type_not_transactional = 2
      conflicting_deletion_criteria = 3
      delete_failed = 4
      internal_error = 5
      OTHERS = 6.

  IF sy-subrc = 0.
    WRITE: / ‘Successfully deleted data in the DSO’.
    WRITE: / ‘Number of records deleted in the DSO: ‘, i_count.

   ELSE.
    CASE sy-subrc.
      WHEN 1.
        WRITE: / ‘Error: data_target_not_ods’.
      WHEN 2.
        WRITE: / ‘Error: ods_type_not_transactional’.
      WHEN 3.
        WRITE: / ‘Error: conflicting_deletion_criteria’.
      WHEN 4.
        WRITE: / ‘Error: delete_failed’.
      WHEN 5.
        WRITE: / ‘Error: internal_error’.
      WHEN 6.
        WRITE: / ‘Error: unable_to_delete_selective_data’.
    ENDCASE.

    STOP.
  ENDIF.

 

Below are the benefits I have noticed by implementing DataStore Object for Direct Update in place of Standard DataStore Object to meet one of my requirements…

 

Requirement – Load large amounts of transaction data (close to 100 million records) every month thru flat files and provide reporting capability on it to slice and dice data.

1) PERFORMANCE – DataStore Object for Direct Update stores data in single version, so no activation needed and data can be loaded much faster.
2) DISK SPACE – Since the data was received thru flat files, using an ABAP program which calls the RSDRI_ODSO_INSERT API to insert data into the DataStore Object for Direct update eliminates additional layers like generation of ready to load data files, PSA, Change Log Table, etc. Within the ABAP program data cleansing was also performed.

Initially I also considered using Write-Optimized DataStore Object, but due to the following reasons I went with DataStore Object for Direct Update instead…

• Data was received thru flat files which was not in ready to load format and required a lot of transposing & cleansing every month.
• Avoid additional layers like generation of ready to load data files & PSA, considering the high data volume.
• DataStore Object for Direct Update was used as the staging location.
• Data was updated in the target Info Providers using appropriate filters (FULL update), so that data transfer happens in smaller sets.

 

References:
http://help.sap.com/saphelp_nw70/helpdata/EN/f9/45503c242b4a67e10000000a114084/frameset.htm

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply