Migration von kundeneigenen Implementierung für BW 7.4

In diesem Blog beschreibe ich die Umstellung von kundeneigenen Implementierung, die durch Änderungen an SAP Standard Datentypen notwendig sein könnte.

Der Hinweis 1823174 – BW 7.4 Umstellungen und kundeneigene Programme geht bereits auf dieses Thema ein und beschreibt auch Analyse- und Lösungswege. Der Blog soll ergänzend zu dem Hinweis zusätzliche Hintergrundinformationen geben und bei der Suche nach dem besten Weg für die Umstellung unterstützen.

1.1      Warum und wann ist die Umstellung notwendig?

Auf Grund der Schlüsselerweiterung von InfoObjekten von zuvor max. 60 Zeichen auf nun 250 Zeichen wurde in BW 7.4 der Datentyp der Domain RSCHAVL (die vom Datenelement RSCHAVL verwendet wird) von CHAR 60 auf SSTRING geändert.

Der Datentyp STRING ist ein dynamischer Datentype mit einer variablen Länge von bis zu 1333 Zeichen (siehe
http://help.sap.com/abapdocu_731/en/abenbuilt_in_types_dictionary.htm).

Das Datenelement RSCHAVL wird in mehreren BW Strukturen im Rahmen von Selektionsoptionen (Range Tabellen) verwendet. Figure 1.1 zeigt die beiden Selektionsstrukturen die im Rahmen des Customer Exits zur Verarbeitung von BEx Variablen zum Einsatz kommen. Der Import-Parameters I_T_VAR_RANGE basiert auf der Struktur RRRANGEEXIT (BW: Simplified variable structure for exit variables) und der Export-Parameter E_T_RANGE basiert auf der Struktur RRRANGESID (Range expanded around SID). Interne greifen beide Strukturen auf die Include-Struktur RRRANGE (Range table in brain) zurück.

Figure_1_1

Figure 1.1: Selektions-Struktureim Customer Exit EXIT_SAPLRRS0_001

Die Änderung der Strukturen durch die Änderung der Domain RSCHAVL muss nicht zwangsläufig dazu führen das kundeneigene Implementierungen angepasst werden müssen. Durch die Änderung der Domain RSCHAVL werden alle Strukturen bei denen eine oder mehrere Komponenten auf dem Datenelements RSCHAVL basieren zu tiefen Strukturen. Figure 1.2 zeigt Codierungsbeispiele auf die nach der Umstellung zu Syntaxfehlern führen.

Figure_1_2

Figure 1.2: Invalid ABAP Syntax in BW 7.4

Die Deklaration von lokalen Strukturen mittels der Anweisung TABLES ist nur für Tabellen basierend auf flachen Strukturen erlaubt. Dies gilt auch für die Deklaration mittels DATA und LIKE.

Der LIKE Operator kann hier einfach durch den typenspezifischen Operator TYPE ausgetauscht werden. Für die Deklaration mittels der Anweisung TABLES muss das Coding auf die Deklaration mittels DATA umgestellt werden.

Die für CHAR Typen typische Verwendung von Offsets und Längenangaben wie ls_e_range-low+6(2) ist für String basierte Typen nicht erlaubt und führt zu Syntaxfehlern.

Die Verwendung von Offset- und Längenangaben kann durch String-Verknüpfungen (Concatenation) oder durch die Verwendung von String-Templates ersetzt werden, siehe Figure 1.2.

Weitere Beispiele für Implementierungen, die in NW 7.4 zu Syntaxfehlern führen sind im Hinweis 1823174 – BW 7.4 Umstellungen und kundeneigene Programme im Abschnitt Syntaxfehler aufgelistet.

1.2      Welche bzw. wo sind Umstellungen notwendig?

  •  Customer Exit für Variablen
  • Kundeneigenen Programmen
  • Transformationen / DTPs / InfoPackages

1.3      Wie können die Stellen mit den Syntaxfehler gefunden werden

Okay wir wissen nun welche Implementierungen zu Syntaxfehlern führen und in welchen Bereiche wir zu suchen müssen.

  • Aber wie finden wir nun die Stellen in kundeneigen Implementierungen?
  • Müssen alle Reports / Includes / Funktionsbausteine / Klassen / … manuell überprüft werden?
  • Welche Optionen bestehen für die Korrektur der gefundenen Fehler?

1.3.1       Customer Exit für Variablen und kundeneigene Programme

Die Antwort ist hier leider nicht eindeutig. Wenn wir uns die drei Bereiche anschauen die wir untersuchen müssen können wir für die ersten beiden, Customer Exit für Variablen und kundeneigene Programme, klar sagen dass diese automatisiert überprüft werden können.

Der Hinweis 1823174 – BW 7.4 Umstellungen und kundeneigene Programme stellt zwei Word-Dokumente zur Verfügung in denen beschrieben wird wie mit Hilfe des Code Inspektors (Transaktion SCI) kundeneigene Implementierungen auf Syntaxfehler untersucht werden können. Der Hinweis bietet hier zwei Varianten für den Code Inspektor an. Die Variante CodeInspector Pre Post kann vor dem Upgrade und nach dem Upgrade durchgeführt werden. Mit Hilfe des Reports ZSAP_SCI_DELTA kann das Delta der beiden Läufe ermittelt und verglichen werden.

Die zweite Variante für den Code Inspektor CodeInspector Post die im Hinweis beschrieben wird, kann verwendet werden wenn die Syntax Prüfung vor dem Upgrade nicht durchgeführt werden konnte.

Figure 1.3 zeigt das Ergebnis der beiden Code Inspektor Varianten.

Figure_1_3

Figure 1.3: Code Inspector and Customer Programs

Die gefundenen Syntaxfehler können direkt aus dem Ergebnisreport des Code Inspektors heraus mittels Vorwärtsnavigation angesprungen und korrigiert werden.

Bei der Korrektur der Fehler die im Rahmen des Customer Exit von Variablen auftreten, werden Kunden seitens der SAP unterstützt. Im Blog New BAdI RSROA_VARIABLES_EXIT_BADI (7.3) habe ich den neuen BAdI zur Verarbeitung von Customer Exit Variablen vorgestellt der mit BW 7.3 eingeführt wurde. Mit BW 7.4 hat SAP die Auslieferung der Default Implementierungen um eine zusätzliche BAdI Implementierung erweitert. Zusätzlich zur Standard BAdI Implementierung SMOD_EXIT_CALL (Implementation: BAdI for Filling Variables) wird mit BW 7.4 die BAdI Implementierung CL_RSROA_VAR_SMOD_DIFF_TYPE (SMOD Exit Call with differnent Tables and Types) als inaktive Version ausgeliefert. Die Default BAdI Implementierung SMOD_EXIT_CALL wird weiterhin als aktive Implementierung ausgeliefert.

  • Was ist nun der Unterschied der beiden Implementierungen?
  • Wann muss welche Implementierung aktiviert werden?
  • Können beide Implementierungen aktiv sein?

Beide Implementierungen dienen als Wrapper / Mediator / Vermittler zum Aufruf des Customer Exits. Kunden die auf einem frischen System anfangen und noch keine Customer Exit Implementierungen als „Altlasten“ in ihrem System haben können und sollten neue Implementierungen für die Verarbeitung von Exit Variablen über eigene BAdI Implementierungen umsetzten, siehe New BAdI RSROA_VARIABLES_EXIT_BADI (7.3).

Um den Unterschied der beiden Implementierungen zu erklären schauen wir uns zunächst die Parameter des Customer Exit EXIT_SAPLRRS0_001 an. In Figure 1.4 zeigt im unteren Teil die Importing und Exporting Parameter des Funktionsbausteins. Zusätzlich zu den beiden Parameter I_T_VAR_RANGE und E_T_RANGE sind die zwei Parameter I_T_VAR_RANGE_C und E_T_RANGE_C hinzugekommen. Bei den beiden Parameter I_T_VAR_RANGE und E_T_RANGE basieren die Komponenten LOW und HIGH auf dem Datenelement RSCHAVL (siehe oben) und sind somit vom Datentyp SSTRING Felder.

Bei den beiden Parameter I_T_VAR_RANGE_C und E_T_RANGE_C basieren die Komponenten LOW und HIGH auf dem Datenelement RSCHAVL_MAXLEN und sind somit vom Datentyp CHAR. Die Parameter I_T_VAR_RANGE_C und E_T_RANGE_C können daher analog wie zuvor die original Parameter I_T_VAR_RANGE und E_T_RANGE verwendet werden, sie basieren auf flachen Strukturen.

Figure 1.4: Optional Customer Exit Parameter

Die Parameterpaare I_T_VAR_RANGE_C, E_T_RANGE_C und I_T_VAR_RANGE, E_T_RANGE stellen zwei Optionen dar. Welche Option verwendet wird hängt von der aktuell aktiven BAdI Implementierung ab. Figure 1.4 zeigt die Beziehung zwischen den beiden von der SAP ausgelieferten BAdI Implementierungen SMOD_EXIT_CALL und CL_RSROA_VAR_SMOD_DIFF_TYPE und den verwendeten Parameterpaaren. Die BAdI Implementierung SMOD_EXIT_CALL (default) arbeitet mit den Parametern I_T_VAR_RANGE und E_T_RANGE und die BAdI Implementierung CL_RSROA_VAR_SMOD_DIFF_TYPE arbeitet mit den Parametern I_T_VAR_RANGE_C und E_T_RANGE_C.

Für den Fall, dass der Code Inspektor viele Syntaxfehler gefunden hat die auf die Umstellung des Datenelementes RSCHAVL zurück zu führen sind empfiehlt SAP die optionale BAdI Implementierung CL_RSROA_VAR_SMOD_DIFF_TYPE zu verwenden. Figure 1.5 zeigt auf welche Schritte notwendig sind um die optionale Implementierung zu verwenden.

Starten Sie die Transaktion SE18 (BAdI Builder), wählen Sie die Option BAdI Name, tragen Sie den BAdI Namen RSROA_VARIABLES_EXIT_BADI ein und wählen Sie anschließend Anzeigen.

Im Erweiterungs-Spot (Enhancement Spot) expandieren Sie den Eintrag RSROA_VARIABLES_EXIT_BADI. Ein Doppelklick auf Implementierungen zeigt die Liste der aktuell verfügbaren Implementierungen zu dem BAdI. (1)

Die gelbe Lampe zeigt an, dass die Default-Implementierung SMOD_EXIT_CALL aktiv ist. Die graue Lampe zeigt an, dass die Implementierung CL_RSROA_VAR_SMOD_DIFF_TYPE nicht aktiv ist. Die Definition des BAdI erlaubt, das mehrere BAdI Implementierungen parallel aktiv sein dürfen. Daher ist die Reihenfolge von Schritt (2) und (3) beliebig.

Im Schritt zwei deaktivieren wir zunächst die Default-Implementierung. Ein Doppelklick auf die Implementierung in der Liste rechts von (1) öffnet die BAdI Implementierung (2). Zum deaktivieren der Implementierung muss das Kennzeichen Implementation is active de-selektiert werden. Anschließend muss die Implementierung aktiviert werden.

Im Schritt drei aktivieren wir die optionale BAdI Implementierung CL_RSROA_VAR_SMOD_DIFF_TYPE. Ein Doppelklick auf die Implementierung in der Liste rechts von (1) öffnet die BAdI Implementierung (2). Zum aktivieren der Implementierung muss das Kennzeichen Implementation is active selektiert werden. Anschließend muss die Implementierung aktiviert werden.

Nachdem die Default Implementierung deaktiviert und die optionale Implementierung aktiviert ist sollten die Farben der Lampen sich entsprechend (4) geändert haben. Ist dies nicht der Fall muss die Anzeige eventuell aktualisiert werden.

Figure_1_5

Figure 1.5: Switch BAdI Implementation

Nach dem nun die optionale BAdI Implementierung aktiv ist muss nun das kundeneigene Coding angepasst werden. Hierzu müssen lediglich die Namen der verwendeten Objekte (Strukturen, Tabellentypen) innerhalb der kundeneigenen Implementierungen entsprechend der Liste in Table 1 ausgetauscht werden. Hierzu kann die Editor Funktion Suchen und Ersetzten verwendet werden.

Alt Neu
i_t_var_range i_t_var_range_c
e_t_range e_t_range_c
rrrangeexit rrs0_s_var_range_c
rrs0_s_var_range rrs0_s_var_range_c
rrrangesid rrs0_s_range_c
rsr_s_rangesid rrs0_s_range_c

Die hier beschriebene Anpassung und Umstellung der verwendeten Implementierung ist nur dann sinnvoll wenn der Code Inspektor (siehe oben) Syntaxfehler gefunden hat die auf die Umstellung des Datenelements RSCHAVL zurück zuführen sind.

Hat der Code Inspektor keine entsprechenden Fehler gefunden oder die Anzahl der Fehler ist sehr gering, empfiehlt es sich die Syntaxfehler in den Kundenimplementierungen zu korrigieren und die Default BAdI Implementierung zu verwenden.

Für kundeneigene Programme gilt prinzipiell das gleiche wie für die kundenspezifischen Implementierungen im Rahmen des Customer Exits. Hier kommt hinzu, dass es weitere Strukturen gibt in denen das Datenelement RSCHAVL verwendet wird als in Table 1 (siehe oben) aufgelistet. Für diese Strukturen werden keine CHAR basierten Alternativen angeboten. Wird zum Beispiel die Struktur RSDRD_S_RANGE (Single Selection for a an Infoobject in a Deletion Criterion) im Rahmen eines kundeneigenen Programms verwendet muss geprüft werden ob es hier zu Syntaxfehlern kommt. Dies kann analog zum Variablen Exit mit Hilfe des Code Inspektors überprüft werden.

Eventuell muss die Objektliste im Code Inspektor angepasst werden. Das ist dann der Fall wenn die Implementierung für den Variablen Exit in einem anderen Entwicklungs-Paket organisiert ist als zum Beispiel die Wartungsprogramme fürs Houskeeping.

1.3.2       Transformationen / DTPs / InfoPackages

Beim dritten Bereich, Transformationen / DTPs / InfoPackages, hängt es davon ab wie Implementierung hier umgesetzt ist. Aus technischer Sicht sind Transformationen Reports auch als generiertes Programm bezeichnet. Figure 1.6 zeigt wie man von der Transformation zum entsprechenden generierten Programm gelangt. Weiter zeigt Figure 1.6 was passiert wenn versucht wird das generierte Programm mit Hilfe des Code Inspektors auf Syntax Fehler zu untersuchen.

Figure_1_6

Figure 1.6: Code Inspector and Transformations

Das generierte Programm ist ein SAP Objekt und kann nicht durch den Code Inspektor untersucht werden.

Aus Gründen der Wartbar- und Widerverwendbarkeit gehen viele Kunden dazu über Implementierungen von Start-, End-, Feld- oder Expertenroutinen auszulagern. Hier findet man Unterschiedliche Ansätze von der einfachen Verwendung von Includes bis hin zu komplexen Klassenmodellen. Ausgelagerte Implementierungen können, da es sich ja hier um kundenspezifische Implementierungen handelt, mit Hilfe des Code Inspektors (Transaktion SCI) überprüft werden.

Findet die Implementierung direkt innerhalb der Transformation statt so muss die entsprechende Transformation manuell überprüft werden.

Generiertes Programm der Transformation

Aus technischer Sicht ist eine Transformation ein Report in dem eine lokale ABAP-OO Klasse definiert wird. Basis für den Report und die lokale Klasse sind Templates. Diese Templates bilden die Grundlage für das generierte Programm. Der Programmcode der im Rahmen der Definition der Transformation hinzugefügt wird wie Start-, End-, Feld- oder Expertenroutine wird in die lokale Klasse hineingeneriert.

Um nicht jede Transformation einzeln und manuell zu überprüfen können Transformationen mit Hilfe des Reports RSDG_TRFN_ACTIVATE automatisiert aktiviert werden. Der Report kann hierzu auch als Hintergrundjob eingeplant werden.

Über den Selektionsscreen des Reports RSDG_TRFN_ACTIVATE kann gesteuert werden ob eine einzelne Transformation, eine Liste von Transformationen oder Transformationen mit bestimmten Ziel- oder Quellobjekten aktiviert werden soll. Figure 1.7 zeigt auf wie der Report für eine Transformation ausgeführt wird. Wenn alle Transformationen durch Re-Aktivierung auf Syntaxfehler geprüft werden sollen müssen alle Selektionsfelder freigelassen werden.

Bei der Aktivierung einer Transformation wird das generierte Programm neu generiert (dies geschieht nur bei Bedarf) und auf Syntaxfehler geprüft. D.h. enthält eine Transformation fehlerhaftes Coding kann der Report diese nicht aktivieren.

Figure_1_7

Figure 1.7: Re-Aktivierung von Transformationen

Das Log-Ergebnis auf der rechten Seite in Figure 1.7 zeigt, dass durch die Aktivierung der Transformation der bzw. die zugehörigen DTPs zunächst inaktiv werden. Der Report aktiviert anschließend auch die abhängigen DTPs.

Bei den inaktiven Transformationen muss nun manuell geprüft werden warum sie nicht aktiviert werden konnten. Als Einstieg für die Nacharbeitung kann das Ergebnis des Applikation Logs (siehe Figure 1.7) oder die Tabelle RSTRAN (Transformationen) verwendet werden.

Code PushDown der Transformationen und DTPs

Positiver Nebeneffekt der Re-Aktivierung der Transformationen ist, dass hierdurch implizit ein Code PushDown der Transformationen durchgeführt wird wenn dies möglich ist. Dies setzt natürlich voraus, dass die Datenbank eine SAP HANA ist.

Mit Hilfe des Reports RSDHA_TRFN_CHECK_HANA_PROCESS kann geprüft werden welche Transformationen potentiell für einen Code PushDown geeignet sind.

Routinen im DTP Filter und im InfoPackage

Die Strukturen die im Rahmen der Selektion durch BEx Variablen vom Typ Customer-Exit oder ABAP Routinen im DTPs und/oder InfoPackages von der SAP verwendet werden sind aktuell nicht betroffen. Das heißt hier ist nur dann Handlungsbedarf wenn innerhalb der eigenen Implementierung eine Struktur verwendet wird bei der einen Komponente auf dem Datenelement RSCHAVL basiert.

2      SAP Hinweise

1823174 – BW 7.4 Umstellungen und kundeneigene Programme

1943752 – SYNTAX_ERROR Dump Occurs when Executing a BW Query with Customer Exit Variable after Upgrading to BW7.4

2080574 – Massenaktivierungsprogramme laden generierte Programme unbeabsichtigt in Hauptspeicher, Abbruch wegen Speicherüberlauf

2098262 – SAP HANA Execution: Only RownumFunction() calculated attributes are allowed

3      Links

http://help.sap.com/saphelp_nw74/helpdata/de/54/cf56a496a244518fd774e1bfc68bfd/frameset.htm

Programs for Activating BW Objects in a Productive System

Was Sie schon immer über die Verarbeitung von Customer Exit-Variablen wissen wollten, aber …

In diesem Blog möchte ich versuchen etwas Klarheit in die Verarbeitung von Exit-Variablen (EXIT_SAPLRRS0_001) zu bringen. Der mit BW 7.30 aufgetauchte BAdI RSROA_VARIABLES_EXIT_BADI hat den Umgang mit Exit Variablen auch nicht gerade vereinfacht. Hinzu kommt, dass der BAdI in der SAP Hilfe leider gar nicht dokumentiert ist. Des Weiteren wurde mit 7.4 nun auch noch die Domain RSCHAVL von CHAR 60 auf SSTRING geändert.

Alle hier beschriebenen Exit-Variablen dienen dazu den Wertebereich eines Berichtes einzuschränken bzw. im Rahmen von Berechtigungen zu erweitern. Des Weiteren gelten die hier beschriebenen Eigenschaften von Exit Variablen auch für Exit Variablen die im Rahmen des Staging, in DTP’s oder InfoPackages, verwendet werden.

Zunächst wollen wir uns aber erst einmal mit den unterschiedlichen Typen von Exit Variablen und deren Verarbeitungsreihenfolge beschäftigen.

1.1      Variablentypen

Wenn ich von Exit-Variablen spreche unterscheiden ich folgende Verwendungsarten:

  • Eingabebereit
  • Nicht eingabebereit
  • Verwendung in Berechtigungen und im Staging

Eingabebereite Variablen kommen dann zum Einsatz wenn dem Anwender die Möglichkeit gegeben werden soll das Berichtsergebnis individuell zu beeinflussen. Das Grundkonzept einer eingabebereiten Variablen sieht vor das der Anwender den Wert für die Variable bestimmt und dieser nicht durch interne Verarbeitungsprozesse (Customer-Exit) verändert werden darf. In Abschnitt 1.3 »Überschreiben von eingegebenen Werten« beschreibe ich wie dieses Konzept umgangen werden kann und auch der vom Benutzer eingegebene Wert einer eingabebereiten Variablen im Customer-Exit überschrieben werden kann.

Eingabebereite Variablen werden im I_STEP = 1 und I_STEP = 3 prozessiert, siehe Abschnitt 1.2 »Verarbeitungsschritte (I_STEP)«.

Nicht eingabebereite Variablen kommen dann zum Einsatz wenn der Wert mittels Regeln bestimmt werden soll. Häufig werden hier Regeln definiert (implementiert) bei denen die Variablenwerte für nicht eingabebereite Variablen in Abhängigkeit von eingabebereiten Variablen ermittelt werden.

Nicht eingabebereite Variablen werden im I_STEP = 1 und I_STEP = 2 prozessiert, siehe Abschnitt 1.2 »Verarbeitungsschritte (I_STEP)«.

Exit Variablen können auch im Rahmen der Berechtigung oder im Staging verwendet. Bei Exit Variablen die hier zum Einsatz kommen muss berücksichtigt werden, dass hier in der Regel keine Interaktion mit einem Benutzer statt findet. Das heißt hier ist die Verarbeitungsreihenfolge eine andere.

Daher muss hier sichergestellt sein, dass Kombinationen wie eingabebereit, verpflichtend und keinen Vorschlagswert (Default value) dazu führen dass ein Variablendialog benötigt wird. Prozesses des Staging (DTP, InfoPackage) finden in der Regel in eingeplanten Prozessen statt die von Hintergrund-Benutzern ausgeführt werden.

Variablen der Verwendungsart Berechtigung und Staging werden nur im I_STEP = 0 prozessiert, siehe Abschnitt 1.2 »Verarbeitungsschritte (I_STEP)«.

1.2      Verarbeitungsschritte (I_STEP)

Exit Variablen werden je nach Verwendungsart und Verwendungszweck in ein oder mehreren Schritten, den I_STEP’s, verarbeitet. Im Abschnitt »Abhängigkeiten bei Variablen vom Typ Customer-Exit« der SAP Hilfe werden die I_STEP’s kurz erläutert. Die Beschreibung in der Online-Hilfe ist leider unvollständig und verzichtet vollkommen auf Beispiele. Ich werde die einzelnen Schritte daher noch einmal kurz an Hand von Beispielen erläutern.

1.2.1       Berechtigung und Staging (I_STEP = 0)

Im I_STEP = 0 werden Exit-Variablen verarbeitet die in der Berechtigung und die im Staging verwendet werden. Figure 1.1 zeigt die Verwendung einer Exit Variablen innerhalb der Berechtigung. Für die Verarbeitung von Exit Variablen innerhalb der Berechtigung wird nur der I_STEP = 0 durchlaufen.

Figure_1_1

Figure 1.1: Exit Variablen innerhalb der Berechtigung

Figure 1.2 zeigt die Verwendung einer Exit-Variablen im Staging am Beispiel der Selektion innerhalb eines InfoPackage.

Figure_1_2

Figure 1.2: Exit Variablen innerhalb des Staging

1.2.2       Initialisierung (I_STEP = 1)

Der I_STEP = 1 dient zur Initialisierung von Exit Variablen und wird für jede Exit Variable separat durchlaufen. Hierbei werden zuerst die eingabebereiten Variablen und anschließend die nicht eingabebereiten Variablen verarbeitet, siehe Figure 1.7.

Figure 1.3 zeigt ein typisches Beispiel zur Initialisierung einer eingabebereiten Variablen. Hier wird die Variable mit dem aktuellen Monat des letzten Jahres vorbelegt.

Figure_1_3

Figure 1.3: Initialisierung

1.2.3       Ableitung von Variablenwerten (I_STEP = 2)

Der I_STEP = 2 dient der Ableitung der Werte für die nicht eingabebereiten Exit Variablen. Auch hier werden analog zum I_STEP = 1 die Variablen separat prozessiert. Zur Ableitung der Werte für nicht eingabebereiten Exit Variablen stehen alle bisher erfassten Variablenwerte im Parameter I_T_VAR_RANGE zur Verfügung. In Abschnitt 1.3 »Überschreiben von eingegebenen Werten« beschreibe ich wie auch eingabebereite Variable hier prozessiert werden können.

Figure 1.4 zeigt wie für die aktuelle Variable (Prüfung des Variablennamen ist hier nicht abgebildet) der Wert basierend auf dem Wert der Variablen ZTKE_MONTH abgeleitet wird.

Figure_1_4

Figure 1.4: Ableitung von Variablen

1.2.4       Validierung (I_STEP = 3)

Der I_STEP = 3 dient der Validierung aller erfassten Variablenwerte. Im I_STEP = 3 stehen alle bisher erfassten Werte im Parameter I_T_VAR_RANGE zur Validierung zur Verfügung.

Der Parameter I_T_VAR_RANGE enthält nur die Variablen die einen Wert enthalten. D.h. hier sind nur Variablen enthalten die:

  • Einen Default Wert haben oder
  • Für die per Implementierung (I_STEP = 1 oder I_STEP = 3) ein Wert erfasst wurde oder
  • Der Anwender hat im Variablendialog einen Wert eingegeben

Im I_STEP = 3 können die Werte der einzelnen Variablen nicht verändert werden. Es besteht die Möglichkeit Nachrichten (Messages) zu generieren die mit dem Berichts-Ergebnis angezeigt werden. Für den Fall, dass die Validierung der Variablen dazu führt, dass es keinen Sinn macht den Bericht auszuführen kann durch das Werfen einer Exception (RAISE EXCEPTION) verhindert werden, dass der Bericht ausgeführt wird. Die Exception führt dazu, dass der Anwender erneut zum Variablendialog gelangt.

Figure 1.5 zeigt wie im I_STEP = 3 die Werte für die beiden Variablen ZYEARFROM und ZYEARTO ermittelt und anschließend verglichen werden. Ist der FROM Wert größer als der TO Wert wird eine Meldung ausgegeben und mit der Anweisung RAISE wrong_value verhindert, dass der Bericht ausgeführt wird. Der Anwender hat so die Möglichkeit den Wert im Variablendialog zu korrigieren.

Figure_1_5

Figure 1.5: Validierung – Customer Exit

Figure 1.6 zeigt analog zu dem Beispiel in Figure 1.5 wie im objektorientierten Kontext das Ausführen des Berichtes verhindert werden kann. Die Exception muss hier im objektorientierten Kontext geworfen werden.

Figure_1_6

Figure 1.6: Validierung – BAdI

1.3      Ausführungsreihenfolge der I_STEP

Figure 1.7 zeigt die Aufrufreihenfolge der einzelnen I_STEP’s im Rahmen eines BEx Reports. Ich unterscheide hier die beiden Phasen:

  • Präparation (Preparation Phase) und
  • Validierung (Validation Phase)

Die I_STEP’s der Präparation Phase werden vor dem Variablendialog durchlaufen und die I_STEP’s der Validierungsphase werden nur dann durchlaufen wenn die Werte der eingabebereiten Variablen im Variablendialog ändern.

Figure_1_7

Figure 1.7: Verarbeitung von Exit-Variablen (I_STEP’s)

Das heißt der aufrufende SAP Standard Verarbeitungsprozess geht zunächst davon aus, dass der Anwender die Default Werte des Variablendialoges ohne zu verändern akzeptiert. In diesem Fall wird die Validierungsphase nicht noch einmal durchlaufen!

Die Prozessschritte der Validierungsphase werden nur dann durchlaufen wenn die Werte im Variablendialog vom Anwender geändert wurden.

1.4      Verarbeitungsprozess von Exit Variablen

Mit BW 7.3 wurde der BAdI RSROA_VARIABLES_EXIT_BADI eingeführt und dem Customer Exit EXIT_SAPLRRS0_001 vorgestellt. Der Blog Koexistenz von BAdI RSROA_VARIABLES_EXIT_BADI und Customer-Exit EXIT_SAPLRRS0_001 zeigt auf wie der BAdI und der Customer Exit sich in einem BW 7.3 System verhalten.

Figure 1.8 zeigt die einzelnen Verarbeitungsblöcke die im Rahmen der Variablenverarbeitung von Exit Variablen durchlaufen werden.

Figure_1_8

Figure 1.8: Variablen Verarbeitung

Der Standard Verarbeitungsprozess prüft zunächst ob eine aktive BAdI Implementierung vom Type RSROA_VARIABLES_EXIT_BADI vorhanden ist. Als Filterwert wird hier der technische Name des InfoObjektes verwendet auf dem die Exit-Variable basiert die aktuell verarbeitet wird. Aus technischer Sicht erfolgt diese Prüfung innerhalb des Funktionsbausteins RRS_VAR_EXIT mittels GET BADI.

Der Blog BAdI RSROA_VARIABLES_EXIT_BADI beschreibt den Verarbeitungsprozess des BAdI‘s im Detail.

1.5      Überschreiben von eingegebenen Werten

Das Grundprinzip für eingabebereite Variablen war zunächst, dass vom Anwender eingegebene Werte nicht überschrieben werden dürfen. Eine eingabebereite Variable wird per Standard nach dem Variablendialog nicht mehr als Einzelvariable prozessiert.

Im I_STEP = 3 kann die Variable zwar validiert aber nicht mehr geändert werden. Wird im Rahmen der Validierung festgestellt, dass der vom Benutzer eingegebene Wert nicht sinnvoll ist kann im I_STEP = 3 eine Meldung generiert werden die den Anwender darüber informiert. Zusätzlich kann eine Exception geworfen werden. Die Exception sorgt dafür, dass der Variablendialog erneut erscheint.

Mit Einführung des Parameters E_CHECK_AGAIN (siehe Hinweis 1272242 – Erneute Variablenverprobung im I_STEP = 2) wurde das Konzept aufgehoben. Der Parameter erlaubt es dem Entwickler dem vom Anwender eingegebenen Wert einer eingabebereite Variable nach dem Variablendialog im I_STEP = 2 bei Bedarf zu überschreiben.

Wie in Abschnitt 1.2 »Verarbeitungsschritte (I_STEP)« beschrieben wird eine eingabebereite Variable nur im I_TEP = 1 und I_STEP = 3 verarbeitet, wobei der Wert nur im I_STEP = 1 verändert (initialiesiert) werden kann. Um zu erreichen, dass eine eingabebereite Variable im I_STEP = 2 noch einmal verarbeitet wird muss im I_STEP = 1 für diese Variable der Export Parameter E_CHECK_AGAIN (E_CHECK_AGAIN = ‘X‘) gesetzt werden. Ist der Parameter E_CHECK_AGAIN gesetzt so wird diese eingabebereite Variable nach dem Variablendialog analog zu einer nicht eingabebereiten Variablen im I_STEP = 2 verarbeitet.

Name des Berichtes in Exit-Variablen für die Berechtigung verwenden – Nachtrag

Im Block Name des Berichtes in Exit-Variablen für die Berechtigung verwenden habe ich aufgezeigt wie der Name eines Berichtes bei der Verarbeitung von Exit-Variablen im Rahmen der Berechtigung verwendet werden kann.  In diesem Block zeige ich auf weche Einschränkungen hierbei zu berücksichtigen sind.

Der Customer Exit wird im Rahmen der Berechtigung zweimal durchlaufen. Im ersten Durchlauf ist das Feld COMPID im Memory noch nicht verfügbar und der Aufruf

IMPORT compid = l_compid FROM MEMORY ID 'COMPID'.

liefert für l_compid nichts zurück. Mit folgendem Coding soll erreicht werden, dass alle Benutzer des Berichtes ‘ZTKE_EXIT_VAR_AUTH’ nur die Informationen zum Land Deutschland (DE) erhalten.

METHOD if_rsroa_variables_exit_badi~process.
  DATA: l_compid TYPE rszcompid,         
        ls_range TYPE rrrangesid.   
  
  IMPORT compid = l_compid FROM MEMORY ID 'COMPID'.   

  CASE l_compid .     
    WHEN 'ZTKE_EXIT_VAR_AUTH'.       
         ls_range-sign = 'I'.       
         ls_range-opt = 'EQ'.       
         ls_range-low = 'DE'.       
         APPEND ls_range TO c_t_range.      
     …   
  ENDCASE. 
ENDMETHOD.

Der erste Aufruf im I_STEP = 0 ermittelt noch keine COMPID und somit wird kein Wert für die hier prozessierte Exit Variable im Rahmen der Berechtigung zurück geliefert. Beim zweiten Aufruf kann die COMPID ermittelt werden und die Berechtigung wird auf DE eingeschränkt.

Der erste Aufruf hat zur Folge, dass wir bei der Ausführung des Berichtes die Warnung

You do not have analysis authorization for any char. values of char. 0COUNTRY

bekommen, siehe Figure 2.1. Die Berechtigung

Per Default werden im Rahmen der Berechtigungsprüfung die ermittelten Variablen Werte gepuffert. Um zu erreichen, dass die Werte im zweiten Durchlauf ausgewertet werden kann die Pufferung in der RSECADMIN (siehe Figure 2.1) abgeschaltet werden. Dies ist aber nur systemweit möglich!

Figure_2_1

Figure 2.1: Variablen Pufferung deaktivieren

Nachdem die Pufferung abgeschaltet wurde bekommen wir keine Warnungen bezgl. der fehlenden Analyseberechtigung mehr.

Leider gibt es hier auch keine Alternative zum Abschalten des Puffers. Das Analyseberechtigungskonzept besagt ganz klar, dass eine Analyseberechtigung an den Daten und nicht am Reporting Objekt festgemacht werden soll.

Fast alles ist leichter begonnen als beendet

Fast alles ist leichter begonnen als beendet  (Johann Wolfgang von Goethe)

Nach nun mehr als 5 Jahren als Trainer und Verantwortlicher für die Weiterentwicklung des SAP Education Kurses BW Backend und Programming (PDEBWP) endet dieser Abschnitt im November 2014 für mich.

Ob der Kurs weiter geht kann ich aktuell noch nicht sagen. Seitens SAP Education ist es geplant den Kurs weiter zu führen und auch zu aktualisieren.

Mir hat der Kurs immer sehr viel Spaß gemacht. Es gab viele sehr interessante Frage von sehr fitten Teilnehmern, eine Vielzahl sehr guter Anregungen und eine Menge sehr interessanter Gespräche.

Auch ich habe viel durch die kontinuierliche Weiterentwicklung des Kurses gelernt. Insbesondere die Hinweise , Anregungen und Verbesserungsvorschläge vieler Teilnehmer haben mir und dem Kurs geholfen.

Hierfür sage ich Danke.

Ich persönlich finde es schade, dass ich den Kurs nicht weiter halten kann. Dennoch möchte ich versuchen gute Ideen und Konzepte weiter zu teilen. Hierzu möchte ich diesen Blog und das SCN (http://scn.sap.com) in Kombination nutzen. Dennoch wird mir die Face-to-Face Kommunikation fehlen.

Als Trainier wurde ich häufig gefragt warum die SAP immer weniger deutschsprachige Unterlagen anbietet. Viele Teilnehmer hätten die Unterlagen gerne auf Deutsch. Daher werde ich meinen Blog Einträge hier auf Deutsch verfassen und im SCN übersetzt zur Verfügung stellen.

Mein Plan ist es hier zunächst erst einmal Blog Einträge zu interessanten Einzelthemen zu verfassen, wie:

Dann mal gucken was die Zeit so bringt.

Name des Berichtes in Exit-Variablen für die Berechtigung verwenden

Im Rahmen der Berechtigungsprüfung fürs Reporting‘s können die berechtigungsrelevante Werte unter anderem mit Hilfe von Exit-Variablen ermittelt werden. Es kommt vor, dass die Anforderungen aus dem Business es erfordern, dass bei der Ermittlung der Werte innerhalb der Exit-Implementierung der Bericht in dem die Daten dargestellt werden sollen berücksichtigt werden sollen. D.h. wenn User A sich die Daten über den Bericht X anschaut soll er für andere Werte berechtigt sein als wenn er die gleichen Daten über Bericht Z anschaut.

Das SAP BW Berechtigungskonzept sieht die Berücksichtigung des Berichts bei der Ermittlung der berechtigungsrelevanten Daten nicht vor. Aus diesem Grund wird der Name des Berichtes auch nicht über das Cuxtomer-Exit Interface übergeben. Das heißt der Parameter der den Berichtsnamen normalerweise im Customer Exit für Exit-Variablen bereitstellt ist bei der Verarbeitung von Exit Variablen im Rahmen der Berechtigung initial.

Im Folgenden möchte ich das Verhalten an einem Beispiel aufzeigen. Des Weiteren möchte ich einen alternativen Weg aufzeigen wie man den Namen des aktuellen Berichtes ermitteln kann.

Das Merkmal 0COUNTRY wird über eine Exit Variable innerhalb der Berechtigungsprüfung gefiltert. Figure 1.1 zeigt die Definition der Berechtigung ZTKE_AUTH01. Zur Ermittlung der entsprechenden Werte wird die Exit-Variable ZTKE_COUNTRY verwendet.

Figure_1_1
Figure 1.1: Definition der Berechtigung

Figure 1.2 zeigt die Verwendung der Berechtigung in der Rolle.

Figure_1_2

Figure 1.2: Definition der Rolle

In meinem Beispiel lege ich die Implementierung nicht in dem Customer Exit EXIT_SAPLRRS0_001 (Erweiterung – RSR00001 BI: Enhancements for Global Variables in Reporting) an, sondern nutze hier den mit SAP BW 7.30 neu eingeführten BAdI RSROA_VARIABLES_EXIT_BADI.

Für die neue Implementierung des BAdIs RSROA_VARIABLES_EXIT_BADI definiere ich als Filter IODBJNM = 0COUNTRY. Die Filter-Kombination IOBJNM = ‘‘ benötigen wir hier nicht, da uns der I_STEP = 3 nicht interessiert. Nur im I_STEP = 3 ist der Parameter IOBJNM nicht gepflegt. Exit-Variablen die im Rahmen der Berechtigung zum Einsatz kommen werden im I_STEP = 0 prozessiert und hier ist der Parameter IOBJNM gepflegt. Figure 1.3 zeigt im oberen Teil die verwendete Filterkombination.

Figure_1_3

Figure 1.3: BAdI Implementierung

Die untere Abbildung in Figure 1.3 zeigt auf wie der Name des Reports ermittelt werden kann. Bei der Verarbeitung im I_STEP 1, 2 und 3 steht der Name des Reports in dem Feld COMPID der Struktur I_S_RKB1D. Im I_STEP = 0 ist das Feld aber leer. Mit Hilfe der Anweisung:

  IMPORT compid = l_compid FROM MEMORY ID 'COMPID'.

kann der Name des Reports aber zur Laufzeit ermittelt werden.

Fehler beim aktivieren eines SPOs das mit Vorlage angelegt wurde

Bei einem semantisch partitioniertes Objekt (SPO) das basierend auf einem Template Objekt angelegt wurde kann es bei der Aktivierung zu einem Fehler kommen. Figure 1.1 zeigt die Anlage eines semantisch partitioniertes DSOs. Als Vorlage wird ein DSO verwendet.

SPO_1_1

Figure 1.1: Anlage eines SPO mit Vorlage
 

Beim Aktivieren des SPOs tritt der Fehler “Not possible to create external SAP HANA view for object <SPO>00 / Message no. RS2HANA_VIEW001”.

In der Fehlermeldung wird darauf verwiesen, dass versucht wird für ein SPO (oder einen HybridProvider) eine externen SAP HANA View zu generieren.

SPO_1_2

Figure 1.2: Fehler bei der Aktivierung
 

Die Ursache für den Fehler liegt in diesem Fall an dem Vorlagen DSO.In dem Vorlagen DSO ist das Kennzeichen External SAP HANA View for reporting gesetzt, siehe Figure 1.3.

SPO_1_3

Figure 1.3: Kennzeichen External SAP HANA View for reporting im Vorlagen-Obejkt

Beim Anlegen des SPOs wird zunächst die Referenz Struktur für das SPO erzeugt. Die Referenz Struktur eines SPOs dient als Kopiervorlage für die einzelnen Partitionen des SPOs.

Bei der Anlage des Referenz Struktur des SPO Objektes <SPO>00 werden die Metadaten des Vorlageobjektes kopiert. Zu den Metadaten des Vorlageobjektes gehört auch das Kennzeichen External SAP HANA View for reporting.

Aktuell werden externen SAP HANA Views für semantisch partitioniertes Objekt (und HybridProvider) nicht unterstützt. Daher ist die Pflege des Kennzeichens im semantisch partitioniertes Objekt (siehe Figure 1.4) nicht möglich.

SPO_1_4

Figure 1.4: Eigenschaften der Referenz Struktur des SOPs
 

Wir finden das Kennzeichen HANAMODELFL (External SAP HANA view for BW object) in der Tabelle RSDODSO (Directory of all DataStores), siehe Figure 1.5. Für InfoCubes finden wir das Kennzeichen in der Tabelle RSDCUBE (Directory of InfoCubes / InfoProvider).

SPO_1_5

Figure 1.5: Kennzeichen External SAP HANA view for BW object

Damit das SPO aktiviert werden kann muss das Kennzeichen HANAMODELFL für die Referenz Struktur des SPOs entfernt werden. Die Referenz Struktur hat die Namenkonventiuon <SPO-Name>00. Alternativ kann die Referenz Struktur über den Namen des SPOs in der Tabelle RSDODSO gesucht werden. Figure 1.6 zeigt beide Varianten.

SPO_1_6

Figure 1.6: Referenz Struktur des SPO in der RSDODSO suchen
 

Kennzeichen HANAMODELFL (SAP HANA View) entfernen, siehe Figure 1.7. Die Änderung nun noch speichern.

SPO_1_7

Figure 1.7: Kennzeichen HANAMODELFL (SAP HANA View) entfernen
 

Anschließend kann das SPO ohne Fehler aktiviert werden.

Koexistenz von BAdI RSROA_VARIABLES_EXIT_BADI und Customer-Exit EXIT_SAPLRRS0_001

Im Blog BAdI RSROA_VARIABLES_EXIT_BADI habe ich aufgezeigt wie Exit-Variablen unter Verwendung des BAdI RSROA_VARIABLES_EXIT_BADI verarbeitet werden können.

In diesem Blog will ich nun auf die Koexistenz von BAdI und Customer-Exit eingehen.

Zunächst sollte man immer überlegen, benötige ich den neuen technischen Weg den SAP mir hier zur Verfügung stellt oder kann ich auch mit dem (Customer-Exit) Leben!?

1.1 Strukturierung des Customer-Exits

Der Customer-Exit für BEx Variablen war schon immer ein guter Kandidat für unstrukturiertes, umfangreiches und historisch (häufig auch hysterisch) gewachsenes Coding. Das liegt zum einen daran, dass der Exit (Include ZXRSRU01) in der Regel von viele unterschiedliche Entwickler (häufig auch kurzfristig eingekaufte externe Berater) mit unterschiedlichen Programmieransichten (Funktional oder Objektorientier) bearbeitet wird. Nicht selten bringen diese ihre Verfahren und Ansätze zur Strukturierung des Customer-Exits (Aufruf dynamischer Funktionsbausteine / Methoden, Schachtelung von Includes, …) aus anderen Projekten mit ein.

Ein weiterer Grund der eine Strukturierung des Customer-Exits so kompliziert macht ist die Verschachtelung von zwei Fallunterscheidungen. Zum einen muss nach dem aktuellen Prozessschritt, dem I_STEP, und zum anderen nach der zu verarbeitenden Variable unterschieden werden. Diese verschachtelte Verzweigung macht nahezu unmöglich den Exit zu strukturieren.

Aus diesem Grunde haben sich bei Kunden inzwischen eine Menge unterschiedlicher Verfahren entwickelt wie man dem Problem begegnen kann. Folgende Verfahren findet man in der Praxis (teilweise leicht modifiziert):

–       Verschachtelte Includes

Die Implementierungen der einzelnen Fachbereiche werden hierbei in Includes ausgelagert und der Include ZXRSRU01 enthält nur noch die einzelnen Fachbereich-spezifischen Includes.

–       Dynamischer Aufruf von Funktionsbausteinen

Für jede Variable wird ein Funktionsbaustein angelegt. Mittels festgelegter Namenskonvention kann der Name des Funktionsbausteins aus dem Namen der Variablen abgeleitet und somit dynamisch aufgerufen werden.

–       Dynamischer Aufruf von Methoden von ABAP-OO Klassen

Für jede Variable wird eine Methode angelegt. Mittels festgelegter Namenskonvention kann der Name der Methode aus dem Namen der Variablen abgeleitet und somit dynamisch aufgerufen werden. Analog zum Verfahren beim Funktionsbaustein. Bei diesem Verfahren werden die fachlich zusammengehörenden Variablen / Methoden häufig in einer Klasse zusammengefasst. Das macht die Verknüpfung der Variablen mit der entsprechenden Methode zwar etwas aufwändiger hat aber den Vorteil, dass Hilfsmethoden in der Klasse leicht wiederverwendet werden können.

Häufig haben Kunden viel Arbeit in die Entwicklung eines solchen Konzeptes investiert und eine Migration in Richtung des BAdI RSROA_VARIABLES_EXIT_BADI wird durch diese Verfahren erschwert. Darum ist es wichtig, dass zunächst geklärt ist ob die Verwendung des neuen BAdI auch soviel Mehrwert bringt, dass sich der Migrationsaufwand lohnt.

Um zu verstehen wo der Mehrwert der Verwendung des BAdI’s gegenüber dem Customer-Exit liegt will ich hier die Verwendung und die interne Verarbeitung von Exit-Variablen und das zusammenspeil von dem BAdI RSROA_VARIABLES_EXIT_BADI und dem Customer-Exit noch einmal kurz beschreiben.

1.2     Interne Verarbeitung von Exit-Variablen

Um den internen Verarbeitungsprozess zu verstehen ist es zunächst notwendig zu verstehen wie der BAdI RSROA_VARIABLES_EXIT_BADI funktioniert.

Bei dem BAdI RSROA_VARIABLES_EXIT_BADI handelt es sich um einen „neuen“ BAdI. Neue BAdIs sind in Erweiterungsspots organisiert. Da in der Regel der BAdI Name und nicht der Erweiterungsspots bekannt sind steige ich immer über den BAdI Builder (Transaktion SE18) zur Bearbeitung von BAdI Implementierungen ein.

Des Weiteren ist der BAdI RSROA_VARIABLES_EXIT_BADI ist ein Filter basierter BADI. Als Filter verwendet der BAdI das InfoObjekt das die Basis für die BEx Variable bildet.

Figure 1.1 zeigt auf der linken Seite den SAP Code zur Verarbeitung von Variablen. Handelt es sich bei der aktuell zu verarbeitenden Variablen um eine Exit-Variable wird mittels

GET BADI variable_exit
  FILTERS           
    iobjnm = i_iobjnm.

geprüft ob eine aktive BAdI Implementierung existiert bei der die Filtereinstellungen mit dem InfoObjekt-Namen übereinstimmen. Das heißt der aufrufende Prozess, innerhalb der SAP Standard Variablenverarbeitung, prüft über das BAdI Framework ob für einen Filterwert eine aktive BAdI Implementierung existiert.

Wird eine aktive BAdI Implementierung gefunden wird PROCESS Methode der Klasse der BAdI Implementierung aufgerufen:

CALL BADI variable_exit->process         
  EXPORTING           
    i_vnam        = i_vnam           
    i_vartyp      = i_vartyp           
    i_iobjnm      = i_iobjnm           
    i_s_cob_pro   = i_s_cob_pro           
    i_s_rkb1d     = i_s_rkb1d           
    i_periv       = i_periv           
    i_t_var_range = i_t_var_range           
    i_step        = i_step         
  CHANGING           
    c_t_range     = e_t_range           
    c_no_screen   = e_no_screen           
    c_check_again = e_check_again           
    c_s_customer  = c_s_customer.

Die Definition des BAdIs RSROA_VARIABLES_EXIT_BADI erlaubt mehr als eine aktive Implementierung (Multible Use) zu einem Filterwert. Findet das BAdI Framework für einen Filterwert mehrere aktive Implementierungen werden alle nacheinander ausgeführt. Hierbei ist die Reihenfolge unbestimmt.

RSROA_VARIABLES_EXIT_BADI_01

Figure 1.1: Verarbeitung von Exit-Variablen

1.2      Standard Implementierung

Neben der BAdI RSROA_VARIABLES_EXIT_BADI Definition liefet SAP im Standard auch eine aktive BAdI Implementierung (SMOD_EXIT_CALL) aus. Der Filterwert ( IOBJNM <> ‘‘ OR IOBJNM = ‘‘ ) dieser Implementierung ist so definiert, dass diese BAdI Implementierung immer als aktive Implementierung verwendet wird.

Die BAdI Implementierung SMOD_EXIT_CALL ist in Release 7.30 als Default Implementation gekennzeichnet. Das hat zur Folge, dass diese Implementierung nur aufgerufen wird wenn keine andere aktive Implementierung gefunden wird. Hierbei muss beachtet werden, dass der Filterwert bei der Ermittlung der aktiven Implementierungen berücksichtigt wird.

Ich will das an einem kleinen Beispiel veranschaulichen. Im Rahmen eines Migrationsprojektes wollen wir die Verarbeitung der Exit-Variablen von der Verarbeitung im Customer-Exit auf die BAdI basierte Variante umstellen. Das Migrationsprojekt kann aber auf Grund des Umfangs nicht in einem Big-Bang umgesetzt werden. So dass einige Variablen im Customer-Exit und einige im BAdI verarbeitet werden.

Variablen und Basis InfoObjekte:

–       ZTKE_TODAY (0CALDAY)

–       ZTKE_YESTERDAY (0CALDAY)

–       ZTKE_CURWEEK (0CALWEEK)

BAdI Implementierungen für Variablen und die Filter

–       SMOD_EXIT_CALL [Default Implementierung]

o   BAdI Impl.: SMOD_EXIT_CALL

o   Filter:  IOBJNM <> ‘‘ OR IOBJNM = ‘‘

–       TKE_TODAY

o   BAdI Impl.:      ZTKE_IMPL_CALDAY

o   Filter:  IOBJNM = ‘0CALDAY‘ OR IOBJNM = ‘‘

–       ZTKE_YESTERDAY

o   Verarbeitung findet im Customer-Exit statt!

Query und Variable

–       ZTKE_Q_DAY (ZTKE_TODAY)

–       ZTKE_Q_WEEK (ZTKE_CURWEEK)

–       ZTKE_Q_YDAY (ZTKE_YESTERDAY)

Verarbeitung Query ZTKE_Q_DAY

Zunächst betrachten wir die Verarbeitung im I_STEP = 1.

Beim Aufruf der Query ZTKE_Q_DAY ermittelt die Standard SAP Verarbeitung alle aktiven Implementierung zu dem Filter 0CALDAY die nicht als Default Implementierung gekennzeichnet sind.

GET BADI variable_exit         
  FILTERS           
    iobjnm = i_iobjnm.

Hier findet das BAdI Framework nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter: IOBJNM = ‘0CALDAY‘ ).

Im I_STEP = 3 findet das BAdI Framework wieder nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter: IOBJNM = ‘‘ ). Im I_STEP = 3 stehen alle Variablen zur Validierung (i_t_var_range) zur Verfügung. Die Parameter i_vnam und i_iobjnm sind im I_STEP = 3 initial.

