DTP determines the process of transferring data between two persistent / non-persistent objects within the BI. In this blog we’ll be discussing about the types of DTP in SA
Starting with SAP NetWeaver 7.0, InfoPackage uploads data from Source System to PSA. DTP decides to upload more data thereafter.
Use
- Uploading data from PSA to InfoProvider (s).
- Transferring data from one InfoProvider to another within the BI.
- Distribution of targeted data outside the BI system; e.g. Open HUBs, etc.
- In the process of transferring data within the BI, Transformation defines the map layout and logical data analysis for targeted data while, Output Mode and Update mode are determined using DTP.
NOTE: DTP is only used for uploading data within the BI system; unless used in Virtual InfoProviders situations where DTP can be used to determine direct data downloads to the source system during operation.
Key Benefits of using DTP over standard IP uploads
- DTP follows one to one path between source and target, i.e. one DTP data source goes to only one data target while, IP uploads data to all data directions at once. This is one of the biggest benefits beyond the InfoPackage approach as it helps to achieve many other benefits.
- Distribution of Data Upload from Source to system BI (PSA) and within the BI system. This helps to schedule data uploads to InfoProviders anytime after uploading data from a source.
- The best error management method is using the Temporary Storage, Semantic Keys and Error Stack.
Extraction
- Background
There are two types of DTP Exit methods – Full and Delta.
Full:
Full update mode is the same as in InfoPackage.
Selects all available data from the source based on the Filter conditions specified in the DTP.
If the data source is from InfoProviders below, only Full Release Mode is available.
- InfoObjects
- InfoSets
- DataStore Direct Update Items
Delta is not possible if the source is one of the above.
Delta:
Unlike InfoPackage, delta transfers using DTP do not require explicit implementation. When DTP is used in Extraction mode Delta for the first time, all existing applications up to date are found in the source and delta is started automatically.
The following 3 options are available in DTP with Exit Mode: Delta.
- Get Delta Only Once.
- Get All New Data Request per Application.
- Retrieve Until New Data Exists.
Get delta only once:
Once this indicator is set, a summary status is created. The data found in Target accurately reflects the Source Data.
Status:
Let’s consider a situation where Data is transferred from Flat File to InfoCube. Target only needs to contain data from the latest Flat File uploads. Each time a new application is uploaded, the previous application requires removal of Target. For all new data uploads, any previous application uploaded on the same selection terms will be automatically deleted from InfoCube. This is required, whenever the source only brings the final status of important statistics, such as the Snap Shot of Source Data.
A fully loaded DTP should meet the requirement. However, it is not recommended to use Full DTP; the reason is, full DTP uploads all applications from PSA whether these were previously uploaded or not. Therefore, in order to avoid duplication of data due to overload, we should always plan for PSA removal before full DTP is activated again.
‘Delta Once Only’ does this work in a very effective way; as it only uploads the latest application (Delta) from PSA to the data target.
- Remove the previous request from the data target.
- Upload data to PSA using Full InfoPackage.
- Use DTP in Exit Mode: Delta with ‘Get Delta Once’ only.
The above 3 steps can be incorporated in a Process Chain which avoids any manual intervention.
Get all new data requests per request:
If you set this guide to ‘Return Until No New Data’, DTP receives data from a single source request. Upon completion of processing, DTP checks whether the source contains some new applications. If the source contains multiple requests, a new DTP request is automatically generated and processed.
NOTE: If ‘Restore Till No New Data’ is not checked, the above option automatically changes to ‘Get One Request Only’. This will only get one application per source.
Also, once DTP is activated, the ‘Restore Until No New Data’ option no longer appears in DTP configuration.
Package Size
The number of Data records contained in one individual Data package is determined here.
Default value is 50,000.
Filter:
The selection Criteria for fetching the data from the source is determined / restricted by filter.
We have following options to restrict a value / range of values:
- Multiple selections
- OLAP variable
- ABAP Routine
On the right of the Filter button indicates the Filter selections exist for the DTP.
Update
Error Handling
- Deactivated:
If an error occurs, the error is reported at the package level and not at the data record level.
The incorrect records are not written to the error stack since the request is terminated and has to be updated again in its entirety.
This results in faster processing.
- No Update, No Reporting:
If errors occur, the system terminates the update of the entire data package. The request is not released for reporting. The incorrect record is highlighted so that the error can be assigned to the data record.
The incorrect records are not written to the error stack since the request is terminated and has to be updated again in its entirety.
- Valid Records Update, No Reporting (Request Red):
This option allows you to update valid data. This data is only released for reporting after the administrator checks the incorrect records that are not updated and manually releases the request (by a QM action, that is, setting the overall status on the Status tab page in the monitor).
The incorrect records are written to a separate error stack in which the records are edited and can be updated manually using an error DTP.
- Valid Records Update, Reporting Possible (Request Green):
Valid records can be reported immediately. Automatic follow-up actions, such as adjusting the aggregates, are also carried out.
The incorrect records are written to a separate error stack in which the records are edited and can be updated manually using an error DTP.
DTP error
Error records in DTP uploads are written in a stack called Error Stack
Error Stack is a request-based table (PSA table) in which records error data from the data transfer process (DTP). The error stack is based on a data source (PSA, DSO or Info Cube), i.e., records from the source are written to the error stack.
In order to upload data to the Target Data, we need to modify the data records in the Error Stack and use the DTP Error manually.
Execute
Processing Mode
Serial Extraction, Immediate Parallel Processing:
A request is processed in a background process when a DTP is started in a process chain or manually.
Serial in dialog process (for debugging):
A request is processed in a dialog process when it is started in debug mode from DTP maintenance.
This mode is ideal for simulating the DTP execution in Debugging mode. When this mode is selected, we have the option to activate or deactivate the session Break Points at various stages like – Extraction, Data Filtering, Error Handling, Transformation and Data Target updating.
You cannot start requests for real-time data acquisition in debug mode.
Debugging Tip:
When you want to debug the DTP, you cannot set a session breakpoint in the editor where you write the ABAP code (e.g. DTP Filter). You need to set a session break point(s) in the Generated program as shown below:
No data transfer; delta status in source: fetched:
This processing is available only when DTP is operated in Delta Mode. It is similar to Delta Initialization without data transfer as in an InfoPackage.
In this mode, the DTP executes directly in Dialog. The request generated would mark the data found from the source as fetched, but does not actually load any data to the target.
We can choose this mode even if the data has already been transferred previously using the DTP.
Delta DTP on a DSO
There are special data transfer options when the Data is sourced from a DTP to other Data Target.
- Active Table (with Archive)
The data is read from the DSO active table and from the archived data.
- Active Table (Without Archive)
The data is only read from the active table of a DSO. If there is data in the archive or in near-line storage at the time of extraction, this data is not extracted. - Archive (Full Extraction Only)
The data is only read from the archive data store. Data is not extracted from the active table. - Change Log
The data is read from the change log and not the active table of the DSO.
Important Notice for college students
If you’re a college student and have skills in programming languages, Want to earn through blogging? Mail us at geekycomail@gmail.com
For more Programming related blogs Visit Us Geekycodes . Follow us on Instagram.
