1.1 Eclipse Views des neuen Transformation Editors

Der neu Eclipse basierte Transformations -Editor, siehe Abbildung 1.1, ist Teil der BW Perspektive (). Die wichtigsten Views sind:

  • der Transformation Editor (2) selbst,
  • die Properties Views (4),
  • der Outline View (3)

Abbildung 1.1 Transformations-Editor

Eine Transformation kann über unterschiedliche Wege (Project Explorer, BW Search, Data Flow, …) zur Bearbeitung im Eclipse basierten Transformations-Editor geöffnet werden. In Abbildung 1.1 habe ich die Transformation aus dem Project Explorer (1) heraus geöffnet. Die Outline view (3) bietet eine Übersicht über die Regeln einer Transformation. Hierbei sind die Regeln entsprechend des Regeltyps gruppiert.

Im Folgenden werde ich auf die einzelnen Komponenten und ihre Aufgaben:

  • Transformation Editor,
  • Properties View,
  • Outline View und
  • Weitere Views

kurz beschreiben.

1.1.1       Transformation Editor

Der Transformation Editor ist organisiert in einzelne Tab-Reiter. Die Anzahl der verfügbaren Tab-Reiter hängt vom Design der Transformation ab. Transformations-Quelle und -Ziel können ebenfalls Einfluss auf die Anzahl der Tab-Reiter haben.

Der Tab-Reiter general tab ist immer verfügbar und liefert allgemeine Information (Metadaten) zur Transformation. Zu diesen allgemeinen Metadaten gehören Informationen wie:

  • Beschreibung der Transformation,
  • Name und Beschreibung des Quellobjektes,
  • Name und Beschreibung des Zielpbjektes,

Zusätzlich können im Tab-Reiter general tab allgemeine Eigenschaften der Transformation festgelegt werden:

  • Währungen und Einheiten Umrechnungen
  • Die Runtime der Transformation (SAP HANA oder ABAP)
  • Einstellungen bzgl. der Regelgruppen,
  • Gruppierungsverhalten,

Des Weiteren können im Tab-Reiter general tab globale Routinen (Start-, End- und Expert-Routinen) angelegt und bearbeitet werden.

Die erste Regelgruppe (im SAP GUI Editor als Standard Group bezeichnet) wird im Tab-Reiter Rule tab abgebildet. In der Sektion Additional Rule Groups können zusätzliche Regelgruppen angelegt werden.

1.1.1.1       Runtime Property

Ein neues Feature der Transformation ist das Runtime Property auf dem Tab-Reiter General. Im Gegensatz zu früheren Releases (BW 7.50 und früher) muss nun die Runtime der Transformation vom Entwickler explizit bei der Anlage der Transformation festgelegt werden.

Für neu angelegte Transformationen ist die Default Runtime SAP HANA Runtime.

Der Entwickler kann hier wählen zwischen:

  • SAP HANA Runtime und
  • ABAP Runtime

Die Laufzeit (Runtime) der Transformation legt fest welche Feature innerhalb der Transformation verwendet werden können. Die Laufzeit einer Transformation kann über den Button Switch Runtime umgeschaltet werden. Viele Standard Feature und Regeltypen werden von beiden Laufzeiten unterstützt aber nicht alle. D.h. sobald ein Feature oder eine Regel verwendet wird die nicht von beiden Laufzeiten unterstützt wird kann die Laufzeit nicht mehr umgeschaltet werden. Kann die Laufzeit nicht umgeschaltet werden liefert der Fehlerversuch die Laufzeit umzuschalten eine Liste der verwendeten Feature und/oder Regeln die einen Wechsel verhindern.

Das Transformations-Framework versucht möglichst viele Features in beiden Laufzeiten zu unterstützen. Dies ist aber nicht immer möglich! Am offensichtlichsten ist dies bei den Regel bzgl. der Routinen. Eine ABAP Start Routine zum Beispiel verhindert das Umschalten von der ABAP Runtime zur SAP HANA Runtime. Analog verhindert eine AMDP Start Routine das Umschalten von der SAP HANA Runtime zur ABAP Runtime. Es gibt hier aber auch Ausnahmen, so wird die ABAP End Routine zum Beispiel unter bestimmten Bedingungen auch in der SAP HANA Runtime unterstützt, hierzu komme ich später noch wenn wir uns die Transformation im Detail anschauen.

