ROOSFIELD table — DataSource extract structure field metadata

One row in ROOSFIELD describes one field belonging to the extract structure of a specific DataSource, as that structure was replicated from the source system (or generated for the DataSource) into the BW metadata repository. It does not hold any extracted business values. It holds the technical shape of the interface: which fields exist, in what order, which ones form the key of the extract structure, and which extraction-relevant flags apply to each field, such as whether the field can be used for selective extraction or is treated as a hierarchy field. Consultants query it when a field they expect to see in the extraction is missing, appears in the wrong position, or behaves unexpectedly during selection, and they need to confirm what the DataSource definition itself says versus what the transformation or InfoProvider expects.

ROOSFIELD is metadata, not a transactional table, so selectivity by client and DataSource is what matters, not date ranges or volume filters. Always restrict by OLTPSOURCE first; scanning the table without it returns rows for every DataSource in the system, which is meaningless in isolation. If the system has multiple source system connections for the same logical DataSource, remember the extract structure metadata is generally per DataSource definition, not per source system connection, so do not assume different rows exist for different source system IDs unless the DataSource itself is source-system-dependent. Cross-check field position and key flag together, not in isolation, since a field can be present and correctly positioned but still excluded from selection.

Symptom: a field that exists in the source extract structure is not offered as a selection option when scheduling extraction. Selection: read ROOSFIELD for the exact OLTPSOURCE value, locate the row for that FIELDNM, and check the selection-relevant indicator alongside KEYFL. If the field is present with the correct position but the selection indicator is off, the DataSource definition itself excludes it from selective extraction, and the fix belongs in DataSource maintenance, not in the transformation or the process chain.

ROOSFIELD continues to exist in current BW-on-HANA and embedded BW environments alongside classic extractor-based DataSources; the table shape has not been replaced by a CDS compatibility view in the way some application tables have been. Where DataSources are built on ODP or CDS-based extraction rather than classic function-module extractors, the extract structure and its field metadata are still generated and reflected into this table when the DataSource is activated, so the table remains a valid diagnostic source across both extraction styles. No version-specific structural rewrite is confirmed here, so treat any release-specific behaviour claims with caution and verify against the system in hand.

The extraction or data engineering consultant who owns the DataSource is the first point of contact for anything found in ROOSFIELD. Field meaning and business relevance sit with the functional module team that owns the source application area. Basis or system administration gets involved only when the issue is replication failure between source and BW system, not when the metadata is simply out of sync after a change nobody regenerated.

ROOSOURCE is the DataSource header table that ROOSFIELD always joins against, and it is where the DataSource's application component, source system, and general settings live. roosgen holds generation-related information tied to the same DataSource once it has been activated for use. rsdiobj comes into play only once a transformation maps a ROOSFIELD field to an InfoObject, at which point the two are related through the transformation, not directly through this table. DataSource maintenance and replication transactions are what write and refresh ROOSFIELD; nothing updates it through direct table maintenance in a supported way.