4 User-Exits und BAdIs im Reporting

Transkript

1 4 User-Exits und BAdIs im Reporting Die bisher behandelten Exits sind zweifellos sehr mächtig und bieten Ihnen die Möglichkeit, die Daten so aufzubereiten, dass viele typische Reporting- Anforderungen damit erfüllt werden können. Jedoch gibt es immer wieder Anforderungen, die Berichte durch die Eingabe von Variablen flexibler zu gestalten. So würde beispielsweise kein SAP NetWeaver BW-Berater empfehlen, pro Kostenstelle im Unternehmen einen eigenen Bericht zu definieren, sondern die Kostenstelle als einzugebende Variable zu bestimmen. Andererseits soll diese Flexibilität aber nicht auf den Anwender abgewälzt werden, sodass er mit einer Vielzahl von Variablen überfordert wird. Daher können Sie versuchen, dem Anwender möglichst die Kostenstelle(n) vorzuschlagen, die er abhängig von seiner Position und Verantwortung vermutlich in dem Bericht sehen möchte. Im Folgenden wird daher erklärt, wie Sie durch geschickte Programmierung Variablenwerte ableiten und Vorschlagswerte setzen. Danach werden Sie sich mit virtuellen Merkmalen und Kennzahlen sowie mit dem Thema VirtualProvider auseinandersetzen. Während die Variablen die Auswahl der Werte zum Zeitpunkt der Berichtsauswertung flexibilisieren, gehen diese beiden Techniken noch einen Schritt weiter und ermöglichen es, die Daten selbst zum Berichtszeitpunkt anzupassen. Dazu ist jedoch auch eine komplexere Form der Implementierung notwendig. Abschließend lernen Sie kurz alle weiteren Techniken kennen, die mittels ABAP eine Anpassung des Reportings erlauben. 4.1 Variablen-Exit RSR00001 Der User-Exit RSR00001 enthält im Kern den Funktionsbaustein EXIT_ SAPLRRS0_001, der mehrere verschiedene Funktionen rund um die Variableneingabe erfüllt. Dieser Exit hat dasselbe Problem wie der User-Exit zur Extraktorerweiterung in Abschnitt 2.3,»User-Exit RSAP0001«: In einem typischen BW-System wächst und wächst der User-Exit. Daher sollten Sie schon zu Beginn darauf achten, dass Sie die Implementierung nicht im Include ZXRSRU01 vornehmen, sondern die Implementierung vom Include 103

2 4 User-Exits und BAdIs im Reporting lösen. Das können Sie zum Beispiel tun, indem Sie aus dem Variablennamen den Namen eines Funktionsbausteins ableiten. In der Schnittstelle des User-Exits gibt es jedoch zwei zentrale Parameter: Neben dem Namen der Variablen I_VAR ist außerdem der Aufrufschritt I_STEP entscheidend. Dabei handelt es sich um einen Zähler, denn der User-Exit wird mehrmals an insgesamt bis zu vier verschiedenen Stellen aufgerufen. Zu diesen unterschiedlichen Zeitpunkten können Sie verschiedene Funktionen implementieren. Vor der eigentlichen Behandlung der Implementierung soll deshalb zunächst der Parameter I_STEP erklärt werden: I_STEP = 1 Der erste Aufruf des User-Exits dient dazu, Vorschlagswerte zu berechnen, das heißt die Werte, die in den eingabebereiten Variablen als Vorschlag für den Benutzer angezeigt werden. Dazu wird der Exit einmal pro Variable des Typs Customer-Exit aufgerufen. Dies ist zugleich eine große Schwäche des Exits. Möchten Sie einer bestehenden Eingabevariablen nachträglich einen Vorschlagswert geben, sind Sie gezwungen, eine neue Variable vom Typ Customer-Exit anzulegen und diese eingabebereit zu machen. Es wäre wünschenswert, wenn in diesem Schritt auch die anderen eingabebereiten Variablen versorgt werden könnten. Auch wenn in diesem Schritt normalerweise Vorschlagswerte bestimmt werden, können ebenso Variablen gefüllt werden, die nicht eingabebereit sind. Dies ist jedoch nur interessant, wenn Sie die Werte in Schritt 2 benötigen, um weitere Variablen abzuleiten. I_STEP = 2 Dieser Schritt wird nicht für alle Variablen vom Typ User-Exit aufgerufen, sondern nur für die Variablen vom Typ User-Exit, die nicht eingabebereit sind. In diesem Schritt werden die endgültigen Variablenwerte bestimmt. Dazu wird für jede nicht eingabebereite Variable der User-Exit einmal aufgerufen. Sie können daher in diesem Schritt keine Eingaben des Benutzers überschreiben. Dies ist generell nicht möglich, weil ein derartiges Verhalten meist zu einer starken Verunsicherung des Anwenders führt. Daher sollten Sie entweder gar keine Benutzereingabe zulassen oder die Benutzereingabe mit einer Fehlermeldung zurückweisen. I_STEP = 3 Der dritte Schritt wird im Gegensatz zu den ersten beiden Schritten nicht pro Variable aufgerufen, sondern nur einmal insgesamt. Dabei werden Ihnen sämtliche Variableninhalte übergeben, um diese zu validieren. Sie können demnach überprüfen, ob die»periode von«kleiner gleich der 104

3 Variablen-Exit RSR »Periode bis«ist, wenn sie nicht als Intervall, sondern in zwei verschiedenen Variablen eingegeben werden. Diese Technik ist für eine flexible Validierung unerlässlich, das heißt eine Überprüfung, ob die Eingabewerte zueinander passen, jedoch für eine saubere Trennung nach Querys oder wenigstens Projekten hinderlich, da Variablen möglichst projektübergreifend verwendet werden sollten, um ihre Anzahl zu reduzieren. Daher müssen Sie ein anderes Feld verwenden, um eine Trennung in der Implementierung zu erreichen. I_STEP = 0 Der Schritt 0 wird nur selten eingesetzt. Er wird bei allen Aufrufen verwendet, die nicht in Zusammenhang mit dem Variablenbild stehen. In SAP NetWeaver 7.x und in SAP BW 3.x gibt es dazu drei Anwendungen: Zum einen nutzen Sie diesen Schritt, wenn Variablen im InfoPackage für die Selektion verwendet werden. Zum anderen wird der Schritt für die Bestimmung der Filterwerte im Navigationsblock der Query angewendet. Zum dritten und vielleicht wichtigsten dient er dazu, Variablen zu füllen, die in Berechtigungen genutzt werden. Dies ist besonders dann nützlich, wenn Berechtigungen aus Tabellen gefüllt werden sollen, die in ein DataStore-Objekt geladen wurden, oder wenn die Berechtigungen aus Stammdaten abgeleitet werden sollen. In diesem Buch wird ausschließlich der letzte Fall behandelt, da die anderen Fälle in der Praxis zu selten vorkommen Interface des Funktionsbausteins EXIT_SAPLRSR0_001 Nachdem die Bedeutung des Parameters I_STEP geklärt ist, lernen Sie die komplette Schnittstelle kennen. Der Kopf des Funktionsbausteins sieht dabei wie in Listing 4.1 aus. FUNCTION EXIT_SAPLRRS0_001. *" *"*"Lokale Schnittstelle: *" IMPORTING *" VALUE(I_VNAM) LIKE RSZGLOBV-VNAM *" VALUE(I_VARTYP) LIKE RSZGLOBV-VARTYP *" VALUE(I_IOBJNM) LIKE RSZGLOBV-IOBJNM *" VALUE(I_S_COB_PRO) TYPE *" RSD_S_COB_PRO *" VALUE(I_S_RKB1D) TYPE *" RSR_S_RKB1D 105

4 4 User-Exits und BAdIs im Reporting *" VALUE(I_PERIV) TYPE *" RRO01_S_RKB1F-PERIV *" VALUE(I_T_VAR_RANGE) TYPE *" RRS0_T_VAR_RANGE *" VALUE(I_STEP) TYPE I DEFAULT 0 *" EXPORTING *" VALUE(E_T_RANGE) TYPE RSR_T_RANGESID *" VALUE(E_MEEHT) LIKE RSZGLOBV-MEEHT *" VALUE(E_MEFAC) LIKE RSZGLOBV-MEFAC *" VALUE(E_WAERS) LIKE RSZGLOBV-WAERS *" VALUE(E_WHFAC) LIKE RSZGLOBV-WHFAC *" CHANGING *" VALUE(C_S_CUSTOMER) TYPE *" RRO04_S_CUSTOMER OPTIONAL *" Listing 4.1 Schnittstelle des Funktionsbausteins EXIT_SAPLRSR0_001 Die einzelnen Parameter haben dabei folgende Bedeutung: I_VNAM Dieser Parameter enthält in Step 0, 1 und 2 den Variablennamen, der berechnet werden soll. I_VARTYP Dieser Parameter gibt in Step 1 und 2 an, um welchen Variablentyp es sich handelt, das heißt, ob als Rückgabe ein Merkmalswert, Text, Formelwert, Hierarchieknoten oder eine Hierarchie erwartet wird. I_IOBJNM Dieser Parameter gibt das InfoObjekt an, auf das sich die Variable bezieht. I_S_COB_PRO Dieser Parameter enthält verschiedene Informationen über das InfoObjekt, auf das sich die Variable bezieht. ATRNAVFL gibt beispielsweise an, ob es sich bei der Variablen um ein Navigationsattribut handelt, oder ATRTIMFL, ob das Navigationsattribut zeitabhängig ist. Des Weiteren gibt er ähnliche Informationen, die nur in speziellen Situationen benötigt werden, weil sie normalerweise zum Zeitpunkt der Programmierung feststehen und nicht verändert werden. Dieser Parameter wird deshalb nur selten benötigt. I_S_RKB1D Dieser Parameter enthält Informationen wie den Query-Namen, den Aufrufer etc. Er ist vor allem in Step 3 von Bedeutung, um zu bestimmen, welche Validierungen durchgeführt werden sollen. Wichtige Felder dafür sind INFOCUBE (der Name des InfoProviders, auf dem der Bericht ausgeführt wird) und COMPID (der Query-Name, der gerade ausgeführt wird). 106

5 Variablen-Exit RSR I_PERIV Dieser Parameter enthält die Geschäftsjahresvariante, sofern sie in der Query eindeutig bestimmt werden kann. Dies ist immer dann wichtig, wenn aus einem Datum eine Periode bestimmt, beispielsweise die aktuelle Buchungsperiode als Vorschlagswert gezeigt werden soll. Da aber nur selten mehrere unterschiedliche Geschäftsjahresvarianten in einem System vorhanden sind, wird der Parameter auch entsprechend selten benötigt. I_T_VAR_RANGE Dieser Parameter enthält eine Tabelle, die sämtliche weiteren Variablenwerte beinhaltet. Dies ist besonders in Step 2 und 3 sinnvoll. I_STEP Der Schritt für die Variablenbestimmung wurde bereits ausführlich erläutert. E_T_RANGE In dieser Tabelle müssen die Rückgabewerte in Step 0, 1 und 2 zurückgegeben werden. Sie ist im Prinzip wie eine Ranges-Tabelle aufgebaut, die weiteren Felder können ignoriert werden. Abhängig von der Art der Variablen, müssen dabei folgende Beschränkungen berücksichtigt werden: Das Feld LOW enthält bei Merkmalswertvariablen den Wert oder die Wertuntergrenze (bei Intervallen), bei Textvariablen den Text, bei Hierarchievariablen die Hierarchie, bei Knotenvariablen den Knotennamen und bei Formelvariablen den Rechenwert. Das Feld HIGH enthält bei Merkmalswertvariablen für Intervalle oder Selektionsoptionen die Obergrenze des Intervalls. Bei Hierarchieknotenvariablen beinhaltet dieses Feld das InfoObjekt des Hierarchieknotens. Dieses kann entfallen, wenn es sich bei dem Knoten um ein Blatt der Hierarchie handelt. Bei anderen Variablen ist es immer leer. Das Feld SIGN enthält in der Regel immer ein I (für include: einschließen). Einzige Ausnahme können Selektionsoptionen sein, bei denen auch ein E (für exclude: ausschließen) erlaubt ist. SAP NetWeaver Business Warehouse erlaubt ein E auch bei Intervallen. Da dies aber nicht der Logik von Intervallen entspricht, sollten Sie solche Variablen als Selektionsoptionen implementieren. Das Feld OPT wird in der Regel mit EQ (für equal: gleich) gefüllt. Bei Intervallen können Sie auch BT (für between: zwischen) oder NB (für not between: nicht zwischen) verwenden. Bei Selektionsoptionen sind sämtliche in Ranges-Tabellen zulässigen Operatoren möglich, die Sie zum Beispiel in der ABAP-Dokumentation zum Schlüsselwort IF finden können. 107

6 4 User-Exits und BAdIs im Reporting E_MEEHT, E_MEFAC, E_WAERS, E_WHFAC, C_S_CUSTOMER Diese Parameter sind in der Schnittstelle zwar angegeben, werden jedoch nicht abgefragt. Aufgrund der unterschiedlichen Bedeutungen der Schritte können Sie auch die Implementierung des Exits entsprechend vorgeben. Möchten Sie, wie bereits zu Listing 4.2 beschrieben, eine generische Vorgabe machen, die dann einzelne Funktionsbausteine aufruft, können Sie folgende Implementierung verwenden (siehe Listing 4.2): DATA: l_d_fname(30) TYPE c. CASE i_step. WHEN 1. CONCATENATE 'Z_VAR_PRE_POPUP_' i_vnam INTO l_d_fname. WHEN 2. CONCATENATE 'Z_VAR_POST_POPUP_' i_vnam INTO l_d_fname. WHEN 0. CONCATENATE 'Z_VAR_AUTHORITY_' i_vnam INTO l_d_fname. WHEN 3. l_d_fname = 'Z_VAR_CHECK_VALIDITY'. ENDCASE. TRY. CALL FUNCTION l_d_fname EXPORTING I_VNAM = i_vnam I_VARTYP = i_vartyp I_IOBJNM = i_iobjnm I_S_COB_PRO = i_s_cob_pro I_S_RKB1D = i_s_rkb1d I_PERIV = i_periv I_T_VAR_RANGE = i_t_var_range I_STEP = i_step IMPORTING E_T_RANGE = e_t_range E_MEEHT = e_meeht E_MEFAC = e_mefac E_WAERS = e_waers E_WHFAC = e_whfac CHANGING C_S_CUSTOMER = c_s_customer EXCEPTIONS OTHERS = 1. IF SY-SUBRC <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY 108

7 Variablen-Exit RSR NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4 RAISING ERROR_IN_VARIABLE. CATCH CX_SY_DYN_CALL_ILLEGAL_FUNCTION. * Nichts machen, weil kein Exit implementiert wurde, * zum Beispiel in Step 1, wenn nur Step 2 implementiert wurde. ENDTRY. Listing 4.2 Beispielimplementierung für den Variablen-Exit ZXRSRU01 Wenn Sie sich die Funktionsbausteine RSVAREXIT_* anschauen, werden Sie feststellen, dass Variablen mit einem SAP-Exit von der SAP-Entwicklung fast genauso implementiert werden, nur dass die Entwicklung nicht nach dem I_STEP unterscheidet. Sie sollten in diesem Schritt jedoch eine Unterscheidung vornehmen, da Sie auf diese Art und Weise bereits am Namen des Funktionsbausteins erkennen, wozu er gedacht ist. Haben Sie bereits in größeren BW-Systemen gearbeitet, werden Sie festgestellt haben, dass der Exit ZXRSRU01 einer der größten im System ist. Alle Änderungen an diesem Exit sind kritisch, da gegebenenfalls sämtliche Berichte davon betroffen sind. Nach Ihrem ersten Transport eines nicht syntaxfehlerfreien Exits in ein Produktivsystem werden Sie wissen, wovon hier die Rede ist. Sie sollten deshalb von Anfang an die Beispielimplementierung übernehmen, um damit ein lästiges Problem zu vermeiden, das sich meist erst zeigt, wenn mehrere Projekte in dem System bereits produktiv laufen: einen inhaltlich getrennten Transport, um verschiedene Variablenimplementierungen zu ermöglichen. Natürlich stellt sich dann noch die Frage, wer die Verantwortung für den Funktionsbaustein Z_VAR_CHECK_VALIDITY übernimmt. Aber im Zweifelsfall können Sie in diesem Baustein aus jedem Projekt heraus einen zentralen Funktionsbaustein aufrufen und die Prüfergebnisse sammeln Implementierung bei I_STEP = 1 Nun zur eigentlichen Implementierung der Variablenlogik. Da I_STEP = 1 die Vorschlagswerte setzen soll, können Sie nur Algorithmen implementieren, die keine Benutzereingaben erfordern. Daher gibt es hauptsächlich zwei Arten von Algorithmen: eine datumsabhängige Vorschlagswertbestimmung eine tabellengesteuerte Vorschlagswertbestimmung 109

8 4 User-Exits und BAdIs im Reporting Beispiel 1: Datumsabhängige Vorbelegung Eine Variable WEEK6F soll für das InfoObjekt 0CALWEEK implementiert werden. Diese Variable ist eine Merkmalswertvariable vom Typ Intervall und soll als Vorschlagswert das Intervall von der aktuellen Woche bis in sechs Wochen erhalten. Das Coding hierzu könnte wie in Listing 4.3 aussehen. DATA: l_d_datum TYPE d, l_d_woche TYPE /bi0/oicalweek. DATA: l_s_range TYPE rsr_s_rangesid. CASE i_vnam. WHEN 'WEEK6F'. IF i_step = 1. "Vor dem Pop-up * Aktuelle Woche bestimmen CALL FUNCTION 'DATE_GET_WEEK' EXPORTING date = sy-datum IMPORTING week = l_d_woche. * Woche in Rückgabe aufnehmen l_s_range-low = l_d_woche. l_s_range-sign = 'I'. l_s_range-option = 'EQ'. * Jetzt sechs Wochen später bestimmen l_d_datum = sy-datum "42 Tage = 6 Wochen CALL FUNCTION 'DATE_GET_WEEK' EXPORTING date = l_d_datum IMPORTING week = l_d_woche. * Ende des Rückgabeintervalls füllen l_s_range-high = l_d_woche. APPEND l_s_range TO l_t_range. Listing 4.3 Beispiel zur datumsabhängigen Variablenvorbelegung Beispiel 2: Tabellenabhängige Vorbelegung Im zweiten Beispiel soll eine Variable LASTCPER die letzte im Quellsystem abgeschlossene Periode enthalten. Damit nicht bei jedem Query-Aufruf das Quellsystem mittels Remote Function Call aufgerufen wird, wurde zu diesem Zweck eine Tabelle Z_BEX_VAR angelegt, die manuell während des Monatsabschlusses gepflegt wird und aus den Feldern KEY (CHAR 20) und VALUE (CHAR 60) besteht. KEY ist dabei das einzige Schlüsselfeld der Tabelle, VALUE das Datenfeld. 110

9 Variablen-Exit RSR In dem Eintrag mit KEY = 'LASTCPER' wird dabei manuell die letzte abgeschlossene Periode gepflegt. Das Coding zur Abfrage der Tabelle sieht wie in Listing 4.4 aus. DATA: l_s_bex_var TYPE z_bex_var, l_s_range TYPE rsr_s_rangesid. CASE i_vnam. WHEN 'LASTCPER'. IF i_step = 1. "Vor Variablen-Popup * Tabelleneintrag lesen SELECT SINGLE * FROM z_bex_var INTO l_s_bex_var WHERE key = 'LASTCPER'. IF SY-SUBRC = 0. * In Rückgabe übertragen l_s_range-low = l_s_bex_var-value. ELSE. * Hier könnte man auch einen Fehler ausgeben clear l_s_range-low. l_s_range-sign = 'I'. l_s_range-opt = 'EQ'. ENDCASE. Listing 4.4 Beispiel zur tabellenabhängigen Vorbelegung Aus der gewünschten Art der Vorbelegung ergibt sich, welche Art der Implementierung Sie nutzen. Häufig wird die tabellenabhängige Vorbelegung auch für eine Vorbelegung abhängig vom Benutzernamen oder gar von bestimmten Benutzerberechtigungen verwendet. Da das Handling von Reporting- Berechtigungen nicht ganz einfach ist, wird im Folgenden noch anhand eines etwas komplexeren Beispiels gezeigt, wie Sie Reporting-Berechtigungen der Klasse RSR oder die neuen Analyseberechtigungen lesen, ohne für jeden Stammdateneintrag einen AUTHORITY-CHECK durchzuführen. Beispiel 3: Vorbelegung aus Berechtigungen Für einen Kunden, der über gesellschaftsübergreifende Geschäftsbereiche verfügt, soll ein zweidimensionales Berechtigungsobjekt implementiert werden, das die externe Unternehmensstruktur (InfoObjekt 0COMPANY) und die interne Unternehmenssicht (InfoObjekt 0BUS_AREA) in einem Berechtigungsobjekt vereint. Auf diese Weise soll die externe und die interne Sicht besser unterschieden werden. Je nach Bericht sollen die Verantwortlichen entweder alle Kosten ihrer Gesellschaft oder alle Kosten in ihrem Geschäftsbereich sehen. 111

10 4 User-Exits und BAdIs im Reporting Zweidimensionales Berechtigungsobjekt Es ist sicherlich eher eine Ausnahme, dass zwei InfoObjekte in einer Reporting- Berechtigung Verwendung finden, und vielen ist bestimmt nicht bewusst, dass dies möglich ist. Aber sowohl Reporting als auch Planung laufen in dem System einwandfrei und verproben die Berechtigungen korrekt. Daher haben zahlreiche Mitarbeiter zwei Ausprägungen des Berechtigungsobjektes, beispielsweise: 0COMPANY = 100 und 0BUS_AREA = * 0COMPANY = * und 0BUS_AREA = 1000 Dieses Konzept bereitet eine große Schwierigkeit: Ruft ein Mitarbeiter einen Bericht in der externen Sicht auf, soll ihm automatisch seine Gesellschaft 100 als Vorschlagswert eingeblendet werden. Lassen Sie die Variable jedoch aus der Berechtigung füllen, wird dem Benutzer immer die erweiterte Ausprägung * vorgeschlagen; in diesem Fall eine leere Selektion. Die Implementierung in Listing 4.5 liest die Berechtigungen und füllt den Vorschlagswert entsprechend. Dabei werden im ersten Schritt die existierenden Berechtigungen zu dem InfoObjekt 0BUS_AREA gelesen. Anschließend werden diese überprüft. Handelt es sich um eine allgemeine Berechtigung (*-Berechtigung), wird diese ignoriert. Handelt es sich um einen konkreten Geschäftsbereich, wird dieser in die Vorbelegung der Variablen zurückgegeben. DATA: v_tsx_auth_values_user TYPE rssb_tsx_auth_values_user, w_sx_auth_values_user TYPE line of rssb_tsx_auth_values_user, w_sx_auth_values_auth TYPE rssb_sx_auth_values_user_auth, w_sx_auth_values_iobjnm TYPE rssb_sx_auth_values_user_iobj, w_sx_auth_values_range LIKE rrrange, v_ts_authnode TYPE rssbr_ts_authnode, w_s_authnode TYPE line of rssbr_ts_authnode, v_authhieruid TYPE rssauthhieruid. CONSTANTS: c_zcomp_bus TYPE rssb_sx_auth_values_user-object VALUE 'ZCOMP_BUS', c_attrinm_company TYPE rssb_sx_auth_values_user_iobj-iobjnm VALUE '0COMPANY', 112

11 Variablen-Exit RSR c_attrinm_busarea TYPE rssb_sx_auth_values_user_iobj-iobjnm VALUE '0BUS_AREA'. IF i_step = 1. * Lies alle Reporting-Berechtigungen für den Benutzer * (nur InfoObjekt 0BUS_AREA) CALL FUNCTION 'RSSB_AUTHORIZATIONS_OF_USER' EXPORTING I_IOBJNM = '0BUS_AREA' I_INFOPROV = 'DEMOCUBE' I_UNAME = sy-uname I_HIENM = 'DEMOHIER' I_DATETO = sy-datum I_VERSION = '000' IMPORTING * E_T_RANGESID = E_TSX_AUTH_VALUES_USER = v_tsx_auth_values_user * E_NIOBJNM = * E_NODE = * E_TS_NODE = * E_TS_AUTH_VALUES_HIERARCHY = * E_T_MSG = EXCEPTIONS NOT_AUTHORIZED = 1 INTERNAL_ERROR = 2 USER_DOESNT_EXIST = 3 X_MESSAGE = 4 OTHERS = 5. IF sy-subrc <> 0. MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4 RAISING not_authorized. * LOOP über alle Reporting-Berechtigungen des Benutzers LOOP AT v_tsx_auth_values_user INTO w_sx_auth_values_user. * Welches Berechtigungsobjekt? CHECK w_sx_auth_values_user-object = c_zcomp_bus. * Doppelberechtigungsobjekt LOOP über alle Ausprägungen * zum Berechtigungsobjekt LOOP AT w_sx_auth_values_user-auth INTO w_sx_auth_values_auth. * Company-Ausprägung lesen READ TABLE w_sx_auth_values_auth-values_iobjnm 113

12 4 User-Exits und BAdIs im Reporting INTO w_sx_auth_values_iobjnm WITH KEY iobjnm = c_attrinm_company. IF sy-subrc = 0. * Gesellschaft gefunden LOOP AT w_sx_auth_values_iobjnm-ranges INTO w_sx_auth_values_range. IF ( w_sx_auth_values_range-sign = 'I' ) AND ( w_sx_auth_values_range-opt = 'CP' ) AND ( w_sx_auth_values_range-low = '*' ). * Existiert eine *-Berechtigung für 0COMPANY? * Geschäftsbereich bestimmen. READ TABLE w_sx_auth_values_auth-values_iobjnm INTO w_sx_auth_values_iobjnm WITH KEY iobjnm = c_attrinm_busarea. IF sy-subrc = 0. * Berechtigung zum Geschäftsbereich LOOP AT w_sx_auth_values_iobjnm-ranges INTO w_sx_auth_values_range. MOVE-CORRESPONDING w_sx_auth_values_range TO l_s_range. APPEND l_s_range TO e_t_range. ENDLOOP. "w_sx_auth_values_iobjnm_range "sy-subrc = 0 "*-Berechtigung für 0COMPANY ENDLOOP. " w_sx_auth_values_iobjnm-ranges "sy-subrc = 0 ENDLOOP. "w_sx_auth_values_user-auth ENDLOOP. "v_tsx_auth_values_user Listing 4.5 Ableitung der Berechtigungen aus speziellen Berechtigungsobjekten Implementierung bei I_STEP = 2 Im Prinzip unterscheidet sich die Implementierung von Schritt 2 nicht von der Implementierung von Schritt 1. Es gibt jedoch eine bedeutende Abweichung, die enorm wichtig ist: In Schritt 2 haben Sie die Möglichkeit, auf die Werte zurückzugreifen, die im Pop-up eingegeben wurden. Dies ist oft nötig, wenn der Benutzer einen Zeitpunkt eingibt und abhängig von dem Zeitpunkt Ableitungen getroffen werden. Dies wird im folgenden Beispiel erläutert. Beispiel 4: Zeitabhängige Versionen Der Benutzer soll in der Variablen REP_PER eine Berichtsperiode eingeben. Die Variable REP_VERS soll dann abhängig von dem Zeitpunkt der Variablen REP_PER die Werte in Tabelle 4.1 annehmen. 114

