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

Dieser Beitrag wurde unter SAP abgelegt und mit , , , , , , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar