ROOSOURCE table — ROOSOURCE: DataSource metadata in the source system

One row represents one version of one DataSource as it exists in the system that generates the extraction: technical name, the logical system it belongs to, the application component it is filed under, and which delta process (if any) has been assigned to it. Because a DataSource can exist in several object states at once, the same technical name can appear multiple times, once per OBJVERS value, as it moves from delivered content, through a modified working copy, to an activated version. BW does not maintain this table directly; it reads it when a DataSource is replicated from the source system into the BW metadata repository. If a change was made at extractor level but never replicated, ROOSOURCE in the source system already reflects it while the BW-side copy still does not.

Always restrict on OBJVERS first, normally to A for the active definition, otherwise a query returns the delivered, modified and active copies stacked together and looks like duplication. Restrict on LOGSYS next whenever more than one source system feeds the same BW system, since two unrelated source systems can register a DataSource of the same technical name. The table itself is small, generally a few thousand rows per system, so it is never a performance risk; the risk is entirely interpretive, not volumetric. Do not assume the row seen in the BW system's own copy of this table matches what actually sits in the real source system until a replication has been triggered.

Symptom: an InfoPackage or DTP that should pull delta only keeps behaving like a full load. Select from ROOSOURCE where OLTPSOURCE equals the DataSource name, OBJVERS equals A, and LOGSYS equals the source system in question. Read the DELTA field. If it is blank or set to a generic full-extraction value, the DataSource genuinely has no delta process defined at source, and the fix belongs in the extractor or generic extraction configuration, not in the BW load process.

Where classic DataSources are still used, including generic DataSources built on views or function modules, the source system continues to maintain this table in essentially the same shape, and BW or BW/4HANA continues to read it on replication. Where extraction has moved to ODP-based access on CDS views or extractors exposed through the operational data provisioning framework, the relevance of this particular table diminishes because the delta and field metadata are increasingly driven by the CDS annotation layer rather than by the classic DataSource shell, though a compatible entry can still appear once the object is exposed as a DataSource.

Day-to-day ownership sits with the BW extraction or data integration consultant configuring the load. When the question is about what delta process is technically possible for a given business object, that question belongs to whoever owns the source application (FI, MM, SD, or a custom extractor developer), since the delta capability is defined there, not in BW.

ROOSFIELD carries the field-level definition of the same DataSource. ROOSGEN carries its generation and program status. RSMONICDP links the metadata to actual extraction monitor entries once loads have run. On the source system side, the transactions that write and change this table are the DataSource repository and postprocessing transactions used to create, edit, and activate DataSources before they are replicated into BW.