Architektur + Entwicklung des SAP Basis Systems

Transkript

1 Architektur + Entwicklung des SAP Basis Systems (1) Prof. Dr. H. Neuendorf neuendorf@dhbw-mosbach.de 1. Klassischer SAP Abap-Applikationsserver = Basis-System Dreistufige Client-Server Architektur Workprozesse 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 Systementwicklungs-Projekt 5.Semester ( ERP-Systeme Prof.Dr. Palleduhn 5. Semester )

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 Geschäftsprozess-Orientierung SAP ERP-Weltmarktführer Gegründet 1972 durch fünf IBM-Mitarbeiter HQ Walldorf + St.Leon Roth Entw. Deutschland, USA, Indien... > Installationen in > 150 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 öffenete 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 und Einheitlichkeit der Handhabung Ortstransparenz Benutzer muss nicht wissen muss, wo sich Ressource befindet - Identifikation über bloßen Namen Zugriffstransparenz Einheitlicher Zugriff unabhängig von Lokalisation der Ressource 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 Entwicklung des SAP-Systems (5) Aufbrechen der monolithischen Struktur in separate Teillösungen Öffnung des Systems für neue Technologien Aktuelles Release = SAP ERP 6.0 diese Entwicklung setzt sich fort : SOA, Cloud, Mobile, BigData

6 Selbst-Darstellung SAP-Welt (6) Betonung der Anwendungsvielfalt Wir sprechen hier über den (ABAP-) Applikationsserver

7 SAP-Welt - Produkte und Lösungen (stark vereinfacht) Quelle : Skript Prof. Palleduhn "ERP-Systeme" [angepasst] (7) Produkt Merkmale /Anmerkungen SAP ECC ERP Central Component / SAP Business Suite SAP All-in-One Für Unternehmen ab ca bis Mitarbeiter Umfassende Abbildung aller Geschäftsprozesse Modifizierbarkeit + umfassende Systemprogrammierung Für mittelgroße Unternehmen mit weniger als Mitarbeiten Vorkonfiguriertes, kleines ERP-System für größere Mittelständler oder Tochterunternehmen großer Konzerne, das die Vorteile eines ERP- Systems einschließlich branchentypischer Funktionalität bietet bei voller Kompatibilität zum "großen" SAP SAP Business ByDesign Für Unternehmen mit ca. 100 bis 500 Mitarbeitern Mittelstand!! Gehostet in SAP-Cloud (SAP-RZs) Umfassende + praktikable SaaS- Lösung : Servicebasierter Aufbau, konkrete Umsetzung der SaaS-Idee Public-Solution-Modell : Entwicklung von Erweiterungen mit eigener Skriptsprache im SAP Business ByDesign Studio SAP-App-Store mit aktuellen Erweiterungen SAP Business One Kein aufwendiges Customizing, sondern. Funktionalitätsauswahl durch den Anwender (Scoping) und anschließende Parametrisierung des Systems: Adaptive modulare Geschäftsprozess- Plattform - Einstellungen erzeugen im Gegensatz zu SAP ERP immer ein konsistentes System Einführung direkt durch den Kunden, ohne externe Beraterleistung Nicht im fachlichen Kern direkt modifizierbar, aber UI-Anpassungen + Personalisierungen, Definition spezieller Reports, Anlegen von eigenen Datenstrukturen und Formularen, Einbinden von externen Infoquellen (Mashups) + AddOns (Apps) Nutzung von InMemory-Technologien Für Unternehmen mit ca. 10 bis 100 Mitarbeitern Basiert auf "TopManage" der TopManage Financial Solutions LTD Eigener GUI + Plattformgebunden (Microsoft Windows) Keine Verbindung zu SAP ERP ECC

8 Release-Politik SAP (9) Gesamtes SAP-Release = SAP ERP 6.0 Applikations Server = NetWeaver 7 AS ("die Basis") häufige Umbenennungen Betriebswirtschaftliche Kernkomponenen = ECC 6.0 aktuell NW AS 7.x

