Architektur + Entwicklung des SAP Basis Systems

(1)
Architektur + Entwicklung des SAP Basis Systems
Prof. Dr. H. Neuendorf
[email protected]
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
SWE-Projekt 5.Semester
( ERP-Systeme
© Dr. H.Neuendorf
Prof.Dr. Palleduhn )
(2)
ERP = Enterprise Resource Planing
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
> 250.000 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 öffenete sich das System vom monolithischen allwissenden ERP-Server zum kollaborativen System ?
© Dr. H.Neuendorf
Abstrakte Kriterien der Wandlungsfähigkeit von ERP-Systemen
(3)
Unabhängigkeit
Plattformunabhängigkeit
Autonome Subsysteme und
Services
Verfügbarkeit
Flexible Zugreifbarkeit
unabhängig von Ort und
Zeit
Kapazitätsmäßige
Anpassung
Eigenschaften
wandlungsfähiger
ERP-Systeme
Interoperabilität
Skalierbarkeit
Kommunikationsfähigkeit
mit anderen Systemen
Selbstähnlichkeit
Ähnliche Strukturen auf
unterschiedlichen
Systemebenen
Modularität
Wissen
Struktureller Aufbau aus
unabhängigen
Teilsystemen
Selbstauskunft des
Systems
Quelle: Gronau: "Enterprise Resource Planing", Oldenbourg, 2010, S.52ff [angepasst]
© Dr. 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
© Dr. H.Neuendorf
(4)
(5)
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 …
© Dr. H.Neuendorf
(6)
Selbst-Darstellung SAP-Welt
Betonung
Anwendungsvielfalt +
Modularität
SAP ERP
Applikations Server :
→ NetWeaver 7 AS ("die Basis")
aktuell NW AS 7.x
Bwl. Kernkomponenten :
→ EnterpriseCoreComponents
© Dr. H.Neuendorf
Wir sprechen hier
über den (ABAP-)
Applikationsserver
SAP Applikationsserver
(11)
Gemeinsame Basis + Middleware
SAP Anwendungen
HR, FI, SCM, CO ...
ABAP (anwendungsübergreifend)
SAP Applikationsserver
Betriebssysteme + DB
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
Hardware-Plattformen
Unterstützte Plattformen :
BS :
Unix Linux
DB :
Oracle MSSQLServer DB2 …
GUI:
SAPGUI
… alle relevanten
MS
HTMLGUI
NetWeaver Business Client via WebDynpro
WebClient via BSP
Netz:
TCP/IP – IPv6 unterstützt
© Dr. H.Neuendorf
Verteilung von Ressourcen +
Komponenten
Mobile Lösungen via UI5
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
(13)
Client / Server
Server
Hardware-orientierte Sicht :
Client
LAN / WAN
Niedrige WANTransferraten bei
R/3-Etablierung:
Zugriff auf Server
übers WAN von
Anfang an intendiert !
Software-orientierte Sicht :
Client
Prozess
Architektur des AppServers musste dies
performant zulassen !
Anforderung
Dienstleistung
Erbringen
Server
Prozess
Dienstleistung
Service
=
Komponente =
Dienst, der von einer Software-Komponente angeboten wird
Fachliche Komposition von Services
SAP-System =
Gesamtheit aller 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
© Dr. H.Neuendorf
SAP Client / Server
Klassische dreistufige verteilte Architektur
(14)
3-Tier / - Layer
Browser
Mobile
?
Präsentationsschicht
User- Eingabe / Ausgabe
SAPGUI
LAN / WAN
SAPGUI
SAPGUI
KByte
Applikationsschicht
Programmlogik +
Application Server 1
Application Server n
DB-Zugriffe
LAN
Persistenzschicht
KByte - MByte
Database Management System
Zentrale DB →
Alle Daten +
Anwendungsprogramme +
Datentypen (Dictionary)
© Dr. H.Neuendorf
Database
Verteilte Client / Server- Konfigurationen
Zweistufige Konfiguration
(ca. 100 User)
Skaliert nicht !
Präsentation
Horizontale Verteilung
Einstufige Konfiguration
Regelfall : skaliert !!
Dreistufige Konfiguration
(Three Tier)
(Two Tier)
Vertikale Verteilung
Kleines Kundensystem
(15)
Präsentation
Applikation
(Demo-System)
DB + Appl. + Präsentation
© Dr. H.Neuendorf
DB + Appl.
DB
(17)
Dreistufige Architektur - Prozesse
5 - 10
User pro
DialogWorkprozess
App-Server-Workprozess :
Admin
Spezialisiertes Programm für
definierte Servives
1-n
ApplikationsServer
SAP GUI
SAP GUI
Application Server 1
BTC
V
SPO
DIA
BTC
Database Management System
Database
© Dr. H.Neuendorf
10 - 20
Workprozesse
pro ApplikationsServer
Application Server n
Message
Server
DIA
SAP GUI
V
ENQ
SAP Dispatcher : Verteilung Benutzeranfragen auf Dialog-Workprozesse
1 User ↔ 1 WP ↔ 1 DB-Prozess
WP ist User nur während Verarbeitung zugeteilt !
(18)
Hoher Verwaltungsaufwand - aber während langer EingabeZeiten kann WP anderen Anfragen zugeteilt werden
Viel effektiver als feste WP-Zuteilung !
Präsentation
SAP GUI
SAP GUI
SAP GUI
1
8
DIAG-Format
SAP GUI
via TCP/IP
Dispatcher
7
3
4
Workprozess
Workprozess
Workprozess
9
Request Queues
fifo
Puffer
Shared Memory
Rollbereich
Benutzerkontext
6
5
Relationale Datenbank
kennt nur WP - nicht indiv. User
© Dr. H.Neuendorf
DBMS - Prozesse
DB
arbeitet statetful !
2
SAP AS hält Kontext / State
Applikationsserver
Neuere Darstellung
… Architektur ist stabil und entwickelt sich evolutionär
Quelle: Bachelorarbeit Eric Egenberger, WI12A, 2015, S.10.
© Dr. H.Neuendorf
(19)
Entkopplung User-Verhalten und Workprozess-Zuordnung
(20)
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 DialogWorkprozess soll
nicht durch UserEingabeverhalten
blockiert werden
© Dr. H.Neuendorf
Verteilung Benutzeranfragen auf D-Workprozesse
SAP Logon
SAPGUI
SAPGUI
SAPGUI
SAPGUI
(21)
Abbildung zahlreicher User
auf wenige DialogWorkprozesse mittels
Request Queue
+
Zuordnung von App-ServerWPs zu DB-WPs
Dispatcher
Shared
Memory
n:1
Workprozess
Workprozess
Workprozess
Kommunikation zwischen
Dispatcher und WPs via
Shared Memory
Datenbank Workprozess
Zahl der effektiven DBBenutzer deutlich geringer
als Zahl der System-User
DB entlastet !
Workprozess-Multiplexing :
Transaktion durch verschiedene, jeweils nur pro
Einzelschritt zugeordnete DWorkprozesse abgearbeitet
SAP-Transaktion :
User-Interaktion 5 -10 x länger als Bearbeitungszeit durch Workprozess
5 -10 Frontend-User im Mittel pro Dialog-Workprozess
Vorraussetzung : Keine lang laufenden Programme, die DWP belegen !!
© Dr. H.Neuendorf
Aufeinanderfolgende, inhaltlich
zusammengehörige Bildschirmbilder ≡
Teilschritte der Gesamt-Transaktion
Paradigmen : Data to Code (D2C) versus Code to Data (C2D)
Präsentation
(22)
Präsentation
Präsentationsschicht
Orchestrierungslogik
Applikationsschicht
Kalkulationslogik
Orchestrierungslogik
Kalkulationslogik
Daten
Daten
Persistenzschicht (DB)
Nutzung traditioneller DB-Technologie folgt D2C
Nutzung IMDB (HANA) folgt C2D
Code-Pushdown-Prinzip
Umgang mit DB : aus black box wird white box
© Dr. H.Neuendorf
Verlagerung von Anwendungslogik von
der Applikationsschicht in die DB-Schicht
zur Nutzung IMDB bei komplexen
Kalkulationen auf großen Datenmengen
Dialog
(25)
Message-Server
Workprozess-Typen
Disp .
Disp .
Verbuchung
Disp .
Pro App-Server :
MS
Disp .
1x Dispatcher
+
2x Dialog-WP
SAP- Dispatcher
Batch
11
12
10
1
Message Server
2
9
8
Sperrverwaltung
Nur 1x pro System :
Gateway - Server
3
7
6
5
4
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
© Dr. H.Neuendorf
+
ABAP- und Java-Stack :
(26)
Dispatcher-WP- Bild bleibt gültig
Browser
Web Application Server
JEE
ABAP
Java VM
ABAP VM
Linux
Unix
Windows
Operating System
OS/400
OS/390
DB Server
Oracle
Informix
© Dr. H.Neuendorf
MS SQL Server
DBMS
IBM DB2
SAP DB
(27)
Serverübersicht
Darauf laufende Workprozess-Typen
Server
Aufruf :
sm51
Werkzeuge → Administration → Monitor → Systemüberwachung → Server
Doppelklick auf Servernamen liefert WP-Verteilung
© Dr. H.Neuendorf
Prozessübersicht
Aufruf : sm50
Werkzeuge → Administration → Monitor → Systemüberwachung → Prozesse
Doppelklick auf Listeneintrag liefert Infos zum laufenden Prozess …
© Dr. H.Neuendorf
(28)
(29)
Message-Server
Instanz : Dialog-Server
Instanz : Batch-Server
Dispatcher
D-WP
...
Instanz :
Administrative Einheit,
die Services anbietet
Dispatcher
B-WP
...
D-WP
D-WP
Message Server :
Zentraler Dienst für
Kommunikation zw.
Dispatchern der
Applikationsserver
Anmeldung von Usern
an Applikationsserver
Zentrale Instanz : enthält MS 1 x pro System
Dispatcher
MS
D-WP
...
V-WP
E-WP
B-WP
S-WP
AppServer Info
WPs + Load
Skalierbarkeit
Lastverteilung
Logon - LoadBalancing
MS : 1. Dispatcher melden sich beim MS mit ihren verfügbaren Workprozessen an
2. MS speichert Informationen über App.Server 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
© Dr. H.Neuendorf
SAPGUI
(31)
Dialog-Workprozess
SAPGUI
LAN - / WAN
Der Dialog-Workprozess
Dispatcher
-
WP 1
Maximale Dauer begrenzt !
Langlaufende Programme
als Batch realisierbar !
Dynpro
interner Speicher
Request
Request
Queue
Queues
-
WP n
Prozessor
ABAP-
Task-
Prozessor
Handler
Datenbankschnittstelle
Roll out
Puffer-Zugriffe
Applikations-Puffer
Shared Memory
...
Dynpros
ABAP-Programme
Tabellen
...
Roll in
Roll-Bereich
User-Kontext
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
© Dr. H.Neuendorf
Roll File
Roll File
(32)
Ausführung ABAP- Code
Sourcecode
ABAP Objects
( Ausgeliefert ! )
VM
ABAP IL
Intermediate
Language
Ausführung
Durch ABAP VM
( Bytecode )
Interpretation
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
© Dr. H.Neuendorf
Strukturierte Zusammenfassung
von ABAP-Code in Paketen
(33)
Performanz-Analyse Dialog-Betrieb : Scatter-Plot
= accumulierte Antwortzeit
Hoher Workload
bei wenig freien
Ressourcen
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
© Dr. H.Neuendorf
(34)
Hintergrundverarbeitung - Batch-Workprozesse
Dialog-Server
Hintergrundverarbeitung
Hintergrundverarbeitungs-Server
3
Dispatcher
...
Dispatcher
D-WP
...
D-WP
B-WP
B-WP
Jobstatus
B-WP
geplant
freigegeben
1
11
12
10
bereit
2
1
2
9
3
8
Batch Scheduler
4
7
6
5
Job
rdisp/btctime
aktiv
4
fertig
Default = 60s
abgebrochen
Job1
C
...
...
↓
DB
DB
XXX
XXX
xxxx
UUU
xxxx
xxxx xxx
uuuu uuuu
uuu
xxx
uuu
uu
xx
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
© Dr. H.Neuendorf
Jobübersicht
Aufruf : sm37
Werkzeuge → CCMS → Jobs → Pflege
Doppelklick auf Listeneintrag liefert Infos zum Job …
© Dr. H.Neuendorf
(35)
SAP-Transaktion = SAP-LUW
versus
DB-LUW
→ Mismatch !!
(40)
SAP-LUW
Benutzerdialoge
Logical Unit of Work
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 !!
© Dr. H.Neuendorf
Datenbank-LUW
(41)
(Logical Unit of Work)
Datenbankoperationen
Zwischenzustände
insert update delete
Konsistenter
Konsistenter
Zustand 1
Zustand 2
alle Sperren
freigeben
Sperren auf DB-Tabellensätze halten
Physische Sperren :
Nicht hintergehbar !
ROLLBACK
möglich
DB-COMMIT
(oder DB-Rollback)
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
© Dr. H.Neuendorf
Verhalten SAP DBMS :
Systemarchitektur: Impliziter DB-COMMIT
Bildschirm 1
(42)
Automatischer DB-COMMIT
Bildschirm 2
Bildschirm 3
Nach DialogschrittVerarbeitung :
Neues Bild gesendet +
WP wird User entzogen
Ziel :
Vermeiden von WPBlockaden durch UserInteraktionen
DB-COMMIT
DB-COMMIT
Wenn App-Server-WP
endet, müssen auch
zugehörige DBÄnderungen erfolgen
DB-COMMIT
DB-Commit automatisch
ausgelöst !
DB-LUW 1
DB-LUW 2
DB-LUW 3
DB-LUW 4
SAP-Transaktion : Umfasst in der Regel mehrere Dialogschritte
DB-LUW :
Umfasst nie mehr als einen einzigen Dialogschritt
Keine Benutzer-Interaktion innerhalb DB-LUW !!
© Dr. H.Neuendorf
Zeit
Vergleich typischer Zeitskalen :
Schematische Sicht
PBO
User-Interaktion vs. Systemaktivität
User Interaktionen
Screen
100
PAI
PBO
Screen
200
|- Dialogverarbeitung-|
Zeitlich realistische Sicht
PAI
Screen
300
PBO
PAI
|- Dialogverarbeitung-|
Lange User Interaktionen
Screen
100
Screen
200
Screen
300
kurze DB LUWs
SAP Logical Unit of Work
PBO :
PAI :
© Dr. H.Neuendorf
Process before Output
Process after Input
Unvorhersagbar lange
Benutzer-InteraktionsZeiten dürfen nicht in
DB-LUW eingehen !
(43)
(44)
Direkte synchrone DB-Änderungen aus Dialog
Zeit
SAP Transaktion
Dialogschritt 1
Dialogschritt 2
Daten
Daten
Letzter
Dialogschritt
...
Daten
Anwender muss auf Durchführung der DB-Änderungen warten
Synchroner Ablauf hinsichtlich Dialogschritt
Schlechtere Performance bei vielen parallelen DB-Usern
© Dr. H.Neuendorf
UPDATE tab1.
............
Daten
Dialog Workprozess wird nicht freigegeben
Sichern :
UPDATE tab2.
Globale Daten des Programms ITABs
Einfaches Konzept - aber :
synchron
(45)
Asynchrone Verbuchung durch Verbuchungs-Workprozess
Verbuchungs-Server
Dialog-Server
Dispatcher
Dispatcher
ABAP :
COMMIT WORK
...
D-WP
ABAP :
Call Function
in update task
...
3
2
...
V-WP
+
MS
4
Bündelung von
DB-Änderungen
zur gemeinsamen
Ausführung
5
1
Transaktionalität !
Protokolltabellen
VB*
Entkopplung von
Dialog-WP und
DB-Update
DB
XXX
XXX
xxxx
UUU
xxxx
xxxx xxx
uuuu uuuu
uuu
xxx
uuu
xx
uu
UU
uuuu
uuu
u
DB-Änderungen: Nicht direkt im Dialog ausgeführt - sondern in Protokolltabelle nur vorgemerkt
Ausführung = Schreiben in DB → asynchron an Verbuchungs-WP delegiert
© Dr. H.Neuendorf
Verbuchung : Bündelung von Datenbankänderungen
(46)
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
Workprozess
DialogWP
Protokolltabelle
SQL in spez.
Funktionsbausteinen
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
© Dr. H.Neuendorf
asynchron
Workprozess
VerbucherWP
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 !
(48)
Vormerkungen schreiben : Verbuchungsbausteine
Protokolltabelle
1
Vormerkung 1
p1 = 1
Vormerkung 2
Daten
q1 = 2
Vormerkung 3
Workprozess
DialogWP
p1 = 3
Dialogprogramm
a = .1
CALL FUNCTION 'F1' IN UPDATE TASK
p1 = a
EXPORTING
p2 = ...
...
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
© Dr. H.Neuendorf
.
.
b = 2.
CALL FUNCTION 'F2' IN UPDATE TASK
EXPORTING
.
.
q1
= b
.
...
c = 3.
CALL FUNCTION 'F1' IN UPDATE TASK
EXPORTING
...
p1 = c
Abschluss durch :
COMMIT WORK
Wirkung von Rollback Work
ROLLBAK WORK
Protokoll tabelle
(49)
Fehler innerhalb SAP-LUW
DB-Änderungen nicht ausgeführt
Protokollsätze der SAP-LUW gelöscht
Vormerkung 1
Vormerkung 2
Vormerkung 3
Löschen aller bis
dahin geschriebenen
Vormerkungen
Workprozess
DialogWP
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
© Dr. H.Neuendorf
(51)
Asynchrone Verbuchung
Zeit
VBLOG
auf DB
Verb.-WP
Dialog-WP
Text
Protokolltabelle
Vormerkung 1
A
...
COMMIT WORK.
Vormerkung n
C
B
A
SAP-LUW 1
Dialogprogramm
B
SAP-LUW 1
Verbuchungsprogramm
C
SAP-LUW 2
Dialogprogramm
© Dr. H.Neuendorf
DB
Dialogprozess wartet NICHT auf
Ausführung der DB-Änderung !
Dialogprozess und Verbuchung sind
zeitlich entkoppelt asynchron !
(53)
Warum müssen Sperren gesetzt werden ?
Verwaltung konkurrierenden
Zugriffs auf selbe Daten
Programm A
Programm B
Programm C
Mehrere User greifen auf
selbe Ressource zu
Synchronisation erforderlich,
um Konsistenz zu garantieren :
Ausschließender Zugriff !
Datenbank
Sperren nur so lange wie
nötig halten !
Tab 4
Tab 1
Tab 3
Tab 6
Tab 2
Performance-Bottleneck
Tab 5
Physische Sperren :
durch DB selbst
Sperren : Datenbankobjekt wird zeitweise für Zugriff eines Prozesses
reserviert - für Zugriffe aller anderen gesperrt
© Dr. H.Neuendorf
Logische Sperren :
durch ProgrammierKonvention
(54)
Datenbanksperren nicht ausreichend im SAP-Umfeld
SAP-Transaktion :
Datenbanksperren reichen nicht
COMMIT
(implizit)
Ersteckt sich i.A.
über mehrere
Bildschirmbilder
COMMIT
WORK
(explizit)
COMMIT
(implizit)
UPDATE
UPDATE
INSERT
INSERT
SELECT
UPDATE
Sperren müssen
länger gehalten
werden als nur über
einen Dialogschritt
DELETE
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 !
© Dr. H.Neuendorf
SAP Sperrkonzept : Logische(!) Sperren - ENQUEUE-Workprozess
SAP Sperrkonzept: logisches Sperren
SAPGUI
SAPGUI SAPGUI SAPGUI
Dispatcher
Dialog. . .
WP
Dialog
SAPGUI
SAPGUI
Dispatcher
Message
Server
...
WP
(55)
DB-unabhgängiger
high-level SperrMechanismus
Sperrtabelle
Enqueue
WP
Enq.-WP +
Sperrtabelle
Auf AS !
1 x pro
System
DB Management System
Ziel :
Sperren über Bildwechsel system-global aufrechterhalten
Mittel :
Globale Sperrtabelle auf App-Server - enthält Verzeichnis gesperrter Tabellen
© Dr. H.Neuendorf
Logische Sperren setzen + löschen
Auftrag :
Erzeuge Sperre
(56)
Anforderung Sperre + Eintrag in Sperrtabelle
sowie späteres Löschen der Sperre mit
speziellen ABAP-Funktionsbausteinen *
Sperrtabelle
Sperren zurücksetzen :
durch Programm
ABAP
Programm
Sperrbaustein
oder
Sperreintrag
erzeugen
durch Verbucher
Call Function
ENQUEUE_...
Antwort :
EXCEPTIONS
Sperre erfolgreich gesetzt
keine
Keine Sperre gesetzt
Eintrag bereits gesperrt
Fehler in Sperrverwaltung
*Sperrbausteine :
FOREIGN_LOCK
SYSTEM_FAILURE
ENQUEUE-<......>
+
ABAP-Programm reagiert durch
Auswertung Returncode
Wenn Sperre bereits gesetzt ist :
weitere Anforderungen abweisen
DEQUEUE-<......>
Durch System generiert, nachdem im Dictionary ein Sperrobjekt definiert wurde :
Enthält zu sperrende Tabelle + Sperrargument (= Schlüsselfelder) + Sperrmodus
(S = Shared - Lesesperre,
© Dr. H.Neuendorf
E = Exclusive - Schreibsperre)
(58)
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 Anwendungsprogrammen
Automatisch durch Datenbank
angewandt
Am Ende der SAP LUW freigegeben
Am Ende der DB LUW durch DB
freigegeben
Im Hauptspeicher des App-Servers in
Enqueue-Tabelle verwaltet
© Dr. H.Neuendorf
Physische DB-Sperren
In DB verwaltet
(60)
SAP-AS Lastverteilung
SAP
GUI
SAP
GUI
SAP
GUI
SAP
GUI
App-Server 1
SAP
GUI
App-Server n
100 KB
Gateway
Dispatcher
Dispatcher
MB
Gateway
0.1ms
Table
Buffers
DIA
WP
BTC
WP
SPO
WP
MB-GB
Table
Buffers
DIA
WP
ENQ
WP
Enqueue
Table
MB
1ms
DBMS
DBWP
DBWP
GB
DB (disk)
TB
DBWP
DBWP
100ms
Zugriffszeit
© Dr. H.Neuendorf
Speicherverbrauch
Data / Dialogschritt
Workprozessverteilung
Service
Systemweit
(61)
Per AS-Instanz
Dialog
>=2
>=2
Verbuchung
>=1
>=0
Enqueue
1
Batch
>=1
Message
1
0 oder 1
Gateway
>=1
1
Spool
>=1
>=0
Systemstart :
1. Datenbank
0 oder 1
2. Zentrale Instanz
>=0
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 ...
Automatischer Betriebsartenwechsel :
Abfrage System-Werte :
Report RSPFPAR
Anpassung an aktuelle Anforderungen
Automatische Änderung der Workprozess-Verteilung zu vordefinierten Zeitpunkten, z.B. :
Tagesbetrieb → Zahlreiche Dialog-WPs
(überwiegend Dialog-User, wenige Batchjobs)
Nachtbetrieb → Umwandlung von Dialog-WPs in Batch-WPs (überwiegend Batch)
© Dr. H.Neuendorf
Betriebsarten-Konzept : Anpassung Instanzen an Lastverteilung
Betriebsart Tag :
Betriebsart Nacht :
Primär Dialogverarbeitung
Primär Hintergrundverarbeitung
Dispatcher
Dispatcher
D
D
D
D
(63)
D
B
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äß Zeitplan
Kein System-Neustart nötig
© Dr. H.Neuendorf
Kein Abbruch laufender Requests
Umschaltplan
definierbar mittels
Pflege-Transaktion
(64)
SAP Datenbank-Schnittstelle
Applikationsserver
Datenbank
ABAP Interpeter
Die SAP Basis-Datenbankschnittstelle
DB
Schnitt
Daten
-stelle
SELECT *
FROM
Open SQL
Plattform- und
DB-unabhängig
Lokale
Puffer
OPEN-SQL
Native-SQL
Daten
Daten
Relationale
Datenbank
Verschalung der
DB-Schnittstellen
verschiedener
DB-Hersteller
Native-SQL
Nutzt vollen
Sprachumfang
EXEC SQL.
SELECT ....
END EXEC.
ABAP Open-SQL :
Native
-SQL
Native-SQL
DB - Daten
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
© Dr. H.Neuendorf
aber :
Code abhg. von
DB-Hersteller !
Umgeht
Tabellenpuffer !
(68)
Exkurs : CAP-Theorem und Verteilte Systeme
Consistency
All clients have the same view on the data
Atomic
Continuous
Consistency
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 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 nur die Wahl zwischen Consistency und Availability
Beide Anforderungen sind nicht simultan erfüllbar !
© Dr. H.Neuendorf
(69)
SAP Puffer : Tabellenpuffer der App-Server
App-Server 1
App-Server 2
ABAP Programm 1
ABAP Programm 2
Open-SQL
Tabellen
puffer
Weitere Puffer für :
Programme
Bildschirmdaten
Dictionary-Daten
DBSchnittstelle
DBSchnittstelle
Native
SQL
Tabellen
puffer
Tabellenpuffer
sind lokal zum
jeweiligen AppServer in dessen
Hauptspeicher
Füllen Puffer :
Beim ersten Lesen
DBMS
1 - 60 ms
Nach Änderungen
Nach Synchronisation - s.u.
Datenbank
CAP-Theorem
Atomic
Continuous
Consistency
Availability
Ziel der Pufferung von DB-Tabellen auf App-Servern :
Reduzierung Lese-Zugriffszeit → Rascher Zugriff auf App-Server
Entlastung Datenbank → Reduzierung Zahl teurer DB-Zugriffe
© Dr. H.Neuendorf
Partition
Tolerance
(70)
Aktualisierung + Synchronisation von SAP Puffern
AS 1
AS 2
PROGRAM z...
UPDATE dbtab1 ...
dbtab1
Zeitverzögerte
Synchronisation der
Puffer der anderen
App-Server !
ABAP Programm 2
DBSchnittstelle
DBSchnittstelle
dbtab1
Kann Systemverhalten
beeinflussen !
Nicht alle Tabellen
puffer-geeignet !
Nur vorwiegend
gelesene Tabellen !
DBMS
aktuell
App-Server, der
Daten auf DB ändert,
aktualisiert zugleich
eigenen Puffer
Vorteil :
verzögert
dbtab1
bufreftime
Datenbank
dbtab1 X
Synchronisations-Informationen
Periodisch von App-Servern gelesen
Netzlast gering – kein Broadcast
Nachteil : Lokale Puffer enthalten eventuell veraltete Daten
© Dr. H.Neuendorf
(60 - 3600 s)
Leseintervall → Profilparameter
bufreftime
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
© Dr. H.Neuendorf
(71)
(72)
Drei Pufferungsarten
Resident
Generisch
Generisch
Partiell
1 Schlüsselfeld
2 Schlüsselfelder
Einzelsatz
key1
key1
key2
key3
data
key2
key3
data
001
001
001
001
002
002
002
002
002
002
003
003
003
003
003
003
003
003
key1
key2
001
001
001
001
002
002
002
002
002
002
002
002
003
003
003
003
003
003
003
003
003
003
003
A
A
B
B
A
A
B
B
B
C
C
D
A
A
A
B
B
C
C
C
D
D
D
key3
key1
key2
key3
001
001
001
001
001
002
002
002
002
002
002
002
002
002
002
003
003
003
003
003
003
003
003
003
003
003
003
003
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
2
4
1
3
5
1
3
6
8
1
2
3
0
3
5
2
3
6
2
4
2
3
5
8
1
2
3
4
data
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
© Dr. H.Neuendorf
data
SAP ERP AS :
Anforderungen ↔ Technologische Lösungen
Prozessorientierung
Anpassbarkeit der Prozesse
Plattformunabhängigkeit
(73)
ABAP-VM
ABAP-Eigenentwicklung
ABAP-Open-SQL
Mehrsprachigkeit
Dispatcher-WP-Mechanismus
Dialog- und Batch-Betrieb
MultiUser MultiTasking
Logon-Load-Balancing
Asynchrone Verbuchung
Begrenzte Ressourcen
Darstellung bwl. Transaktionen
Transaktionalität
Verbuchung + High-Level-Sperrkonzept
Integrität der Daten
Wechselnde Anforderungen
Betriebsartenkonzept + Logon-Gruppen
Wechselndes Userverhalten
Puffermechanismen auf App-Server
Anpassung an firmeninterne
Auslastungssituation
Hochgradige Administrierbarkeit
Integrations - Aspekte :
Bwl. Prozess-Integration
Datenintegration
Systemintegration
Administrative Integration
Vermeidung von System-, Medien-, Prozess- und Organisationsbrüchen
© Dr. H.Neuendorf
Konsistenz