Architektur + Entwicklung des SAP Basis Systems

Transkript

1 Architektur + Entwicklung des SAP Basis Systems (1) Prof. Dr. H. Neuendorf herbert.neuendorf@dhbw-mosbach.de 1. Klassischer SAP ABAP-Applikationsserver = Basis-System Dreistufige Client-Server Architektur Workprozesse eines verteilten Systems SAP-LUW Verbuchung SAP-Sperrkonzept DB-Zugriff Tabellenpuffer CAP-Theorem 2. Weiterentwicklung - NWAS SAP NetWeaver AS System-Öffnung : Internet & neue Technologien SAP-Web-Programmierung ICF + Business Server Pages SWE-Projekt 5.Semester ( ERP-Systeme Prof.Dr. Palleduhn )

2 ERP = Enterprise Resource Planing (2) IT-System zur umfassenden, integrierten, bereichsübergreifenden, bruchfreien Abbildung und Kontrolle aller relevanten Geschäftsprozesse des Unternehmens WI-Kerngedanke Integration + optimale Prozess-Orientierung SAP ERP-Weltmarktführer Gegründet 1972 durch fünf IBM-Mitarbeiter HQ Walldorf + St.Leon Roth > Installationen in > 200 Ländern Leitende Fragestellungen: Warum war SAP so erfolgreich? Detail : Welche technische Maßnahmen sorgen für Performanz des geschäftskritischen Systems? Wie hat sich das System evolutionär weiterentwickelt? Wie korrespondieren betriebswirtschaftliche Anforderungen mit technischen Lösungen? Wie öffnete sich das System vom monolithischen allwissenden ERP-Server zum kollaborativen System?

3 Abstrakte Kriterien der Wandlungsfähigkeit von ERP-Systemen (3) Verfügbarkeit Flexible Zugreifbarkeit unabhängig von Ort und Zeit Unabhängigkeit Plattformunabhängigkeit Autonome Subsysteme und Services Skalierbarkeit Kapazitätsmäßige Anpassung Interoperabilität Kommunikationsfähigkeit mit anderen Systemen Eigenschaften wandlungsfähiger ERP-Systeme Selbstähnlichkeit Ähnliche Strukturen auf unterschiedlichen Systemebenen Modularität Struktureller Aufbau aus unabhängigen Teilsystemen Wissen Selbstauskunft des Systems Quelle: Gronau: "Enterprise Resource Planing", Oldenbourg, 2010, S.52ff [angepasst]

4 Transparenzleistungen Verteilter Systeme und ihrer Middleware (4) Transparenz = Verstecken der Funktion bei Bewahren des Effekts + Einheitlichkeit der Handhabung Ortstransparenz Benutzer muss nicht wissen muss, wo sich Ressource befindet - Identifikation über Namen Zugriffstransparenz Einheitlicher Zugriff unabhängig von Lokalisation der Ressource + des Nutzers Nebenläufigkeitstransparenz Konsistenter paralleler Zugriff mehrerer User auf selbe Ressource - ohne gegenseitige Beeinflussung. Synchronisationsleistung durch das System - nicht durch User Migrationstransparenz Ressourcen können verlagert werden - ohne dass User dies bemerkt Fehlertransparenz Fehler und deren Behebung bleiben (teilweise) vor User verborgen Skalierungstransparenz Neue Ressourcen können hinzugefügt werden können - ohne negative Auswirkungen auf bestehende. Leistungstransparenz Automatische Lastverteilung (load balancing) auf einzelne Teilsysteme

5 Historische Entwicklung des SAP-Systems (5) Aufbrechen der monolithischen Struktur in separate Teillösungen Öffnung des Systems für neue Technologien Entwicklung setzt sich fort : SOA, Cloud, Mobile, BigData

6 Selbst-Darstellung SAP-Welt (6) Betonung Anwendungsvielfalt + Modularität SAP ERP Applikations Server : NetWeaver 7 AS ("die Basis") aktuell NW AS 7.x Bwl. Kernkomponenten : SAP Business Suite Wir sprechen hier über den (ABAP-) Applikationsserver

7 SAP Applikationsserver Gemeinsame Basis + Middleware (11) SAP Anwendungen HCM, FI, MM, SD, CO... ABAP (anwendungsübergreifend) SAP Applikationsserver Betriebssysteme + DB Hardware-Plattformen SAP AS ("Basis") Technisches Fundament aller Anwendungen auf Vielzahl verschiedener Plattformen Datenintegration über eine gemeinsame Datenbank Anwendungsübergreifende Geschäftsprozessabwicklung Laufzeitumgebung für die meisten SAP-Anwendungen Systemadministration Verteilung von Ressourcen + Komponenten (Transporte) Unterstützte Plattformen : alle relevanten BS : DB : GUI: Netz: Unix Linux MS Oracle DB2 anydb SAPGUI WebGUI NetWeaver Business Client via WebDynpro WebClient via BSP Mobile via SAPUI5 TCP/IP IPv6 unterstützt Marketing : SAP R/3, mysap.com, SAP WAS, NetWeaver, SAP ECC, S/4Hana Technischer Kern des Systems blieb konstant - evolutionär erweitert um zusätzliche Komponenten

