User Defined Libraries (UDL) in SQLScript

Mit SAP HANA 2.0 SPS03  wurde das Konzept der benutzerdefinierten Bibliotheken (User Defined Libraries – UDL) in SQLScript eingeführt. Es ermöglicht uns als Entwickler, mehrere Funktionen, Prozeduren und Variablen in einem Objekt zu bündeln. Alle Komponenten einer UDL werden in einem Stück Quellcode definiert und es wird auch nur ein Metadaten-Objekt dafür angelegt.

Eine Bibliothek ähnelt in einigen Punkten einer statischen Klasse in ABAP, d.h. einer Klasse, die nur Klassenmethoden und -variablen enthält. Die Sichtbarkeit von einzelnen Komponenten einer Bibliothek kann mit den Schlüsselwörtern PUBLIC und PRIVATE gesteuert werden. Die Eigenschaft PRIVATE legt fest, dass nur innerhalb der gleichen Bibliothek auf diese Komponente zugegriffen werden kann. Über PUBLIC können Sie dagegen einen freien Zugriff von außerhalb erlauben.

Die Lebensdauer der Daten einer Variablen einer UDL ist auf eine Session begrenzt. Auf öffentliche Variablen kann auch von außerhalb der Bibliothek zugegriffen werden.

Direkter Zugriff auf Komponenten

Innerhalb derselben Bibliothek können alle Komponenten direkt verwendet werden. Die Variablen der Bibliothek sind auch in allen Prozeduren und Funktionen der Bibliothek direkt sichtbar. Außerhalb der Bibliothek muss man der Komponente jeweils den Namen der UDL voranstellen:

<UDL>:<Komponente> 

Zugriff über Alias

Bis SAP HANA 2.0 SPS03 ist der Zugriff von außerhalb der Bibliothek nur innerhalb eines logischen Containers möglich. Dazu muss dort jeweils ein Alias pro Bibliothek angelegt werden, über den dann auf die Komponenten zugegriffen werden kann. Pro Bibliothek ist nur ein Aliasname möglich. Mit SPS04 wurde der direkte Zugriff erlaubt, was auch die Nutzung von Komponenten außerhalb logischer Container ermöglicht.

Das Beispiel im folgenden Listing zeigt die unterschiedlichen Arten des Zugriffs auf die Komponenten der UDL:

  • innerhalb der gleichen Bibliothek
  • außerhalb der Bibliothek über den Bibliotheksnamen
  • in einem anderen logischen Container mit Aliasnamen

Listing: Definition einer UDL mit Konstanten

In nächsten Listing sehen Sie, wie man diese dann in einer Abfrage an anderer Stelle nutzen kann. Voraussetzung hierfür ist aber natürlich die Deklaration mit dem Schlüsselwort PUBLIC.

Listing: Nutzung der Konstanten aus dem Listing 1.36

Leider gibt es bei der Nutzung von Variablen und Konstanten außerhalb der Bibliothek noch Einschränkungen, weshalb es notwendig sein kann, eine Variable aus einer Bibliothek zunächst in eine lokale Variable zu kopieren. Das ist zum Beispiel der Fall, wenn Sie einen Wert in der TOP -Klausel einer Abfrage nutzen möchten.

Anders herum ist das direkte Zuweisen einer UDL-Variablen mit  der Anweisung SELECT … INTO nicht möglich. Stattdessen muss zunächst eine lokale Variable gefüllt werden, die dann der Variablen aus der UDL zugewiesen wird.

Fazit

Insgesamt scheint Konzept der benutzerdefinierten Bibliotheken noch nicht zu 100 Prozent ausgereift. Nichtdestotrotz bietet es bereits viele nützliche Features. Es bleibt zu hoffen, dass mit dem nächsten Servicepack das Konzept weiter abgerundet wird. Auch eine Integration von UDL in das AMDP-Framework wäre wünschenswert.