Verarbeitung Query ZTKE_Q_YESTERDAY

Auch hier betrachten wir zunächst die Verarbeitung im I_STEP = 1.

Beim Aufruf der Query ZTKE_Q_YESTERDAY ermittelt die Standard SAP Verarbeitung alle aktiven Implementierung zu dem Filter 0CALDAY die nicht als Default Implementierung gekennzeichnet sind.

GET BADI variable_exit         
  FILTERS           
    iobjnm = i_iobjnm.

Hier findet das BAdI Framework nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter è IOBJNM = ‘0CALDAY‘ )! Wir wollen aber die Verarbeitung im Customer-Exit nutzen. Dies kann der Fall sein wenn, wie in unserem Beispiel, die Verarbeitung für diese Variable noch nicht migriert haben. Weiter unten zeige ich wie dies umgesetzt werden kann.

Im I_STEP = 3 findet das BAdI Framework wieder nur die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter è IOBJNM = ‘‘ ). Hier gilt das gleiche wie im I_STEP = 1.

Verarbeitung Query ZTKE_Q_WEEK

Auch hier betrachten wir zunächst die Verarbeitung im I_STEP = 1.

Beim Aufruf der Query ZTKE_Q_WEEK ermittelt die Standard SAP Verarbeitung alle aktiven Implementierung zu dem Filter 0CALWEEK die nicht als Default Implementierung gekennzeichnet sind.