8 Client / Server (13) Hardware-orientierte Sicht : Client LAN / WAN Server Niedrige WAN- Transferraten bei R/3-Etablierung: Zugriff auf Server übers WAN von Anfang an intendiert! Software-orientierte Sicht : Client Anforderung Dienstleistung Server Architektur des App- Servers musste dies performant zulassen! Prozess Erbringen Prozess Dienstleistung Service Komponente = Dienst, der von einer Software-Komponente angeboten wird = Fachliche Komposition von Services

9 SAP Client / Server Klassische dreistufige verteilte Architektur 3-Tier / - Layer (14) Quelle: M. Sahlmüller (WI13) Bachelorarbeit, 2016 Erweiterung dieser Sicht aktuell durch S/4HANA SAP-System = Alle Software-Komponenten, die der selben Datenbank zugeordnet sind Daten-Integration aller Unternehmensdaten in logisch zentraler Datenbank Konsistenter Zugriff auf zentralen Datenbestand durch alle zentralen SAP-Anwendungen

10 SAP Client / Server (15) Präsentationsschicht User- Eingabe / Ausgabe LAN / WAN SAPGUI SAPGUI SAPGUI KByte Browser Mobile? Applikationsschicht Programmlogik + DB-Zugriffe LAN Application Server 1 KByte - MByte Application Server n Persistenzschicht Zentrale DB Alle Daten + Anwendungsprogramme + Datentypen (Dictionary) Database Management System Database

11 Verteilte Client / Server- Konfigurationen Zweistufige Konfiguration (Two Tier) Kleines Kundensystem (ca. 100 User) Skaliert nicht! Präsentation Vertikale Verteilung Regelfall : skaliert!! Dreistufige Konfiguration (Three Tier) Präsentation (16) Einstufige Konfiguration (Demo-System) Horizontale Verteilung Applikation DB + Appl. + Präsentation DB + Appl. DB

12 Dreistufige Architektur - Prozesse (18) Admin App-Server-Workprozess : Spezialisiertes Programm für definierte Services 5-10 User pro Dialog- Workprozess SAP GUI 1 - n Applikations- Server SAP GUI SAP GUI Application Server 1 DIA BTC V SPO Message Server Application Server n DIA BTC V ENQ Workprozesse pro Applikations- Server Database Management System Database

13 SAP Dispatcher : Verteilung Benutzeranfragen auf Dialog-Workprozesse (19) 1 User 1 WP 1 DB-Prozess WP ist User nur während Verarbeitung zugeteilt! Hoher Verwaltungsaufwand - aber während langer Eingabe- Zeiten kann WP anderen Anfragen zugeteilt werden Viel effektiver als feste WP-Zuteilung! Präsentation SAP GUI SAP GUI SAP GUI SAP GUI 8 1 DIAG-Format via TCP/IP Applikationsserver Dispatcher Workprozess Workprozess Workprozess Request Queues fifo Puffer Shared Memory Rollbereich Benutzerkontext arbeitet statetful! SAP AS hält Kontext / State 5 Relationale Datenbank kennt nur WP - nicht indiv. User DBMS - Prozesse DB

14 Entkopplung User-Verhalten und Workprozess-Zuordnung (21) Typische Eingabezeit des Users ist länger als Verarbeitungszeit auf App-Server SAP-Transaktion umfasst Folge von Eingabemasken zur Darstellung des bwl. Vorgangs Oberstes Ziel : Ressource Dialog- Workprozess soll nicht durch User- Eingabeverhalten blockiert werden!

15 Verteilung Benutzeranfragen auf D-Workprozesse Abbildung zahlreicher User auf wenige Dialog- SAP Logon Shared Memory SAPGUI SAPGUI Dispatcher SAPGUI Workprozess Workprozess Workprozess SAPGUI n : 1 Datenbank - Workprozess User-Interaktion 5-10 x länger als Bearbeitungszeit durch Workprozess 5-10 Frontend-User im Mittel pro Dialog-Workprozess Kommunikation zwischen Dispatcher und WPs via Shared Memory Vorraussetzung : Keine lang laufenden Programme, die DWP belegen!! Workprozesse mittels Request Queue + (22) Zuordnung von App-Server- WPs zu DB-WPs Zahl der effektiven DB- Benutzer deutlich geringer als Zahl der System-User DB entlastet! Workprozess-Multiplexing : Transaktion durch verschiedene, jeweils nur pro Einzelschritt zugeordnete D- Workprozesse abgearbeitet SAP-Transaktion : Aufeinanderfolgende, inhaltlich zusammengehörige Bildschirmbilder Teilschritte der Gesamt-Transaktion

