View
224
Download
3
Category
Preview:
Citation preview
(1)
© H.Neuendorf
Architektur + Entwicklung des SAP ERP-Systems
� 1. Klassischer SAP ABAP-Applikationsserver Klassik
� Dreistufige Client-Server Architektur
� Workprozesse eines verteilten Systems
� SAP-LUW Verbuchung SAP-Sperrkonzept
� DB-Zugriff Tabellenpuffer CAP-Theorem
� 2. Weiterentwicklung - NWAS Web
� SAP NetWeaver AS → System-Öffnung : Internet & neue Technologien
� SAP-Web-Programmierung → ICF + Business Server Pages
� SWE-Projekt 5.Semester
� ERP-Systeme Prof.Dr. Palleduhn
Prof. Dr. H. Neuendorf herbert.neuendorf@dhbw-mosbach.de
(2)
© H.Neuendorf
Literaturhinweise
� R. Plota, W. Fix: SAP – Der technische Einstieg, SAP PRESS (Rheinwerk) 2017 (1).
� S. Hagemann, L. Will, R. Mayr: SAP NetWeaver AS ABAP Systemadministration,
SAP PRESS (Rheinwerk) 2015 (5).
� T. Schneider: SAP-Performanceoptimierung, SAP PRESS (Rheinwerk) 2017 (8).
� F.Heinemann, C.Rau : SAP Web Application Server, SAP PRESS (Rheinwerk) 2005 (2).
� H. Gahm et.al.: ABAP-Entwicklung für SAP HANA, SAP PRESS (Rheinwerk) 2015 (2).
� C. Bönnen et al.: SAP Gateway und OData, SAP PRESS (Rheinwerk) 2016 (2).
� C. Goebels et al.: SAPUI5, SAP PRESS (Rheinwerk) 2016 (1).
� A. Bavaraju: SAP Fiori Implementation and Development, SAP PRESS (Rheinwerk) 2016(1).
(3)
© H.Neuendorf
Klassischer SAP Applikationsserver ABAP
� Anforderungen an ERP-Systeme
� Dreistufige Client-Server Architektur
� Workprozesse eines verteilten Systems
� SAP-LUW - SAP-Verbuchung - SAP-Sperrkonzept
� DB-Zugriff - Tabellenpuffer - CAP-Theorem
(4)
© H.Neuendorf
Anforderungen an ERP-Systeme
� ERP-Systeme : Eigenschaften & Anforderungen
� Leitende Fragestellungen
� Kriterien der Wandlungsfähigkeit von ERP-Systemen
� Transparenzleistungen Verteilter Systeme
� Historie der SAP-Selbstdarstellung
� SAP-Systembezeichnungen
(5)
© H.Neuendorf
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
> 300.000 Installationen in > 200 Ländern
ERP = Enterprise Resource Planing
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 ?
(6)
© H.Neuendorf
Abstrakte Kriterien der Wandlungsfähigkeit von ERP-Systemen
Quelle: Gronau: "Enterprise Resource Planing", Oldenbourg, 2010, S.52ff [angepasst]
Eigenschaften wandlungsfähiger
ERP-Systeme
SkalierbarkeitKapazitätsmäßige
Anpassung
ModularitätStruktureller Aufbau aus
unabhängigen Teilsystemen
VerfügbarkeitFlexible Zugreifbarkeit
unabhängig von Ort und Zeit
WissenSelbstauskunft des
Systems
SelbstähnlichkeitÄhnliche Strukturen auf
unterschiedlichen Systemebenen
UnabhängigkeitPlattformunabhängigkeit
Autonome Subsysteme und Services
InteroperabilitätKommunikationsfähigkeit mit anderen Systemen
(7)
© H.Neuendorf
Transparenzleistungen Verteilter Systeme und ihrer Middleware
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
(8)
© H.Neuendorf
Historische Entwicklung des SAP-Systems
Aufbrechen der monolithischen Struktur in separate Teillösungen
Öffnung des Systems für neue Technologien … Entwicklung setzt sich fort :
SOA, Cloud, Mobile, BigData …
(9)
© H.Neuendorf
Selbst-Darstellung SAP-Welt
Betonung Anwendungs-vielfalt + Modularität
Wir sprechen hier über den (ABAP-) Applikationsserver
SAP ERP
Applikations Server :
→→→→ NetWeaver 7 AS ("die Basis")
aktuell NW AS 7.x
Bwl. Kernkomponenten :
→→→→ SAP Business Suite
(14)
© H.Neuendorf
Klassik : SAP-Applikationsserver / Client-Server
� SAP Applikationsserver
� Client / Server - Prinzip / Tier & Layer
� Klassische dreistufige verteilte Architektur
3-Tier / - Layer Skalierbarkeit
� SAP Workprozesse
(15)
© H.Neuendorf
SAP Applikationsserver Gemeinsame Basis + Middleware
SAP Applikationsserver
ABAP (anwendungsübergreifend)
Betriebssysteme + DB
Hardware-Plattformen
SAP Anwendungen
HCM, FI, MM, SD, CO ...
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 : Unix Linux MS
DB : Oracle DB2 … anyDB
GUI: SAPGUI WebGUI
NetWeaver Business Client via WebDynpro
WebClient via BSP Mobile via SAPUI5
Netz: 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
(17)
© H.Neuendorf
Client / Server
Client
ServerLAN / WAN
Hardware-orientierte Sicht :
Client
Prozess
ServerProzess
Anforderung
Dienstleistung
Erbringen
Dienstleistung
Software-orientierte Sicht :
Service = Dienst, der von einer Software-Komponente angeboten wird
Komponente = Fachliche Komposition von Services
Layer : Logische Schichtung Tier : Physische Schichtung
Niedrige WAN-Transferraten bei R/3-Etablierung :
Zugriff auf Server übers WAN von Anfang an intendiert !
Architektur des App-Servers musste dies performant zulassen !
(18)
© H.Neuendorf
SAP Client / ServerKlassische dreistufige verteilte Architektur 3-Tier / 3-Layer
Quelle: M. Sahlmüller (WI13) Bachelorarbeit, 2016
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
Erweiterung dieser Sicht aktuell durch S/4 HANA …
(19)
© H.Neuendorf
SAP Client / Server
Präsentationsschicht
User- Eingabe / Ausgabe
ApplikationsschichtProgrammlogik +
DB-Zugriffe
PersistenzschichtZentrale DB →
Alle Daten + Anwendungsprogramme + Datentypen (Dictionary)
LAN
LAN / WAN
SAPGUI SAPGUI SAPGUI
Application Server 1 Application Server n
Database Management System
Database
?KByte
KByte - MByte
Browser
Mobile
(20)
© H.Neuendorf
Verteilte Client / Server- Konfigurationen
Einstufige Konfiguration(Demo-System)
Zweistufige Konfiguration
(Two Tier)
Dreistufige Konfiguration
(Three Tier)
DB + Appl. + Präsentation DB + Appl. DB
Applikation
Präsentation Präsentation
Kleines Kundensystem
(ca. 100 User)Skaliert nicht !
Regelfall : skaliert !!
Horizontale Verteilung
Ver
tikal
e V
erte
ilung
(22)
© H.Neuendorf
Dreistufige Architektur - Prozesse
Database Management System
Database
SAP GUI
Admin
DIA SPOBTC V Mes
sage
Ser
ver
ENQVDIA BTC
SAP GUISAP GUI
10 - 20 Workprozesse
pro Applikations-Server
5 - 10 User pro Dialog-
Workprozess
1 - n Applikations-
Server
Application Server 1 Application Server n
App-Server-Workprozess :Spezialisiertes Programm für definierte Services
(23)
© H.Neuendorf
Klassik : Realtime Dialog-Betrieb
� Dialog-Betrieb mittels Dialog-WP (DWP)
� Dispatcher-Pattern
� Dialog-WP im Detail
� Entkopplung User-Verhalten und WP-Zuordnung
� Verteilung Benutzeranfragen auf Dialog-WP
� Dialog-WP im Detail
(24)
© H.Neuendorf
SAP Dispatcher : Verteilung Benutzeranfragen auf Dialog-Workprozesse
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
Applikationsserver
Relationale Datenbankkennt nur WP - nicht indiv. User
SAP GUI
DBDBMS - Prozesse
Dispatcher
Work-prozess
Puffer Shared Memory
SAP GUI SAP GUI SAP GUI
Work-prozess
Work-prozess
Request Queues
RollbereichBenutzerkontext
fifo
DIAG-Format via TCP/IP1
2
3
4
5
6
7
8
9
SA
P A
S hält K
ontext / State
�
arbeitet statetful !
(26)
© H.Neuendorf
Entkopplung User-Verhalten und Workprozess-Zuordnung
Typische Eingabezeitdes Users ist länger als Verarbeitungszeitauf 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 !
(27)
© H.Neuendorf
Verteilung Benutzeranfragen auf D-WorkprozesseAbbildung zahlreicher Userauf wenige Dialog-Workprozesse mittels Request Queue
+
Zuordnung von App-Server-WPs zu DB-WPs
�
Zahl der effektiven DB-Benutzer deutlich geringer als Zahl der System-User
DB entlastet !
SAPGUI
Work-prozess
Dispatcher
Datenbank -Workprozess
SAPGUI SAPGUISAPGUI
Work-prozess
Work-prozess
n : 1SharedMemory
User-Interaktion 5 -10 x länger als Bearbeitungszeit durch Workprozess
� 5 -10 Frontend-User im Mittel pro Dialog-WorkprozessVorraussetzung : Keine lang laufenden Programme, die DWP belegen !!
SAP Logon
Workprozess-Multiplexing :
Transaktion durch verschie-dene, jeweils nur pro Einzelschritt zugeordnete D-Workprozesse abgearbeitet
Kommunikation zwischen Dispatcher und WPs via Shared Memory
SAP-Transaktion : Aufeinanderfolgende, inhaltlich zusammengehörige Bildschirmbilder ≡Teilschritte der Gesamt-Transaktion
(28)
© H.Neuendorf
Dialog-Workprozess
Der Dialog-Workprozess
Shared Memory
Request -Queues
SAPGUI
Dispatcher
DynprosABAP-ProgrammeTabellen...
Applikations-Puffer
Roll FileUser-Kontext
Roll-Bereich
Dynpro -
Prozessor
ABAP-
Prozessor
Datenbank-
schnittstelle
Task-
Handler
inte
rner
Spe
iche
rRoll inRoll outPuffer-Zugriffe
LAN - / WAN
WP n
...
WP 1
Roll File
Request Queue
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
Maximale Dauer begrenzt ! Langlaufende Programme als Batch realisierbar !
(29)
© H.Neuendorf
Ausführung ABAP- Code
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
Sourcecode
ABAP Objects
( Ausgeliefert ! )
ABAP ILIntermediate
Language
( Bytecode )
Ausführung
Durch ABAP VM
Interpretation
VM
Strukturierte Zusammenfassung von ABAP-Code in Paketen
(30)
© H.Neuendorf
Performanz-Analyse Dialog-Betrieb : Scatter-Plot
Accumulierte Antwortzeit = durchschnittliche Antwortzeit * Anzahl der Ausführungen
= durchschnittliche Antwortzeit
= ac
cum
ulie
rte
Ant
wor
tzei
t
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
Hoher Workload bei wenig freien Ressourcen
System hat genügend freie Ressourcen
GeringerWorkload
Zu wenig freie Ressourcen / System falschkonfiguriert
(31)
© H.Neuendorf
Exkurs : SAP HANA
Verlagerung von Anwendungs-logik von Applikationsschicht in DB-Schicht zur Nutzung IMDBbei 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…
(32)
© H.Neuendorf
Paradigmen : Data to Code (D2C) versus Code to Data (C2D)
Nutzung traditioneller DB-Technologie folgt D2C Nutzung IMDB (HANA) folgt C2D
���� Code-Pushdown-Prinzip
���� Umgang mit DB : aus black box wird white box
Präsentationsschicht
Applikationsschicht
Persistenzschicht (DB)
Orchestrierungslogik
Kalkulationslogik
Daten
Präsentation
Orchestrierungslogik
Kalkulationslogik
Daten
Präsentation
(35)
© H.Neuendorf
Klassik : Weitere Workprozesse
� Klassische Workprozess-Typen
Server-Übersicht / Prozess-Übersicht
� Message-Server
Logon-Load-Balancing
� Hintergrundverarbeitung - Batch-Workprozess
(36)
© H.Neuendorf
Workprozess-Typen
Dialog
SAP-Dispatcher
Spool
Batch12
9
6
3
11 1
7 58 4
210
Verbuchung
Sperrverwaltung
Message-Server
Disp .
Disp .
Disp .
Disp .
MSMS
Gateway-Server
R/3z.B.R/3GWGW
Message Server → Komunikation zwischen Dispatchern verschiedener App-Server eines SystemsGateway Server → Kommunikation zwischen SAP-Systemen oder mit externen SystemenDialog → Abarbeitung Dialoganfragen
Spool → Verwaltung DruckaufträgeVerbuchung → Verwaltung + Bündelung + transaktionale Ausführung von DB-ÄnderungenSperrverwaltung → Verwaltung logischer Sperren (Enqueues) für DB-Tabellen
Batch → Verwaltung dialogfreier Hintergrundprozesse (Jobs)
Pro App-Server :
1x Dispatcher
2x Dialog-WP
Nur 1x pro System :
Message Server
Enqueue Server
Dispatcher + alle Workprozesse : Identische Programme !
���� Workprozesstyp kann durch Dispatcher umgeschaltet werden - ohne Neustart App-Server
(37)
© H.Neuendorf
ABAP- und Java-Stack : Dispatcher-WP- Bild bleibt gültig
Web Application Server
Operating SystemLinuxUnix
OS/400OS/390
Windows
ABAPABAP
DB Server
DBMSOracleInformix
IBM DB2 SAP DB
MS SQL Server
JEEJEE
Java VMJava VM ABAP VMABAP VM
BrowserBrowser
(38)
© H.Neuendorf
Server-Übersicht
Server Darauf laufende Workprozess-Typen
Aufruf : sm51
Werkzeuge → Administration → Monitor → Systemüberwachung → Server
Doppelklick auf Servernamen liefert WP-Verteilung
(39)
© H.Neuendorf
Prozess-Übersicht
Aufruf : sm50
Werkzeuge → Administration → Monitor → Systemüberwachung → Prozesse
Doppelklick auf Listeneintrag liefert Infos zum laufenden Prozess …
(40)
© H.Neuendorf
Message-Server
InstanzAdministrative Einheit, die Services anbietet
Message ServerZentraler Dienst : Kommunikation zw.
Dispatchern der Applikationsserver
Anmeldung von Usern an Applikationsserver
�
Skalierbarkeit
Lastverteilung
SAPGUI
Logon - Load-
Balancing
D-WP
Dispatcher
Instanz : Batch-ServerInstanz : Dialog-Server
Zentrale Instanz : enthält MS 1 x pro System
Dispatcher
. . .D-WPD-WP
. . .
. . .
MS
Dispatcher
D-WP B-WP
V-WP E-WP B-WP S-WP
MS : 1. Dispatcher melden sich beim MS mit ihren verfügbaren Workprozessen an2. 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
AppServer Info WPs + Load
(42)
© H.Neuendorf
Batch →→→→ Dialogfreie Abarbeitung lang laufender Programme - keine Benutzeraktion !
� Periodische Aufgaben - Reorganisation, Datenübernahme …
� Jobs in Einplanungstabelle → Name, Prio, Starttermin / Event
� Anstoß durch Batch-Scheduler via Einplanungstabelle
Ausgelöst zu definierter Zeit oder durch Systemereignis
Hintergrundverarbeitung - Batch-Workprozesse
C
Hintergrundverarbeitung
DBDB
11
44
12
9
6
3
11 1
7 5
8 4
210
Job
22
Dialog-Server
. . .D-WP
Hintergrundverarbeitungs-Server
. . .
XXX xxxx
XXX xxxx xxxx xxx xxx xx
UUU uuuu uuuu uuu uuu uuUU uuuu uuu u
Einplanungstabelle
Job1 C ...... ......
Batch Schedulerrdisp/btctime Default = 60s
DispatcherDispatcher
D-WP B-WPB-WPB-WP
33
Jobstatus
� geplant
� freigegeben
� bereit
� aktiv
� fertig
� abgebrochen
↓
Jobübersicht
(43)
© H.Neuendorf
Jobübersicht
Aufruf : sm37
Werkzeuge → CCMS → Jobs → Pflege
Doppelklick auf Listeneintrag liefert Infos zum Job …
(48)
© H.Neuendorf
SAP-LUW versus DB-LUWProblem Transaktionalität / Verbuchung
� DB-LUW
� SAP-LUW
� Verhalten SAP DBMS
� Direkte synchrone DB-Änderungen aus Dialog /
Synchrone Verbuchung
� Asynchrone Verbuchung durch Verbuchungs-WP
� Vormerkungen : Verbuchungsbausteine
(49)
© H.Neuendorf
Datenbank-LUW (Logical Unit of Work)
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
KonsistenterZustand 1
Zwischenzustände
KonsistenterZustand 2
ROLLBACKmöglich
Datenbankoperationeninsert update delete
DB-COMMIT(oder DB-Rollback)
Sperren auf DB-Tabellensätze haltenalle Sperren freigeben
Physische Sperren :
Nicht hintergehbar !
(50)
© H.Neuendorf
SAP-Transaktion = SAP-LUW versus DB-LUW →→→→ Mismatch !!
DB- LUW
SAP-LUW
DB-Änderungen
ABAP-programme
Benutzerdialoge
Forderung nach Transaktionalität ����
DB-Änderungen einer SAP-Transaktion auf eine DB-LUW bündeln
Logical Unit of Work
Problem : Ohne geeignete Maßnahmen verteilt sich eine SAP-LUW auf mehrere DB-LUWs !!
(51)
© H.Neuendorf
Verhalten SAP DBMS : Automatischer DB-COMMIT
Systemarchitektur: Impliziter DB-COMMIT
DB-LUW 1 DB-LUW 2 DB-LUW 3 DB-LUW 4 Zeit
DB-COMMITDB-COMMIT 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
Wenn App-Server-WP endet, müssen auch zugehörige DB-Änderungen erfolgen �
DB-Commit automatisch ausgelöst !
SAP-Transaktion : Umfasst in der Regel mehrere Dialogschritte
DB-LUW : Umfasst nie mehr als einen einzigen Dialogschritt
Keine Benutzer-Interaktion innerhalb DB-LUW !!
(52)
© H.Neuendorf
Vergleich typischer Zeitskalen : User-Interaktion vs. Systemaktivität
Screen300
Screen100
Screen200
kurze DB LUWs
PBO PBO PBOPAI PAI PAIScreen
300Screen
100Screen
200
Schematische Sicht
Lange User InteraktionenZeitlich realistische Sicht
SAP Logical Unit of Work
User Interaktionen
PBO : Process before Output PAI : Process after Input
Unvorhersagbar lange Benutzer-Interaktions-Zeiten dürfen nicht in DB-LUW eingehen !
|- Dialogverarbeitung-| |- Dialogverarbeitung-|
(53)
© H.Neuendorf
Direkte synchrone DB-Änderungen aus Dialog
SAP Transaktion
Dialog-schritt 1
Dialog-schritt 2
LetzterDialog-schritt
Globale Daten des Programms ITABs
Daten Daten
...
Daten
Daten
Zeit
Sichern :UPDATE tab1.
UPDATE tab2.
............
synchron
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
(54)
© H.Neuendorf
Asynchrone Verbuchung durch Verbuchungs-Workprozess
DBDB XXX xxxx
XXX xxxx xxxx xxx xxx xx
UUU uuuu uuuu uuu uuu uuUU uuuu uuu uVB*
Verbuchungs-Server
. . . . . .
MS
. . .
Dialog-Server
D-WP
Dispatcher
V-WP
DispatcherABAP :
COMMIT WORK
1
2 3
4 5
Protokolltabellen
DB-Änderungen: Nicht direkt im Dialog ausgeführt - sondern in Protokolltabelle nur vorgemerkt
Ausführung = Schreiben in DB → asynchron an Verbuchungs-WP delegiert
Entkopplung von Dialog-WP und DB-Update
+
Bündelung von DB-Änderungenzur gemeinsamen Ausführung
�
Transaktionalität !
ABAP :Call Function in update task
(55)
© H.Neuendorf
Verbuchung : Bündelung von Datenbankänderungen
Workprozess
Dialog-WP
Workprozess
Verbucher-WP
SAPGUI
Ziel : 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
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
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 !
asynchronProtokoll-tabelle
SQL in spez. Funktions-bausteinen
(57)
© H.Neuendorf
Vormerkungen schreiben : Verbuchungsbausteine
Protokolltabelle
Vormerkung 3
Vormerkung 1
Vormerkung 2
Workprozess
Dialog-WP
11
Daten
.
CALL FUNCTION 'F1' EXPORTING
p2 = .....
...
.
CALL FUNCTION 'F2'EXPORTING
.
.
.
...
.
CALL FUNCTION 'F1'EXPORTING
...
a = 1
b = 2
q1 = b
p1 = a
IN UPDATE TASK
IN UPDATE TASK
Dialogprogramm
c = 3IN UPDATE TASK
p1 = c
p1 = 1
q1 = 2
p1 = 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
Abschluss durch : COMMIT WORK
(58)
© H.Neuendorf
Wirkung von Rollback WorkROLLBAK WORK
Vormerkung 3
Vormerkung 1
Vormerkung 2
Workprozess
Dialog-WP
PROGRAM ...
.
.
ROLLBACK WORK.
Dialogprogramm
Löschen aller bisdahin geschriebenenVormerkungen
Protokoll -tabelle
Fehler innerhalb SAP-LUW �
DB-Änderungen nicht ausgeführt �
Protokollsätze der SAP-LUW gelöscht
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
(60)
© H.Neuendorf
Asynchrone Verbuchung
AA
BB
CC
SAP-LUW 1 Dialogprogramm
SAP-LUW 1 Verbuchungsprogramm
SAP-LUW 2 Dialogprogramm
Text
Vormerkung n
Vormerkung 1
. . .
Protokoll-tabelle
VBLOGauf DB
DB
Dialog-WP Verb.-WP
COMMIT WORK.
AA
BB
CC
Zeit
Dialogprozess wartet NICHT auf Ausführung der DB-Änderung !
Dialogprozess und Verbuchung sind zeitlich entkoppelt asynchron !
(61)
© H.Neuendorf
Synchrone Verbuchung
Verb.-WPDialog-WP
COMMIT WORKAND WAIT.
AA
AA
BB
CC
SAP-LUW 1 Dialogprogramm
SAP-LUW 1 Verbuchungsprogramm
SAP-LUW 2 Dialogprogramm
BB
CC
Zeit
Text
Vormerkung n
Vormerkung 1. . .
Protokoll-tabelle
VBLOG
DBDB
Dialogprozess wartet auf Ende der Ausführung der DB-Änderung !
COMMIT WORK AND WAIT
(62)
© H.Neuendorf
SAP - High-Level-Sperrkonzept
� Setzen von Sperren
� DB-Sperren nicht ausreichend im SAP-Umfeld
� SAP Sperrkonzept :
Logische Sperren
ENQUEUE-WP
� Sperren setzen + löschen
� Sperrmodi
� SAP Sperren vs. DB-Sperren
(63)
© H.Neuendorf
Warum müssen Sperren gesetzt werden ?
Verwaltung konkurrierenden
Zugriffs auf selbe Daten
Programm CProgramm C
Tab 1
Tab 2
Tab 3
Tab 4
Tab 5
Tab 6
Programm A
Programm B
Mehrere User greifen auf selbe Ressource zu �
Synchronisation erforderlich, um Konsistenz zu garantieren :
Ausschließender Zugriff !
Datenbank
Sperren : Datenbankobjekt wird zeitweise für Zugriff eines Prozesses
reserviert - für Zugriffe aller anderen gesperrt
Sperren nur so lange wie nötig halten !
Performance-Bottleneck
Physische Sperren :durch DB selbst
Logische Sperren :durch Programmier-Konvention
(64)
© H.Neuendorf
Datenbanksperren nicht ausreichend im SAP-Umfeld
Datenbanksperren reichen nicht
COMMIT(implizit)
SELECTUPDATE DELETEDELETEINSERTINSERTUPDATEUPDATE
Sperren
COMMIT(implizit)
COMMITWORK(explizit)
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 !
SAP-Transaktion :
Ersteckt sich i.A. über mehrere Bildschirmbilder
�
Sperren müssen länger gehalten werden als nur über einen Dialogschritt
(65)
© H.Neuendorf
SAP Sperrkonzept : Logische(!) Sperren - ENQUEUE-Workprozess
Ziel : Sperren über Bildwechsel system-global aufrechterhalten
Mittel : Globale Sperrtabelle auf App-Server - enthält Verzeichnis gesperrter Tabellen
Enq.-WP + Sperrtabelle
Auf AS !
1 x pro System
DB-unabhgängiger high-level Sperr-Mechanismus
SAP Sperrkonzept: logisches Sperren
. . .
Dispatcher
DB Management System
DialogWP
Dialog . . .
Dispatcher
WPEnqueue
WP
SperrtabelleMessageServer
SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI
(66)
© H.Neuendorf
Logische Sperren setzen + löschen
ABAP Programm
Sperrbaustein
Auftrag :Erzeuge Sperre
Antwort :Sperre erfolgreich gesetzt
Keine Sperre gesetztEintrag bereits gesperrtFehler in Sperrverwaltung
Sperrtabelle
EXCEPTIONSkeine
FOREIGN_LOCKSYSTEM_FAILURE
ABAP-Programm reagiert durch Auswertung Returncode
Wenn Sperre bereits gesetzt ist : weitere Anforderungen abweisen
Anforderung Sperre + Eintrag in Sperrtabelle sowie späteres Löschen der Sperre mit speziellen ABAP-Funktionsbausteinen *
*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)
Sperreintrag erzeugen
Call Function ENQUEUE_...
Sperren zurücksetzen :
durch Programm
oder
durch Verbucher
(68)
© H.Neuendorf
Sperrmodi� E = Exclusive → Schreibsperre
� 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 Anwendungs-programmen
� 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
(70)
© H.Neuendorf
Weitere Strukturen & Performanz-Technologien
� SAP Lastverteilung
� Workprozessverteilung und Einstellung
� Betriebsarten-Konzept
� SAP DB-Schnittstelle
� Exkurs : CAP-Theorem & Verteilte Systeme
� SAP Puffer : Tabellenpuffer der App-Server
Aktualisierung + Synchronisation
Pufferungsprinzipien & -Arten
(71)
© H.Neuendorf
SAP Lastverteilung
Table Buffers
Dispatcher
SPOWP
BTCWP
DIAWP
Table Buffers
Dispatcher
DIAWP
ENQWP
EnqueueTable
SAPGUI
SAPGUI
SAPGUI
SAPGUI
SAPGUI
DBWPDBWPDBWP DBWP
GatewayGateway
Zugriffszeit Speicherverbrauch Data / Dialogschritt
0.1ms
1ms
100ms
MB
100 KB
TB
GB
MB-GB
MB
DB (disk)
DBMS
App-Server 1 App-Server n
(72)
© H.Neuendorf
Instanzprofil : In Profildatei → bei Serverstart ausgewertetArt + Anzahl der vom Dispatcher gestarteten WorkprozesseGröße von Puffern, Rollbereichen, Logfiles ...Rechnername Messageserver, Enqueueserver, DB-Rechner ...
rdisp/ wp_no_dia = 3rdisp/ wp_no_upd = 4 ...
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)
Workprozessverteilung
Service Systemweit Per AS-InstanzDialog >=2 >=2
Verbuchung >=1 >=0Enqueue 1 0 oder 1Batch >=1 >=0Message 1 0 oder 1
Gateway >=1 1Spool >=1 >=0
Systemstart :
1. Datenbank
2. Zentrale Instanz
3. Weitere Instanzen
Abfrage System-Werte :Report RSPFPAR
(74)
© H.Neuendorf
Betriebsarten-Konzept : Anpassung Instanzen an Lastverteilung
D D D D B
Dispatcher
Betriebsart Tag :Primär Dialogverarbeitung
D D B B B
Dispatcher
Betriebsart Nacht :Primär Hintergrundverarbeitung
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
(75)
© H.Neuendorf
SAP Datenbank-Schnittstelle
Die SAP Basis-Datenbankschnittstelle
Native-SQL
Daten
Applikationsserver Datenbank
ABAP Interpeter
SELECT *FROM
EXEC SQL.SELECT ....END EXEC. DB - Daten
Native -SQL
OPEN-SQL
Daten
DBSchnitt-stelle
LokalePuffer
Daten
RelationaleDatenbank
Native-SQL
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
Native-SQLNutzt vollen
Sprachumfang
aber :
Code abhg. von DB-Hersteller !
Umgeht Tabellenpuffer !
Open SQLPlattform- und
DB-unabhängig
Verschalung der DB-Schnittstellen
verschiedener DB-Hersteller
(79)
© H.Neuendorf
Exkurs : CAP-Theorem und Verteilte Systeme
Consistency
All clients have the same view on the data
Availability
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 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 !
Atomic
Consistency
Continuous
Availability
Partition Tolerance
Bei verteilten Systemen nur zwei von dreien zu haben …
(80)
© H.Neuendorf
SAP Puffer : Tabellenpuffer der App-Server
DBMS
Datenbank
ABAP Programm 1
Tabellen puffer
DB-Schnittstelle
App-Server 1
ABAP Programm 2
Tabellen puffer
DB-Schnittstelle
App-Server 2
1 - 60 ms
Füllen Puffer :
Beim ersten Lesen
Nach Änderungen
Nach Synchronisation - s.u.
Ziel der Pufferung von DB-Tabellen auf App-Servern :
Reduzierung Lese-Zugriffszeit → Rascher Zugriff auf App-Server
Entlastung Datenbank → Reduzierung Zahl teurer DB-Zugriffe
Tabellenpuffer sind lokal zum jeweiligen App-Server in dessen Hauptspeicher
Open-SQL
Native SQL
Weitere Puffer für :
Programme
Bildschirmdaten
Dictionary-Daten
CAP-Theorem
Atomic
Consistency
Continuous
Availability
Partition Tolerance
(81)
© H.Neuendorf
Nicht alle Tabellen puffer-geeignet !
Nur vorwiegend gelesene Tabellen !
Aktualisierung + Synchronisation von SAP Puffern
DBMS
PROGRAM z... UPDATE dbtab1 ...
dbtab1 DB-Schnittstelle
AS 1
ABAP Programm 2
dbtab1DB-Schnittstelle
AS 2
Datenbankdbtab1 dbtab1 X
aktuell verzögert
bufreftime (60 - 3600 s)
Zeitverzögerte Synchronisation der Puffer der anderen App-Server !
Kann Systemverhalten beeinflussen !
Synchronisations-Informationen
Periodisch von App-Servern gelesen
Leseintervall → Profilparameter
bufreftime
App-Server, der Daten auf DB ändert, aktualisiert zugleich eigenen Puffer
Vorteil : Netzlast gering – kein Broadcast
Nachteil : Lokale Puffer enthalten eventuell veraltete Daten
(82)
© H.Neuendorf
SAP-Tabellenpuffer - Sinnvolle Pufferung von Tabellen
� 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
(83)
© H.Neuendorf
Resident Generisch1 Schlüsselfeld
Generisch2 Schlüsselfelder
PartiellEinzelsatz
key1 key2 key3 data
key1 key2 key3 data
key1 key2 key3 data
key1 key2 key3 data
001001001001002002002002002002003003003003003003003003
001001001001002002002002002002002002003003003003003003003003003003003
001001001001001002002002002002002002002002002003003003003003003003003003003003003003
AA
BB
AABBBC
DC
AAABBCCCDDD
AA
BB
BAAAABBBC
DC
AAABBCCCCDDDD
42
31
513681230
53
2362423581234
Drei Pufferungsarten
� 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
� Partielle Pufferung : Hoher Verwaltungsaufwand - geringster Speicherbedarf
� Residente Pufferung : Geringster Verwaltungsaufwand - höchster Speicherbedarf
(84)
© H.Neuendorf
Zusammenfassung & Ausblick
� SAP ERP AS :
Betriebliche Anforderungen & Technologische Lösungen
Integrations - Aspekte
� Neue Strategische Orientierungen …
(85)
© H.Neuendorf
SAP ERP AS : Anforderungen ↔↔↔↔ Technologische Lösungen
Prozessorientierung Anpassbarkeit der Prozesse
Plattformunabhängigkeit
Integrations - Aspekte :Bwl. Prozess-Integration Datenintegration Systemintegration Administrative Integration
Vermeidung von System-, Medien-, Prozess- und Organisationsbrüchen � Konsistenz
MultiUser MultiTasking
Begrenzte RessourcenDarstellung bwl. Transaktionen
Transaktionalität
Integrität der Daten
Wechselnde Anforderungen
Wechselndes Userverhalten
Anpassung an firmeninterne Auslastungssituation
ABAP-VM ABAP-Eigenentwicklung
ABAP-Open-SQL Mehrsprachigkeit
Dispatcher-WP-Mechanismus
Dialog- und Batch-Betrieb
Logon-Load-Balancing
Asynchrone Verbuchung
Verbuchung + High-Level-Sperrkonzept
Betriebsartenkonzept + Logon-Gruppen
Puffermechanismen auf App-Server
Hochgradige Administrierbarkeit
Recommended