Eingebettete (oder anonyme) Funktionen in SQLScript

Mit SAP HANA 2.0 SPS04 ist mit den eingebetteten Funktionen ein weiteres Feature zur Sprache SQLScript hinzugekommen. Diese ermöglichen die Verwendung von imperativem SQLScript Code innerhalb einer SELECT Abfrage. Diese Funktionen werden nur für exakt diese eine Abfrage erstellt und nur dort ausgeführt. Da diese Funktionen keinen Namen bekommen, werden sie auch als Anonyme Funktionen bezeichnet.

Im folgenden Beispiel wird die Abfrage mit einer eingebetteten Funktion innerhalb einer Prozedur aufgerufen.

  • Die eingebettete Funktion beginnt mit Zeile 11 und endet in Zeile 37. Sie enthält imperatives Coding, womit die ganze Prozedur imperativ ist.
  • Der Parameter IV_MAX der Prozedur wird in Zeile 11 an den Parameter IV_A der Funktion weitergegeben. Dieser wird dann in Zeile 24 als Obergrenze für die FOR-Schleife verwendet wird. Ein direkter Zugriff auf IV_MAX innerhalb der Funktion ist nicht möglich.
  • Die WHERE-Bedingung in Zeile 38 verdeutlicht nochmals, dass es sich um eine Abfrage handelt
  • Mit der CALL Anweisung in Zeile 41 können Sie die Prozedur testen.

Von der Verwendung von eingebetteten Funktionen rate ich grundsätzlich ab, da bereits einfache Funktionen die Lesbarkeit des Codes erheblich verschlechtern. Dies konnten Sie auch deutlich an dem gezeigten Beispiel sehen.

Als Alternative bietet sich die Anlage einer separaten UDF-Funktion an oder die Zerlegung der Abfrage in zwei Schritte:

  • Erzeugung einer Tabellenvariablen mit dem imperativen Code
  • Abfrage auf diese Tabellenvariable

Durch diese Zerlegung lässt sich der Code besser lesen. Und es ist im Debugger möglich, die Zwischenergebnisse zu betrachten. Manchmal sind diese Alternativen aber aus technischen Gründen nicht möglich. Dann erlauben uns die eingebetteten Funktionen die Nutzung von imperativem Code direkt in einer Abfrage.

SAP Dokumentation zu eingebetteten Funktionen

Rekursive Prozeduraufrufe in SQLScript

Bis SAP HANA 2.0 SPS03 waren rekursive Aufrufe Prozeduren in SQLScript nicht erlaubt. Das bedeutet, dass sich eine Prozedur weder direkt noch indirekt über andere Prozeduren aufrufen darf. Diese Einschränkung wurde mit dem SPS04 aufgehoben. Allerdings ist die Aufruftiefe auf 32 beschränkt und Prozeduren in Bibliotheken erlauben ebenfalls keine rekursiven Aufrufe. In sehen Sie ein Beispiel für die rekursive Berechnung der Fibonacci Zahlen. Bitte seien Sie vorsichtig, wenn Sie diese Prozedur mit zu großen Parametern (>20) aufrufen, kann es schnell passieren, dass das SAP HANA System an seine Grenzen kommt.

 CREATE PROCEDURE fibonacci(IN iv_value INT,
                            OUT rv_result INT)
 AS BEGIN
   DECLARE lv_tmp INT;
   
   IF iv_value IN (1, 2)
     THEN rv_result = 1;
   ELSE
     fibonacci( iv_value - 1 , rv_result );
     fibonacci( iv_value - 2 , lv_tmp );
     rv_result = rv_result + lv_tmp;
   END IF;
 END; 
  
 CALL fibonacci(20, ?); 

Listing: Rekursive Berechnung der Fibonacci-Zahlen

Hier ist der Link zur SAP Dokumentation zu dem Thema. Soweit mir bekannt ist, werden keine rekursiven Abfragen unterstützt.