16 Exkurs : SAP HANA (23) Verlagerung von Anwendungslogik von Applikationsschicht in DB-Schicht zur Nutzung IMDB bei komplexen Kalkulationen auf großen Datenmengen Fokus: Realtime Analytics SAP forciert zentrale Rolle der eigenen InMemory-DB HANA Verlagerung von App-Server Funktionen auf DB-Ebene Zukünftige Rolle des klassischen App-Servers ungewiss / Neue Programmiermodelle

17 Paradigmen : Data to Code (D2C) versus Code to Data (C2D) (24) Präsentationsschicht Präsentation Präsentation Applikationsschicht Orchestrierungslogik Kalkulationslogik Orchestrierungslogik Persistenzschicht (DB) Daten Kalkulationslogik Daten Nutzung traditioneller DB-Technologie folgt D2C Nutzung IMDB (HANA) folgt C2D Code-Pushdown-Prinzip Umgang mit DB : aus black box wird white box

18 Workprozess-Typen Message-Server Disp. Disp. (27) Dialog Verbuchung Disp. MS Disp. Pro App-Server : 1x Dispatcher + 2x Dialog-WP Batch SAP- Dispatcher Sperrverwaltung Gateway-Server Nur 1x pro System : Message Server Spool R/3 GW z.b. R/3 Enqueue Server Message Server Komunikation zwischen Dispatchern verschiedener App-Server eines Systems Gateway Server Kommunikation zwischen SAP-Systemen oder mit externen Systemen Dialog Abarbeitung Dialoganfragen Spool Verwaltung Druckaufträge Verbuchung Verwaltung + Bündelung + transaktionale Ausführung von DB-Änderungen Sperrverwaltung Verwaltung logischer Sperren (Enqueues) für DB-Tabellen Batch Verwaltung dialogfreier Hintergrundprozesse (Jobs) Dispatcher + alle Workprozesse : Identische Programme! Workprozesstyp kann durch Dispatcher umgeschaltet werden - ohne Neustart App-Server

19 ABAP- und Java-Stack : Dispatcher-WP- Bild bleibt gültig (28) Browser Web Application Server JEE ABAP Java VM ABAP VM Linux Unix Windows Operating System OS/400 OS/390 DB Server Oracle Informix MS SQL Server DBMS IBM DB2 SAP DB

20 Server-Übersicht (29) Server Darauf laufende Workprozess-Typen Aufruf : sm51 Werkzeuge Administration Monitor Systemüberwachung Server Doppelklick auf Servernamen liefert WP-Verteilung

21 Prozess-Übersicht (30) Aufruf : sm50 Werkzeuge Administration Monitor Systemüberwachung Prozesse Doppelklick auf Listeneintrag liefert Infos zum laufenden Prozess

22 Message-Server Instanz : Batch-Server Dispatcher Instanz : Dialog-Server Dispatcher Instanz : (31) Administrative Einheit, die Services anbietet D-WP B-WP D-WP Zentrale Instanz : enthält MS 1 x pro System Dispatcher D-WP V-WP E-WP B-WP S-WP... D-WP MS AppServer Info WPs + Load Message Server : Zentraler Dienst für Kommunikation zw. Dispatchern der Applikationsserver Anmeldung von Usern an Applikationsserver Skalierbarkeit Lastverteilung Logon - Load- Balancing MS : 1. Dispatcher melden sich beim MS mit ihren verfügbaren Workprozessen an 2. MS speichert Informationen über App.Server + deren Auslastung 3. Wenn Dispatcher erforderlichen WP nicht selbst hat, wird Request via MS an Dispatcher auf anderem App.Server weitergeleitet, der nötigen WP bereithält SAPGUI

23 Dialog-Workprozess Der Dialog-Workprozess SAPGUI LAN - / WAN (33) Request Queue Request - Queues Dispatcher Maximale Dauer begrenzt! Langlaufende Programme als Batch realisierbar! WP 1 interner Speicher Dynpro - Prozessor ABAP- Prozessor Datenbankschnittstelle Task- Handler... WP n Puffer-Zugriffe Applikations-Puffer Roll out Roll in Roll-Bereich Shared Memory Dynpros ABAP-Programme Tabellen... User-Kontext Roll File Roll File An Abarbeitung Dialogschritt sind auf Applikationsserver-Ebene beteiligt : Dispatcher als zentraler Steuerungsprozess Vom Dispatcher verwaltete Workprozess-Warteschlange für eingehende Requests Dialog-Workprozess Puffer im Shared Memory und Roll File

