On this page
SAP BW
Understand the SAP BW extraction package, coordinate catalog and object-detail collection, and reconcile the source scope with the analysis.
modernAIze supports SAP BW as a data estate source platform. Prepare its material by extracting the metadata and source artifacts for the agreed scope, then supply the reviewed package to a modernAIze project. The extraction describes the warehouse’s structures and processing so the assessment can investigate how its outputs are produced.
Run the extraction agent
Follow the SAP BW extraction agent guide to install the supplied distribution, arrange SAP connectivity and permissions, run catalog and object-detail extraction, and resolve collection errors. It includes command examples, the option reference, and package-review steps.
Input format
Supply the extracted .json metadata and object definitions, with the required
catalog, through Folder or one ZIP that preserves catalog/ and
objects/<family>/ paths. Do not flatten these directories or select individual
JSON files through Files. Follow the agent guide’s
import package instructions.
.xlsx workbooks can provide supporting context.
Upload supporting .xlsx workbooks through Files or Folder, separately
from ZIP archives. Keep native source alongside the workbook; see
upload batches.
Collection method: dedicated SAP BW extractor
SAP BW uses a dedicated extraction program, the SAP BW Metadata Audit Tool. The SAP/Basis team provides source connectivity and a read-authorized account; the team running the tool selects the scope and produces the metadata package. Use the distribution supplied for the engagement.
The collection workflow differs from copying a SAS script or exporting a DSX job: BW definitions are obtained from the SAP system into a catalog and object-detail files. Handwritten JSON or screenshots of BW objects are not substitutes for that extracted structure. You can review and assemble the output manually, but the source collection itself uses the extractor.
Native BW assets in the extraction
| Asset family | Material collected | Review focus |
|---|---|---|
| InfoObjects | Definitions and associated metadata | Characteristics, key figures, and their meaning |
| ADSOs | Provider metadata and available field definitions | Stored structures and source/target roles |
| InfoCubes | Catalog metadata | Provider inventory; do not assume object-detail extraction |
| Transformations | Rules, field context, and available ABAP routines | Mapping and business processing |
| DataSources | Source and segment catalog metadata; additional extracted detail for manual review | Input fields and source-system context; separate object-detail files are not consumed by the current analysis |
| Data Transfer Processes | Transfer definitions | How data moves between objects |
| Process chains | Chain and activity definitions | Orchestration and dependencies |
| BEx queries | Available query definitions | Reporting selections and calculations |
| Hierarchies and CompositeProviders | Available hierarchy or provider metadata | Structural and reporting context; inspect the detail actually returned |
| InfoAreas, application components, and source systems | Catalog context | Scope organization and object ownership |
This table describes the extractor’s source material. It is not a promise that every object receives the same detail in Understand. Catalog presence, extracted object detail, and analyzed coverage must be reconciled separately. In particular, flat provider metadata may not contain the complete lineage available in SAP’s native design tools.
What to collect
Begin with the business output or area being assessed. Identify the source objects and supporting logic needed to explain it. Depending on scope and access, the extractor’s material can include:
| Material | Contribution to the assessment |
|---|---|
| InfoObjects and data-provider definitions | Structure, fields, and the meaning of the represented data |
| Transformations and available ABAP routines | Processing and business logic between inputs and outputs |
| Data transfer processes and process chains | Transfer and orchestration context |
| Query definitions | Reporting selections, calculations, and outputs |
| Catalog information | The inventory used to identify objects for further extraction |
Check the contents actually obtained. The presence of an object name in the catalog does not establish that its detailed definition or source was extracted.
Coordinate with the SAP/Basis team
The team preparing the extraction needs source connectivity and an account with the metadata-read permissions required for the selected scope. Arrange these with the SAP/Basis team and use the extractor distribution supplied for the engagement.
Agree who chooses the objects, performs extraction, investigates omissions, and reviews the package before transfer. Include a BW specialist who can explain routines and reporting semantics during the analysis review.
Catalog and object detail
The extraction has two useful levels:
- The catalog inventories BW metadata and helps identify the available objects.
- Object detail adds the definitions and available source for selected objects.
A catalog-only pass is useful for scoping. A behavioral assessment also needs the relevant object detail. For example, identifying a transformation in the catalog does not explain a conversion rule implemented in its routine.
The agent guide explains the optional separate DataSource detail pass for manual review when the main extraction is scoped by InfoArea, and distinguishes it from the catalog metadata used by the current analysis.
A staged extraction can reuse a previously collected catalog to obtain more detail. Preserve the catalog and the relevant object output when assembling the handover; the final stage’s directory alone may not contain the complete package.
Review the package
Follow Review and hand over the extraction for the canonical output layout, checks, and import package. Retain the summary and log with the extraction evidence and investigate omissions before transfer.
Metadata and source code can contain business logic and infrastructure identifiers. Business-data sampling is an additional option; it is not part of the default metadata extraction. Agree explicitly whether such samples are needed and authorized for the engagement. The agent’s sampling scope is catalog-wide; detail filters do not restrict it.
Reconcile extraction and analysis
Review the workflow at three points:
- Requested scope: list the outputs, objects, and dependencies selected for assessment.
- Extracted material: confirm the catalog entries, relevant definitions and routines, and any extraction omissions.
- Represented analysis: locate the expected processing and relationships in Understand and inspect their available detail.
If a required routine was not extracted, return to the source team. If its source was supplied but the analysis remains partial, investigate the represented result and its limitations. These are different follow-up tasks.
Investigate a reporting flow
Read the Briefing for the system’s purpose and composition. Use Landscape to locate the reporting area and surrounding dependencies, then inspect the relevant assets.
In the synthetic monthly-revenue example, the important question is how the conversion and aggregation produce the output. An available transformation definition can establish the surrounding flow while an omitted routine leaves rate selection open. Ask the BW specialist to resolve that specific behavior before completing the assessment.