GET BADI variable_exit         
  FILTERS           
    iobjnm = i_iobjnm.

Hier findet das BAdI Framework keine aktive Implementierung die nicht als Default Implementierung gekennzeichnet ist!

Die Default Implementierung SMOD_EXIT_CALL wird als aktive Implementierung verwendet.

Im I_STEP = 3 findet das BAdI Framework die BAdI Implementierung ZTKE_IMPL_CALDAY (Filter: IOBJNM = ‘‘ ).

1.3      Erkenntnis

Folgende Punkte sind zu beachten:

  • In den einzelnen Implementierungen muss der I_STEP und die aktuelle Variable geprüft werden (Verlagerter CASE)

Im Beispiel oben wird für alle Variablen die auf dem InfoObjekt 0CALDAY basieren die Implementierung ZTKE_IMPL_CALDAY als aktive Implementierung herangezogen. D.h. innerhalb der Implementierung muss analog zum Customer-Exit eine Fallunterscheidung nach der aktuell zu verarbeitenden Variable unterschieden werden. Die Fallunterscheidung wird hier in der Regel mit Hilfe der CASE Anweisung umgesetzt.

  • I_STEP 0,1,2 und dem Sonderfall I_STEP = 3

Analog zum Variablennamen muss innerhalb der Implementierungen der I_STEP unterschieden werden.

