Objektabhängigkeiten und Konsistenz 

Abhängigkeiten zwischen Objekten

BI-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

Das InfoObject Kalendertag hat keine Referenzen zu anderen Objekten.

●      Von anderen Objekten desselben Typs abhängig

InfoObjects, welche Attribute haben: Die eingetragenen Attribute sind wieder InfoObjects, welche ebenfalls vorhanden sein müssen, damit das InfoObject konsistent ist.

●      Von Objekten eines anderen Typs abhängig

InfoCubes enthalten InfoObjects.

●      Von nicht-transportierbaren (systemlokalen) Objekten abhängig

Die DataSource ist vom Quellsystem abhängig, das Quellsystem kann nicht transportiert werden.

●      Von Objekten eines anderen Typs abhängig, welche von systemlokalen Objekten abhängig sind

Die Transformation ist von der DataSource abhängig, welche ihrerseits vom Quellsystem abhängig ist.

Konsistente Aufträge

Neben dem Versionskonzept ist die Hilfestellung zur Erstellung eines konsistenten Auftrags die zweite wichtige BI-Erweiterung des Standard-Transportwesens.

Abhängigkeiten zwischen Objekten gibt es nicht nur im BI. 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 BI 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 BI ist die Erstellung eines konsistenten Auftrags aus folgenden Gründen schwieriger als bei Programmobjekten:

●      Die adressierte Benutzergruppe (der BI-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.

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.

Wir empfehlen zur Erstellung eines Transportauftrages (unabhängig von der Tatsache, ob Sie aktive Objekte oder Auslieferungsversionen transportieren möchten) immer den Funktionsbereich Transportanschluß (BI-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 BI-Objekten manuell konsistent zu erstellen.

Weitere Informationen über die Unterschiede zwischen dem BI-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.

Die Abhängigkeit der BI-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 an ist 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.