Advanced Open Hub: Architecture, Integration and Production Design (Part 4)

At senior and architect level, Open Hub should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
Open Hub Fundamentals: Purpose and Core Concepts: Understand why Open Hub Destinations exist in SAP BW, what business and technical problems they solve, and the basic building blocks involved in distributing data outside the BW system.

Configuring Open Hub Destinations and DTP-Based Extraction: Learn the practical steps and design decisions for configuring an Open Hub Destination, defining field mappings, choosing delta settings, and wiring the extraction DTP into a process chain.

Managing Delta Loads and Change Data Capture in Open Hub Destinations: Learn how Open Hub Destinations track delta changes, how DTP delta modes interact with OHD request status, and how to design robust incremental extraction for downstream consumers without duplicate or missing records.

Architecture and production criteria

• Always extract from a governed, reconciled reporting-layer InfoProvider rather than raw acquisition layer objects.
• Always gate downstream consumption on OHD request status (only process complete/green requests)
• Communicate request-ID-based consumption patterns to downstream teams to prevent duplicate processing.
• Confirm delta support and behavior on the source object before enabling delta mode on the OHD DTP.
• Confirm with the downstream team whether they need full history, delta only, or periodic full refresh before configuring the DTP.
• Curate the OHD field mapping deliberately as a stable external contract, not a raw mirror of the source InfoProvider.
• Document and rehearse the delta reinitialization procedure, including downstream reconciliation steps
• Document the contract (field list, data types, delta semantics) shared with the consuming team since Open Hub crosses a system boundary.
• Establish a housekeeping or archiving policy for database table destinations to control long-term growth.
• For custom third-party destination classes, explicitly implement and test request status handling rather than assuming full-package delivery
• Implement target-side upsert or deduplication logic keyed on business key plus request identifier as a safety net
• Keep each downstream consumer on its own dedicated DTP rather than sharing one DTP output across multiple unrelated targets
• Monitor delta record counts over time to catch silently stalled or abnormally large delta extractions
• Sequence OHD DTPs strictly after upstream activation/load steps in the process chain.
• Treat Open Hub Destinations as production interfaces with the same change control rigor as external interfaces, not as ad hoc exports.
• Use database table destinations for high-volume, tool-based consumption and file destinations for smaller, more universally consumable extracts.

Failure analysis and operational risk

• Allowing database table destinations to grow unbounded without an archiving or housekeeping strategy for old requests.
• Allowing downstream jobs to consume Open Hub table data before the request status is confirmed green/complete
• Assuming all OHDs and DTPs on the same InfoProvider share one delta pointer, when each DTP tracks its own independently
• Assuming an OHD definition alone moves data — forgetting that a DTP must actually be executed to populate the destination.
• Building custom third-party OHD classes without properly checking request completion status, leading to processing of partial data packages
• Configuring delta extraction on an OHD DTP without first verifying the source InfoProvider genuinely supports reliable delta for that object type and load pattern.
• Deleting and rerunning a failed delta DTP request without checking whether downstream systems already partially consumed the data
• Exposing all technical/internal fields in the OHD mapping instead of curating a minimal, stable contract for the consumer.
• Forgetting that changing field names or removing fields from the source InfoProvider silently breaks the OHD mapping or the consumer's expectations.
• Not considering target system capacity when choosing file vs. database table destination type, leading to file size or table growth issues over time.
• Not implementing idempotent (upsert-based) logic on the downstream target as a safety net against reprocessed delta requests
• Placing the OHD DTP in the process chain before the source InfoProvider's activation step completes, risking extraction of incomplete data.
• Pointing an OHD at a source InfoProvider that does not yet have finalized, reconciled data, resulting in downstream systems consuming semi-validated numbers.
• Reinitializing delta after a source reload without coordinating a corresponding reload or reconciliation on the downstream target
• Treating Open Hub as a real-time integration mechanism when the business actually needs live query access.
• Using full extraction mode for large InfoProviders on every run instead of configuring delta, causing unnecessary load and long runtimes.

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A retail company's finance team built their consolidated reporting in BW/4HANA but needed daily extracts of reconciled GL balances pushed into a corporate data lake used by a separate analytics team running Python-based forecasting models. Rather than granting the data lake team direct database access to BW/4HANA tables (a security and stability risk), the BW team modeled an Open Hub Destination on top of a reporting-layer ADSO, targeting a database table type OHD, scheduled via a process chain that ran after the nightly load chain completed. The data lake ingestion job then picked up new requests from the OHD table on a schedule, using request status fields to avoid reprocessing.

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.