Optimale Paketgröße der DTPs

Mit dem BW/4HANA 2.0 habe ich beobachtet, dass sich die Paketgröße der DTPs vom System dynamisch vorgeschlagen wird. In der Abbildung 1 sieht man beispielsweise eine vorgeschlagene Größe von 1.311.000 Datensätzen. Damit wagt sich das System in eine Größenordnung vor, die aus eigener praktischer Erfahrung besser ist, als der ehemalige fixe Standardwert von 100.000 Zeilen.

Abbildung 1: Vorschlagswert für die DTP Paketgrösse

In diesem Blogpost habe ich ein paar nützliche Informationen in Bezug auf die DTP Paketgröße zusammengetragen und diese um eine eigenes Beispiel mit einer Messreihe ergänzt.

Tatsächliche Größe der Pakete bei HANA Ausführung

Bei der HANA Ausführung von DTPs sehen wir im Monitor für jedes Paket immer nur genau eine Anzahl von Datensätzen. Bei ABAP Ausführung wurde hier für jeden Teilschritt eine Anzahl angegeben: Extraktion, Transformation, Einfügen, etc. . Diese Teilschritte lassen sich aber bei HANA Ausführung nicht mehr unterscheiden. Alle Logik aus Extraktion, Transformationsregeln, Routinen und das ggf. über mehrere Ebenen, wird in ein CalculationSzenario eingebunden, aus dem dann später gelesen wird. Und dieses Szenario wird als Ganzes optimiert. Damit haben wir keine Einzelwerte mehr für die jeweiligen Schritte. Und das erklärt auch, warum die Anzahl von Datensätzen im Monitor erst nach der Verarbeitung eines ganzen Paketes angezeigt wird, und nicht wie früher jeweils Schritt für Schritt.

Wieviele Daten tatsächlich auf einmal verarbeitet werden, hängt von mehreren Parametern ab. Die Paketgröße im DTP gibt die Anzahl der Datensätze in der Quelle an. Normalerweise werden dann N Pakete dieser Größe gebildet, das letzte der Pakete wird meistens nicht ganzu voll.

Wenn die Daten requestweise abgeholt werden, dann wird dieses Verfahren für jeden einzelnen Request wiederholt. D.h. für jeden Request gibt es ein Paket, das nicht die volle Paketgröße hat.

Wenn eine semantische Partitionierung eingestellt ist, dann werden die Daten nicht requestweise abgeholt. Statt dessen werden in jedes Paket so viele Partitionen eingefügt, bis die Paketgröße überschritten wird. Bei ungünstiger Wahl der Partitionierungskriterien kann es sein, dass so enorm große bzw. ungleichmäßige Pakete anfallen.

Die tatsächliche Paketgröße wird aber auch durch die Transformationsroutinen beeinflusst. Wenn beispielsweise ein Filter in Form einer WHERE-Klausel auf die INTAB in einer SQLScript Routine angewendet wird, dann wird die Anzahl der Datensätze in dem Paket entsprechend reduziert. Diese Bedingung wird bis in die Extraktion der Daten runtergedrückt. Da die Paketbildung aber vor der Verarbeitung der einzelnen Pakete stattfindet, werden die Pakete effektiv durch das Filterkriterium verkleinert.

Umgekehrt kann es auch vorkommen, dass die tatsächliche Paketgröße durch die Logik in den Routinen erhöht wird. Das ist zum Beispiel der Fall, wenn sich Daten durch einen Join ausmultiplizieren oder eine Transponierung von Daten von einem Kennzahlenmodell in ein entsprechendes Merkmalsmodell stattfindet.

Wichtig für eine gute Performance ist die tatsächliche Anzahl von Datensätzen.

Optimale Paketgröße bei HANA Ausführung