9 SAP Applikationsserver Gemeinsame Basis + Middleware (11) SAP Anwendungen HR, FI, SCM, CO, SEM... ABAP (anwendungsübergreifend) SAP Applikationsserver Betriebssysteme + DB Hardware-Plattformen SAP AS ("die 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 Unterstützte Plattformen : alle relevanten BS : DB : GUI: Netz: Unix Linux MS Oracle MSSQLServer DB2 SAP-GUI Windows + Java HTML-GUI via ITS NetWeaver Business Client via WebDynpro WebClient via BSP Mobile Lösungen TCP/IP ab NW7.0 EHP2 wird IPv6 unterstützt Marketing : SAP R/3, mysap.com, SAP WAS, NetWeaver, mysap ERP, SAP ECC... Technischer Kern des Systems war stets konstant - evolutionär erweitert um zusätzliche Komponenten

10 Client / Server (13) Hardware-orientierte Sicht : Client LAN / WAN Server Historische LAN / WAN-Werte für die Zeit der Etablierung des R/3-Systems : LAN: [Mbit/s] WAN: [Kbit/s] 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 SAP-System = Gesamtheit aller Software-Komponenten, die derselben Datenbank zugeordnet sind Daten-Integration aller Unternehmensdaten in logisch zentraler Datenbank Konsistenter Zugriff auf zentralen Datenbestand durch alle zentralen SAP-Anwendungen

11 SAP Client / Server Klassische dreistufige verteilte Architektur 3-Tier / -Layer (14) Browser Mobile Präsentationsschicht? User- Eingabe / Ausgabe LAN / WAN SAPGUI SAPGUI SAPGUI KByte Applikationsschicht Programmlogik + DB-Zugriffe Application Server 1 Application Server n LAN KByte - MByte Persistenzschicht Zentrale DB Alle Daten + Anwendungsprogramme + Datentypen (Dictionary) Database Management System (DBMS) Database

12 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 (15) Einstufige Konfiguration (Demo-System) Horizontale Verteilung Applikation DB + Appl. + Präsentation DB + Appl. DB

13 Dreistufige Architektur : Services und Prozesse (17) Admin App-Server-Workprozess : Spezialisiertes Programm zur Abwicklung bestimmter Aufgaben User User 5-10 User pro Dialog- Workprozess SAP GUI 1 - x 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 (DBMS) Database

14 SAP Dispatcher : Verteilung Benutzeranfragen auf Dialog-Workprozesse (18) 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 1 : 1 5 Relationale Datenbank kennt nur WP - nicht indiv. User DBMS - Prozesse DB

15 Entkopplung User-Verhalten und Workprozess-Zuordnung (19) Typische Eingabezeit des menschlichen Users ist länger als die Verarbeitungszeit auf dem App-Server Typische SAP- Transaktion umfasst eine Folge von Eingabemasken zur Darstellung des bwl. Vorgangs Ziel : Ressource Workprozess soll nicht durch Eingabeverhalten des Users blockiert werden

16 Verteilung Benutzeranfragen auf D-Workprozesse Abbildung zahlreicher User auf wenige AppServer- SAP Logon Shared Memory SAPGUI SAPGUI 1 : 1 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!! Dialog-Workprozesse mittels Request Queue + 1:1 Zuordnung von App- Server-WPs zu DB-WPs Zahl der effektiven DB- Benutzer deutlich geringer als Zahl der System-User DB entlastet! (20) Workprozess-Multiplexing : Transaktion durch verschiedene jeweils nur pro Schritt zugeordnete, freie Workprozesse abgearbeitet SAP-Transaktion : Aufeinanderfolgende, inhaltlich zusammengehörige Bildschirmbilder Teilschritte der Gesamt-Transaktion

17 Paradigmen : Data to Code (D2C) versus Code to Data (C2D) (21) 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 Verlagerung von Anwendungslogik von der Applikationsschicht in die DB-Schicht zur Nutzung IMDB bei komplexen Kalkulationen auf großen Datenmengen

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

19 ABAP- und Java-Stack : Dispatcher-WP- Bild bleibt gültig (25) 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 (26) Server Darauf laufende Workprozess-Typen Aufruf : sm51 Werkzeuge Administration Monitor Systemüberwachung Server Doppelklick auf Servernamen liefert WP-Verteilung

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

22 Message-Server : 1x pro System Instanz : Batch-Server Instanz : Dialog-Server Dispatcher Dispatcher Instanz : (28) 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 interne Kommunikation zwischen Dispatchern der Applikationsserver Anmeldung von Präsentationsrechnern an Applikationsservern Lastverteilung Logon - Load- Balancing MS : 1. Dispatcher melden sich beim MS mit ihren verfügbaren Workprozessen an 2. MS speichert Informationen über App.Server (WP) und 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-Netz (30) Request Queue Request - Queues Dispatcher Workprozess n Workprozess 1 Maximale Dauer begrenzt! Langlaufende Programme als Batch realisierbar! interner Speicher Dynpro - Prozessor ABAP- Prozessor Datenbankschnittstelle Task- Handler... 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 (31) Sourcecode ABAP Objects ( Ausgeliefert! ) ABAP IL Intermediate Language ( Bytecode ) Ausführung Durch ABAP VM Interpretation VM BS CPU ABAP: 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 Grund für VM-Architektur : Plattformunabhängigkeit VM-Prinzip! Sicherheit bei Ausführung der Programme VM-Sandbox Strukturierte Zusammenfassung von ABAP-Code in Paketen

25 Performanz-Analyse Dialog-Betrieb : Scatter-Plot (32) 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 Bedeutung der 4 Quadranten 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 (33) Dialog-Server Hintergrundverarbeitung Dispatcher Hintergrundverarbeitungs-Server 3 Dispatcher... D-WP D-WP... B-WP B-WP B-WP Jobstatus geplant freigegeben bereit Job Batch Scheduler rdisp/btctime Default = 60s 4 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 langlaufender Programme - keine Benutzeraktion! C Einsatz : Periodische Aufgaben (Reorganisation, Datenübernahme ) Planung : Jobs in Einplanungstabelle Programmname, Prio, Starttermin / Event Anstoß : Durch Batch-Scheduler / Event-Scheduler via Einplanungstabelle Ausgelöst zu definierter Zeit oder durch Systemereignis

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

28 SAP-Transaktion = SAP-LUW versus DB-LUW Mismatch!! (39) 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) (40) 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 Wird entweder vollständig oder überhaupt nicht durchgeführt Ganz oder gar nicht, Alles-oder-Nichts, atomarer Prozess Abgeschlossen durch DB-Commit : Prinzip ACID Davor kann durch DB-Rollback noch alles rückgängig gemacht werden Durch Commit werden Änderungen insgesamt unwiderruflich festgeschrieben

