DBSQL_REDIRECT_INCONSISTENCY – in den langen Jahren als ABAP-Entwickler sind mir schon viele „Dumps“ untergekommen. Doch dieser war neu. Was war passiert?
ABAP-Kochbuch-Autor Maic berichtet über Hürden und Lösungsansätze beim Umgang mit S/4HANA-bedingten Änderungen im Datenmodell der Logistik.
In einem S/4-System musste für ein Projekt die Tabelle für Materialbelege, MSEG, um ein Feld erweitert werden. Im Prinzip kein Problem: Append-Struktur anlegen, Feld aufnehmen, aktivieren und fertig. So auch hier, nur dass es diesmal bei der Aktivierung zu einem Fehler kam.
OK, irgendeine abhängige View enthält jetzt also eine Inkonsistenz. Komisch. Muss eben geprüft werden, ist aber im ersten Moment nicht tragisch. Vermutlich bin ich auch noch nicht einmal der Schuldige (Spoiler: doch!). Erstmal testen, ob man Materialbelege buchen kann. MIGO aufrufen, Daten eingeben – *wumms*. Oh nein. Der Fehler bei der Aktivierung scheint dann wohl doch nicht so nebensächlich gewesen zu sein. Dann müssen wir wohl mal recherchieren.
Neues S/4 HANA-Datenmodell in der Logistik
Nach kurzer Suche fand ich die Lösung, die in Form diverser Hinweise im SAP-Support-Portal beschrieben ist. Im Zuge der Einführung von S/4 HANA wurde das Datenmodell in der Logistik geändert. Zwar existieren nach wie vor die bekannten Materialstammtabellen wie MARC, MARD oder MCHB, jedoch wurde die Semantik verändert. Die genannten Tabellen enthalten Felder zur Bestandsführung. Diese werden mit S/4 jedoch nicht mehr statisch gepflegt (bei der Buchung eines Materialbelegs). Die Werte werden vielmehr dynamisch zum Zeitpunkt des Auslesens der Tabellen durch Abfrage der Materialbelege ermittelt. Vorteil: Die Tabellen des Materialstamms müssen zum Zeitpunkt des Buchens nicht mehr gesperrt werden. Nachteil: Die Ermittlung der Bestände kostet Performance.
Damit nun eine Kompatibilität zu existierenden Programmen erhalten wird (,die die Bestände in den Materialstammtabellen vermuten,) wird zu jeder Tabelle eine CDS-View als Vertreterobjekt ausgeliefert. Diese ist in der SAP GUI in der Tabellenanzeige (SE11) über „Extras à Vertreterobjekt“ zu sehen, in der Tabellendefinition in den ABAP Development Tools existiert eine Annotation „@AbapCatalog.replacementObject“. Beim Zugriff auf die Tabelle aus einem ABAP-Programm heraus leitet die Datenbank-Schicht des SAP-Systems die Abfragen an das Vertreterobjekt weiter. Eine Übersicht der betroffenen MM-Tabellen mit den zugehörigen Vertreterobjekten liefert der SAP-Hinweis 2206980 <https://launchpad.support.sap.com/#/notes/2206980>.
Im Falle der Tabelle MSEG hat sich das Datenmodell komplett geändert. Materialbelege werden mit S/4 in der Datenbanktabelle MATDOC gespeichert. Um eine reibungslose Erweiterung der Tabelle MSEG zu gewährleisten, sind mehrere Schritte notwendig:
- Erweiterung der Basis-Tabelle MATDOC
- Erweiterung der Tabelle MSEG
- Erweiterung der zugehörigen CDS-View NSDM_E_MSEG
Dabei ist auf die korrekte Namensgebung der einzelnen Objekte zu achten.
Im folgenden Beispiel wird der Materialbeleg um das Feld „Bezugsort“ erweitert. Dafür steht ein Datenelement im Standard bereit. Der Feldname muss, wie bei Kundenfeldern in SAP-Tabellen üblich, mit dem Präfix „ZZ“, „YY“ oder einem Namensraum beginnen.
Schritt 1: Struktur anlegen
Um zwischen beiden Tabellen, MATDOC und MSEG, die Strukturgleichheit zu gewährleisten, wird eine Struktur angelegt, die die notwendigen Felder enthält. Diese Struktur wird dann als Include in den Tabellen-Appends verwendet. Im Beispiel trägt die Struktur den Namen ZST_MM_INCL_MSEG_MATDOC.
Schritt 2: Tabelle MATDOC erweitern
Wer in der SAP GUI arbeitet geht hier den bekannten Weg über die SE11. In den ADT kann eine Append-Struktur über das Kontextmenü zur Tabelle im Project Explorer angelegt werden.
Als Name für die Append-Struktur wurde im Beispiel ZZA_MATDOC gewählt. Die Definition ist dabei recht übersichtlich:
Der Append kann nun aktiviert werden.
Schritt 3: Tabelle MSEG erweitern
Die MSEG wird analog zur Tabelle MATDOC per Append-Struktur erweitert. Der Name des Appends sollte 14 Stellen nicht überschreiten, da es sonst zu Problemen mit der Erweiterung des CDS-Views kommt: Die maximale Länge des Namens einer Tabelle im ABAP-Dictionary beträgt 16 Zeichen. Der Name des Appends wird im Extension View um „_V“ erweitert, wodurch nur noch 14 Stellen für den eigentlichen Namen zur Verfügung stehen.
Im Beispiel verwenden wir „ZZA_MSEG“ als Name:
Eine Aktivierung des Appends zu diesem Zeitpunkt würde zu Fehlern führen. Nachfolgende Zugriffe auf die Tabelle MSEG haben unweigerlich einen Dump zur Folge. Daher sollte mit der Aktivierung noch gewartet werden.
Schritt 4: CDS-View erweitern
Eine Erweiterung von CDS-Views ist modifikationsfrei über sogenannte „Extension Views“ möglich. Eine solche wird nun für das Vertreterobjekt der Tabelle MSEG angelegt. Dabei ist auf die Namensgebung zu achten. Deren gibt es für jedes Objekt drei:
- Name der DDL-Source
- Name der View auf Datenbankebene
- Name der View im ABAP Dictionary
Für unser Beispiel sind die Namen der folgenden Tabelle zu entnehmen:
Objekt DDL-Source Datenbank Dictionary
CDS View NSDM_DDL_MSEG NSDM_E_MSEG NSDM_V_MSEG
Extension View ZZA_MSEG_DDL ZZA_MSEG_E ZZA_MSEG_V
CDS-Objekte können nur in den ABAP Development Tools (Eclipse) angelegt werden.
Schritt 4.1: Neues Objekt anlegen
Strg+N drücken und unter „ABAP à Core Data Services“ den Eintrag „Data Definition“ auswählen. Die Liste der Objekttypen kann über eine Filter-Bedingung eingeschränkt werden, um sie zu verkürzen.
Schritt 4.2: Name, Beschreibung und Paket eingeben
Schritt 4.3: Transportauftrag wählen
Achtung: Wenn man den Dialog über „Enter“ verlässt wird der Wizard beendet und man wird in den Editor weitergeleitet. Für die Anlage eines Extension Views gibt es jedoch eine Vorlage, die hier verwendet werden kann. Daher unbedingt mit „Next >“ weitermachen!
Schritt 4.4: Vorlage auswählen
Die Vorlage „Extend View“ auswählen, Wizard mit „Finish“ abschließen.
Schritt 4.5: Vorlage-Code anpassen
Die DDL-Source enthält bereits die richtigen Schlüsselworte zur Erweiterung eines CDS-Views. Es müssen nur noch die passenden Namen (siehe Tabelle oben) und die Felder eingetragen werden.
Abschließend werden der Extension View und der MSEG-Append aktiviert. Es darf dabei zu keinen Aktivierungsfehlern kommen! Insbesondere keinen, die mit dem Vertreter-Objekt NSDM_E_MSEG zusammenhängen.
Die Tabelle MSEG ist nun um ein Kundenfeld erweitert und sowohl einer Anzeige im Data Browser als auch in den Materialbuchungen steht nichts mehr im Weg.
Weitere Hilfestellungen zum Thema MSEG
Im SAP-Support-Portal stehen einige Hinweise bereit, die die Problematik beleuchten und Hilfestellung geben:
Hinweis 2206980
Gibt einen Überblick über die Thematik und listet die betroffenen Tabellen und ihre Vertreterobjekte auf. Der Hinweis enthält darüber hinaus Referenzen auf weitere Hinweise zur Problematik, insbesondere auch für Upgrade-Szenarien.
https://launchpad.support.sap.com/#/notes/2206980
Hinweis 2240878
Problematik mit dem Customer-IncludeCI_COBL. Mindestens bei Upgrade-Projekten zu beachten!
https://launchpad.support.sap.com/#/notes/2240878
So viel zur heutigen Lektion. Viele Grüße,
euer Maic