Eine ungünstige Paketgröße reduziert die Laufzeit. Bei der HANA Ausführung können die Pakete erheblich größer sein, als bei ABAP Ausführung. Eine Größenordnung von 1.000.000 Datensätze ist in den meisten Fällen ein guter Startwert, wenn man keine Vorschläge vom System bekommt. Wichtig ist, das es sich hierbei um die tatsächliche Anzahl der Datensätze handelt. Wenn also Ihre Routinen 90% der Datensätze ausfiltern, sollten Sie dieses in der Paketgröße der DTPs berücksichtigen.

Wenn die Pakete zu groß werden, dann kann es vorkommen, dass die Anzahl der Parallelen Prozesse nicht ausgenutzt wird. Ein Beispiel dafür sehen sie im folgenden Beispiel.

Die optimale Paketgröße kann man nur durch Tests ermitteln. Diese sollten auf dem Produktivsystem mit echten Daten durchgeführt werden.

Beispiel für ein DTP mit Verarbeitungslogik

Im Folgenden zeige ich die Laufzeiten für einen DTP, der eine Transformation beinhaltet, die aus einem Datensatz durch Transponieren jeweils 16 Datensätze macht. Dies ist erforderlich, um die PCA-Plandaten aus dem Kennzahlenmodell ein Merkmalsmodell umzuwandeln, in der jeder Datensatz für eine Periode steht. In dem Beispiel sind in der Quelle 1.994.590 Datensätze, woraus durch die Routine 31.913.440 Datensätze im Ziel werden.

Paketgröße im DTPTatsächliche Anzahl DatensätzeLaufzeit in Sekunden
10.000160.000243
62.5001.000.000155
100.0001.600.000138
1.000.00016.000.000258

Tabelle 1: Laufzeit in Abhängigkeit von der Paketgröse

Der Vorschlagswert des BW/4HANA Systems für die DTP Größe ist 1.000.000 Datensätze. Durch die Vervielfältigung der Datensätze ist das aber natürlich nicht mehr optimal. Wenn wir statt dessen eine Paketgröße wählen, so dass die tatsächlich Anzahl an Datensätzen ca. 1.Mio. entspricht, dann ist die Laufzeit erheblich besser. In unserem Beispiel ist das Optimum bei 1.6Mio. tatsächlichen Datensätzen.

Auswirkung der Anzahl der Workprozesse bei HANA Ausführung

Neben der Paketgrösse hat natürlich auch die Anzahl der Workprozesse einen Einfluss auf die Gesamtlaufzeit für einen DTP. Allerdings ist die Wirkung von einer Verdoppelung der Workprozesse bei weitem nicht so groß, wie man es naiv erwarten würde:

Für das obige Beispiel habe ich die Anzahl der Workprozesse von 3 auf 6 hochsetzt. Dadurch verkürzt sich die Laufzeit von 138 Sekunden nur um 14% auf 121 Sekunden.

Von der ABAP Ausführung kennen wir hier eine halbwegs lineare Abhängigkeit von Laufzeit und Anzahl der Workprozesse. Wobei man beim Ausführen der Prozessketten immer darauf achten muss, dass die Gesamtzahl der Hintergrundprozesse (Typ BTC) auch ausreicht.

Zusammenfassung

Die Paketgröße ist ein wichtiger Parameter zur Optimierung der DTP Laufzeit. Mit der HANA Ausführung können wir jetzt grundsätzlich größere Pakete wählen. Der Vorschlagwert von BW/4HANA 2.0 muss manchmal angepasst werden, insbesondere wenn die Transformationslogik die tatsächliche Anzahl der Datensätze verändert. Hier hilft oft nur ausprobieren.

BW/4HANA Cockpit – Wo ist die Administration in der SAP GUI?

