Full questions with full answers — no sign-in required.
easyData Acquisition, Extraction, Transformation and Process Chains
1. What is a CompositeProvider in BW/4HANA and how does it differ structurally from an InfoSet used in classic BW/ECC?
A CompositeProvider is a HANA-based virtual (or optionally persisted) union/join of multiple InfoProviders such as ADSOs, InfoObjects, and Open ODS Views, modeled graphically in BW modeling tools. Unlike InfoSets, which only supported joins and ran on the application layer, CompositeProviders push union and join operations to HANA calculation views, support both union and join in one model, and can combine data from multiple layers into a single reporting-ready object.
mediumData Acquisition, Extraction, Transformation and Process Chains
2. During an S/4HANA implementation, a client needs a new DataSource for a custom finance reporting requirement not covered by standard business content extractors. What options would you evaluate for building this DataSource?
I'd first check if a suitable CDS view with an analytical annotation exists that can be released as a DataSource via ODP, since this leverages S/4HANA's native extraction capability without custom ABAP. If no CDS view fits, I'd consider a generic DataSource based on a database view or SQL query, or extend an existing extractor using append structures and a customer exit. Custom ABAP extractors would be a last resort due to higher maintenance overhead in S/4HANA's simplified data model.
hardData Acquisition, Extraction, Transformation and Process Chains
3. A reporting query on a HANA-optimized ADSO-based CompositeProvider is running significantly slower than expected after go-live on S/4HANA. What architectural and modeling factors would you investigate first?
First check whether the CompositeProvider is unnecessarily combining multiple large ADSOs via Union when a single consolidated ADSO would suffice, review whether navigational attributes or master-data joins are pushed down efficiently, verify that the ADSO active table has appropriate SID generation and compression settings, check for excessive use of calculated/restricted key figures at query runtime versus persisted values, and confirm partitioning of the ADSO aligns with typical query filters (e.g., by fiscal period).
easyData Acquisition, Extraction, Transformation and Process Chains
4. What is the core architectural difference between classic BW on HANA and BW/4HANA that drives the need for a migration project?
BW/4HANA is a re-engineered, HANA-only version that removes legacy DB-agnostic objects (InfoCubes, classic DSOs, MultiProviders) in favor of simplified HANA-optimized objects like ADSOs and CompositeProviders. BW on HANA still supports legacy object types and non-HANA compatibility layers. BW/4HANA also drops obsolete data flow objects, forces InfoObject-based modeling consolidation, and requires OLAP cache/HANA-native processing, eliminating dual-stack overhead and simplifying the data model considerably.
mediumData Acquisition, Extraction, Transformation and Process Chains
5. Your S/4HANA source system extractor for sales orders is configured for delta loads, but after a support pack upgrade, the delta DTP suddenly pulls duplicate records already loaded previously. What would you investigate first?
I would first check whether the upgrade reset or reinitialized the delta queue, which can cause the extractor to resend already-delivered records; this is visible in RSA7 or the ODQ delta queue status showing a new initialization timestamp. I'd also verify if the DataSource's delta-relevant fields or pointer logic changed with the support pack, and check the DTP's request history for any manual reinitialization or repair full load that overlapped with delta processing.
mediumData Acquisition, Extraction, Transformation and Process Chains
6. When configuring SLT (SAP Landscape Transformation Replication Server) as a source for BW real-time data acquisition, what are the key configuration steps and monitoring transactions you need to set up on the SLT side?
Configure a replication configuration in LTRC (or LTR) defining the source system, target BW/HANA system, and tables/schema to replicate; assign trigger-based logging on source tables which SLT creates automatically. Monitor replication status, latency, and error queues in LTRC, checking table load status and any suspended/erroneous tables. On the BW side, create an ODP-based DataSource referencing the SLT connection and load via process chains. Performance tuning involves adjusting the number of jobs and data transfer parallelism.
