Configuring and Operating ODP-Based DataSources and DTPs

Explanation

Once the conceptual model of ODP is understood, the practical work centers on replicating ODP-based DataSources into BW, building transformations, and configuring Data Transfer Processes (DTPs) that correctly handle full loads, delta initialization, and ongoing delta extraction. In BW/BW4HANA, DataSources originating from an ODP-enabled source system (an S/4HANA system, an ECC system with the relevant extraction framework, or an HANA-based source) are replicated much like classic DataSources, but the system internally recognizes them as ODP objects and manages their delta queues accordingly. The first practical step is source system connection setup, ensuring the RFC connection or HANA connection to the source is correctly configured and that the source exposes the desired ODP objects. After replication, the DataSource appears with standard fields, but its extraction behavior is governed by the ODP queue on the source rather than by BW-side delta tables alone. When creating a DTP against this DataSource, the extraction mode options typically include full, delta initialization (init), and delta. Choosing 'delta init without data transfer' is a common technique when historical data has already been loaded through another mechanism and you only want to establish the delta starting point going forward. A critical operational detail is that the first delta-capable DTP execution creates the ODP subscription on the source side. From that point, the source system's ODP framework tracks which records have been confirmed as successfully processed by that specific subscriber. If a second DTP is created against the same DataSource for a different target, it establishes its own independent subscription, meaning both subscribers can consume the same underlying change stream without interfering with each other, since each maintains its own read pointer. Monitoring ODP-based loads involves checking DTP request status in BW, which reflects standard request monitor information (records extracted, transformed, activated), but when troubleshooting missing or duplicate records, consultants need to look at ODP-specific tools that show queue status, subscription health, and confirmed read pointers on the source system. Common issues include a 'stuck' or unconfirmed queue read because the DTP failed after extraction but before confirmation, requiring careful analysis before deciding whether to repeat the delta or roll back. Another key consideration is data volume and queue growth: if delta DTPs are not run frequently enough, the ODP queue can grow large, impacting both source system resource usage and extraction runtime when it is finally processed. Similarly, if a DataSource is used by multiple ODP subscribers with very different extraction frequencies, monitoring should account for each subscriber's queue backlog independently. For S/4HANA sources, many DataSources are delivered as CDS-view-based extractors exposed through ODP with context HANA rather than classic SAPI-wrapped extractors; this affects available fields, extraction performance characteristics, and sometimes which enhancement techniques are supported. Consultants must verify, per DataSource, whether classic extractor enhancement techniques still apply or whether CDS-view-level extensions are required instead, since these two approaches are not interchangeable.

Code example

* Example: Conceptual sequence for configuring an ODP-based delta extraction* (Illustrative step-by-step description, not literal ABAP code) 1. Replicate DataSource from ODP-enabled source system   - Verify source system connection is active   - Confirm DataSource shows ODP context (e.g., SAPI or HANA) in its properties 2. Build or reuse Transformation   - Map source fields to target ADSO/InfoObject fields   - Apply routines only where necessary to avoid unnecessary processing overhead 3. Create DTP - Initial Load   - Extraction mode: Full or Delta Init   - Execute and verify request in BW request monitor (green status)   - Confirm ODP subscription created on source system side 4. Create/Schedule DTP - Delta   - Extraction mode: Delta   - Schedule via process chain on defined frequency (e.g., hourly)   - Monitor queue backlog to ensure delta frequency matches data volume 5. Troubleshooting a failed delta DTP   - Check DTP request status and error logs in BW   - Check ODP queue/subscription status on source system   - Decide: repeat delta (safe if queue not yet confirmed) vs manual intervention   - Avoid deleting/recreating DTP unless reinitialization is acceptable

Real project scenario

During a go-live cutover for a new BW/4HANA system extracting financial line items from S/4HANA via an ODP-based DataSource, the delta DTP fails midway due to a short network interruption between BW and the source system. The consultant must determine whether the ODP queue on the source already confirmed the read (meaning a repeat delta would skip records) or whether the failure occurred before confirmation (meaning a simple repeat delta is safe). This requires coordinated checking of the BW request monitor and the source system's ODP queue status before deciding on remediation, avoiding both data loss and duplicate loading.

Common mistakes

• Recreating a delta DTP after a failure without checking whether the ODP subscription was already confirmed, risking data loss or duplicates. • Assuming CDS-view-based ODP DataSources support the same enhancement techniques as classic SAPI extractors. • Running delta DTPs too infrequently, allowing the ODP queue to grow and cause long-running extraction jobs. • Not accounting for multiple independent subscriptions when the same DataSource feeds more than one target, leading to confusion when monitoring queue backlogs. • Using 'delta init without data transfer' incorrectly, causing historical data gaps when the assumption about prior loading is wrong.

Best practices

• Always verify ODP subscription/queue confirmation status before deciding to repeat a failed delta DTP. • Schedule delta DTPs at a frequency appropriate to source data volume to prevent queue backlog growth. • Document per-DataSource whether it is CDS-view-based (HANA context) or classic extractor-based (SAPI context) to guide correct enhancement approach. • Avoid unnecessary DTP deletion/recreation; treat it as a delta-resetting action requiring sign-off. • Include ODP queue and subscription health checks in standard production support monitoring routines, not just BW request monitor checks.

Interview angle

Interviewers often probe candidates on the operational difference between full, delta init, and delta DTP modes for ODP DataSources, and how to safely recover from a failed delta load without causing duplicates or data loss. Strong candidates explain the subscription/confirmation model and demonstrate awareness that recreating a DTP is not a routine recovery action.