Objektabhängigkeiten und Konsistenz 
Abhängigkeiten zwischen Objekten
BW-Objekte können in ihrer Definition von anderen Objekten abhängig sein. Diese Abhängigkeiten können verschiedene Ausprägungen haben:
Von nichts weiter abhängig
BeispielDas InfoObject Kalendertag hat keine Referenzen zu anderen Objekten.
Ende des Beispiels.Von anderen Objekten desselben Typs abhängig
BeispielInfoObjects, welche Attribute haben: Die eingetragenen Attribute sind wieder InfoObjects, welche ebenfalls vorhanden sein müssen, damit das InfoObject konsistent ist.
Ende des Beispiels.Von Objekten eines anderen Typs abhängig
BeispielInfoCubes enthalten InfoObjects.
Ende des Beispiels.Von nicht-transportierbaren (systemlokalen) Objekten abhängig
BeispielDie DataSource ist vom Quellsystem abhängig, das Quellsystem kann nicht transportiert werden.
Ende des Beispiels.Von Objekten eines anderen Typs abhängig, welche von systemlokalen Objekten abhängig sind
BeispielDie Transformation ist von der DataSource abhängig, welche ihrerseits vom Quellsystem abhängig ist.
Ende des Beispiels.
Konsistente Aufträge
Neben dem Versionskonzept ist die Hilfestellung zur Erstellung eines konsistenten Auftrags die zweite wichtige BW-Erweiterung des Standard-Transportwesens.
Abhängigkeiten zwischen Objekten gibt es nicht nur im BW. Auch bei ABAP-Workbench-Objekten sind Objekte voneinander abhängig. Zum Beispiel ist ein Auftrag inkonsistent, der ein Programm enthält, welches auf eine Datenbanktabelle zugreift, die ihrerseits nicht exportiert wird. Wenn solch ein Auftrag transportiert wird, fehlt die Tabelle im Zielsystem, und das Programm enthält dadurch im Zielsystem Syntaxfehler. Daher sollte bereits bei der Entwicklung darauf geachtet werden, dass alle abhängigen Objekte demselben Paket oder jedenfalls einem Paket derselben Transportschicht zugeordnet werden und dann auf demselben Auftrag aufgezeichnet werden.
Konsistente Aufträge, in denen die Objektabhängigkeiten berücksichtigt sind, sind im BW insbesondere wichtig, weil die Metadatenobjekte im Import-Nachbearbeitungsschritt aktiviert werden. Wenn abhängige Objekte auf dem Transportauftrag fehlen, führt dies zu Fehlern bei der Aktivierung, welche im Protokoll des Transportauftrags angezeigt werden.
Im BW ist die Erstellung eines konsistenten Auftrags aus folgenden Gründen schwieriger als bei Programmobjekten:
Die adressierte Benutzergruppe (der BW-Modellierer) setzt sich i.d.R. nicht mit Auslieferungsfragen auseinander.
Es soll möglich sein, Objekte testweise anzulegen ohne sie auf einen Transportauftrag schreiben zu müssen, weil sie nicht transportiert werden sollen.
Es gibt eine große Anzahl von Objekttypen, und die Abhängigkeit der Objekte untereinander ist schwierig zu überblicken.
Neben der technischen Abhängigkeit, welche zu Inkonsistenzen führt, gibt es noch andere Arten von Abhängigkeit, welche es erleichtern, ein komplettes Szenario zu transportieren.
Daher führt das System direkt vor der Freigabe einer Aufgabe oder eines Auftrags eine Konsistenzprüfung durch. Weitere Informationen finden Sie unter Konsistenzprüfung bei der Freigabe von Transporten.
Werkzeuge
Aus den oben genannten Gründen gibt es für Transport und BI-Content-Aktivierung von Objekten eigene Funktionsbereiche in der Data Warehousing Workbench. Diese Bereiche arbeiten analog, und sind über den Transaktionscode RSOR oder RSORBCT auch direkt erreichbar.
Weitere Informationen über die Funktionsweise der Bereiche finden Sie unter Objekte sammeln.
Achtung
Wir empfehlen zur Erstellung eines Transportauftrages (unabhängig von der Tatsache, ob Sie aktive Objekte oder Auslieferungsversionen transportieren möchten) immer den Funktionsbereich Transport anschluß(BW-Transportwesen) zu verwenden oder das Standard-Transportwesen einzuschalten, und keine Transportaufträge manuell zusammenzustellen. Nur mit viel Erfahrung (und bei überschaubaren Objektmengen) wird es gelingen, einen Auftrag mit BW-Objekten manuell konsistent zu erstellen.
Weitere Informationen über die Unterschiede zwischen dem BW-Transportwesen und dem Standard-Transportwesen finden Sie unter Aufzeichnungszeitpunkt für den Transport.
Objektabhängigkeiten im Einzelnen
Es gibt folgende grundlegende Arten der Objektabhängigkeit:
benötigt
hat Unterobjekt
verwendet von (Umkehrung von benötigt)
sendet Daten an
empfängt Daten von / gehört zum Szenario
Zusätzlich gibt es noch einige weniger wichtige Abhängigkeiten, z.B. ist sichtbar in oder eingeplant durch.
Diese Abhängigkeiten werden abgebildet auf die Gruppierungsmodi beim Sammeln der Objekte:
Nur notwendige Objekte: Enthält rekursiv alle Objekte der Abhängigkeiten benötigt und Unterobjekt.
Im Datenfluss davor: Enthält alle notwendigen Objekte und zusätzlich rekursiv jene der Abhängigkeit empfängt Daten von. Die Rekursivität bezüglich der Abhängigkeit empfängt Daten von wird jedoch auf der Ebene der Attribute von InfoObjects abgebrochen, um die Objektmenge zu beschränken.
Im Datenfluss danach: Enthält alle notwendigen Objekte und zusätzlich jene der Abhängigkeit sendet Daten an.
Objekte der Abhängigkeit verwendet von können Sie sammeln, indem Sie auf einem Objekt der Objektmenge den Kontextmenüeintrag optionale Objekte sammeln wählen.
Hinweis
Die Abhängigkeit der BW-Objekte untereinander ist je nach Objekttyp an einer der beiden folgenden Stellen festgelegt:
Im Funktionsbaustein RSO_<TLOGO>_GET_RELATED wobei <TLOGO> der Name des logischen Transportobjektes ist.
In der Methode IF_RSO_TLOGO_GENERAL~GET_RELATED jener Klasse, welche Sie der Tabelle RSTLOGOPROP entnehmen können.
Weitere Informationen zu den Namen der logischen Transportobjekte und der Tabelle RSTLOGOPROP finden Sie unter Transportierbare Objekttypen.
Weitere Informationen: Gruppierungsmodus festlegen
Objektabhängigkeiten ausgewählter Objekttypen
Im Folgenden werden einige wichtige Objekttypen in Ihrer Abhängigkeit grafisch dargestellt. Die Abbildungen beschränken sich auf die drei Abhängigkeitsarten hat Unterobjekt, benötigt, empfängt Daten von.
Aus Gründen der Übersichtlichkeit werden nicht zu jedem dargestellten Objekttyp alle seine abhängigen Objekttypen dargestellt, und die Beziehung sendet anist nicht eingezeichnet, sie ist in der Regel die Umkehrung von empfängt von.
Staging-Objekte im Datenfluss
Im Vergleich zum Datenfluss 3.x (siehe unten) wurde das Tripel Übertragungsregel, Transferstruktur, DataSource 3.x durch die zwei Objekte Transformation und DataSource ersetzt. Auch die Fortschreibungsregel ist in der Transformation aufgegangen. Ebenso ist das Tupel InfoSource 3.x und Kommunikationsstruktur im Objekt InfoSource zusammengefasst worden.
Die DataSource verweist nicht auf das Quellsystem, umgekehrt hat das Quellsystem jedoch noch die (nicht eingezeichnete) Beziehung sendet an gegenüber der DataSource. Diese Beziehung ist wichtig für den Sammelmodus Für Systemkopie(weitere Informationen: Objekte sammeln).
Weitere Informationen zu den grau gezeichneten Objekten finden Sie unter Besonderheiten quellsystemabhängiger Objekte.
Staging-Objekte im 3.x-Datenfluss
Das InfoObject ist in dieser Abbildung in zwei Rollen eingezeichnet: Zum Einen als Komponente eines Strukturobjektes, zum Anderen als Ziel für Stammdaten- und Text-Ladevorgänge.
Beachten Sie das Zusammenspiel der Objekte Übertragungsregel, Transferstruktur und DataSource 3.x: Es müssen immer alle 3 Objekte gleichzeitig transportiert werden, damit der Auftrag konsistent ist. Dasselbe gilt für die InfoSource 3.x und die Kommunikationsstruktur.
Weitere Informationen zu den grau gezeichneten Objekten finden Sie unter Besonderheiten quellsystemabhängiger Objekte.
Prozessobjekte
Die Prozessvariante ist zweimal eingezeichnet, da sie als Container für verschiedenste Prozesse dient; insbesondere dient sie sowohl als Container für im Datenteil mittelbar quellsystemabhängige Prozesse als auch für Prozesse, die nicht quellsystemabhängig sind (weitere Informationen: Klassifikation quellsystemabhängiger Objekte).
Weitere Informationen zu den grau gezeichneten Objekten finden Sie unter: Besonderheiten quellsystemabhängiger Objekte.
Reporting- und Analyse-Objekte
Das Objekt Query-Element taucht mehrfach auf, da es zum Transport der verschiedensten Element-Arten, z.B. Query, berechnete Kennzahl oder Variable, benutzt wird. Diese Element-Arten haben verschiedenartige Abhängigkeiten voneinander.