30 Verhalten SAP DBMS : Impliziter DB-COMMIT Systemarchitektur: Impliziter DB-COMMIT Bildschirm 1 Bildschirm 2 Bildschirm 3 DB-COMMIT DB-COMMIT DB-COMMIT Nach Dialogschritt- Verarbeitung : (41) Neues Bild gesendet + WP wird User entzogen Ziel : Vermeiden von WP- Blockaden durch User- Inter-aktionen 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!! Unvorhersehbar lange Zeiten der User-Interaktion dürfen nicht in DB- LUW eingehen! Sonst Blockaden und schwere Performance- Engpässe!

31 Vergleich typischer Zeitskalen : User-Interaktion vs. Systemaktivität (42) 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 (43) 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 Schlechte Performance bei vielen parallelen DB-Usern

33 Asynchrone Verbuchung durch Verbuchungs-Workprozess (44) Dialog-Server Verbuchungs-Server Dispatcher ABAP : COMMIT WORK Dispatcher... ABAP : Call Function in update task 1 D-WP 2 3 MS V-WP Entkopplung von Dialog-WP und DB-Update + 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 (45) Ziel : SAPGUI Trennung der Dialogschritte von vorzunehmenden DB-Änderungen 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- Protokolltabelle SQL in spez. Funktionsbausteinen asynchron Workprozess Verbucher- WP Organisation der gesammelten DB-Änderungen durch Verbuchungs-Workprozess Prinzip : DB-Änderungen der einzelnen Dialogschritte nicht sofort ausgeführt Erst protokolliert zur späteren gemeinamen Ausführung vorgemerkt - in Protokolltabelle Ende der SAP-Transaktion protokollierte DB- Änderungen komplett ausgeführt Änderungen nicht direkt durch Wäre synchron wartend auf Ende der jeweiligen DB-Änderung Übergeben Änderungsaufträge an den Verbuchungs-WP Asynchron Dialog-WP wartet nicht auf Verbucher!