24 Ausführung ABAP- Code (34) Sourcecode ABAP Objects ( Ausgeliefert! ) ABAP IL Intermediate Language ( Bytecode ) Ausführung Durch ABAP VM Interpretation VM Quellcode kompilierter Bytecode (IL) Von plattformspezifischer LZ-Umgebung (VM ) ausgeführt Ausgeliefert wird kompletter ABAP-Quellcode : Liegt in Kunden-DB Bei erstmaligem Aufruf automatisch in Bytecode kompiliert Bytecode liegt dann mit Quellcode in DB VM-Architektur : Plattformunabhängigkeit Sicherheit bei Ausführung der Programme VM-Sandbox Strukturierte Zusammenfassung von ABAP-Code in Paketen

25 Performanz-Analyse Dialog-Betrieb : Scatter-Plot (35) Hoher Workload bei wenig freien Ressourcen = accumulierte Antwortzeit System hat genügend freie Ressourcen Geringer Workload Zu wenig freie Ressourcen / System falsch konfiguriert = durchschnittliche Antwortzeit Accumulierte Antwortzeit = durchschnittliche Antwortzeit * Anzahl der Ausführungen Hohe Accumulierte Antwortzeit bei niedriger durchschnittlicher Antwortzeit bedeutet starke Nutzung des performanten Systems durch zahlreiche User Hohe durchschnittliche Antwortzeit bedeutet stets ein schlecht laufendes System

26 Hintergrundverarbeitung - Batch-Workprozesse (36) Dialog-Server Hintergrundverarbeitung Dispatcher Hintergrundverarbeitungs-Server 3 Dispatcher... D-WP D-WP... B-WP B-WP B-WP Jobstatus geplant freigegeben Job 1 2 Batch Scheduler rdisp/btctime Default = 60s 4 bereit aktiv fertig abgebrochen Job1... C... DB XXX xxxx XXX xxxx xxxx xxx xxx xx UUU uuuu uuuu uuu uuu uu UU uuuu uuu u Jobübersicht Einplanungstabelle Batch Dialogfreie Abarbeitung lang laufender Programme - keine Benutzeraktion! C Periodische Aufgaben - Reorganisation, Datenübernahme Jobs in Einplanungstabelle Name, Prio, Starttermin / Event Anstoß durch Batch-Scheduler / Event-Scheduler via Einplanungstabelle Ausgelöst zu definierter Zeit oder durch Systemereignis

27 Jobübersicht (37) Aufruf : sm37 Werkzeuge CCMS Jobs Pflege Doppelklick auf Listeneintrag liefert Infos zum Job

28 SAP-Transaktion = SAP-LUW versus DB-LUW Mismatch!! (42) SAP-LUW Logical Unit of Work Benutzerdialoge ABAPprogramme DB-Änderungen Forderung nach Transaktionalität DB-Änderungen einer SAP-Transaktion auf eine DB-LUW bündeln DB- LUW Problem : Ohne geeignete Maßnahmen verteilt sich eine SAP-LUW auf mehrere DB-LUWs!!

29 Datenbank-LUW (Logical Unit of Work) (43) Datenbankoperationen insert update delete Zwischenzustände Konsistenter Zustand 1 Konsistenter Zustand 2 Physische Sperren : Nicht hintergehbar! Sperren auf DB-Tabellensätze halten ROLLBACK möglich DB-COMMIT (oder DB-Rollback) alle Sperren freigeben DB-LUW : Unteilbare Folge von Operationen, die DB von einem konsistenten Zustand in den nächsten überführen zwischen zwei DB-Commits oder DB-Rollbacks Entweder vollständig oder überhaupt nicht durchgeführt : Ganz oder gar nicht Prinzip ACID Abgeschlossen durch DB-Commit : Davor kann durch DB-Rollback noch alles rückgängig gemacht werden Durch Commit werden Änderungen insgesamt unwiderruflich festgeschrieben

30 Verhalten SAP DBMS : Automatischer DB-COMMIT (44) Systemarchitektur: Impliziter DB-COMMIT Bildschirm 1 Bildschirm 2 Bildschirm 3 Nach Dialogschritt- Verarbeitung : Neues Bild gesendet + WP wird User entzogen Ziel : Vermeiden von WP- Blockaden durch User- Interaktionen DB-COMMIT DB-COMMIT DB-COMMIT Wenn App-Server-WP endet, müssen auch zugehörige DB- Änderungen erfolgen DB-Commit automatisch ausgelöst! DB-LUW 1 DB-LUW 2 DB-LUW 3 DB-LUW 4 Zeit SAP-Transaktion : Umfasst in der Regel mehrere Dialogschritte DB-LUW : Umfasst nie mehr als einen einzigen Dialogschritt Keine Benutzer-Interaktion innerhalb DB-LUW!!

