Type of Data Transfer Procesess

There are a few types of DTP. A purpose of the DTP or so called Data Transfer Process is to specify how data is transferred between two objects in BW system. It governs from which objects data is extracted (source object) and into which objects the data is stored to (target object.). The data transfer process forms a template for requests. When a request of this type is processed, data is loaded into a target object from a source object.

Technical name of the DTP can have different prefixes as I wrote here. However, in this blog post I discuss the type of the DTP. There are following DTP types recognized by their purpose or a context in which the particular DTP can be used:

 

<blank>      Standard (Can Be Scheduled)

Mostly to run in Process Chains on periodic basis (thus a term scheduled) as loading process. Also can be running manually by the user.

REAL

DTP for Real-Time Data Acquisition, A daemon provides DTPs of this type with new data from a source in regular and frequent intervals.

 

REMT           DTP for Direct Access

Is used to read data from a query directly from a source system using RFC. DTPs for direct access typically access highly current data that has not yet been made available in the BW system by the scheduled load processes.

 

EDTP            Error DTP

The DTP that serve for purposes of error handling of another DTP. The other DTP is called standard DTP. Error DTP has the standard DTP specified in table RSBKDTP and column DTP_STANDARD. In addition, the standard DTP is specified in column SRC in the same table.

 

Type of the DTP can be spotted in t-codes like RSDTP:

Technically the type of the DTP is stored in table RSBKDTP and in column DTPTYPE (Type of Data Transfer Process). The column definition refers to data dictionary domain RSBKDTPTYPE.

Apart of column DTP_STANDARD there is one more interesting column in the table RSBKDTP. It is DTP_ORIGINAL column. In most cases the DTP technical ID (column DTP) is equal to the DTP_ORIGINAL. However, when the DTP was copied from the DTP that was transferred from a Business Content the DTP_ORIGINAL carries the ID of the content DTP. In case the DTP_ORIGINAL column is empty there is an ABAP program RSBK_FILL_ORIGINAL_DTP that populates the column. This is needed as the DTP that has no original column maintained may fail to transport across BW systems in a landscape. 

More information:

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

2016048 - P34: DTP: Fill Original_DTP if field is empty

DTP: Temporary storage

Within the SAP BW DTP object there is used a term temporary storage. It is used during DTP’s runtime and it enables a restart of particular DTP’s task in case an error occurred. Aim is to restart DTP’s task without an impact on overall performance of DTP’s runtime as well as on data consistency when errors occur.

Naturally, during such restarts the system generates a temporary data into database tables. There are settings at DTP level related to temporary storage. Those settings enables management of the temporary data. Means data management of the temporary storage thus they are a so called Settings for temporary storage.

The temporary data can be deleted depending on whether a request has been updated successfully to the target, when the request is deleted, or after a specific interval has passed since the request was processed.

These Settings for temporary storage are available in DTP’s screen (e.g. t-code RSDTP) in menu Goto -> Settings for DTP Temporary Storage.

Following are the settings available:

1/ related to Delete Temporary Storage:

1.1 With Request Status ‘Green’ - Deletion of Temp. Storage If Request Status Is 'Green'

With Request Status ‘Deleted’ - Deletion of temp. storage if req. status is 'deleted'

After x Days/Weeks/Month - Deletion of the Temporary Storage by Time Interval

Technically stored in table RSBKDTP and in following fields:

1.1 GREEN                      RSBKBUFFERDELETEGREEN            Deletion of Temp. Storage If Request Status Is 'Green'

1.2 DELETED                   RSBKBUFFERDELETEDELETED         Deletion of temp. storage if req. status is 'deleted'

1.3 AFTER                      RSBKBUFFERDELETEAFTER            Deletion of the Temporary Storage by Time Interval

Above 3 data are resented as checkboxes (domain RS_BOOL)

1.4 TIMEINTERVAL           RSBKTIMEINTERVAL                     Time Interval

Above data is represented by no of days e.g. (domain PERCDAYS, range from 1 to 31 depending on particular month)

4.5 TIMEUNIT                  RSBKTIMEUNIT                            Time Unit ( Days / Weeks / Months )

Represented by either Days (0), or Weeks (1), or Months (2) – domain RSBKTIMEUNIT.

 

2/ Level/Degree of Detail

Describes what is a level of detail on which the system is tracing the errors.

Technically stored in table RSBKDTP and in field BUFFERLEVEL (DTP Temporary Storage: Level of Detail, domain: RSBKBUFFERLEVEL). It can have a following values:

0        Tracing the Transformation by Package

1        Trace of Erroneous Records

2        Trace of the Transformation by Record

 

3/ Fill Temporary Storage After Following Substeps:

Save Data After the Substep - Indicates whether the system should generate a temporary storage behind a substep of DTP request processing.