13 Variablen-Exit RSR Zeitpunkt REP_PER Periode ist abgeschlossen. Periode ist im aktuellen Jahr, aber nicht abgeschlossen. Periode ist in einem der Folgejahre. Wert REP_VERS ACT (Ist-Version) PRE (Vorschau) PLN (Planversion) Tabelle 4.1 Versionsumsetzung Die Implementierung dazu finden Sie in Listing 4.6. Dabei wird zuerst die Berichtsperiode REP_PER gelesen. Anschließend wird der letzte Tag der Berichtsperiode bestimmt. Nach den Vorgaben der Tabelle 4.1 wird dann der Rückgabewert bestimmt. DATA: l_s_range TYPE rsr_s_rangesid. DATA: l_s_var_range LIKE rrrangeexit, l_d_datum LIKE sy-datum, l_d_year TYPE /bi0/oifiscyear, l_d_per3 TYPE /bi0/oifiscper3. CASE i_vnam. WHEN 'CUMMONTH'. CLEAR l_s_range. IF i_step = 2. "Nach Pop-up * Eingabe der Variablen REP_PER lesen READ TABLE i_t_var_range INTO l_s_var_range WITH KEY vnam = 'REP_PER'. IF sy-subrc = 0. l_d_year = l_s_var_range-low(4). l_d_per3 = l_s_var_range-low+4(3). CALL_FUNCTION 'LAST_DAY_IN_PERIOD_GET' EXPORTING I_GJAHR = l_d_year I_PERIV = i_periv I_POPER = l_d_per3 IMPORTING E_DATUM = l_d_datum EXCEPTIONS OTHERS = 1. IF SY-SUBRC <> 0. * Nicht bestimmbar (fehlende * Geschäftsjahresvariante?) => Default setzen l_s_range-low = 'ACT'. ELSE. IF l_d_datum <= sy-datum. * Periode abgeschlossen l_s_range-low = 'ACT'. ELSE. CALL_FUNCTION 'FIRST_DAY_IN_YEAR_GET' 115

14 4 User-Exits und BAdIs im Reporting EXPORTING I_GJAHR = l_d_year I_PERIV = i_periv IMPORTING E_DATUM = l_d_datum EXCEPTIONS OTHERS = 1. IF sy-subrc <> 0. * Nicht bestimmbar (aber Periode war * bestimmbar?) => Default setzen l_s_range-low = 'ACT'. ELSE. IF l_d_datum > sy-datum. * Geschäftsjahr noch nicht begonnen l_s_range-low = 'PLN'. ELSE. l_s_range-low = 'PRE'. ELSE. * Variable wurde irrtümlich verwendet, sinnvollen * Default setzen (zum Beispiel ACT) l_s_range-low = 'ACT'. l_s_range-sign = 'I'. l_s_range-opt = 'EQ'. APPEND l_s_range TO e_t_range. Listing 4.6 Beispiel zur Variablenbestimmung abhängig von Eingabevariablen Typische Beispiele für die Variablenbestimmung abhängig von Eingabevariablen sind: Ableitung einer Formelvariablen aus einer eingegebenen Periode zur Hochrechnung von Jahresprognosen oder Verteilung von Jahreswerten Ableitung einer Vergleichsgruppe (zum Beispiel einer Hierarchieknotenvariablen) zu einem eingegebenen Merkmal, beispielsweise einem Profit- Center Ableitung der Unter- oder Obergrenze eines Zeitintervalls, das nicht durch eine feste Anzahl von Perioden, sondern durch andere Schranken definiert ist, zum Beispiel Quartalsanfang oder -ende Bestimmung einer berechtigungsabhängigen Formelvariablen zur Anzeige von noch nicht freigegebenen Perioden. Dabei wird abhängig von der ein- 116

