1.1 Eclipse Views of the new Transformation Editor

The new Eclipse-based transformation editor, see Figure 1.1, is part of the BW perspective (). The most important views are:

  • the transformation editor (2) itself,
  • the Properties Views (4),
  • the outline view (3)

Figure 1.1 Transformation Editor

A transformation can be opened in different ways (Project Explorer, BW Search, Data Flow, …) for editing in the Eclipse-based transformation editor. In Figure 1.1 I opened the transformation from the Project Explorer (1). The Outline view (3) provides an overview of the rules of a transformation. The rules are grouped according to the rule type.

In the following I will look at each of the components and their tasks:

  • Transformation editor,
  • Properties View,
  • Outline View and
  • More views

briefly describe.

1.1.1 Transformation Editor

The Transformation Editor is organized in individual tabs. The number of tabs available depends on the design of the transformation. Transformation source and destination can also influence the number of tabs.

The general tab is always available and provides general information (metadata) on the transformation. This general metadata includes information such as:

  • Description of the transformation,
  • Name and description of the source object,
  • Name and description of the target object,

In addition, general properties of the transformation can be specified in the general tab:

  • Currency and unit conversions
  • The runtime of the transformation (SAP HANA or ABAP)
  • Settings regarding the rule groups,
  • Grouping behavior,

In addition, global routines (start, end and expert routines) can be created and edited in the general tab.

The first rule group (called Standard Group in the SAP GUI Editor) is mapped in the Rule tab. Additional rule groups can be created in the Additional Rule Groups section. Runtime Property

A new feature of the transformation is the runtime property on the General tab. In contrast to earlier releases (BW 7.50 and earlier), the runtime of the transformation must now be explicitly defined by the developer when the transformation is created.

The default runtime for newly created transformations is SAP HANA Runtime.

The developer can choose between:

  • SAP HANA runtime and
  • ABAP runtime

The runtime of the transformation determines which features can be used within the transformation. The runtime of a transformation can be switched using the Switch Runtime button. Many standard features and rule types are supported by both runtimes, but not all. I.e. as soon as a feature or rule is used that is not supported by both runtimes, the runtime can no longer be switched. If the runtime cannot be switched, the error attempt to switch the runtime provides a list of the features and / or rules used that prevent a change.

The transformation framework tries to support as many features as possible in both runtimes. But this is not always possible! This is most obvious with the rules regarding the routines. An ABAP start routine, for example, prevents switching from ABAP runtime to SAP HANA runtime. Similarly, an AMDP start routine prevents switching from SAP HANA runtime to ABAP runtime. There are exceptions to this, for example, the ABAP end routine is also supported in the SAP HANA runtime under certain conditions; I will come to this later when we look at the transformation in detail.

In BW 7.50 and BW4 Version 1.0, the runtime could be selected in the Data Transfer Process (DTP) if the transformation supports both. With BW4 Version 2.0 it was introduced that the runtime is determined by the DTP depending on the runtime specified in the transformation. Global routines

There are three types of global routines:

  • Start routine,
  • End – routine and
  • Expert routine

All three types can be implemented in both runtimes. For a transformation with the runtime ABAP Runtime I have to

For a transformation with the ABAP Runtime, all routines must be implemented as ABAP routines. For a transformation with the runtime SAP HANA Runtime, start and expert routines must always be implemented as AMDP routines.

In the SAP HANA Runtime, the routines are called AMDP routines, but in reality they are SQLScript routines, I will come back to this point later in the detailed description of the transformations.

The end routine has a special position in the SAP HANA runtime. If the target of the transformation is a persistent data target (i.e. not an InfoSource), the end routine of a transformation with the SAP HANA Runtime can also be implemented in ABAP.

Figure 1.2: Special case ABAP end routine

All routines block the subsequent change of the runtime, with the exception of the ABAP end routine, if the target of the transformation is a persistent data target.

1.1.1 Properties View

The PROPERTIES view, see Figure 1.1 (4), provides context-sensitive information (metadata) on the currently selected object (transformation, rule) in the transformation editor.

