ROOSGEN table — Generic DataSource Generation Metadata
ROOSGEN is a source-system table that records how a generic DataSource, created via transaction RSO2, was generated: which table, view, function module or InfoSet feeds it, and what generic delta settings, if any, were attached. It lives on the OLTP/source-system side, not in BW's own InfoProvider tables, and is read when the extraction program is (re)generated or checked.
This page covers ROOSGEN, the source-system table holding generation metadata for generic DataSources built through RSO2, including which underlying object supplies the data and what generic delta configuration is recorded. It focuses on how to trace extraction failures back to this table and the mistakes consultants make when they assume the row guarantees the extractor still works.
Published 15 Sept 2026· 1,022 words
What it stores
One row in ROOSGEN represents the generation record for a single generic DataSource, identified by its DataSource name and the logical system of the client that owns it, as it was last created or regenerated through RSO2 on the source-system side. The row records which underlying object was picked as the extraction source at the time of generation - a database table, a view, a function module, or an InfoSet - and, when generic delta was configured for that DataSource, the delta-relevant settings attached to it, such as which field drives the delta and what delta logic applies. ROOSGEN sits in the source system, not in the BW system's own metadata layer, and it is written the moment a developer saves and generates a generic DataSource, then read again whenever that extraction program is regenerated or interrogated by the extractor checker.
Key fields
- OLTPSOURCE - name of the generic DataSource the generation record belongs to
- LOGSYS - logical system of the source client that owns the DataSource
- a field recording the category of extraction source chosen at generation time (table, view, function module, or InfoSet)
- a field holding the name of that source table, view, function module or InfoSet
- fields indicating whether generic delta is active for the DataSource and, if so, which source field and delta logic drive it
- generation timestamp and user fields recording who last generated the extract structure and when
How it joins the data model
- ROOSGEN-OLTPSOURCE = ROOSOURCE-OLTPSOURCE (matching LOGSYS) to pull the DataSource's descriptive header, extraction mode and application component
- ROOSGEN-OLTPSOURCE = ROOSFIELD-OLTPSOURCE (matching LOGSYS) to expand the actual field list the generated extract structure exposes
- the delta field named in ROOSGEN is cross-checked against the field catalogue in ROOSFIELD to confirm it is genuinely part of the extract structure
- OLTPSOURCE/LOGSYS also anchors the BW-side source system assignment that a transformation later maps to a target DSO or InfoCube for load monitoring
How to read it safely
ROOSGEN is client-dependent like most extraction metadata, so restrict on the client alongside OLTPSOURCE and LOGSYS before browsing. The table is usually small - one row per generic DataSource defined in that source client - so a full display is rarely dangerous, but a source system with many custom extractors built over the years can still return an unhelpfully long list if OLTPSOURCE is left open. Always filter to the exact DataSource name under investigation rather than pattern-matching on prefixes, since naming conventions for generic extractors are inconsistent across projects.
How to prove it in the data
Symptom: delta extraction for a generic DataSource is pulling duplicate or missing records after a source-system change. Select ROOSGEN for the exact OLTPSOURCE and LOGSYS, read off the recorded delta field and delta logic, then check that field against the underlying table or view in the ABAP dictionary to confirm it still exists, is still populated on every insert or change, and still increases monotonically for every business process that should trigger delta capture.
ECC vs S/4HANA
ROOSGEN belongs to the classic generic extraction mechanism, and RSO2 remains available on S/4HANA source systems for backward compatibility, so the table continues to exist and behave the same way it did on ECC. SAP's strategic direction for new extraction is ODP-based and CDS-driven rather than RSO2-based generic extractors, but that is a recommendation for new development, not a removal of ROOSGEN or its generation mechanism. No compatibility CDS view replaces it, since it is technical source-system metadata rather than a business table affected by the Universal Journal migration.
Common pitfalls
- Treating a ROOSGEN entry as proof the extractor still works: the underlying table, view or function module can be changed, renamed or dropped after generation, and ROOSGEN is not automatically re-validated against that object.
- Assuming the delta field recorded here is reliably populated on every source record: ROOSGEN only states what was configured at generation time, not whether that field behaves correctly across every posting path, including mass changes, direct table updates, or interface loads that bypass normal transactions.
- Looking for ROOSGEN in the BW system and concluding a DataSource is broken because no row is found: ROOSGEN exists only on the source system, it is never replicated to BW, so its absence there is expected, not a symptom.
- Editing ROOSGEN directly through a table maintenance transaction instead of regenerating through RSO2: manual edits desynchronize the stored metadata from the actual generated ABAP extraction program, and extraction then fails at runtime with a structure mismatch that has nothing to do with the data itself.
- Assuming a DataSource has no delta capability because the generic delta fields in ROOSGEN are blank: some custom generic extractors implement delta logic entirely inside a custom function module and never populate the standard generic-delta fields that ROOSGEN captures for the built-in cases.
Whose problem this is
Interpretation belongs to whoever created and maintains the generic DataSource in the source system, typically a BW extraction developer or an ABAP developer working with RSO2, not the BW modeling or reporting team. When a target InfoProvider shows missing or duplicated records, the question of what ROOSGEN records for that DataSource should be routed to the source-system extractor owner before anyone touches the BW-side transformation or data transfer process.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/roosgenERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.