DTP Fundamentals: Purpose, Types, and Basic Configuration

Explanation

A Data Transfer Process (DTP) is the runtime and configuration object in SAP BW / BW/4HANA that controls how data physically moves from a source object (PSA, DataSource, InfoSource, or another InfoProvider/ADSO) into a target object, applying the logic defined in a Transformation along the way. Before DTPs existed (in classic BW 3.x), this job was done by InfoPackages combined with update rules, which mixed extraction and transformation logic in a less modular way. The DTP separated 'how data is transformed' (Transformation) from 'how and when data is moved' (DTP), giving BW modelers much finer control over load behavior, error handling, and semantics. Why this matters: every single data load in a BW model — from source system into PSA, from PSA into an ADSO, from one ADSO into another, or into an InfoCube or CompositeProvider staging object — is executed by a DTP. Without a correctly configured DTP, no data reaches the target, and even a technically correct Transformation is useless if the DTP settings (selection, packaging, delta type) do not match the business requirement. DTP Types: The two fundamental DTP types are Full and Delta. - A Full DTP extracts all records matching its selection criteria every time it runs, regardless of what changed since the last load. Full loads are simple, deterministic, and easy to reconcile, but expensive for large volumes because they reprocess unchanged data. - A Delta DTP extracts only records that have changed (new, updated, or in some models deleted) since the last successful delta load. Delta DTPs depend on the underlying source object having delta capability — for a DataSource this typically means it supports delta extraction from the source system or has queued/direct delta enabled; for BW-internal objects (ADSO to ADSO, for example), the source ADSO's change log or delta-enabled active table provides the delta records. A DTP for a delta-enabled data flow maintains a delta pointer (a request/timestamp-based watermark) so each execution only picks up new data since the last run. The very first execution of a Delta DTP is special: it is called the 'initialization' or in newer BW versions can be run with an option to either fetch historical data once or set the pointer without transferring history. Getting this first run wrong is one of the most common production issues, because a mis-initialized delta can either duplicate historical data downstream or silently skip data that existed before initialization. Basic Configuration: When creating a DTP, key settings include: 1. Source and target objects (determined by where in the modeling flow you create the DTP, following the existing Transformation). 2. Extraction mode (Full vs Delta), chosen based on the object's delta capability and the business need. 3. Filter/Selection: restricting the DTP to a subset of data (e.g., only a specific fiscal year, company code, or plant), useful for controlled historical loads, testing, or splitting large loads into manageable parallel streams. 4. Update mode: Standard, or in some object types 'Delta with No Data Transfer' (used to initialize a delta pointer without moving history), and package sizing to control how many records are processed per data package. 5. Semantic Groups (mainly for DTPs into ADSOs with overwrite-type key figures or for parallel processing correctness) which ensure that records that must be processed together (e.g., all line items for one document) land in the same data package. 6. Error handling settings, which determine what happens to records that fail during transformation (covered in more depth at intermediate level). A DTP is typically executed as a step inside a Process Chain, though it can be run manually via its monitor for testing. Each execution creates a Request, visible in the DTP's request monitor, which shows number of records extracted, transferred, and any errors, and which can be used to activate or roll back data in the target.

Code example

* Example: ABAP routine used inside a Transformation feeding a DTP* (illustrative field-level routine, not DTP configuration itself)METHOD compute_fiscal_period.  " Simple example: derive fiscal period from posting date  " This runs during the transformation step executed by the DTP  DATA: lv_period TYPE /bic/oifiscper.   IF source_fields-posting_date IS NOT INITIAL.    lv_period = source_fields-posting_date+4(2). " naive month extraction    result = lv_period.  ELSE.    

Real project scenario

A retail company loads daily sales transactions from an ECC DataSource into a BW/4HANA ADSO. The initial project phase uses a Full DTP during development and unit testing because volumes are small and testers need repeatable, deterministic reloads while the transformation logic is still being adjusted. Once the transformation logic is signed off and the object moves toward production cutover, the team switches to a Delta DTP. During cutover, the Basis/BW team carefully sequences: first a Full DTP for historical data load with a fixed selection (e.g., last 2 fiscal years), then initializes the Delta DTP with 'no data transfer' so it only sets the delta pointer from that point forward, avoiding duplicate historical records. This exact sequencing decision is documented in the cutover runbook and reviewed by the reporting team before go-live.

Common mistakes

• Confusing Full and Delta DTPs and running a Delta DTP without first properly initializing it, leading to missing historical data. • Re-running a Full DTP repeatedly in production without deleting/re-triggering the target appropriately, causing duplicate records in additive-key-figure targets. • Setting overly narrow selections on a DTP without understanding downstream reporting needs, silently excluding valid data. • Assuming a DTP automatically inherits delta capability just because the source DataSource is delta-enabled, without checking that delta was actually activated in the source system extraction settings. • Not distinguishing between the PSA-to-target DTP and the source-system-to-PSA extraction, and troubleshooting the wrong layer when data is missing.

Best practices

• Always confirm the delta capability of the source object before designing a Delta DTP; do not assume it based on naming alone. • Document and follow a clear cutover sequence: full historical load, then delta initialization without data transfer, then regular delta execution. • Use filters/selections deliberately and keep them visible in technical documentation so downstream consumers understand what data is included or excluded. • Keep DTP package sizes reasonable for the target object type and volume; extremely large or small packages can cause performance or lock contention issues. • Test both Full and Delta paths in a non-production system that mirrors production data volumes before go-live.

Interview angle

Interviewers commonly ask candidates to explain the difference between Full and Delta DTPs, what happens on first execution of a Delta DTP, and why DTPs replaced the older InfoPackage/update rule model. A strong answer connects the DTP's role to the broader layered architecture (PSA vs ADSO vs reporting layer) and demonstrates awareness that delta behavior depends on both the source object's capability and the DTP's own initialization state, not just a checkbox.