A retail analytics team used an Open Hub Destination on a sales InfoCube to feed a downstream cloud data lake nightly via a database table destination and a custom pickup job. After a process chain failure mid-load, the support team deleted the failed request and reran the DTP without checking whether the pickup job had already partially read the table. This caused a partial duplicate day of sales data in the data lake. The fix involved adding a request-status check to the pickup job (only reading requests with green status), introducing a target-side upsert key on order line plus request timestamp, and documenting a runbook step requiring reconciliation of record counts before manually rerunning any failed delta request.

• Allowing database table destinations to grow unbounded without an archiving or housekeeping strategy for old requests.
• Allowing downstream jobs to consume Open Hub table data before the request status is confirmed green/complete
• Assuming all OHDs and DTPs on the same InfoProvider share one delta pointer, when each DTP tracks its own independently
• Assuming an OHD definition alone moves data — forgetting that a DTP must actually be executed to populate the destination.
• Building custom third-party OHD classes without properly checking request completion status, leading to processing of partial data packages
• Configuring delta extraction on an OHD DTP without first verifying the source InfoProvider genuinely supports reliable delta for that object type and load pattern.
• Deleting and rerunning a failed delta DTP request without checking whether downstream systems already partially consumed the data
• Exposing all technical/internal fields in the OHD mapping instead of curating a minimal, stable contract for the consumer.
• Forgetting that changing field names or removing fields from the source InfoProvider silently breaks the OHD mapping or the consumer's expectations.
• Not considering target system capacity when choosing file vs. database table destination type, leading to file size or table growth issues over time.
• Not implementing idempotent (upsert-based) logic on the downstream target as a safety net against reprocessed delta requests
• Placing the OHD DTP in the process chain before the source InfoProvider's activation step completes, risking extraction of incomplete data.
• Pointing an OHD at a source InfoProvider that does not yet have finalized, reconciled data, resulting in downstream systems consuming semi-validated numbers.
• Reinitializing delta after a source reload without coordinating a corresponding reload or reconciliation on the downstream target
• Treating Open Hub as a real-time integration mechanism when the business actually needs live query access.
• Using full extraction mode for large InfoProviders on every run instead of configuring delta, causing unnecessary load and long runtimes.

• Always extract from a governed, reconciled reporting-layer InfoProvider rather than raw acquisition layer objects.
• Always gate downstream consumption on OHD request status (only process complete/green requests)
• Communicate request-ID-based consumption patterns to downstream teams to prevent duplicate processing.
• Confirm delta support and behavior on the source object before enabling delta mode on the OHD DTP.
• Confirm with the downstream team whether they need full history, delta only, or periodic full refresh before configuring the DTP.
• Curate the OHD field mapping deliberately as a stable external contract, not a raw mirror of the source InfoProvider.
• Document and rehearse the delta reinitialization procedure, including downstream reconciliation steps
• Document the contract (field list, data types, delta semantics) shared with the consuming team since Open Hub crosses a system boundary.
• Establish a housekeeping or archiving policy for database table destinations to control long-term growth.
• For custom third-party destination classes, explicitly implement and test request status handling rather than assuming full-package delivery
• Implement target-side upsert or deduplication logic keyed on business key plus request identifier as a safety net
• Keep each downstream consumer on its own dedicated DTP rather than sharing one DTP output across multiple unrelated targets
• Monitor delta record counts over time to catch silently stalled or abnormally large delta extractions
• Sequence OHD DTPs strictly after upstream activation/load steps in the process chain.
• Treat Open Hub Destinations as production interfaces with the same change control rigor as external interfaces, not as ad hoc exports.
• Use database table destinations for high-volume, tool-based consumption and file destinations for smaller, more universally consumable extracts.

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers often probe whether a candidate understands that OHD is a metadata object requiring a DTP to execute, and whether they can articulate when to use Open Hub versus alternative extraction methods (direct table read, CDS views, query-based extraction, SDA). Be ready to explain the three destination types (file, database table, third-party/API) and give a business reason for choosing one over another, plus how delta works conceptually at a high level.

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.

Interviewers assess whether you understand that Open Hub delta tracking is per-DTP, not global, and that downstream consumers must respect request status semantics rather than blindly polling target tables. Be ready to explain the difference between delta initialization and delta extraction, why request status checks matter for data integrity, and how you would design idempotent downstream consumption to tolerate DTP reruns safely.