35 Vormerkungen schreiben : Verbuchungsbausteine (47) 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 + Parameter Funktionsbaustein enthält SQL-Anweisungen für DB-Änderungen 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 dürfen nicht ausgeführt werden! Protokollsätze der fraglichen SAP-LUW werden verworfen + gelöscht (48) Workprozess Vormerkung 1 Vormerkung 2 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 Zeitliche Koordination der Verbuchung : Asynchrone Verbuchung (50) Zeit VBLOG auf DB Dialog-WP Verb.-WP 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 Warum müssen Sperren gesetzt werden? (52) Programm A Programm B Verwaltung des konkurrierenden Zugriffs auf gleiche Daten Programm C Datenbank Mehrere Verwender greifen auf gleiche Ressource zu Synchronisation erforderlich, um Konsistenz der Daten zu gewährleisten : Ausschließender Zugriff! Tab 1 Tab 3 Tab 4 Tab 6 Sperren nur so lange wie nötig halten! 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

39 Datenbanksperren nicht ausreichend im SAP-Umfeld (53) Datenbanksperren reichen nicht SAP-Transaktion : Ersteckt sich i.a. über mehrere Bildschirmbilder COMMIT (implizit) COMMIT (implizit) COMMIT WORK (explizit) Sperren müssen länger gehalten werden als nur über 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!

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

41 Logische Sperren setzen + löschen Auftrag : Erzeuge Sperre Anforderung Sperre + Eintrag in Sperrtabelle sowie späteres Löschen der Sperre erfolgt mit speziellen ABAP-Funktionsbausteinen * (55) Sperrtabelle Zurücksetzen der Sperren : ABAP Programm Sperrbaustein Sperreintrag erzeugen a) durch Programm oder b) 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-<...> Werden 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)

42 Sperrmodi E = Exclusive Schreibsperre (57) Daten sollen geändert werden vom Anforderer der Sperre Andere können weder schreiben noch lesen! Andere können keinerlei Sperren für dasselbe 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 dasselbe Objekt erhalten Vergleich SAP Sperren / 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

43 SAP-App-Server Lastverteilung (59) 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

44 Workprozessverteilung (60) Service Systemweit Per Instanz (App-Server) 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 a) Message Server b) Dispatcher c) Enqueue Server 3. Weitere Instanzen Instanzprofil : Durch Profildatei festgelegt 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 rdisp/ wp_no_btc = 1... Abfrage System-Werte : Report RSPFPAR Automatischer Betriebsartenwechsel des Systems : Anpassung an aktuelle Anforderungen Automatische Änderung der Workprozess-Verteilung zu vordefinierten Zeitpunkten, zb: Tagesbetrieb Zahlreiche Dialog-WPs (überwiegend Dialog-User, wenige Batchjobs) Nachtbetrieb Umwandlung von Dialog-WPs in Batch-WPs (überwiegend Batch)