In BW 7.50 und BW4 Version 1.0 konnte die Laufzeit (Runtime) im Data Transfer Process (DTP) ausgewählt werden, wenn die Transformation beide unterstützt. Mit BW4 Version 2.0 wurde eingeführt, dass die Laufzeit durch den DTP in Abhängigkeit der in der Transformation festgelegten Laufzeit (Runtime) ermittelt wird.

1.1.1.2       Global Routinen

Es existieren drei Arten von globalen Routinen:

  • Start – Routine,
  • End – Routine und
  • Experten – Routine

Alle drei Arten können in beiden Laufzeiten implementiert werden.

Für eine Transformation mit der Laufzeit ABAP Runtime müssen alle Routinen als ABAP Routinen implementiert werden.

Für eine Transformation mit der Laufzeit SAP HANA Runtime müssen Start- und Experten- Routinen immer als AMDP Routinen implementiert werden.

In der SAP HANA Runtime werden die Routinen als AMDP Routinen bezeichnet, in Wirklichkeit sind es aber SQLScript Routinen, ich komme später bei der Detail Beschreibung der Transformationen noch einmal auf diesen Punkt.

Die End Routine hat in der SAP HANA Runtime eine Sonderstellung. Wenn das Ziel der Transformation ein persistentes Datenziel ist (also keine InfoSource) kann die End Routine einer Transformation mit der Laufzeit SAP HANA Runtime auch in ABAP implementiert werden.

Abbildung 1.2: Spezialfall ABAP End-Routine

Alle Routinen blockieren das nachträgliche Wechseln der Laufzeit ausgenommen ist die ABAP End Routine, wenn das Ziel der Transformation ein persistentes Datenziel ist.

1.1.2       Properties View

Die PROPERTIES View, siehe Abbildung 1.1 (4) stellt kontextsensitive Informationen (Metadaten) zum aktuell markierten Objekt (Transformation, Regel) im Transformations-Editor zur Verfügung.

Die Metadaten der Transformation werden im PROPERTIES View in Reitern (Gerneral, Rules und Technical) angezeigt:

  • General
    • Paketzuordnung
    • Status Transformation
    • Informationen über den Erzeuger / Letzte Änderung
  • Rules
    • Hier werden Informationen zur aktuell selektierten Regel angezeigt
  • Technical
    • Transformation ID
    • Analysis Process
      Der HANA Analysis Process (HAP) stellt das Metadaten Objekt der HANA Laufzeit da. Der HAP ist nur verfügbar wenn die Laufzeit (Runtime) der Transformation SAP HANA Runtime ist und diese Transformation mindestens einmal aktiviert werden konnte. Wir schauen uns den HAP im Rahmen der Transformation später noch einmal im Detail an.
      Wenn der Analysis Process als aktiver Version verfügbar ist, kann mittels Vorwärts-Navigation direkt zur SAP HANA Transformation (Transaktion RSDHATR) navigiert werden.
    • Generated ABAP (Generiertes Programm)
      Analog zum Analysis Process der HANA Runtime ist das Generierte Programm das Laufzeit Objekt der ABAP Runtime.
    • Active Routine Class (A-Class)
      Die Active Routine Class oder auch *_A-Klasse ist nur in der SAP HANA Runtime verfügbar wenn mindestens eine Routine definiert ist. Die *_A-Klasse wird im Rahmen der Fehleranalyse zum Debuggen von kunde neigenem Coding benötigt, ich komme später bei der Beschreibung der Fehleranalyse noch einmal auf die *_A-Klasse zurück.

1.1.3       Outline View

Der Outline View interagiert mit dem Transformations-Editor und dem Properties View. D.h. der Outline-View zeigt zunächst die Regeln der Transformation an und kann zur Navigation genutzt werden. Die markierte Regel im Outline View wird im Transformations-Editor selektiert und die Metadaten der Regel werden im Properties View angezeigt.

1.1.4       Zusätzliche Views

Die folgenden Views stellen zusätzliche Informationen im Rahmen der Transformation zur Verfügung:

  • Problem View
    Zeigt Informationen, Warnungen oder Fehlermeldungen bei der Transformations-Prüfung oder Aktivierung auf.
  • Search View
    Zeigt Informationen der letzten Suche auf
  • ABAP Communication Log View
    Mit Hilfe des ABAP Communication Log kann die Kommunikation zwischen den BW Modellierungs-Werkzeugen, wie dem Transformation-Editor, überwacht werden.
    Wenn der ABAP Communication Log aktiv ist werden die Kommunikations-Request und Response Nachrichten zwischen den Modelling-Tools und dem ABAP Application Server mitgeschrieben und protokolliert.
  • Semantic Content View
    Der Semantic Content View zeigt die gespeicherten Modelle der bearbeiteten Objekte auf.