31 Vergleich typischer Zeitskalen : User-Interaktion vs. Systemaktivität (45) Schematische Sicht User Interaktionen PBO Screen 100 PAI PBO Screen 200 PAI PBO Screen 300 PAI - Dialogverarbeitung- - Dialogverarbeitung- Zeitlich realistische Sicht Lange User Interaktionen Screen 100 Screen 200 Screen 300 kurze DB LUWs PBO : PAI : Process before Output Process after Input SAP Logical Unit of Work Unvorhersagbar lange Benutzer-Interaktions- Zeiten dürfen nicht in DB-LUW eingehen!

32 Direkte synchrone DB-Änderungen aus Dialog (46) SAP Transaktion Zeit Dialogschritt 1 Dialogschritt 2... Letzter Dialogschritt synchron Daten Daten Daten Globale Daten des Programms ITABs Sichern : UPDATE tab1. UPDATE tab2.... Daten Einfaches Konzept - aber : Dialog Workprozess wird nicht freigegeben Anwender muss auf Durchführung der DB-Änderungen warten Synchroner Ablauf hinsichtlich Dialogschritt Schlechtere Performance bei vielen parallelen DB-Usern

33 Asynchrone Verbuchung durch Verbuchungs-Workprozess (47) Dialog-Server Verbuchungs-Server Dispatcher ABAP : Dispatcher COMMIT WORK... D-WP V-WP Entkopplung von Dialog-WP und DB-Update ABAP : Call Function in update task 1 MS Bündelung von DB-Änderungen zur gemeinsamen Ausführung Protokolltabellen VB* DB XXX xxxx XXX xxxx xxxx xxx xxx xx UUU uuuu uuuu uuu uuu uu UU uuuu uuu u Transaktionalität! DB-Änderungen: Nicht direkt im Dialog ausgeführt - sondern in Protokolltabelle nur vorgemerkt Ausführung = Schreiben in DB asynchron an Verbuchungs-WP delegiert

34 Verbuchung : Bündelung von Datenbankänderungen (48) Ziel : Trennung der Dialogschritte von vorzunehmenden DB-Änderungen SAPGUI Sammlung / Bündelung aller DB-Änderungen der SAP- LUW Gemeinsame Ausführung am Ende der SAP-LUW in einer einzigen DB-LUW Dialog- WP Workprozess Dialog-WPs führen DB- Änderungen nicht direkt aus Wäre synchron wartend auf Ende der jeweiligen DB-Änderung Übergeben Änderungsaufträge an Verbuchungs-WP Asynchron Dialog-WP wartet nicht auf Verbucher! Protokolltabelle SQL in spez. Funktionsbausteinen asynchron Workprozess Verbucher- WP Organisation der gesammelten DB-Änderungen durch Verbuchungs-Workprozess Erst protokolliert zur späteren gemeinamen Ausführung vorgemerkt - in Protokolltabelle Ende der SAP-Transaktion protokollierte DB- Änderungen komplett ausgeführt

35 Vormerkungen schreiben : Verbuchungsbausteine (50) Protokolltabelle Workprozess Dialog- WP 1 Daten Vormerkung 1 Vormerkung 2 Vormerkung 3 Einträge in Protokolltabelle durch Aufruf Verbuchungs-Funktionsbausteine IN UPDATE TASK Nicht direkt ausgeführt, sondern mit Parametern in Protokolltabelle vermerkt Inhalt Protokolltabelle : Funktionsbaustein mit SQL-Anweisungen für DB-Änderungen + Parameter Dialogprogramm a =. 1 CALL FUNCTION 'F1' IN UPDATE TASK EXPORTING p1 = a p2 = b = 2. CALL FUNCTION 'F2' IN UPDATE TASK EXPORTING.. q1 = b... p1 = 1 q1 = 2. p1 = 3 c = 3. CALL FUNCTION 'F1' IN UPDATE TASK EXPORTING... p1 = c Abschluss durch : COMMIT WORK

36 Wirkung von Rollback Work ROLLBAK WORK Protokoll - tabelle Fehler innerhalb SAP-LUW DB-Änderungen nicht ausgeführt Protokollsätze der SAP-LUW gelöscht (51) Vormerkung 1 Vormerkung 2 Workprozess Vormerkung 3 Löschen aller bis dahin geschriebenen Vormerkungen Dialog- WP Dialogprogramm PROGRAM..... ROLLBACK WORK. ROLLBACK WORK : Protokollsätze der SAP-LUW löschen + DB-Rollback Auch alle im aktuellen Dialog-Schritt evtl. bereits direkt vollzogenen DB-Änderungen werden rückgängig gemacht

