Configuring Open Hub Destinations and DTP-Based Extraction

Explanation

Moving from concept to configuration, building a working Open Hub extraction involves several interdependent decisions: source InfoProvider selection, destination type, field mapping, delta configuration, and process chain placement. Step one is selecting the source InfoProvider. In practice this should almost always be a reporting-layer object (an ADSO in BW/4HANA reporting layer, or a classic InfoCube/standard DSO in older BW) rather than a raw acquisition-layer object, because the acquisition layer typically holds unharmonized, pre-transformation data. Choosing the wrong layer is one of the most common design mistakes and creates data quality disputes with downstream consumers later. Step two is destination type selection. The 'File' type writes to an application server directory (or client workstation, though this is rare in production) in a specified format (CSV-like with configurable delimiters) — useful when the consuming system has simple file-drop ingestion. The 'Database Table' type causes BW to generate (or you to assign an existing) transparent table that mirrors the OHD's field structure; this is the most common choice for programmatic consumption because it supports SQL-based reads and typically performs better for large volumes. The 'Third-Party Tool / Open Hub Service (BAdI-based/API)' type is used when an external ETL tool or custom program calls the Open Hub read APIs directly, receiving data request-by-request with delta pointers managed by BW — this is common when integrating with enterprise ETL orchestration platforms. Field mapping in the OHD definition determines exactly which fields (characteristics and key figures from the source InfoProvider) are exposed, and allows renaming to match a target schema contract expected by the consumer. Because this creates a persistent interface contract, changes to the source InfoProvider's structure (adding/removing fields) require corresponding review of the OHD mapping — this is a common break point after model changes. Delta handling is configured primarily at the DTP level, similar to standard BW DTPs: full extraction re-sends the entire content of the source InfoProvider on every run (appropriate for small dimension-like data or full refresh contracts), while delta extraction sends only new or changed records since the last successful request, relying on the source InfoProvider's delta capability (request-based delta for ADSOs/DSOs, or change log-based mechanisms depending on object type). It's important to verify that the source object actually supports delta before assuming an OHD DTP can run in delta mode — not all InfoProvider types or all loading patterns guarantee clean delta behavior for Open Hub consumption, particularly if the source itself has been reloaded or corrected outside of normal delta chains (a 'delta reinitialization' concern that mirrors standard BW delta issues). Once the OHD and DTP are configured, the DTP is placed into a process chain, typically scheduled after the load chain that populates and activates the source InfoProvider, ensuring OHD extraction only occurs against fully processed, activated data. Monitoring uses the same request monitor techniques as standard DTP monitoring: checking request status, record counts, and error logs. For third-party/API-based OHDs, the consuming application also needs visibility into request status (often via the Open Hub Service API's own status calls) to know which requests are safe to consume versus still in process or containing errors. A key production consideration is idempotency and request tracking on the consumer side: since each DTP run creates a discrete request, well-designed downstream consumers track which request IDs they have already processed to avoid duplicate ingestion, especially in database table destinations where multiple requests may accumulate in the same physical table alongside a request ID column.

Code example

-- Example: querying an Open Hub destination database table-- (illustrative field names; actual generated table and field-- names depend on the OHD definition in your system) SELECT    REQUEST_ID,      -- identifies the DTP request that wrote this row    REQUEST_TIME,    -- timestamp of extraction    GL_ACCOUNT,    COMPANY_CODE,    FISCAL_PERIOD,    AMOUNT_LCFROM    ZOHD_GL_BALANCES   -- generated/assigned table for the OHDWHERE    REQUEST_ID > :last_processed_request_idORDER BY    REQUEST_ID; -- Consumer-side logic (pseudocode):-- 1. Track last_processed_request_id in the consuming application.-- 2. Pull only rows with a newer request id (delta-aware read).-- 3. After successful load, persist the new max request id--    so the next run does not reprocess the same request.

Real project scenario

A manufacturing company needed to feed a legacy MES-adjacent reporting tool with daily production variance data. The BW team modeled an Open Hub Destination on a reporting ADSO, chose the database table destination type for easier SQL-based polling, mapped only the eight fields the MES tool's ingestion job actually needed (hiding internal technical fields), and configured the DTP for delta extraction after confirming the source ADSO's load pattern supported clean deltas. The DTP was added to the existing nightly process chain immediately after the ADSO activation step, with a chain-level check to ensure the OHD DTP only ran if the upstream load succeeded, avoiding extraction of partially loaded data.

Common mistakes

• Configuring delta extraction on an OHD DTP without first verifying the source InfoProvider genuinely supports reliable delta for that object type and load pattern. • Exposing all technical/internal fields in the OHD mapping instead of curating a minimal, stable contract for the consumer. • Placing the OHD DTP in the process chain before the source InfoProvider's activation step completes, risking extraction of incomplete data. • Forgetting that changing field names or removing fields from the source InfoProvider silently breaks the OHD mapping or the consumer's expectations. • Allowing database table destinations to grow unbounded without an archiving or housekeeping strategy for old requests.

Best practices

• Curate the OHD field mapping deliberately as a stable external contract, not a raw mirror of the source InfoProvider. • Sequence OHD DTPs strictly after upstream activation/load steps in the process chain. • Confirm delta support and behavior on the source object before enabling delta mode on the OHD DTP. • Communicate request-ID-based consumption patterns to downstream teams to prevent duplicate processing. • Establish a housekeeping or archiving policy for database table destinations to control long-term growth.

Interview angle

Expect questions distinguishing full versus delta DTP extraction for Open Hub, how request IDs support consumer-side idempotency, and how process chain sequencing prevents extraction of incomplete data. A strong answer connects OHD delta behavior back to general BW delta concepts (request-based deltas) rather than treating Open Hub as a completely separate mechanism.