Der I_STEP = 3 stellt hier einen Sonderfall da. Im I_STEP = 3 stehen alle Variablen zur Validierung zur Verfügung und die Parameter I_VNAM und I_IOBJNM sind initial. D.h. eine Fallunterscheidung nach dem Variablennamen ist hier nicht möglich.

Bei der Verarbeitung des I_STEP = 3 werden alle BAdI Implementierungen als aktive Implementierungen aufgerufen die im Filter IOBJNM = ‘‘ enthalten. D.h. es muss hier eine Unterscheidung nach der aktuell zu verarbeitenden Query erfolgen. Die aktuelle Query kann aus der Komponente COMPID der Struktur I_S_RKB1D ermittelt werden.

  • Mit Release 7.30 ist es nicht ohne weiteres Möglich eine BAdI Implementierung und parallel den Customer-Exit zu nutzen
  • Ab Release 7.40 SPS09 können BAdI und Customer-Exit ohne weiteres parallel verwendet werden. Für 7.40er Systeme vor SPS09 muss der Hinweis 2036773 implementiert werden

2      Koexistenz mit Release 7.30

In einem SAP BW /.3 System können der BAdI RSROA_VARIABLES_EXIT_BADI und der Customer-Exit EXIT_SAPLRRS0_001 nicht ohne weiteres parallel betrieben werden, siehe Beispiel oben. Um sicher zu stellen, dass der Customer-Exit immer durchlaufen wird ist es notwendig hierfür eine eigene BAdI Implementierung an zu legen. Für die BAdI Implementierung werden die Filterwerte analog zur SAP Standard Implementierung festgelegt.