37 Asynchrone Verbuchung (53) Zeit VBLOG Dialog-WP Verb.-WP auf DB A Text Vormerkung 1... Protokolltabelle COMMIT WORK. Vormerkung n C B A SAP-LUW 1 Dialogprogramm DB B C SAP-LUW 1 SAP-LUW 2 Verbuchungsprogramm Dialogprogramm Dialogprozess wartet NICHT auf Ausführung der DB-Änderung! Dialogprozess und Verbuchung sind zeitlich entkoppelt asynchron!

38 Synchrone Verbuchung (54) Zeit Dialog-WP A Verb.-WP Text Vormerkung 1... VBLOG Protokolltabelle COMMIT WORK AND WAIT. Vormerkung n B C A SAP-LUW 1 Dialogprogramm DB B C SAP-LUW 1 SAP-LUW 2 Verbuchungsprogramm Dialogprogramm Dialogprozess wartet auf Ende der Ausführung der DB-Änderung! COMMIT WORK AND WAIT

39 Warum müssen Sperren gesetzt werden? (55) Programm A Programm B Verwaltung konkurrierenden Zugriffs auf selbe Daten Programm C Mehrere User greifen auf selbe Ressource zu Synchronisation erforderlich, um Konsistenz zu garantieren : Ausschließender Zugriff! Datenbank Tab 1 Tab 4 Sperren nur so lange wie nötig halten! Tab 3 Tab 6 Performance-Bottleneck Tab 2 Tab 5 Physische Sperren : durch DB selbst Sperren : Datenbankobjekt wird zeitweise für Zugriff eines Prozesses reserviert - für Zugriffe aller anderen gesperrt Logische Sperren : durch Programmier- Konvention

40 Datenbanksperren nicht ausreichend im SAP-Umfeld (56) Datenbanksperren reichen nicht SAP-Transaktion : Ersteckt sich i.a. über mehrere Bildschirmbilder Sperren müssen länger gehalten werden als nur über COMMIT (implizit) COMMIT (implizit) COMMIT WORK (explizit) einen Dialogschritt UPDATE INSERT SELECT UPDATE DELETE Sperren Bei direkter Änderungsanweisung aus Dialogprogramm setzt DB die Sperren selbst = physische Sperren Problem : Sperren werden von der DB nur bis zum Ende eines Dialogschrittes gehalten - Dann wird Änderung ausgeführt und Sperre freigegeben = zu früh für SAP-Transaktion!

41 SAP Sperrkonzept : Logische(!) Sperren - ENQUEUE-Workprozess (57) SAP Sperrkonzept: logisches Sperren SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI DB-unabhgängiger high-level Sperr- Mechanismus Dialog... WP Dispatcher Message Server Dialog... WP Dispatcher Enqueue WP Sperrtabelle Enq.-WP + Sperrtabelle Auf AS! 1 x pro System DB Management System Ziel : Mittel : Sperren über Bildwechsel system-global aufrechterhalten Globale Sperrtabelle auf App-Server - enthält Verzeichnis gesperrter Tabellen

42 Logische Sperren setzen + löschen Auftrag : Erzeuge Sperre Anforderung Sperre + Eintrag in Sperrtabelle sowie späteres Löschen der Sperre mit speziellen ABAP-Funktionsbausteinen * (58) Sperrtabelle Sperren zurücksetzen : durch Programm ABAP Programm Sperrbaustein Sperreintrag erzeugen oder durch Verbucher Call Function ENQUEUE_... Antwort : Sperre erfolgreich gesetzt Keine Sperre gesetzt Eintrag bereits gesperrt Fehler in Sperrverwaltung EXCEPTIONS keine FOREIGN_LOCK SYSTEM_FAILURE ABAP-Programm reagiert durch Auswertung Returncode Wenn Sperre bereits gesetzt ist : weitere Anforderungen abweisen *Sperrbausteine : ENQUEUE-<...> + DEQUEUE-<...> Durch System generiert, nachdem im Dictionary ein Sperrobjekt definiert wurde : Enthält zu sperrende Tabelle + Sperrargument (= Schlüsselfelder) + Sperrmodus (S = Shared - Lesesperre, E = Exclusive - Schreibsperre)