15 Variablen-Exit RSR gegebenen Periode geprüft, ob die Periode schon freigegeben ist. Wenn nicht, wird eine Berechtigungsprüfung durchgeführt. Schlägt diese fehl, wird 0 zurückgeliefert, sonst 1. Die Query multipliziert daraufhin den tatsächlichen Wert mit dem Ergebnis der Formelvariablen. Ableitung von Variablen für MultiProvider. So können Sie zum Beispiel eine Variable für eine Kostenstelle abfragen und aus der Kostenstelle dann das zugeordnete Profit-Center ableiten, da in einem der beteiligten Info- Provider keine Kostenstelle, sondern nur das Profit-Center enthalten ist Implementierung bei I_STEP = 0 Step 0 ist unter anderem für die Ableitung von Variablen in Berechtigungen vorgesehen. Sie können in einer Reporting-Berechtigung einfach eine Variable verwenden, indem Sie einen Variablennamen eintragen, der mit einem Dollarzeichen ($) beginnt. Diese Variable muss vorher im Query Designer definiert worden sein. Bei der Ausführung eines Berichts wird der Exit aufgerufen, und Sie können die Bestimmung der Berechtigung in ABAP durchführen. Bei der Bestimmung der Berechtigungen wird die Rückgabetabelle wie eine Berechtigung aufgefasst, daher müssen auch hier die Einschränkungen wie bei Berechtigungen berücksichtigt werden. Dementsprechend muss SIGN immer den Wert I haben, OPT muss einen der Werte EQ oder BT annehmen. Ausschließende Berechtigungen, zum Beispiel»alle Gehälter außer den Vorstandsbezügen«, sind nicht erlaubt. Mögliche und typische Anwendungen dafür sind Ableitungen von Berechtigungen aus Tabellen oder aus Stammdaten. Auf diese Art und Weise ist es jedoch auch möglich, die Berechtigung abhängig vom aktuellen Datum zu vergeben. Eine typische Anwendung dafür zeigt das folgende Beispiel. Beispiel 5: Berechtigungen in der Quiet Period ändern In diesem Beispiel soll für eine Regionalhierarchie eine Berechtigung zeitabhängig gesteuert werden. Dabei haben alle Mitarbeiter immer die Berechtigung auf alle Regionen, nur in der sogenannten Quiet Period vom 25. eines Monats zum Quartalsende bis zum 15. des Folgemonats (im Januar bis zum 25. Januar) dürfen sie ausschließlich die Regionen sehen, die in einer Tabelle abgelegt sind. Dazu ist in ihrer Berechtigung die Variable $QREGION hinterlegt. Diese Variable wird in Listing 4.7 gefüllt. Dabei wird zuerst der aktuelle Tag bestimmt. Anschließend wird überprüft, ob der Tag in den definierten 117

16 4 User-Exits und BAdIs im Reporting Perioden liegt. Wenn ja, darf der Benutzer nur bestimmte Regionen sehen, im Übrigen darf er alles sehen. DATA: L_S_RANGE TYPE RSR_S_RANGESID. CASE i_vnam. WHEN 'QREGION'. * Datum in der Quiet Period? DATA: l_d_tag(4) TYPE n, l_s_region TYPE z_user_region. l_d_tag = sy-datum+4(4). IF ( l_d_tag <= '0125' ) OR ( ( l_d_tag >= '0325' ) AND ( l_d_tag <= '0415' ) ) OR ( ( l_d_tag >= '0625' ) AND ( l_d_tag <= '0715' ) ) OR ( ( l_d_tag >= '0925' ) AND ( l_d_tag <= '1015' ) ) OR ( l_d_tag >= '1225' ). l_s_range-sign = 'I'. l_s_range-opt = 'EQ'. SELECT * FROM z_user_region INTO l_s_region WHERE uname = sy-uname. l_s_range-low = l_s_region-region. APPEND l_s_range TO e_t_range. ENDSELECT. ELSE. l_s_range-sign = 'I'. l_s_range-opt = 'CP'. l_s_range-low = '*'. APPEND l_s_range TO e_t_range. Listing 4.7 Implementierung einer Berechtigungsvariablen Die IF-Abfrage in Listing 4.7 würde normalerweise nicht direkt in die Variable geschrieben, sondern in eine separate Check-Funktion ausgelagert, eventuell sogar in einer Customizing-Tabelle hinterlegt werden. In der Praxis würden diese Zeilen sonst regelmäßig geändert Implementierung bei I_STEP = 3 Die Implementierung bei I_STEP = 3 ist anders und etwas komplizierter als die Implementierung der anderen Schritte. Dies liegt vor allem an zwei Faktoren: Zum einen ist darauf zu achten, dass nicht in jeder Query dieselben 118