1.1.5      Design- und Runtime Artefakte

Beide Transformations-Laufzeiten (ABAP und HANA) haben ihre eigenen Runtime Artefakte

Für die Transformations-Laufzeit ABAP wird beim Aktivieren der Transformation das Generierte Programm (siehe Abbildung 1.3 Generated ABAP) erzeugt.

Abbildung 1.3: Transformation Runtime Artefakte

Das korrespondierende Runtime Artefakt für die SAP HANA Laufzeit ist der Analytische Prozess (siehe Abbildung 1.3 Analysis Process). Der Analytische Prozess oder auch HANA Analytical Process (HAP) oder HANA Transformation genannt kann mit Hilfe der Transaktion RSDHATR in der SAPGUI detailliert betrachtet werden.

Auf den Punkt Active Routine Class (read-only) gehe ich später bei den Routine ein.

Veröffentlicht unter SAP | Schreib einen Kommentar

1. SAP BW/4 Transformations – Editor

Mit BW/4HANA 1.0 SP08 wurde ein neuer BW/4 Transformations-Editor und neuer DTP Editor als Teil der BW Modeling Tools in Eclipse (BWMT) ausgeliefert. Beide neuen Eclipse basierten Editoren ersetzen die alten SAP GUI basierten Editoren.

Im SAP Community Netzwerk sind bereits einige Blogs und Videos zum neuen Transformations-Editor verfügbar. Für mehr Informationen siehe https://blogs.sap.com/2018/03/29/sap-bw4hana-1.0-sp-08-released/.

Dieser Blog bietet weitere Hintergrundinformationen zum Eclipse basierten Transformations-Editor. Dieser Blog versucht zusätzlich, mögliche Fallstricke hervorzuheben, und gibt Empfehlungen, um sie zu vermeiden.

Veröffentlicht unter SAP | Verschlagwortet mit | Schreib einen Kommentar

SAP BW/4 Transformationen

Vor nun über vier Jahren hatte ich im SAP Community Netzwerk die Blog Serie HANA based BW Transformation veröffentlicht. Der Fokus der Serie lag auf den damals aktuellen SAP BW Versionen BW 7.40 SP09 bis BW 7.5 SP00. Zwischenzeitlich wurde ich immer wieder gefragt ob es auch eine aktuellere Version zu BW/4 gibt bzw. geben wird. 

Geplant habe ich dies bereits seit langem aber leider ist der Aufwand recht groß und somit ist das Projekt sehr zeit intensiv. Der neue Plan sieht nun vor die neue Blog Serie nicht on-Block zu veröffentlichen sondern Thema bei Thema.  

In den nächsten Tagen werde ich zunächst den neue Eclipse basierten Transformations Editor vorstellen der ab BW/4 1.0 SP08 als Transformations Editor zum Einsatz kommt.

Veröffentlicht unter SAP | Verschlagwortet mit , , , , , , | Schreib einen Kommentar

Totgesagte leben länger

Letztes Jahr (siehe Fast alles ist leichter begonnen als beendet) habe ich noch gesagt, dass der Kurs BW Backend und Programming (PDEBWP) voraussichtlich ausläuft.

Nun geht es doch weiter!

Aktuell wird der Kurs zwar noch zum Release SAP BW 7.0 angeboten, wir arbeiten aber daran den Inhalt asap auf den neusten Stand zu bringen.

Veröffentlicht unter SAP | Schreib einen Kommentar

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

Veröffentlicht unter SAP | Verschlagwortet mit , , , , , , , , , , , , , | Schreib einen Kommentar

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.

Veröffentlicht unter SAP | Schreib einen Kommentar

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.

Veröffentlicht unter SAP | Schreib einen Kommentar

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.

Veröffentlicht unter SAP | Schreib einen Kommentar

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.

Veröffentlicht unter SAP | Schreib einen Kommentar

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.

Veröffentlicht unter SAP | Verschlagwortet mit , , , , , , , , | Schreib einen Kommentar