Figure 2.1 zeigt eine BAdI Implementierung zum aufrufen des Customer-Exits.

BAdI-Implementierung

Figure 2.1: BAdI Definition für Customer-Exit

Figure 2.2 zeigt die Filterwerte der BAdI IMplementierung.

BAdI-Filter

Figure 2.2: Filterwerte der BAdI Implementierung

Listing 2.1 zeigt die Implementierung der PROCESS Methode der BAdI Implementierung. Innerhalb der Implementierung wird der Aufruf an den Customer-Exit weitergereicht. Hierbei ist zu beachten dass sichergestellt werden muss dass eventuell bereits ermittelte Wert nicht wieder gelöscht werden.

Der Parameter E_T_RANGE des Funktionsbausteins ist ein reiner Export Parameter, d.h. wenn der Parameter C_T_RANGE bereits in einer anderen BAdI Implementierung gefüllt wurde muss dieser Wert vor dem Aufruf des Exits gesichert werden.

METHOD if_rsroa_variables_exit_badi~process.   
  DATA: lt_range_tmp TYPE rsr_t_rangesid.   

  IF c_t_range IS NOT INITIAL.     
    APPEND LINES OF c_t_range TO lt_range_tmp.   
  ENDIF.   

  CALL FUNCTION 'EXIT_SAPLRRS0_001'     
    EXPORTING       
      i_vnam        = i_vnam       
      i_vartyp      = i_vartyp       
      i_iobjnm      = i_iobjnm       
      i_s_cob_pro   = i_s_cob_pro       
      i_s_rkb1d     = i_s_rkb1d       
      i_periv       = i_periv       
      i_t_var_range = i_t_var_range       
      i_step        = i_step     
    IMPORTING       
      e_t_range     = c_t_range 
*  E_MEEHT       =
*     E_MEFAC       =
*     E_WAERS       =
*     E_WHFAC       =       
     e_no_screen   = c_no_screen       
     e_check_again = c_check_again     
   CHANGING       
     c_s_customer  = c_s_customer.   
   
  IF lt_range_tmp IS NOT INITIAL.     
    APPEND LINES OF lt_range_tmp TO c_t_range.   
  ENDIF.

ENDMETHOD.

Listing 2.1: Implementierung der PROCESS Methode