Mit BW/4HANA 2.0 ist die Administration von InfoProvidern und Requests in der SAP GUI nicht mehr vorgesehen. Statt dessen öffnet sich ein Browser Fenster mit dem SAP BW/4HANA Cockpit, wenn wir auf die Administration der ADSOs klicken oder ein DTP starten und sich der DTP Monitor öffnen sollte. Die Dokumentation der SAP für das BW/4HANA Cockpit finden Sie hier: https://help.sap.com/viewer/107a6e8a38b74ede94c833ca3b7b6f51/2.0.0/de-DE/2447401c5d01428a9c4bb8edbd567cd8.html

Das BW/4HANA Cockpit ist eine Fiori Web-Applikation, die sicherlich ihre Berechtigung und Vorteile hat. Aber manchmal ist diese Transaktion nicht erreichbar, z.B. wenn man Probleme mit der Konfiguration des WebServers hat, es fehlen Zertifikate oder zugehörige Rollen (obwohl man das Profil SAP_ALL hat).

Ein einfacher Workaround ist die SAP GUI Transaktion RSMNG. Hier ist (noch) die alte Oberfläche für die Administration eines Datenziels erreichbar. Hierüber können wir dann auch zu dein einzelnen DTP Requests navigieren.

Wenn sich das BW/4HANA Cockpit nicht öffnen lässt

Falls sich das BW/4HANA Cockpit nicht öffnet, wenn Sie in Eclipse auf „Manage the DataStore Object (advanced)“ klicken, dann kann das an Ihren Einstellung in Eclipse liegen. Bei mir hat es mit der Einstellung „Default system web browser“ nicht funktioniert. Mit der expliziten Auswahl von Chrome hat sich dann ein Fenster geöffnet.

Browsereinstellungen in Eclipse

 

Einstellung zum WebBrowser in Eclipse

Grundsätzlich sollten Sie sich natürlich an die neue Oberfläche des BW/4HANA Cockpit im Browser gewöhnen, denn es kann passieren, dass die SAP die „alten“ GUI Transaktionen abschaltet oder einschränkt. Aber als Workaround ist das auf jeden Fall eine gute Zwischenlösung.

Webinar: SQLScript & AMDP im SAP BW

Webinar: SQLScript und AMDP im SAP BW

Das Webinar hat am 13.9.2019 live online stattgefunden.

Nutzen Sie bereits ein SAP BW on HANA oder SAP BW/4HANA? Und nutzen Sie auch die Potenziale der SAP HANA Datenbank voll aus, oder setzen Sie noch auf  ABAP Transformationsroutinen? In diesem kostenlosen Webinar lernen Sie die Vorteile der HANA Ausführung und der ABAP Managed Database Procedures (AMDP) in den BW-Transformationen kennen.  

Inhalte

Lernen Sie in diesem kostenlosen Webinar, 

  • worin der Unterscheid zwischen HANA Ausführung und ABAP Ausführung besteht
  • warum es sich lohnt, sich mit den AMDP Routinen auseinanderzusetzen
  • warum SQL(Script) grundsätzlich besser für die Implementierung von Transformationslogik geeignet ist, als ABAP 
  • warum in 5 Jahren wahrscheinlich keiner mehr neue ABAP Routinen schreiben wird

Webinaraufzeichnung anfordern

Wenn Sie sich hier anmelden, bekommen Sie Zugang zu der Webinar Aufzeichnung und den gezeigten Folien.

Fragen und Antworten aus dem Webinar SQLScript und AMDP für SAP BW

Am 13.9.2019 hat das Webinar SQLScript und AMDP für SAP BW stattgefunden. Am Ende der Veranstaltung bestand die Möglichkeit, Fragen zu stellen bzw. während der Veranstaltung sind im Chat unterschiedliche Fragen aufgetaucht.

Die Aufzeichnung der Veranstaltung und den zugehörigen Foliensatz können  Sie über den Link hinter dem Bild anfordern:

Kommentare und Antworten zum Chat

