DTP Design in Practice: Filters, Error Handling, Delta Mechanics, and Troubleshooting

Explanation

Once a BW consultant understands the basic purpose of a DTP, the next stage is designing DTPs that behave correctly and predictably under real production conditions: partial failures, parallel processing, large volumes, and delta consistency over time. Filters and Selections: A DTP filter restricts which records are extracted from the source, similar to a selection screen. Filters can be static (hardcoded values or ranges) or use variables (e.g., a variable resolved at runtime from a process chain variant, such as 'last month' or a value passed from a preceding process type). Filters are commonly used to split a very large historical load into multiple parallel DTP executions (e.g., one DTP per fiscal year or per plant) to reduce runtime and memory pressure on a single request. When splitting loads this way, it is essential that filters are mutually exclusive and collectively exhaustive; overlapping filters cause duplicate records, and gaps cause silent data loss that may not be noticed until a reconciliation report fails. Semantic Groups: For targets where records must be aggregated or where parallel data package processing could produce wrong results if related records land in different packages (for example, overwrite-type key figures in an ADSO, or routines that aggregate within a package), the Semantic Group setting on the DTP ensures that all records sharing certain key values (e.g., document number) are routed to the same data package. Omitting a needed semantic group is a subtle bug: the load succeeds without error, but produces incorrect aggregated results because related records were split across packages processed independently. Error Handling: DTPs support configurable error handling behavior, generally offering options such as: stop the whole load on any error, or write only the erroneous records to an error stack while good records continue to the target. When error stack handling is enabled, failed records can later be corrected and reprocessed via an error DTP without needing to reload the entire source selection. This is critical in production because a single bad record (e.g., a master data value that fails a validation routine) should not block an entire day's transactional load. However, teams must actively monitor and process the error stack; an error stack that silently accumulates unresolved records is effectively invisible missing data from a reporting perspective, since those records never reached the target. Delta Queue Mechanics: For DataSource-based deltas, the source system typically maintains a delta queue (for ECC/S4 extraction) which the DTP's extraction step reads from during each delta run, then confirms/marks as processed once the BW request is successfully committed. If a delta DTP request fails or is deleted before confirmation, the data generally remains in the queue for the next run, but if a request is confirmed and later deleted from the BW side without properly resetting the delta, the data can be effectively lost from BW without being lost at the source — requiring a full delta re-initialization to recover, which is disruptive and must be carefully planned with the reporting team. For BW-internal object-to-object deltas (e.g., ADSO to ADSO), the mechanism differs: the source ADSO's change log or delta-relevant table tracks changes, and the DTP reads from there; there is no source-system delta queue involved, so recovery procedures for load errors differ from source-DataSource-based deltas. Troubleshooting: Common diagnostic steps include checking the DTP request monitor for the exact error message and layer (extraction vs transformation vs activation), checking whether the request is a Full or Delta type when explaining why volumes look wrong, verifying the delta queue status at the source system side for missing records, and checking whether a semantic group or missing filter caused unexpected aggregation. In S/4HANA environments, especially with embedded analytics or CDS-based extraction, some traditional delta queue behaviors map to different underlying mechanisms, so consultants should verify actual behavior in that specific landscape rather than assuming classic ECC delta queue semantics apply identically.

Code example

* Example: DTP filter variable usage pattern (conceptual, not literal syntax)* A process chain variant passes a calendar month variable into the DTP filter* so each month's data load can be triggered and monitored independently. * Pseudocode representation of filter logic applied by the DTP at runtime:IF fiscal_period BETWEEN selection-low AND selection-high.  " record is extracted and passed to transformationELSE.  " record is skipped by the DTP filter, never reaches transformationENDIF. * Semantic group conceptual grouping (records with same document number* are guaranteed to be in the same data package for correct aggregation) 

Real project scenario

A finance reporting team notices that a monthly aggregated key figure in an ADSO occasionally shows incorrect totals only on days with very high transaction volume. Investigation reveals the DTP feeding that ADSO did not have a Semantic Group defined on the document key, so under high volume the DTP split related line items across multiple parallel data packages, and an aggregating routine in the transformation only aggregated within each package rather than across the full document. The fix requires adding the semantic group, reprocessing the affected historical requests, and adding a reconciliation check to the process chain to catch similar issues earlier.

Common mistakes

• Defining overlapping or gapped filters when splitting a large load into parallel DTPs, causing duplicates or silent data loss. • Enabling error stack handling but never assigning ownership to monitor and reprocess the error stack, leading to invisible missing data. • Omitting semantic groups where package-level aggregation logic depends on related records staying together. • Deleting a confirmed delta request from BW without following the proper delta reset procedure, causing unrecoverable gaps without a full re-initialization. • Assuming ECC-style delta queue behavior applies identically to CDS-based or S/4HANA embedded extraction scenarios without verifying it for that landscape.

Best practices

• Design filters to be mutually exclusive and collectively exhaustive when parallelizing loads, and validate coverage with a record-count reconciliation. • Enable error stack handling for production transactional loads, but pair it with an owned monitoring process and defined SLA for reprocessing. • Apply semantic groups whenever package-dependent aggregation or overwrite logic exists in the transformation. • Before deleting or resetting any delta-related request, confirm current delta queue status and involve the source system team to avoid unrecoverable gaps. • Explicitly verify delta behavior in S/4HANA or CDS-based extraction scenarios rather than assuming classic ECC delta queue semantics.

Interview angle

At the intermediate level, interviewers probe whether a candidate understands why a load can succeed technically yet produce wrong business numbers — this usually points to filter design or semantic group gaps. Candidates should be able to explain the practical difference between stopping a load on error versus using an error stack, and describe a realistic recovery procedure when a delta DTP is broken, including the operational impact of re-initialization.