Articles
SAP BW/4HANA Interview Questions: DTP Errors, Delta Loads, and Safe Recovery
Prepare for SAP BW/4HANA interview questions on DTP errors, DTIS, delta restarts, ordered recovery, target completeness, and evidence before releasing loads.
SAP BW/4HANA interview questions about failed DTPs are usually questions about data state. A process can fail after useful records have been processed, and a successful status can coexist with records awaiting correction. Before proposing a restart, explain what reached the target, what remains in error-handling persistence, and what the next delta run would read.
Recover an identified request and reconcile its data before releasing downstream work. This guide uses SAP's documented error-handling modes, an original eight-record recovery ledger, and a delta-restart counterexample.
Official documentation and our original reasoning are labeled separately. The exercises are not executed SAP captures or candidate reports of interview questions.
What does a DTP request represent?
A data transfer process, or DTP, defines movement between a source and target in BW/4HANA. A request is one runtime execution of that definition. Distinguish the reusable configuration from the particular execution whose records, messages and status you are investigating.
Official SAP behavior: the BW/4HANA Modeling User Guide describes extraction, transformation and other processing steps, with full and delta transfer modes. This article's current “latest” reference resolves to the 2023 SPS00 guide. Check the installed release and execution mode before treating a historical menu label as universally current.
Our preparation focus is BW/4HANA DTP recovery. SAP Data Services Table Comparison, legacy BW loading terminology and a HANA calculation view are different subjects. Knowing one of those does not identify where this particular DTP failed or whether target reporting is complete.
Start with the failed step and the exact request
Official monitoring surface: SAP's DTP Monitor documentation provides request headers, processing-step details, messages, and navigation to related source, transformation, target or process-chain information. Start from the request that actually failed, not only the newest process-chain summary.
Our diagnostic recommendation is to preserve the request identifier, DTP, source, target, extraction mode, selections, timestamps and failing step. Record both technical and overall status where available. Then ask whether the failure is a data defect, transformation problem, capacity issue, lock, or upstream absence; the symptom determines which evidence to collect next.
A currency-conversion failure and a request already being processed should not receive the same remedy. The first needs the offending record and its mapping dependencies. The second needs the active execution and locking context. Repeatedly launching another instance can obscure both investigations.
Trace one affected business key through the available processing data. Capture its source representation, transformation result and target state. Use authorized monitoring views and logs; an interview answer can explain this evidence chain without proposing direct edits to internal tables.
Does red mean nothing loaded, and green mean complete?
Neither conclusion follows from the color alone. Official error-handling options distinguish cancellation from updating valid records while retaining an error stack. The current options page describes both red-status and green-status update modes.
| Configured behavior, paraphrased | What the setting establishes |
|---|---|
| Cancel without record tracing | No normal error-stack repair path should be assumed |
| Cancel with record tracing | Better record-level diagnosis; this is not the valid-row update mode |
| Update valid rows and retain red status | Check the valid data before manually releasing the request as documented |
| Update valid rows and finish green | Valid rows can proceed while erroneous rows remain to be repaired |
The table summarizes configured behavior, not a universal transaction rule for every target. Inspect the request and target administration before claiming that any individual record is visible in a query.
Original inference: a chain that advances successfully can still produce an incomplete business result. Conversely, a red request can require reconciliation of already processed valid records. A strong answer separates execution success, accepted-record completeness and downstream reporting readiness.
What is DTIS, and what does an error DTP read?
Official persistence distinction: SAP's error-record handling documentation uses data transfer intermediate storage, DTIS, as the error-handling persistence layer. The cited topic is version 2021; the current 2023 guide retains this distinction. When the relevant error handling is active, records can be inspected and corrected there.
An error DTP transfers records from this persistence to the original target. Its use of full update mode does not mean it performs a new full extraction from the business source. SAP describes this recovery path in the Modeling User Guide's error-DTP section.
That distinction matters when someone says, “The error DTP finished, so the missing source data is recovered.” It can repair persisted affected records. It cannot prove that records never extracted from the source were discovered, or that every later delta is complete.
The source delta run, error-stack repair and downstream target activation or visibility are separate checks. Draw their boundaries before recommending a reset. If no appropriate error persistence exists, an instruction to “edit the error stack” is not an actionable recovery plan.
Why can a valid record wait behind an invalid one?
Official ordering behavior: SAP's record-handling settings explain that an error-handling key defined through extraction grouping can preserve sequence. Subsequent records with the same key can be held with an incorrect record instead of updating the target. The ordering concern is particularly relevant to overwrite targets; do not generalize one target's behavior to every model.
Our original fixture chooses an overwrite target containing the latest account balance. Grouping uses the account key, and records arrive in the listed order. A row is invalid if its region is unmapped or its amount cannot be converted. Assume enabled error handling and that the configured error allowance is not exceeded.
| Input in order | Balance / region | Fixture outcome |
|---|---|---|
| A, sequence 1 | 100 / west | Accepted |
| B, sequence 1 | 60 / unknown | Invalid; held |
| A, sequence 2 | 120 / west | Accepted |
| B, sequence 2 | 75 / east | Valid, held behind B1 |
| C, sequence 1 | 40 / east | Accepted |
| D, sequence 1 | bad / west | Invalid; held |
| D, sequence 2 | 30 / west | Valid, held behind D1 |
| C, sequence 2 | 50 / east | Accepted |
The ledger has eight input records, four accepted and four held. Only two held records are defective. Treating every held record as a bad record loses the ordering reason for B2 and D2.
Before repair, the fixture's current target balances are A=120 and C=50, totaling 170. The total is a sum of current account balances, not a sum of every source row. This reporting grain is part of the contract.
Repair the affected sequence and prove the result
In the fixture, correct B1's region to east and D1's amount to 20 using an approved correction. Preserve both subsequent same-key records. Applying the corrected sequence yields B=75 and D=30; combined with A and C, the current-balance total becomes 275.
Our local Python check models the chosen partition and overwrite rules. It verifies the four/four split, two actual defects, before/after balances, and the stable result of reapplying the same repaired overwrite sequence. This does not certify SAP's runtime, activation behavior or exactly-once delivery.
Recommended recovery evidence: link the original request, correction and error-DTP request. Compare expected business keys, final values and unresolved error records. Also inspect the target's relevant activation and reporting state rather than stopping at a successful transport message.
Document what changed and why. An unexplained replacement of an invalid region can make a load run while corrupting classification. Where a source defect will recur, correct its upstream cause as well as managing the present request; otherwise the next load recreates the exception.
The error allowance also matters. The settings page describes termination when the configured invalid-record limit is exceeded. A configuration field left blank has documented consequences; do not assume it means an unlimited tolerance. Confirm the actual setting instead of changing it merely to achieve green status.
A delta restart can read more than the failed run
Official restart warning: SAP's general DTP properties describe automatic repetition of canceled requests in process chains and warn that delta repair can include data added to the source after the failed request. The cited version 2021 behavior is also present in the 2023 guide. It is not always a replay of an identical frozen batch.
Our original counterexample begins with eight source records for day 1. A transformation assumes that one request contains exactly one business date. The request fails, and three records for day 2 arrive before the retry. If the chosen delta selection combines all available new data, the replacement request now contains 11 records across two dates.
The source is not necessarily duplicating anything; the transformation's one-day assumption has become false. Checking only whether its code changed would miss the cause. Compare input requests, selection boundaries and business dates as well as the transformation version.
A defensible answer identifies the condition first: whether the DTP bundles source requests, uses request-by-request extraction, or has other relevant selections. These options change the replay boundary. They are not a license to blindly change extraction mode in production.
Before proceeding, decide whether the transformation can safely handle the widened input or whether an approved recovery must preserve the intended boundary. Retain evidence of source availability and target results. A reset that discards the earlier problem without a completeness check can conceal missing history.
What would make the recovery safe to release?
Our release criteria are specific to the data contract: the expected source boundary is accounted for, corrected records retain their order, business-key and value checks pass, unresolved errors are explained, and the target is in the required state for downstream use. Include the next scheduled delta in the handoff, rather than treating the current repair as the end of the pipeline.
Choose checks that can reveal a false success. In our overwrite example, input row count is not target row count because repeated keys replace earlier balances. A total alone can also hide two offsetting mistakes. Check key-level values and the intended reporting grain, then use totals as a separate control.
When the evidence contradicts the expected recovery, stop downstream release and investigate the discrepancy. Preserve identifiers and observations so the next person can reproduce the diagnostic path. A useful interview answer explains why its proposed action is justified by this state, rather than reciting a restart command.
Sources and Further Reading
- SAP: Current options for DTP error handling
- SAP: Handling data records with errors, version 2021
- SAP: Specifying how data records are handled
- SAP: General DTP properties and restart warning, version 2021
- SAP: Monitoring a data transfer process
- SAP BW/4HANA 2023 SPS00 Modeling User Guide
Research checked October 4, 2026. Verify installed release, execution mode, source and target settings. The recovery ledger and Python checks are original conceptual exercises, not a live SAP run or reported interview.