Im Nachgang des Webinars habe ich noch die Fragen bzw. Anmerkungen aus dem Chat zusammengetragen, und möchte diese hier für alle Interessierten beantworten bzw. kommentieren.
  • Wahrscheinlich zum Punkt, warum bislang AMDP so wenig genutzt wird: Weil es sehr aufwendig und riskant ist, eine bestehende, laufende ABAP-TRFN auf SQLScript umzustellen!
Die vollständige Migration bestehender ABAP Routinen kann aufwändig sein. Da stimme ich voll mit Ihnen überein. Das gilt insbesondere für solche Routinen, die komplexes ABAP Coding enthalten und das über einen langen Zeitraum gewachsen ist. Sicherlich wird man diese Routinen nur dann migrieren, wenn es ein akutes Problem gibt. 
Aber was spricht dagegen, neue Routinen als AMDP anzulegen?
Und die meisten ABAP Routinen sind eher klein und lassen sich ganz einfach umstellen. Dafür biete ich meinen Analyseworkshop an, damit man hier ein klares Bild bekommt, wo Aufwand und Nutzen in einem guten Verhältnis liegen. 
Das es riskant ist, auf AMDP umzustellen, kann ich nicht bestätigen.
  • Wie sieht es mit re-use und Modularisierung von SQLScript aus?

In AMDP Routinen kann man andere AMDP Prozeduren aufrufen. Diese müssen aber voll typisiert sein. Das ist ein Nachteil, der hoffentlich demnächst behoben wird. Mit SPS04 der HANA 2.0 sind Tabellenparameter ohne festen Typ möglich, weiter unten sind noch mal Details, insbesondere zu generischen Prozeduren. 
Eine andere Technik der Modularisierung in SQL ist das Anlegen von Views. Oft verwendete Abfragen können so zentral gepflegt werden. Dafür können auch Calculation Views verwendet werden, wobei dies einige Vor- und Nachteile mit sich bringt, die hier den Rahmen sprengen.

  • Da man beim SQLScript auf Datenmengen arbeitet finde ich das Debugging mühsam. Ich finde nur schwer den Datensatz der aus fachlicher oder technischer Sicht Probleme macht. Haben Sie hierzu Tipps / Empfehlungen?

Meine Empfehlung ist, dass man den Code der Routine in die SQL-Konsole kopiert und dort einen anonymen Block darum baut. Hier ist ein Bild von einer Folie aus meiner Schulung dazu, der gelb hinterlegt Code ist hinzugefügt worden. Dieses Vorgehen hat sich sehr für die Analyse bewährt.

  • Fehlerbehandlung in AMDP läuft „nicht wirklich gut“,  Unterstützung error stack?
Das ist völlig richtig und da muss ich mich entschuldigen. Diesen Punkt habe ich in den Folien einfach vergessen. Details finden Sie in SAP Hinweis 2580109. Zusammenfassung: Errorstack funktioniert nicht mit HANA Ausführung. Aber soll mit BW/4HANA 2.0 gelöst werden. 
  • Ein möglicher weiterer Nachteil:  Berechtigungskonzept für direkte Entwicklung auf HANA Ebene .. und „Gefahr“ von Zugriffen auf die Objekte die eigentlich im „Hoheitsbereich“ des BW-Schemas / ABAP-Users liegen.
Das ist nicht richtig. Der Zugriff bei der AMDP Entwicklung erfolgt mit einem normalen NetWeaver Benutzer, ganz ohne spezieller HANA Berechtigung oder einen HANA User. Das hatte der Teilnehmer später bei der Live-Demo auch erkannt. Allerdings: Wenn Calculation Views verwendet werden sollen, dann wird natürlich wieder ein HANA Zugriff mit entsprechenden Berechtigungen benötigt. 
  • ABAP Methoden zu AMDP, wie Kursumrechnungen etc… Momentan noch wenig bis gar keine Codeschnipsel vorhanden
