SOBJ: Definition der transportierbaren Objekttypen 

Die Transaktion bzw. Viewcluster-Pflege SOBJ enthält die technische Definition eines Transportobjektes. Sie enthält alle SAP-Objekte. Im folgenden Abschnitt wird erläutert, welche Informationen Sie ihr im Bezug auf die BI-Transportobjekte entnehmen können.

Übersicht

Hier können Sie das gewünschte Objekt über Positionieren auswählen. Hierzu müssen Sie den technischen Namen des Transportobjektes kennen.

Weitere Informationen zu den technischen Namen der BI-Transportobjekte: Transportierbare Objekttypen

Stückliste

Hier sind die Datenbanktabellen aufgelistet, aus denen sich das Transportobjekt zusammensetzt. Zu jeder Tabelle ist der Objektschlüssel der Tabelle in einer besonderen Notation angegeben:

●      /& repräsentiert den Namensteil des Objektschlüssels, jenen Teil, der allen Tabellen des Objektes gemeinsam ist. Er repräsentiert den eigentlichen Namen des Objektes, den man auf dem Transportauftrag wieder findet.

●      /L repräsentiert ein Sprachenfeld

●      A bzw. D ist die Objektversion, die beim Transport des Objektes exportiert werden soll.

Weitere Informationen zu den Objektversionen: BI-Versionskonzept

●      /* repräsentiert die restlichen Schlüsselanteile, welche nur in der jeweiligen Tabelle vorkommen, und nicht Teil des Objektnamens sind. Hinter /* dürfen keine weiteren Schlüsselkomponenten (also /L, /&, A oder D) mehr stehen.

Eine der Tabellen ist als Kopftabelle gekennzeichnet. Sie enthält neben der Objektversion und dem Namensteil i. d. R. keine weiteren Schlüsselanteile.

Kopfdaten

Wenn Sie auf das Objekt in der Übersicht doppelklicken, gelangen Sie auf die Kopfsicht. Hier werden Kurzbeschreibung und Typ des Objektes sowie die Objekteigenschaften angezeigt.

Als Typ wird für BI-Objekte immer L – Logisches Transportobjekt angezeigt.

Die Kategorie lautet im BI für fast alle Objekttypen SYST – Workbenchobjekt. Dies bedeutet, das Objekt verhält sich beim Transport wie ein mandantenunabhängiges Workbench-Objekt, also z. B wie ein ABAP-Report. Einige ältere Objekte sind noch der Kategorie CUSY – mandantenunabhängiges Customizing-Objektzugeordnet. Auch Objekte dieser Kategorie verhalten sich beim Transport wie Workbench-Objekte, erlauben aber noch zusätzliche Angaben zur Mehrmandantenfähigkeit, welche im BI nicht benötigt werden.

Entsprechend ist das abgeleitete Kennzeichen Mandantenabhängig für BI-Objekte nicht gesetzt. Dieses Kennzeichen wird automatisch vom System gesetzt, wenn die in der Stückliste angegebenen Tabellen mandantenabhängig sind. BI Metadatentabellen sind nie mandantenabhängig.

Das Kennzeichen Übersetzungsrelevant wird automatisch gesetzt, wenn die Stückliste eine Texttabelle, also eine Tabelle mit Sprachenschlüssel enthält. Die meisten BI-Metadatenobjekte sind übersetzungsrelevant.

Die Namenslänge gibt an, wie lang der Schlüsselteil /& im Objektschlüssel der Metadatentabellen ist. Beachten Sie, dass die einzelnen Metadatentabellen nicht unbedingt dieselben Schlüsselfelder haben müssen, für ein bestimmtes Metadatenobjekt müssen aber an der durch /& bezeichneten Position im Schlüssel alle Tabellen denselben Wert von einer durch die Namenslänge bezeichneten Gesamtlänge aufweisen.

Der Zeichensatz ist für BI-Objekte immer Syntaktische Zeichen (ohne a-z). Dies bedeutet, der Name von BI-Objekten besteht nur aus Großbuchstaben, Ziffern sowie einigen wenigen Sonderzeichen wie Schräg- und Unterstrich. Der Schrägstrich wird zur Abtrennung von Namensräumen wie z.B. /APO/ genutzt.

BI-Objekte sind sperrbar, d.h. wenn das Objekt auf einen Transportauftrag aufgezeichnet wurde, kann es nicht gleichzeitig auf einen anderen Transportauftrag aufgezeichnet werden (außer als Transport von Kopien). Dieses Verhalten ist dasselbe wie z.B. bei ABAP-Programmobjekten.

BI-Objekte haben den Namensraumtyp kein Namensraumschutz. Dies bedeutet nicht, dass BI-Objekte beliebige Namen tragen können, sondern dass das Transportwesen den Namen nicht überprüft. Die Prüfung des korrekten Namens wird in den BI-Pflegetransaktionen durch eine eigene Programmlogik abgewickelt, welche wegen des erweiterten Auslieferungskonzeptes komplexer ist als die standardmäßig verfügbaren Prüfungen. Z.B. dürfen BI-Objekte vom Kunden mit beliebigem Anfangsbuchstaben, nicht nur mit Y und Z angelegt werden. Nur Ziffern und spezielle Namensräume mit Schrägstrich sind der SAP vorbehalten.

Methoden

Die BI-Metadatenobjekte generieren meist weitere Objekte. Beim Transport wird diese Generierung im Schritt Import-Nachverarbeitung vorgenommen. Daher sind die angegebenen Funktionsbausteine der Methode AFTER_IMP – After Import zugeordnet. Einige Objekte haben auch BEFORE_EXP-Methoden, welche Vorbereitungen und Prüfungen der zu exportierenden Objekte realisieren.

Der Funktionsbaustein ist für BI-Objekte zumeist identisch RS_AFTER_IMPORT (für aktive Objekte) bzw. RS_AFTER_IMPORT_D (für Auslieferungsobjekte), obgleich jedes BI-Objekt seine eigene After-Import-Methode hat. Die beiden Bausteine sind übergreifend für alle BI-Objekte dieselben und regeln die Reihenfolge, in der die After-Import-Methoden der einzelnen Objekte aufgerufen werden. Diese Reihenfolge ist durch die Festwerte der Domäne RSTLOGO festgelegt. Weitere Informationen hierzu finden Sie unter Transportierbare Objekttypen.

Dadurch, dass für die gesamte Liste von BI-Objekten auf einem Auftrag der After-Import-Baustein nur einmal gerufen wird, ist der entsprechenden Übersichtsmeldung im Transportprotokoll nicht zu entnehmen, welches Objekt bearbeitet wird. Eine Meldung Fehler traten beim Objekt xyz auf bezeichnet nur jenes Objekt, welches zufällig das erste der Liste war, jedoch nicht zwangsläufig jenes, welches fehlerhaft war. Reißen Sie daher das Transportprotokoll vollständig auf, wenn Sie es untersuchen wollen.

Als Upgrade wird hier auch ein SAP Patch bezeichnet. Die BI-After-Import-Methoden sollen auch beim Einspielen von Upgrades und Patches durchgeführt werden.

Weitere Informationen

BC - Zentrale Pflege- und Transportobjekte