43 Sperrmodi E = Exclusive Schreibsperre (60) Daten sollen geändert werden vom Anforderer der Sperre Andere können weder schreiben noch lesen! Andere können keinerlei Sperren für das selbe Objekt erhalten S = Shared Lesesperre Daten sollen während Lesen nicht von anderen geändert werden können Daten werden vom sperrenden Programm nur gelesen Daten dürfen auch von anderen Programmen gelesen werden! Andere Programme können weitere S-Sperren für das selbe Objekt erhalten SAP Sperren vs. DB-Sperren Logische Sperren auf App-Server Vertrag zwischen Anwendungsprogrammen Am Ende der SAP LUW freigegeben Im Hauptspeicher des App-Servers in Enqueue-Tabelle verwaltet Physische DB-Sperren Automatisch durch Datenbank angewandt Am Ende der DB LUW durch DB freigegeben In DB verwaltet

44 SAP Lastverteilung (62) SAP GUI SAP GUI SAP GUI SAP GUI SAP GUI App-Server KB App-Server n Gateway 0.1ms Dispatcher MB Dispatcher Gateway Table Buffers DIA WP BTC WP SPO WP MB-GB Table Buffers DIA WP ENQ WP Enqueue Table 1ms MB DBMS DBWP DBWP DBWP GB DBWP 100ms DB (disk) TB Zugriffszeit Speicherverbrauch Data / Dialogschritt

45 Workprozessverteilung (63) Service Systemweit Per AS-Instanz Dialog >=2 >=2 Verbuchung >=1 >=0 Enqueue 1 0 oder 1 Batch >=1 >=0 Message 1 0 oder 1 Gateway >=1 1 Spool >=1 >=0 Systemstart : 1. Datenbank 2. Zentrale Instanz 3. Weitere Instanzen Instanzprofil : In Profildatei bei Serverstart ausgewertet Art + Anzahl der vom Dispatcher gestarteten Workprozesse Größe von Puffern, Rollbereichen, Logfiles... Rechnername Messageserver, Enqueueserver, DB-Rechner... rdisp/ wp_no_dia = 3 rdisp/ wp_no_upd = 4... Abfrage System-Werte : Report RSPFPAR Automatischer Betriebsartenwechsel : Anpassung an aktuelle Anforderungen Automatische Änderung der Workprozess-Verteilung zu vordefinierten Zeitpunkten, z.b. : Tagesbetrieb Zahlreiche Dialog-WPs (überwiegend Dialog-User, wenig Batch) Nachtbetrieb Umwandlung von Dialog-WPs in Batch-WPs (überwiegend Batch)

46 Betriebsarten-Konzept : Anpassung Instanzen an Lastverteilung (65) Betriebsart Tag : Primär Dialogverarbeitung Betriebsart Nacht : Primär Hintergrundverarbeitung Dispatcher Dispatcher D D D D B D D B B B Wechselnde System-Anforderungen der User Ziel : Optimale Ressourcen-Ausnutzung Art + Zahl der aktiven Workprozesse umschalten : Gesamtzahl der Workprozesse bleibt konstant, aber Verteilung auf Typen kann geändert werden Umschaltung dynamisch bei laufendem System gemäß Umschalt-Zeit-Plan Kein System-Neustart nötig Kein Abbruch laufender Requests

47 SAP Datenbank-Schnittstelle Applikationsserver ABAP Interpeter Die SAP Basis-Datenbankschnittstelle DB Schnitt -stelle SELECT * FROM OPEN-SQL Daten Lokale Puffer Native-SQL Datenbank Relationale Datenbank (66) Open SQL Plattform- und DB-unabhängig Verschalung der DB-Schnittstellen verschiedener DB-Hersteller Daten Daten Native-SQL Nutzt vollen Sprachumfang EXEC SQL. SELECT... END EXEC. Native Native-SQL DB - Daten aber : Code abhg. von DB-Hersteller! Umgeht Tabellenpuffer! ABAP Open-SQL : In ABAP integriertes Subset von SQL Ablauffähig mit allen von SAP unterstützten DBMS - ohne Anpassung! Vermeidet herstellerspezifisches SQL + manuelles Handling von DB-Verbindungen Wird durch DB-spezifische DB-Schnittstelle des App-Servers in Native-SQL umgesetzt

48 Exkurs : CAP-Theorem und Verteilte Systeme (70) Consistency All clients have the same view on the data Atomic Consistency Continuous Availability Availability All clients can always read and write within some maximum latency Partition Tolerance Bei verteilten Systemen nur zwei von dreien zu haben Partition Tolerance No set of failures less than network failure is allowed to cause the system not to respond CAP-Theorem : Systeme können nur maximal zwei der drei Forderungen erfüllen - auf Kosten der dritten! Verteilte Systeme sind per definition partition tolerant In Verteilten Systemen hat man nur die Wahl zwischen Consistency und Availability Beide Anforderungen sind nicht simultan erfüllbar!