Es gibt nicht wie im ABAP eine riesige Bibliothek an Funktionsbausteinen und Methoden, die genutzt werden können. Das ist richtig. Für die Kurs- und Mengenumrechnung gibt es aber eine SQL-Funktion. Wenn Sie etwas spezielles suchen, lassen Sie es mich bitte wissen. 
  • Wie lautet die Quelle für die Aussage dass AMDPs zukünftig dynamische Programmierung erlauben? Und welche konkreten Änderungen möchte SAP hier unternehmen?
Die Einschränkung von AMDP-Routinen ist Read-Only. In den Releasenotes für SPS04 für HANA 2.0 steht, dass dynamische SQL-Anweisungen auch als Read-Only markiert werden können. Damit müssten diese in ReadOnly AMDPs verwendbar sein. Siehe Releasenotes und Doku zu dynamischem SQL
Darüber hinaus kann SQLScript mit SPS04 auch ANY TYPE Tabellenparameter, siehe hier
 
Was jetzt noch fehlt ist, dass man auch AMDP Methoden mit Type ANY TABLE definieren kann. Das habe ich bislang nicht in der Doku gefunden. Und leider habe ich kein System mit dem entsprechenden HANA Stand, um das auszuprobieren. 
Es fehlt also nur noch ein kleiner Baustein, damit man in SQLScript generische Prozeduren implementieren kann.  
  • Nein, es war sicher eine TRNF mit einer InfoSource dazwischen , und ein Tal hatte ABAP-code , der zweite nichts

Da ging es um die anschließende Diskussion mit der Partitial Execution auf HANA. Das kann natürlich gut sein, dass es eine gemischt Ausführung mit ABAP und HANA war. Diese ist grundsätzlich möglich, wenn unten HANA und oben ABAP verwendet wird.

Soweit meine Anmerkungen und Antworten zu den Fragen aus dem Chat. Vielen Dank für diese Beiträge und auch für die vielen positiven Rückmeldungen zu dem Webinar. 

Erste Online Schulung erfolgreich durchgeführt

Die letzte Runde meiner Schulung SQLScript für BW-Berater am 1. & 2. August 2019 hat online stattgefunden. Somit konnten die Teilnehmer von Ihrem Büro bzw. von zu Hause dabei sein, ohne die zugehörigen Strapazen und Kosten einer Anreise hier nach Mannheim.
Durch moderne Übertragungssoftware (wir haben sowohl Zoom als auch GoToMeeting ausprobiert), viel Bandbreite und WebCams bei allen Beteiligten war eine sehr enge und produktive Zusammenarbeit möglich.
Mein Fazit: Ich werde das Format Online Schulung nächstes Jahr (oder bei konkretem Bedarf) gerne wieder anbieten.

Aufzeichnung des Webinar SQLScript und AMDP für SAP BW

Aufzeichnung und Folien des Webinars
SQLScript und AMDP im SAP BW

Folien des Webinars

Aufzeichnung des Webinars

Nachträgliche Aufzeichnung des Webinars vom 13.9.2019 zum Thema „SQLScript und AMDP für SAP BW“. Ergänzt um ein paar Anmerkungen der Teilnehmer, insbesondere bzw. ErrorStack und Modularisierung.

Anmerkungen und Fragen aus dem Chat mit Antworten

Die Fragen und Anmerkungen aus dem Chat während der Veranstaltung finden Sie in diesem Blogpost.
 
Alle Materialien sind geistiges Eigentum von Jörg Brandeis und dürfen nicht weitergegeben werden.

Schulungstermine SQLScript für BW-Berater

An den folgenden Terminen finden 2-tägige Schulungen hier in Mannheim statt:

Weitere Informationen zu den offenen Schulungen.

Inhouse Schulungen

Alle Schulungen können auch als Inhouse-Veranstaltung organisiert werden. In Ihren Räumen, auf Ihren Systemen und natürlich auch angepasst an ihre Schwerpunkte. 

Informationen zu Inhouse-Schulungen.

Wollen Sie mehr Informationen?

Unverbindliche Anfrage