45 Betriebsarten-Konzept : Anpassung Instanzen an Lastverteilung (62) Betriebsart Tag : Primär Dialogverarbeitung Betriebsart Nacht : Primär Hintergrundverarbeitung Dispatcher Dispatcher D D D D B D D B B B Anforderungen User an System schwanken Ziel : Optimale Ausnutzung von CPU + Speicher Art + Zahl der aktiven Workprozesse umschalten : Gesamtzahl der Workprozesse bleibt konstant, aber Verteilung auf Typen kann geändert werden Umschaltplan definierbar mittels Pflege-Transaktion Umschaltung dynamisch bei laufendem System gemäß festgelegtem Zeitplan. Kein System-Neustart nötig 1. Qualität der Puffer bleibt erhalten 2. Kein Abbruch laufender Requests

46 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 (63) 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 -SQL 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 jede Änderung lauffähig! Vermeidet herstellerspezifische SQL-Statements - kein manuelles Öffnen / Schließen von DB-Verbindg. Wird auf DB-spezifischer DB-Schnittstelle des App-Servers in Native-SQL umgesetzt

47 Exkurs : CAP-Theorem und Verteilte Systeme (67) Consistency All clients have the same view on the data Atomic Consistency Continuous Availability Availability Partition Tolerance All clients can always read and write within some maximum latency Partition Tolerance No set of failures less than network failure is allowed to cause the system to respond incorrectly 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 die Wahl zwischen Consistency und Availability Beide Anforderungen sind nicht simultan erfüllbar!

48 SAP Puffer : Tabellenpuffer der App-Server (68) App-Server 1 Tabellen puffer ABAP Programm 1 ABAP-Open-SQL ms 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 Füllen Puffer : Beim ersten Lesen Nach Änderungen via ABAP Nach Synchronisation - s.u. Datenbank Atomic Consistency CAP-Theorem Continuous Availability Ziel der Pufferung von DB-Tabellen auf App-Servern : Reduzierung Lese-Zugriffszeit Rascher Zugriff auf App-Server Partition Tolerance Entlastung Datenbank Reduzierung Zahl teurer(!) DB-Zugriffe Bei verteilten Systemen nur zwei von dreien zu haben

49 Aktualisierung + Synchronisation von SAP Puffern (69) App-Server 1 PROGRAM z... UPDATE dbtab1... App-Server 2 ABAP Programm 2 Zeitverzögerte Synchronisation der Puffer der anderen App-Server! dbtab1 DB- Schnittstelle DB- Schnittstelle dbtab1 Kann Systemverhalten beeinflussen! Nicht alle Tabellen puffer-geeignet! Nur vorwiegend gelesene Tabellen! 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 : Netzlast geringer gehalten kein Broadcast Nachteil : Lokale Puffer enthalten eventuell veraltete Daten Leseintervall gem. Profilparameter bufreftime

50 SAP-Tabellenpuffer - Checkliste zur Pufferung von Tabellen (70) Pufferungsfähige Tabellen sind : relativ kleine Tabellen, auf die überwiegend lesend zugegriffen wird Tabellen, deren Inhalt sich selten verändert z.b. Tabellen mit Stammdaten, Customizing Parametern... Pufferung problematisch : wenn verwendete Daten ständig aktuell sein müssen, so dass evtl Abweichungen innerhalb Synchronisationsperiode nicht tolerierbar sind wenn administrativer Overhead aufgrund häufiger Verdrängung und rascher Synchronisation bei häufigen Änderungen der Inhalte zu hoch wird wenn Tabellen zu groß sind, so dass Neufüllen der Puffer nach Änderungen zur Synchronisation zu zeitaufwendig wäre Wichtig für performanten Puffereinsatz : Wahl der richtigen Pufferungsart : wird bei Anlegen der Tabelle festgelegt Residente Pufferung - gesamter Tabelleninhalt wird komplett gepuffert Generische Pufferung - nur Bereiche der Tabelle werden gepuffert Partielle Pufferung - nur Einzelsätze von DB gelesen und gepuffert