SAP CRM: Tabellenrelationen waren gestern!

In einem SAP CRM-Projekt für ein großes Unternehmen wurden für einen Report immer wieder einzelne Information aus verschiedenen Tabellen benötigt, die allesamt in irgendeiner Form eine Relation zum Ticket, also zur Tabelle CRMD_ORDERADM_H haben.

Die Ticketnummer, der Tabellenname und auch das Tabellenfeld waren bekannt. Für jede Abfrage auf eine Tabelle wäre ein View oder ein select-Befehl mit den entsprechenden Joins auf die Relationen möglich gewesen. Es sind mittlerweile jedoch über 65 Tabellen, aus denen die Informationen, in Relation zum Ticket, benötigt werden. Als Lösungsansatz wurde ein generischer Funktionsbaustein entwickelt, der den Zugriff auf die Tabellen und die Steuerung in der Entwicklung performanter gestaltet. Diesem Funktionsbaustein wird zunächst nur die Ticketnummer und der Tabellennamen übergeben. Als Ergebnis erhält man die zum jeweiligen Ticket gehörenden Datensätze. Mit dem Feldnamen als weiteren Parameter werden nur noch die jeweiligen Werte dieses Feldes returniert. Mit einem zusätzlichen Parameter besteht dann die Möglichkeit, das Ergebnis noch weiter zu filtern, so dass nur noch ein Wert zurückkommt. Dieses lässt sich am bestens an einem Beispiel erklären:

Beispiel 1:

Benötigt werden die Daten wie  Nachname, Vorname, Partnernummer aller Geschäftspartner eines Tickets aus der Tabelle BUT000. Da mehrere Daten aus dieser Tabelle benötigt werden, sollen die ganzen Datensätze returniert werden.

Eingabe der Parameter:

Ticketnumber: 12345678
Table: BUT000

Aufruf der Funktion:

get_info_from_table (Ticketnumber, Table)

Erklärung zu dem Aufruf:

but000

Die benötigten Daten  stehen in BUT000. Der Zugriff auf diese Tabelle erfolgt über diese Relationen

CRMD_ORDERADM_H → CRMD_LINK → CRMD_PARTNER → BUT000

Um diese Relationen zu finden, muss zuerst, von der Tabelle BUT000 ausgehend, die Relation zu der Tabelle CRMD_PARTNER gefunden werden, von dort aus dann zu der Tabelle CRMD_LINK und anschließend zu der Tabelle CRMD_ORDERADM_H. Nun werden in umgekehrter Reihenfolge diese Relationen verwendet. Aus der Tabelle CRMD_ORDERADM_H kommt über die Ticketnummer (OBJECT_ID) die GUID. Die Suche in der Tabelle CRMD_LINK nach der GUID in dem Feld GUID_HI liefert die GUID_SET-Ergebnisse. Die Suche in der Tabelle CRMD_PARTNER nach den GUID_SET-Werten in dem Feld GUID liefert dann die PARTNER_NO-Ergebnisse. Mit diesen Werten wird im Feld PARTNER_GUID in der Tabelle BUT000 gesucht und entsprechenden die Datensätze returniert. Die dafür benötigte Information findet die Funktion in den jeweiligen SAP-Tabellen.

Beispiel 2:

Es soll z.B. in einer Excel-Liste die Spalte Nachnamen aller Geschäftspartner dieses Tickets befüllt werden.

Eingabe der Parameter:

Ticketnumber: 12345678
Table: BUT000
Field: NAME_LAST

Aufruf der Funktion:

get_info_from_table (Ticketnumber, Table, Field)

Erklärung zu dem Aufruf:

Die Suche nach der Tabelle BUT000 wurde bereits oben beschrieben. Da der Parameter field befüllt ist, wird nun eine String-Tabelle mit den Nachnamen zurückgegeben.

Beispiel 3:

Benötigt wird der Nachname des Anfragenden z.B. zur Ausgabe auf den Monitor.

Eingabe der Parameter:

Ticketnumber: 12345678
Table: BUT000
Field: NAME_LAST
addWhere: and PARTNER_FCT = “ZHR001“

Aufruf der Funktion:

get_info_from_table (Ticketnumber, Table, Field, addWhere)

Erklärung zu dem Aufruf:

Die Suche nach der Tabelle BUT000 wurde bereits oben beschrieben. Da der Parameter field befüllt ist, wird nun durch eine weitere Filterung der eine String-Wert mit den Nachnamen zurückgegeben, der in diesem Fall der Anfragende (ZHR001=Inquirer) ist. Die Funktion erkennt, dass sie diesen zusätzlichen Filter in der Tabelle CRMD_PARTNER anwenden muss, da nur hier die Spalte PARTNER_FCT existiert und der Feldname daher auch nur hier abgefragt werden kann.

Fazit:

Müssen für den regelmäßigen Zugriff auf Daten zahlreiche Abfragen entwickelt werden, kann die Entwicklungseffizienz auch durch die Entwicklung komplexer generischer Funktionen stark gesteigert werden.