49 SAP Puffer : Tabellenpuffer der App-Server (71) App-Server 1 Tabellen puffer ABAP Programm 1 Open-SQL DB- Schnittstelle App-Server 2 ABAP Programm 2 DB- Schnittstelle Tabellen puffer Tabellenpuffer sind lokal zum jeweiligen App- Server in dessen Hauptspeicher Weitere Puffer für : Programme Bildschirmdaten Dictionary-Daten Native SQL DBMS 1-60 ms Datenbank Füllen Puffer : Beim ersten Lesen Nach Änderungen Nach Synchronisation - s.u. CAP-Theorem Ziel der Pufferung von DB-Tabellen auf App-Servern : Reduzierung Lese-Zugriffszeit Rascher Zugriff auf App-Server Entlastung Datenbank Reduzierung Zahl teurer DB-Zugriffe Atomic Consistency Partition Tolerance Continuous Availability

50 Aktualisierung + Synchronisation von SAP Puffern AS 1 PROGRAM z... UPDATE dbtab1... dbtab1 DB- Schnittstelle AS 2 ABAP Programm 2 DB- Schnittstelle dbtab1 Nicht alle Tabellen puffer-geeignet! Nur vorwiegend gelesene Tabellen! (72) Zeitverzögerte Synchronisation der Puffer der anderen App-Server! Kann Systemverhalten beeinflussen! aktuell DBMS verzögert App-Server, der Daten auf DB ändert, aktualisiert zugleich eigenen Puffer dbtab1 Datenbank dbtab1 X bufreftime ( s) Synchronisations-Informationen Periodisch von App-Servern gelesen Vorteil : Nachteil : Netzlast gering kein Broadcast Lokale Puffer enthalten eventuell veraltete Daten Leseintervall Profilparameter bufreftime

51 SAP-Tabellenpuffer - Sinnvolle Pufferung von Tabellen (73) Pufferungsfähige Tabellen : relativ kleine Tabellen, auf die überwiegend lesend zugegriffen wird Tabellen, deren Inhalt sich selten verändert z.b. Stammdaten, Customizing Parameter... Pufferung problematisch : wenn verwendete Daten ständig aktuell sein müssen wenn Tabellen zu groß sind - so dass Neufüllen der Puffer nach Änderungen zur Synchronisation zeitaufwendig wäre Performanter Puffer-Einsatz : Wahl der richtigen Pufferungsart : bei Anlegen der Tabelle festgelegt Residente Pufferung - gesamter Tabelleninhalt komplett gepuffert Generische Pufferung - nur Bereiche der Tabelle gepuffert Partielle Pufferung - nur Einzelsätze gepuffert

52 Drei Pufferungsarten Resident key1 key2 key3 data Generisch 1 Schlüsselfeld key1 key2 key3 data Generisch 2 Schlüsselfelder key1 key2 key3 data 001 A 001 A 001 B 001 B 002 A 002 A 002 B 002 B 002 B 002 C 002 C 002 D 003 A 003 A 003 A 003 B 003 B 003 C 003 C 003 C 003 D 003 D 003 D Kleine Tabellen, häufig gelesen, selten verändert Residente Pufferung Große Tabellen, Zugriff auf Einzelsätze Partielle Pufferung Gemeinsame Verarbeitung generischer Bereiche Generische Pufferung Partiell Einzelsatz key1 key2 key3 data 001 A A B B B A A A A B B B C C D A A A B B C C C C D D D D 4 (74) Partielle Pufferung : Hoher Verwaltungsaufwand - geringster Speicherbedarf Residente Pufferung : Geringster Verwaltungsaufwand - höchster Speicherbedarf

53 SAP ERP AS : Anforderungen Technologische Lösungen (75) Prozessorientierung Anpassbarkeit der Prozesse Plattformunabhängigkeit ABAP-VM ABAP-Eigenentwicklung ABAP-Open-SQL Mehrsprachigkeit MultiUser MultiTasking Darstellung bwl. Transaktionen Transaktionalität Integrität der Daten Begrenzte Ressourcen Dispatcher-WP-Mechanismus Dialog- und Batch-Betrieb Logon-Load-Balancing Asynchrone Verbuchung Verbuchung + High-Level-Sperrkonzept Wechselnde Anforderungen Wechselndes Userverhalten Anpassung an firmeninterne Auslastungssituation Betriebsartenkonzept + Logon-Gruppen Puffermechanismen auf App-Server Hochgradige Administrierbarkeit Integrations - Aspekte : Bwl. Prozess-Integration Datenintegration Systemintegration Administrative Integration Vermeidung von System-, Medien-, Prozess- und Organisationsbrüchen Konsistenz