The metadata of the transformation are displayed in the PROPERTIES view in tabs (General, Rules and Technical):

  • General
    • Package assignment
    • Status transformation
    • Information about the creator / last change
  • Rules
    • Information on the currently selected rule is displayed here
  • Technical
  • Transformation ID
    • Analysis Process
      The HANA Analysis Process (HAP) represents the metadata object of the HANA runtime. The HAP is only available if the runtime of the transformation is SAP HANA Runtime and this transformation could be activated at least once. We’ll look at the HAP in detail again later as part of the transformation.
      If the Analysis Process is available as an active version, you can navigate directly to the SAP HANA transformation (transaction RSDHATR) using forward navigation.
    • Generated ABAP (generated program)
      Similar to the Analysis Process of the HANA Runtime, the generated program is the runtime object of the ABAP Runtime.
    • Active Routine Class (A-Class)
      The active routine class or * _A class is only available in the SAP HANA runtime if at least one routine is defined. The * _A class is required as part of the error analysis for debugging customer-specific coding, I will come back to the * _A class later when describing the error analysis.

1.1.2 Outline View

The Outline View interacts with the Transformation Editor and the Properties View. This means that the outline view initially shows the rules of the transformation and can be used for navigation. The marked rule in the outline view is selected in the transformation editor and the metadata of the rule is displayed in the properties view.

1.1.3 Additional views

The following views provide additional information as part of the transformation:

  • Problem View
    Shows information, warnings or error messages during the transformation check or activation.
  • Search View
    Shows information from the last search
  • ABAP Communication Log View
    The ABAP Communication Log can be used to monitor communication between the BW modeling tools such as the transformation editor.
    If the ABAP Communication Log is active, the communication request and response messages between the modeling tools and the ABAP Application Server are recorded and logged.
  • Semantic Content View
    The Semantic Content View shows the saved models of the processed objects.

1.1.5      Design- and Runtime Artefacts

Both transformation runtimes (ABAP and HANA) have their own runtime artifacts

For the ABAP transformation runtime, the generated program (see Figure 1.3 Generated ABAP) is created when the transformation is activated.

Figure 1.3: Transformation runtime artifacts

The corresponding runtime artifact for the SAP HANA runtime is the analytical process (see Figure 1.3 Analysis Process). The analytical process or also called HANA Analytical Process (HAP) or HANA Transformation can be viewed in detail with the help of transaction RSDHATR in the SAPGUI.

I will go into the point Active Routine Class (read-only) later in the Routine.

Posted in SAP | Leave a comment

1. SAP BW/4 Transformation - Editor

With BW / 4HANA 1.0 SP08, a new BW / 4 transformation editor and new DTP editor were delivered as part of the BW Modeling Tools in Eclipse (BWMT). Both new Eclipse-based editors replace the old SAP GUI-based editors.

Several blogs and videos about the new transformation editor are already available in the SAP Community Network. For more information see https://blogs.sap.com/2018/03/29/sap-bw4hana-1.0-sp-08-released/.

This blog provides more background information on the Eclipse-based transformation editor. This blog also tries to highlight possible pitfalls and gives recommendations on how to avoid them.

Posted in SAP | Tagged | Leave a comment

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.

Posted in SAP | Tagged , , , , , , | Leave a comment

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.

Posted in SAP | Leave a comment

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

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: 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: 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: 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: 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: 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: 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


Programs for Activating BW Objects in a Productive System

Posted in SAP | Tagged , , , , , , , , , , , , , | Leave a comment

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: 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: 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: 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: 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: 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: 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: 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: 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.

Posted in SAP | Leave a comment

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 .     
         ls_range-sign = 'I'.       
         ls_range-opt = 'EQ'.       
         ls_range-low = 'DE'.       
         APPEND ls_range TO c_t_range.      

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: 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.

Posted in SAP | Leave a comment

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.

Posted in SAP | Leave a comment

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: Definition der Berechtigung

Figure 1.2 zeigt die Verwendung der Berechtigung in der Rolle.


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: 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.

Posted in SAP | Leave a comment

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.


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.


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.


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.


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).


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.


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.


Figure 1.7: Kennzeichen HANAMODELFL (SAP HANA View) entfernen

Anschließend kann das SPO ohne Fehler aktiviert werden.

Posted in SAP | Tagged , , , , , , , , | Leave a comment