SAP_Basis_Klassisch.pdf

Prof. Dr. H.Neuendorf - Technologie SAP 2
Studiengang Wirtschaftsinformatik WI18 2020
SAP-Architektur
Evolution und Technologie des SAP-Systems
Prof. Dr. Herbert Neuendorf
DHBW Mosbach - SG Wirtschaftsinformatik - SZ WION
herbert.neuendorf@mosbach.dhbw.de
LO B1.110 / 06261-939-470
Skripte https://www.mosbach.dhbw.de/dhbw-mosbach/who-is-who/prof-dr-herbert-neuendorf/
Teil 1

Aufbau der Lehrveranstaltung
Architektur + Technologie zentraler Bestandteile des SAP Systems
1. Teil : Klassischer digitaler Kern
Klassischer SAP Applikationsserver ABAP
2. Teil : Web
Stufenweise System-Öffnung für Internet-basierte
Technologien, Architekturen und Programmiermodelle
Ausblick : Neuartige (hybride) Architektur-Ansätze
SAP-Web-Programmierung → ICF + Business Server Pages
SWE-Projekt ( 5.Semester )
ERP-Systeme ( Prof.Dr. Palleduhn )

Literaturhinweise
Genannte Titel können zur technologischen Vertiefung genutzt werden.
Allerdings gehen sie in der Detailierung teilweise deutlich über das Anliegen dieses LV-Teils hinaus.
Ferner handelt es sich eher um exemplarische Anwendungsliteratur als um wissenschaftliche Darstellungen.
R.Plota, W.Fix: SAP – Der technische Einstieg, SAP PRESS (Rheinwerk) 2017 (1).
U.Koglin: SAP S/4HANA, SAP PRESS (Rheinwerk) 2018 (2).
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).
M.Wegelin, M.Englbrecht: SAP-Schnittstellenprogrammierung, SAP PRESS (Rheinwerk) 2018 (4)
F.Heinemann, C.Rau: SAP Web Application Server, SAP PRESS (Rheinwerk) 2005 (2).
H.Plattner, A.Zeier: In-Memory Data Management, Springer 2016 (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) 2019 (3).
C.Goebels et al.: SAPUI5, SAP PRESS (Rheinwerk) 2016 (1).
A.Bavaraju: SAP Fiori Implementation and Development, SAP PRESS (Rheinwerk) 2016(1).

Klassischer SAP Applikationsserver ABAP
Anforderungen an ERP-Systeme
Dreistufige klassische Client-Server Architektur
Workprozesse eines verteilten Systems
SAP-LUW - SAP-Verbuchung - SAP-Sperrkonzept
DB-Zugriff - Tabellenpuffer ↔
↔
↔
↔ CAP-Theorem

Anforderungen an ERP-Systeme
ERP-Systeme : Eigenschaften & Anforderungen
Vermeiden von Prozessbrüchen
Leitende Fragestellungen
Kriterien der Wandlungsfähigkeit von ERP-Systemen
Transparenzleistungen Verteilter Systeme
Historie der SAP-Selbstdarstellung
SAP-Systembezeichnungen …

IT-System zur umfassenden, integrierten, bereichsübergreifenden,
bruchfreien Abbildung und Kontrolle aller relevanten
Organisationsstrukturen und Geschäftsprozesse des Unternehmens.
Klassisches ERP : OLTP ( Data Warehouse : OLAP )
ERP = Enterprise Resource Planning OLTP
Vermeidung typischer Brüche innerhalb Aufbau- und Ablauf-Organisation :
System-Bruch
Medien- / Format-Bruch
Daten-Bruch ( z.B. OLTP / OLAP )
Organisations-Bruch Verhinderung Schatten-IT …
WI-Kern →
→
→
→ Integration für optimale Prozess-Orientierung
Kritischer Punkt:
Wie agil bezüglich Prozess- und
Technologie-Anpassungen ??

SAP ERP-Weltmarktführer > 300.000 Installationen in > 200 Ländern …
Leitende Fragestellungen
Warum war / ist SAP erfolgreich ? Detail :
Welche technischen Strukturen / Patterns sorgen für Performanz des
geschäftskritischen verteilten Systems ?
Wie korrespondieren betriebswirtschaftliche Anforderungen und
technische Lösungen ?
Wie hat sich das System evolutionär weiterentwickelt ?
Wie öffnete sich das System vom monolithischen allwissenden
ERP-Server zum kollaborativen, hybriden System ?
"Wie funktioniert Wirtschaftsinformatik?" - "Durch (agile) Integration!" …

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

SAP ERP als Verteiltes System
SAP ERP stellt sich technologisch dar als Verteiltes System
Leistungen :
Multi User
Multi Tasking
Betriebliche Echtzeit / primär Dialogbetrieb
Transaktionalität
Skalierbarkeit & Performanz
Erweiterbarkeit / Anpassbarkeit / Wartbarkeit / Administrierbarkeit

Transparenzleistungen Verteilter Systeme
Transparenz = Verstecken der Funktion bei Bewahren des Effekts +
Einheitlichkeit der Handhabung
Ortstransparenz
Benutzer muss nicht wissen, wo sich Ressource befindet - Identifikation über Service-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 (Load-Verteilung & Konsistenz) durch das System - nicht durch User
Migrationstransparenz
Ressourcen können verlagert werden - ohne dass User dies (direkt) bemerkt
Fehlertransparenz
Fehler und deren Behebung bleiben (teilweise) vor User verborgen (Selbstheilungskräfte - Resilienz)
Skalierungstransparenz
Neue / erweiterte Ressourcen können (im laufenden Betrieb) hinzugefügt werden (Elastizität)
Leistungstransparenz
Automatische Lastverteilung (load balancing) auf einzelne Teilsysteme …

Historische SAP-Selbstdarstellung
Aufbrechen monolithischer Strukturen in modulare Teillösungen
System-Öffnung für neue Technologien … fortgesetzt : SOA, EAI, Cloud, Mobile, BigData, IOT, KI, …
Quelle: SAP SE

Selbst-Darstellung …
Betonung
Integration +
Anwendungsvielfalt +
Modularität
Quelle: SAP SE
Typisch für "damals":
Die DB spielt keine Rolle !

SAP ERP System-Bezeichnungen
Wir behandeln primär
NW Applikationsserver ABAP
Applikations Server : ( "Basis" )
→
→
→
→ NetWeaver 7 AS
aktuell NW AS 7.5…
Bwl. Kernkomponenten :
→
→
→
→ SAP Business Suite
SAP ECC =
ERP Central Components
SAP liebt Umbenennungen :
Anwendung Facade-Pattern im Marketing …
Marketing :
SAP R/3 mysap.com SAP WAS NetWeaver SAP
ECC SAP S/4HANA …
Technischer System-Kern blieb konstant -
evolutionär erweitert um zusätzliche Komponenten
… echte Neuerung 2015 durch : SAP S/4HANA

Klassik : SAP-Applikationsserver / Client-Server
SAP Technologie-Strategie
SWE-Infrasstruktur : Mehr-System-Landschaft
SAP Applikationsserver
Client / Server - Prinzip / Tier & Layer
Klassische dreistufige verteilte Architektur
3-Tier / - Layer Skalierbarkeit
SAP Workprozesse

SAP Technologie-Strategie - klassisch
Klassisches SAP-Problem : insbesondere gegenüber KMU …
Standard-SW bedeutet Standardisierung der Geschäftsprozesse
aber :
Vollständige Abdeckung aller betriebswirtschaftlichen Abläufe durch einheitliches
System ohne Festlegung auf bestimmte Plattform (BS / DB / Hardware)
Auslieferung ABAP-Quellcode & Entwicklungsplattform ( Workbench )
ermöglichte Entstehen eines Technologie-Ökosystems im SAP-Umfeld
Frühe Form der "Plattformökonomie" …
Anpassungen durch Customizing / Modifikation / Eigenentwicklung stets möglich
Proprietäre Programmiermodelle und Protokolle (ABAP, DIAG, Dynpro, HANA)
erschweren System-Entwicklung - verhinderten jedoch rasche Substitution …
Aktuell besetzt SAP sofort jedes Technologiefeld (Mobile, DS, (I)IOT, KI … )

SWE-Infrasstruktur : Mehr-System-Landschaft
Stabile Produktivsyteme Keine Entwicklung im Produktivsystem
Typischerweise 3-System-Landschaft (DQP) + Transportwesen (!) = Deployment
Entwicklungssystem : Entwicklung & Customizing
Qualitätssicherungssystem : Test & Verifikation in produktionsähnlicher Umgebung
(realistische Echtdatenmengen & Customizing)
Produktivsystem : Reale OLTP-Abläufe keine Entwicklung, Debugging …
Entwicklung
Dev
Integration
Qualitäts-
sicherung
Konsolidierung
Produktion
Belieferung
Konsolidierung Belieferung
SWE : Development / Delivery & Integration & Consolidation
Aktueller Trend : Agile → CDI / DevOps

SAP Applikationsserver AS
SAP Applikationsserver AS
ABAP (anwendungsübergreifend)
Betriebssysteme + DB
Hardware-Plattformen
Klassische SAP Anwendungen
HCM, FI, MM, CO ...
SAP NW AS "Basis" / Kernel
Middleware
Technisches Fundament (Digitaler
Kern) aller Anwendungen auf
Vielzahl verschiedener Plattformen
Laufzeitumgebung für viele SAP-
Anwendungen OLTP
Datenintegration über eine
gemeinsame Datenbank
Anwendungsübergreifende
Geschäftsprozessabwicklung
Systemadministration
Verteilung von Ressourcen +
Komponenten (Transporte)
Unterstützte Plattformen : … alle relevanten
BS : Unix Linux MS
DB : Oracle DB2 SAP Adaptive Server Enterprise (ASE) … anyDB
GUI: SAPGUI WebGUI NetWeaver Business Client via WebDynpro WebClient via BSP Mobile via SAPUI5
Netz: TCP/IP Websocket RMI / RFC …

Client / Server
Client
Server
LAN / WAN
Hardware-orientierte Sicht :
Client
Prozess
Server
Prozess
Anforderung
Dienstleistung
Erbringen
Dienstleistung
Software-/ Prozess-/
Service-orientierte Sicht :
Niedrige WAN -Transferraten bei R/3-Etablierung :
Zugriff auf Server übers WAN (von verteilten Standorten) von Anfang an intendiert !
Architektur des AppServers musste dies performant zulassen !
Client-Server impliziert : Verzugslose Verarbeitung = Request/Response ≠ Batch
Durch Virtualisierung +
Cloud wird Hardware-
Bild zunehmend obsolet

Client / Server - Vokabular …
Service = Dienst, der von einer Software-Komponente angeboten wird
Komponente = Fachliche Komposition von Services
Layer
Trennt Programmcode und sorgt für logische Trennung
Legt jedoch physische Verteilung des Programmcodes nicht fest.
Tier
Beschreibt die physische Architektur / Verteilung der System-Komponenten
Macht somit Aussage über Hardware-Struktur / -Verteilung des Systems

SAP Client / Server
Datenzentrierte System-Definition : SAP-System =
Alle Software-Komponenten, die der selben Datenbank zugeordnet sind
Daten-Integration aller Unternehmensdaten in logisch zentraler Datenbank
Konsistenter transaktionaler Zugriff auf zentralen Datenbestand
durch alle zentralen SAP-Anwendungen
Datenbank = logisch zentrale Ressource des Systems
Ihr performanter Betrieb ist entscheidend für Verfügbarkeit des Systems
( möglicher Flaschenhals - single point of failure )
Applikationsschicht ist auf zentrale DB-Instanz angewiesen
Aber klassisch: Kein direkter Zugriff auf DB / Zugriff nur via Applikationsserver

SAP Client / Server
Klassische dreistufige verteilte Architektur
3-Tier / - Layer
Quelle: M. Sahlmüller (WI13) Bachelorarbeit, 2016
Erweiterung / Änderung dieser
Sicht aktuell durch S/4HANA …
Stammdaten, Bewegungsdaten, Systemdaten
Datentypen (Dictionary)
Anwendungsprogramme
Dies ist der zentrale Kern des
klassischen Systems !

SAP Client / Server
Präsentationsschicht
Interaktion
User- Ein-/ Ausgabe
Applikationsschicht
Logik
Logik + DB-Zugriff
Persistenzschicht
Zentrale Daten
Daten
Anwendungsprogramme
Datentypen (Dictionary)
LAN
LAN / WAN
SAPGUI SAPGUI (RFC)
Application Server 1 Application Server n
Rel. Database Management System
Database
?
KByte
KByte - MByte
Browser
Mobile

Verteilte Client / Server -Tiers
Einstufige Konfiguration
(One Tier)
Demo-System
Zweistufige Konfiguration
(Two Tier)
DB + Appl. + Präsentation DB + Appl.
Präsentation
Kleines Kundensystem
(ca. 100 User)
Skaliert nicht !

Verteilte Client / Server -Tiers
Dreistufige Konfiguration
(Three Tier)
DB
Applikation
Präsentation
Regelfall : Skaliert !
Insbesondere auf
AppServer-Ebene !
Horizontale Verteilung
Vertikale
Verteilung
Vertikale Lastverteilung :
Verteilung der drei Schichten auf
verschiedene Ressourcen, die somit von
jeweils anderen Aufgaben entlastet werden
Horizontale Lastverteilung in
Applikationsschicht : Cluster, Pool
Mehrere Applikationsserver arbeiten
gleichzeitig innerhalb eines Systems
Drei-Ebenen-Architektur erlaubt …
… große Zahl von Benutzern auf kleine
Zahl von Applikationsservern abzubilden

Grundsätzliche Betriebsweisen
Nachteile Batch :
Hohe Latenz (Verzögerung) zwischen bwl. Ereignis und Darstellung im System
Entsprechende Verzögerung anschließender Prozesse
Logistische Bestands-Unsicherheiten behindern Bestellabwicklung / Lieferzusagen / SLAs
Erzwingt übersteigerte Lagerhaltung (Puffer / Overbloat)
Globale 24/7-Logistik kennt kein "overnight" mehr …
Klassisches SAP-ERP war historisch das erste einsatzkritische betriebliche System,
das auf Basis von Client-Server-Architektur (betriebswirtschaftliche) Echtzeit-
Verarbeitung (Realtime-Processing & -Integration) ermöglichte.
Informationsverarbeitung
Interaktiv (ReqRes) / Dialog-Betrieb Batch-Processing
Hübsche Anekdote :
R/3 - Bedeutung "R" = Realtime

SAP Workprozesse - klassischer Digitaler Kern
Zur Abwicklung spezieller Aufgaben laufen auf SAP-Applikationsservern spezielle Prozesse
(Programme) = Workprozesse
AppServer-Workprozess :
Definierte Services auf Ebene des SAP-Applikationsservers
Skalierbarkeit & Performanz des klassischen Systems :
Zahl der Applikationsserver kann der Last angepasst werden
Verteilung verschiedener Workprozesse (Zahl + Typ) auf einzelne Applikationsserver
kann konfiguriert werden, um spezielle AppServer für spezielle Aufgaben einzurichten
Im Rahmen des klassischen SAP-Systems spielt die DB eine eher passive Rolle :
DB-Zugriffe sind aufwendig und zu minimieren
Im Mittelpunkt steht die Performanz der AppServer-Ebene

SAP Workprozesse
Rel. Database Management System
RDatabase
SAP GUI
Admin
DIA SPO
BTC V
Message
Server ENQ
V
DIA BTC
SAP GUI
SAP GUI
10 - 20
Workprozesse
pro Applikations-
Server
5 - 10
User pro
Dialog-
Workprozess
1 - n
Applikations-
Server
Application Server 1 Application Server n

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

Dialog-Betrieb - Dispatcher-Pattern :
Verteilung Benutzeranfragen auf DWPs
Präsentation
Applikationsserver
Relationale Datenbank
kennt nur WP - nicht User
SAP GUI
DB
DBMS - Prozesse
Dispatcher
Work-
prozess
Puffer
Shared Memory
SAP GUI SAP GUI SAP GUI
Work-
prozess
Work-
prozess
Request Queues
Rollbereich
Benutzerkontext
fifo
DIAG (TCP)
1
2
3
4
5
6
7
8
9
SAP
AS
hält
Kontext
/
State
arbeitet
statetful
!

Dialog : Dispatcher-Worker-Pattern
Hoher Verwaltungsaufwand …
… aber während langer User-Eingabe-Zeiten kann Dialog-WP andere Anfragen bearbeiten !
Dialog-WP ist User nur während Einzelschritt-Verarbeitung zugeteilt !
Viel effektiver als feste Dialog-WP-Zuteilung an User !
Dialog-Betrieb : Interaktive betriebliche Echtzeit-Daten-Verabeitung
Nutzung Pool der Dialog-WPs + Dispatcher-WP
Performanz durch Dispatcher-Worker-Pattern
Dispatcher verteilt (= dispatcht) aktuelle Anforderungen (requests) nacheinander an momentan freie Dialog-WPs. Im
Dialog-WP findet eigentliche Verarbeitung statt. Es gibt keine feste Zuordnung von Workprozessen an Benutzer! Am Ende
der Verarbeitung des Teilschritts gelangt Verarbeitungsergebnis über Dispatcher zum SAPGUI zurück.
Viele Benutzer teilen sich (nacheinander) wenige Workprozesse. Jeder Workprozess arbeitet für viel Benutzer
nacheinander. Jeder Benutzer belegt einen bestimmten Workprozess nur für die Dauer eines Dialogschritts. Beim
nächsten Dialogschritt wird der Benutzer einem anderen WP zugewiesen.
Solange keine Verarbeitung für Benutzer passiert, werden seine benutzerspezifischen Daten (Userkontext) ins shared
memory geschrieben und der Workprozess freigegeben - d.h. er steht wieder anderen Benutzern zur Verfügung. Beim
Prozessieren eines Dialogschritts wird Benutzerkontext dem Workprozess verfügbar gemacht („roll in“ aus shared
memory); der veränderte Benutzerkontext wird am Ende des Dialogschritts wieder ins shared memory geschrieben („roll
out“). Benutzerkontext enthält z.B. Berechtigungen und Variablenwerte.

Entkopplung User-Verhalten und WP-Zuordnung
Typische Eingabezeit
des Users ist viel
länger als
Verarbeitungszeit
auf App-Server
SAP-Transaktion
umfasst Folge von
Eingabebildern zur
Darstellung des bwl.
Vorgangs
Oberstes Ziel :
Ressource Dialog-
Workprozess darf
nicht durch User-
Eingabeverhalten
blockiert werden !
Quelle: SAP

SAPGUI
Work-
prozess
Dispatcher
Datenbank -
Workprozess
SAPGUI SAPGUI
SAPGUI
Work-
prozess
Work-
prozess
Shared
Memory
SAP Logon Workprozess-
Multiplexing :
Transaktion durch
verschiedene,
jeweils nur pro
Einzelschritt
zugeordnete DWPs
abgearbeitet
Kommunikation
zwischen Dispatcher
und WPs via
Shared Memory
Dispatcher + Request-Queue
bewirken Load-Balancing
innerhalb AS :
Anfragen gleichmäßig auf freie
Ressourcen = DWPs verteilt.
DWP-Poolgröße kann gesteigert
werden, um interne horizontale
Skalierung des AS zu ermöglichen.

User-Interaktion 5 -10 x länger als Bearbeitungszeit durch Workprozess
5 -10 Frontend-User im Mittel pro DWP bewältigbar
Vorraussetzung : Keine lang laufenden Programm-Schritte, die DWP blockieren !
Sonst Übergang zur Batch-Verabeitung erforderlich !
Klassischer SAP AS hält Kontext / State - baut Session auf
Jeder einzelne SAP-AS des Systems arbeitet Statetful !
Abbildung zahlreicher User auf wenige Dialog-Workprozesse mittels Dispatcher-
Pattern und Request Queue.
DB "redet" nur mit DWPs - nicht mit Usern direkt !
Anzahl effektiver DB-Benutzer deutlich geringer als Zahl der System-User :
DB entlastet !

Dialog-WP
Der Dialog-Workprozess
Shared Memory
Request -
Queues
SAPGUI
Dispatcher
Dynpros
ABAP-Programme
Tabellen
...
Applikations-Puffer
Roll File
User-Kontext
Roll-Bereich
Dynpro -
Prozessor
ABAP-
Prozessor
Datenbank-
schnittstelle
Task-
Handler
interner
Speicher
Roll in
Roll out
Puffer-Zugriffe
LAN - / WAN
DWP n
...
DWP 1
Roll File
Request
Queue
Abarbeitung Dialogschritt auf AppServer durch :
Dispatcher als zentraler Steuerungsprozess & Workprozess-Warteschlange für Requests
Dialog-Workprozess
Puffer im Shared Memory und Roll File
Maximale Dauer begrenzt !
Langlaufende Programme
nur als Batch !
Quelle: Hagemann (2016) S.82

Lastverteilung / Load Balancing
Horizontal Verteiltes System mit mehreren Knoten / Servern
Abfrage-Verteilungsmechanismen - welcher Knoten ist zuständig ?
(First-Alive, Round-Robin, Dynamische Verteilung …)
Problem Stateful Server : Session Stickness bei zustandsbehaftetem Server #
Aufeinander folgende Abfragen des selben Clients müssen immer vom selben Server
bedient werden, der den User-Kontext # trägt.
Permantente Replikation des User-Kontext zwischen allen Servern (Broadcast) ist
viel zu aufwändig & würde Skalierbarkeit einschränken.
AS 1 #
AS 2
AS 3
Load
Balancer
Client DB
Desiderat :
Zustandslose
Kommunikation
Stateless Server
Web-Modelle /
HTTP / REST …

Vorgriff : SAP HANA High Performance Analytic Appliance
Verlagerung Anwendungslogik
von Applikationsschicht in DB-
Schicht zur Nutzung IMDB bei
komplexen analytischen
Kalkulationen auf großen
Datenmengen
Fokus : Realtime Analytics
Integration OLAP + OLAP
Single Source of Truth
SAP forciert zentrale Rolle seiner InMemory-DB HANA (eigenständige App-Plattform)
Verlagerung / Integration / Verschmelzung von AppServer Funktionen auf DB-Ebene
Zukünftige Rolle des klassischen AppServers ungewiss / Neue Programmiermodelle …
Quelle : SAP

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

Klassik : Weitere Workprozesse
Klassische Workprozess-Typen
Server-Übersicht / Prozess-Übersicht
Message-Server
Logon-Load-Balancing
Logon-Gruppen
Hintergrundverarbeitung - Batch-Workprozess

Dialog
SAP-Dispatcher
Spool
Batch
12
9
6
3
11 1
7 5
8 4
2
10
Verbuchung
Sperrverwaltung
Message-Server
Disp .
Disp .
Disp .
Disp .
MS
MS
Gateway-Server
R/3
z.B.
R/3
GW
GW
Pro AppServer : 1x Dispatcher + 2x Dialog-WP
Nur 1x pro System : Message Server + Enqueue Server
Dispatcher + alle Workprozesse : Identische Programme !
Workprozesstyp kann umgeschaltet / nachgestartet werden - ohne Neustart AppServer
Pattern
Adaptive Computing

Message Server
Komunikation zwischen Dispatchern verschiedener AppServer eines Systems
Gateway Server
Kommunikation zwischen SAP-Systemen oder mit externen Systemen
Dialog
Abarbeitung User-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)

Server-Übersicht
Server Darauf laufende Workprozess-Typen
Aufruf : sm51
Werkzeuge → Administration → Monitor → Systemüberwachung → Server
Doppelklick auf Servernamen liefert WP-Verteilung
Quelle: SAP

Prozess-Übersicht
Aufruf : sm50
Werkzeuge → Administration → Monitor → Systemüberwachung → Prozesse
Doppelklick auf Listeneintrag liefert Infos zum laufenden Prozess …
Quelle: SAP

Message-Server Logon-Load-Balancing
Quelle: Hagemann (2016) S.135
Dispatcher
Workprozess
Workprozess
Workprozess
AS-Instanz
1
Dispatcher
Workprozess
Workprozess
Workprozess
AS-Instanz
2
Message-Server
Dispatcher
Workprozess
Workprozess
Workprozess
Zentral-Instanz
Verteiltes System

SAPGUI
Logon - Load - Balancing
D-WP
Dispatcher
Instanz : Batch-Server
Instanz : Dialog-Server
Zentrale Instanz : enthält MS 1 x pro System
Dispatcher
. . .
D-WP
D-WP
. . .
. . .
MS
Dispatcher
D-WP B-WP
V-WP E-WP B-WP S-WP
AS Info
WPs + Load

Instanz :
Administrative Einheit = AppServer - die bestimmte Services (WPs) anbietet
Wird als Ganzes gestartet, gestoppt, überwacht (Host) / Hat ID
Zentrales System : Nur eine Instanz
Verteiltes System : Mehr als eine Instanz
Message Server :
Zentraler Dienst für Kommunikation zwischen Dispatchern der Applikationsserver
Anmeldung von Usern am System → an bestimmtem Applikationsserver
Skalierbarkeit + (statische) Lastverteilung
Dispatcher melden sich beim MS mit ihren verfügbaren Workprozessen an
MS speichert Informationen über AppServer + deren aktuelle Auslastung
Wenn Dispatcher erforderlichen WP nicht selbst hat, wird Request via MS an
Dispatcher auf anderem AppServer weitergeleitet, der nötigen WP bereithält

C
Hintergrundverarbeitung
DB
DB
1
1
4
4
12
9
6
3
11 1
7 5
8 4
2
10
Job
2
2
Dialog-Server
. . .
D-WP
Hintergrundverarbeitungs-Server
. . .
XXX xxxx
XXX xxxx xxxx xxx xxx xx
UUU uuuu uuuu uuu uuu uu
UU uuuu uuu u
Einplanungstabelle
Job1 C ...
... ...
...
Batch Scheduler
rdisp/btctime Default = 60s
Dispatcher
Dispatcher
D-WP B-WP
B-WP
B-WP
3
3
Jobstatus
geplant freigegeben bereit aktiv fertig abgebrochen

Dialogprogramm : Maximale Dauer Prozesschritts = rdisp/ max_wprun_time
Batch : Dialogfreie Abarbeitung lang laufender Programme
Keine Benutzeraktion !
Periodische Aufgaben - Datenübernahme, Statistik, ETL, Transportwesen …
Jobs in Einplanungstabelle → Name, Prio, Starttermin / Event
Anstoß durch Batch-Scheduler / Event-Scheduler via Einplanungstabelle
Ausgelöst zu definierter Zeit oder durch Systemereignis
C
Job → Immer von einem Batchjob-WP abgearbeitet = feste BWP-Zuordnung !
Job = Ein oder mehrere Steps :
- ABAP-Programm (ohne Eingabescreen oder mit hinterlegten Eingabedaten)
- externes (Betriebssystem-) Programm
Jobprioritäten : Klasse A, B, C mit / ohne Ziel-AppServer-Angabe

Jobübersicht
Aufruf : sm37
Werkzeuge → CCMS → Jobs → Pflege
Doppelklick auf Listeneintrag liefert Infos zum Job …
Quelle: SAP

SAP-LUW versus DB-LUW
Problem 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

SAP-Transaktion = SAP-LUW versus DB-LUW
SAP-LUW = SAP Logical Unit of Work
In sich abgeschlossener betriebswirtschaftlicher Vorgang
Logisch zusammenhängende Einheit von Schritten eines bwl. Vorgangs
Umfaßt Benutzerdialoge, AS-Auswertlogik und auch DB-Änderungen …
Forderung nach Transaktionalität Alles oder Nix
Gesamtheit eines betriebswirtschaftlichen Vorgangs transaktional darstellen !
Persistenzforderung :
DB-Änderungen einer SAP-Transaktion auf eine DB-LUW bündeln !
Problem :
Bei direkten DB-Zugriffen verteilt sich eine SAP-LUW auf mehrere DB-LUWs !
Mechanismen nötig, um alle DB-Änderungen in einer DB-LUW zu bündeln !

Datenbank-LUW (Logical Unit of Work)
DB-LUW : Unteilbare Folge von Operationen, die DB von einem konsistenten Zustand in
nächsten überführen → zwischen zwei DB-Commits oder DB-Rollbacks
Ganz oder gar nicht → Prinzip ACID
Abgeschlossen durch DB-Commit : Davor DB-Rollback noch möglich
Durch Commit werden Änderungen festgeschrieben.
Konsistenter
Zustand 1
Zwischenzustände
Konsistenter
Zustand 2
ROLLBACK
möglich
Datenbankoperationen
insert update delete
DB-COMMIT
( oder DB-Rollback )
Sperren auf DB-Tabellensätze halten
alle Sperren
freigeben
Physische Sperren :
Nicht hintergehbar !

DB- LUW
SAP-LUW
DB-Änderungen
ABAP-
programme
Benutzerdialoge
Logical Units of Work
AS

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

Unvorhersagbar lange Benutzer-Interaktions-Zeiten dürfen nicht in DB-LUW eingehen !
Keine Benutzer-Interaktion innerhalb DB-LUW !!
Performanz der kritischen Ressource DB erfordert impliziten, automatisch
getriggerten DB-Commit nach jedem einzelnen Transaktionsschritt (bei Freigabe
DWP) - auch wenn bwl. Transaktion noch nicht abgeschlossen ist !
DB kennt keine prozessübergreifenden Transaktionsabläufe :
Wenn AppServer-DWP endet, der dem DB-Workprozess zugeordnet ist, dann muss auch ein DB-
Commit erfolgen, damit Datenänderungen nicht verloren gehen, die während dieses Dialogschritts
vorgenommen wurden.
Beim nächsten Dialogschritt ist dem Verwender ein anderer AppServer-DWP zugewiesen.
Die Datenbank ist nicht in der Lage, Änderungen zu bündeln, die sich über mehrere Dialogschritte
hinweg durch mehrere verschiedene aufeinander folgende AppServer-DWPs ergeben.
Lösungen …

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

Organisation DB-Änderungen :
Nicht direkt im Dialog ausgeführt - sondern in Protokolltabelle nur gesammelt +
dadurch vorgemerkt zur späteren gemeinsamen Ausführung / Abarbeitung
Nach Ende SAP-Transaktion protokollierte DB-Änderungen komplett ausgeführt
Ausführung = Schreiben in DB →
Asynchron an Verbuchungs-WP delegiert - während Verwender weiter arbeiten kann
Transaktionalität Prinzip :
Entkopplung von Dialog und DB-Update → Verbesserung Skalierung
+
Bündelung / Vormerkung von DB-Änderungen …
… zur späteren gemeinsamen Ausführung - ganz oder gar nicht

DB
DB XXX xxxx
XXX xxxx xxxx xxx xxx xx
UUU uuuu uuuu uuu uuu uu
UU uuuu uuu u
VB*
Verbuchungs-Server
. . . . . .
MS
. . .
Dialog-Server
D-WP
Dispatcher
V-WP
Dispatcher
ABAP :
COMMIT WORK
1
2 3
4 5
Protokolltabellen
ABAP :
Call Function
in update task

Asyn. Verbuchung : Bündelung DB-Änderungen
Workprozess
Dialog-
WP
Workprozess
Verbucher-
WP
SAPGUI
Ziel : Trennung Dialogschritte von DB-Änderungen
Sammlung / Bündelung aller DB-Änderungen der SAP- LUW →
Gemeinsame Ausführung am Ende SAP-LUW in einer einzigen DB-LUW
DWPs führen DB-Änderungen nicht direkt (= synchron) aus
Übergeben Änderungsaufträge an Verbuchungs-Mechanismus
Asynchron ≡ DWP / User wartet nicht auf Verbucher !
asynchron
Protokoll-
tabelle
SQL in spez.
Funktions-
bausteinen

Wirkung Rollback Work
ROLLBAK WORK
Vormerkung 3
Vormerkung 1
Vormerkung 2
Workprozess
Dialog-
WP
PROGRAM ...
.
.
ROLLBACK WORK.
Dialogprogramm
Löschen aller bis
dahin geschriebenen
Vormerkungen
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 auslösen

Asynchrone Verbuchung
A
A
B
B
C
C
SAP-LUW 1 Dialogprogramm
SAP-LUW 1 Verbuchungsprogramm
Text
Vormerkung n
Vormerkung 1
. . .
Protokoll-
tabelle
VBLOG
auf DB
DB
Dialog-WP Verb.-WP
COMMIT WORK.
A
A
B
B
C
C
Zeit
Dialogprozess wartet NICHT auf Ausführung der DB-Änderung !
Dialogprozess und Verbuchung sind zeitlich entkoppelt
Asynchron !

Synchrone Verbuchung
Verb.-WP
Dialog-WP
COMMIT WORK
AND WAIT.
A
A
A
A
B
B
C
C
SAP-LUW 1 Verbuchungsprogramm
B
B
C
C
Zeit
Text
Vormerkung n
Vormerkung 1
. . .
Protokoll-
tabelle
VBLOG
DB
DB
Dialogprozess wartet auf Ende der Ausführung der DB-Änderung !
COMMIT WORK AND WAIT

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

Setzen von Sperren
Verwaltung konkurrierenden
Zugriffs auf selbe Daten
Programm C
Programm 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

Bei direkter DB-Ä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 / LUW :
Ersteckt sich i.A. über mehrere Bildschirmbilder
Sperren müssen länger gehalten werden als nur über einen Dialogschritt !
Benötigt wird DB-unabhgängiger high-level Sperr-Mechanismus :
Logische Sperren

Datenbanksperren reichen nicht
COMMIT
(implizit)
SELECT
UPDATE DELETE
DELETE
INSERT
INSERT
UPDATE
UPDATE
Sperren
COMMIT
(implizit)
COMMIT
WORK
(explizit)

SAP Sperrkonzept : ENQUEUE-WP
Ziel : Sperren über Bildwechsel System-global aufrechterhalten
Mittel : Globale Sperrtabelle auf AppServer - 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
Dialog
WP
Dialog . . .
Dispatcher
WP
Enqueue
WP
Sperrtabelle
Message
Server
SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI SAPGUI

Sperren setzen + löschen
ABAP
Programm
Sperrbaustein
Auftrag :
Erzeuge Sperre
Antwort :
Sperre erfolgreich gesetzt
Keine Sperre gesetzt
Eintrag bereits gesperrt
Fehler in Sperrverwaltung
Sperrtabelle
EXCEPTIONS
keine
FOREIGN_LOCK
SYSTEM_FAILURE
ABAP-Programm reagiert auf
Returncode
Wenn Sperre bereits gesetzt ist :
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/E)
Sperreintrag
erzeugen
Call Function
ENQUEUE_...
Sperren zurücksetzen :
durch Programm
oder
durch Verbucher

Sperrmodus
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
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 AppServers in
Enqueue-Tabelle verwaltet
Physische DB-Sperren
Automatisch durch Datenbank
angewandt
Am Ende der DB LUW durch DB
freigegeben
In DB verwaltet

Weitere Strukturen & Performanz-Technologien
SAP Lastverteilung
Workprozessverteilung und Einstellung
Betriebsarten-Konzept
SAP DB-Schnittstelle & Dictionary
Exkurs : CAP-Theorem & Verteilte Systeme
SAP Puffer : Tabellenpuffer der App-Server
Aktualisierung + Synchronisation
Pufferungsprinzipien & -Arten

SAP Lastverteilung
Table
Buffers
Dispatcher
SPO
WP
BTC
WP
DIA
WP
Table
Buffers
Dispatcher
DIA
WP
ENQ
WP
Enqueue
Table
SAP
GUI
SAP
GUI
SAP
GUI
SAP
GUI
SAP
GUI
DBWP
DBWP
DBWP DBWP
Gateway
Gateway
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

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 = 2 ...
Workprozessverteilung
Service Systemweit Per AS-Instanz
Dialog >=2 >=2
Verbuchung >=1 >=0
Enqueue 1 0 oder 1
Batch >=1 >=0
Message 1 0 oder 1
Gateway >=1 1
Spool >=1 >=0
Systemstart :
1. Datenbank
2. Zentrale Instanz
3. Weitere Instanzen
Abfrage System-Werte :
Report RSPFPAR

Betriebsarten :
Dynamische 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
Patterns
Adaptive Computing
Pooling

Betriebsarten : Dynamische Anpassung …
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
Automatischer Betriebsartenwechsel :
Anpassung an aktuelle Anforderungen
Automatische Änderung Workprozess-Verteilung zu vordefinierten Zeitpunkten
Beispiel :
Tagesbetrieb → Zahlreiche Dialog-WPs
überwiegend Dialog-User, wenig Batch
Nachtbetrieb → Umwandlung von Dialog-WPs in Batch-WPs
überwiegend Batch

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
DB
Schnitt
-stelle
Lokale
Puffer
Daten
Relationale
Datenbank
Native-SQL
ABAP Open-SQL : In ABAP integriertes Subset von SQL (nur DML)
Ablauffähig mit allen von SAP unterstützten DBMS - ohne Anpassung !
Vermeidet herstellerspezifisches SQL + manuelles Handling von DB-Verbindungen
Durch DB-spezifische DB-Schnittstelle des App-Servers in Native-SQL umgesetzt
Native-SQL
Nutzt vollen
Sprachumfang
aber :
Abhg. von DB-
Hersteller !
Umgeht
Tabellenpuffer !
Open SQL
Plattform- und
DB-unabhängig
Verschalung der
DB-Schnittstellen
verschiedener
DB-Hersteller

ABAP Dictionary : Definition SAP-Datenstrukturen
Datenstrukturen und Tabellendefinitionen
Definieren + Anlegen von DB-Tabellen + Verwaltung ihrer Eigenschaften
Dictionary übernimmt DB-spezifische Umsetzung
ABAP-Compiler und -VM greifen darauf zu
Alle Programme arbeiten somit stets mit aktuellen globalen Datenstrukturen.
Enthält nicht Daten selbst, sondern Definition zugrundeliegender Datenstrukturen.
Sicht auf Struktur aller Anwendungsdaten.
Mantra des klassischen SAP-Systems : ( ≠
≠
≠
≠ HANA ! )
Datenstrukturen werden nie direkt auf der DB angelegt !
Es findet nie ein direkter Zugriff auf die DB statt !
Alle DB-Operationen führen über den AppServer !

Consistency "ACID"
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 ! CP oder AP !!
Atomic
Consistency
Continuous
Availability
Partition
Tolerance
Bei verteilten Systemen nur
zwei von dreien zu haben …

Zwei aus Drei - Garantien :
AC-Systeme atomare Konsistenz + Verfügbarkeit
AP-Systeme Verfügbarkeit auch bei partiellen Ausfällen
CP-Systeme atomare Konsistenz auch bei partiellen Ausfällen
AP = BASE ≠ ACID
Basically Available - Soft State - Eventual Consistent
Schlussendliche Konsistenz :
Knoten erhalten / sehen / bearbeiten für gewisse Zeit veraltete Daten !
Dennoch keine prinzipielle Daten-Inkonsistenz - denn :
Erfolgen keine weiteren Schreiboperationen, sind schlussendlich alle Daten synchron.
Atomic
Consistency
Continuous
Availability
Partition
Tolerance
Bei verteilten Systemen nur
zwei von dreien zu haben …

ACID
Atomicity
Consistency
Isolation
Durability
Exkurs CAP-Theorem : ACID vs BASE
Traditionelle Systeme basieren auf Prinzip ACID
Verteilte Systeme priorisieren verstärkt BASE
ACID BASE
Starke aktuelle Konsistenz
Primär: Isolation + Transaktionalität !
Konservativer Commit
Langsamer
Schwieriger zu implementieren
Schwache Konsistenz - über Zeitraum
Primär: Ständige Verfügbarkeit !
Best effort : Ungefähre Antworten ok
Performanter
Einfacher umsetzbar
BASE
Basically Available
Soft-State
Eventual Consistent
Grundlegende Problematik verteilter Systeme ...

SAP-Tabellenpuffer der AppServer
DBMS
Datenbank
ABAP Programm 1
Tabellen
puffer
DB-
Schnittstelle
AppServer 1
ABAP Programm 2
Tabellen
puffer
DB-
Schnittstelle
AppServer 2
1 - 60 ms
Füllen Puffer :
Beim ersten Lesen
Nach Änderungen
Nach Synchronisation - s.u.
Pufferung von DB-Tabellen auf AppServern :
Reduzierung Lese-Zugriffszeit → Rascher Zugriff durch AppServer
Entlastung Datenbank → Reduzierung Zahl teurer DB-Zugriffe
Tabellenpuffer sind
lokal zum jeweiligen
AppServer-RAM
Open-SQL
Native
SQL
Weitere Puffer für :
Programme
Bildschirm-Bilder
Dictionary-Daten
CAP-Theorem
Atomic
Consistency
Continuous
Availability
Partition
Tolerance

Aktualisierung + Synchronisation
bufreftime
(Default: 120 s)
Zeitverzögerte
Synchronisation der
Puffer der anderen
AppServer !
Kann Systemverhalten
beeinflussen !
Synchronisations-Informationen
Periodisch von AppServern gelesen
Intervall → Profilparameter
bufreftime
Vorteil : Netzlast gering – kein Broadcast
Nachteil : Lokale Puffer enthalten evtl. veraltete Daten
DBMS
PROGRAM z...
UPDATE dbtab1 ...
dbtab1 DB-
Schnittstelle
AS 1
ABAP Programm 2
dbtab1
DB-
Schnittstelle
AS 2
Datenbank
dbtab1 dbtab1 X
aktuell
verzögert
AppServer, der Daten
auf DB ändert,
aktualisiert zugleich
eigenen Puffer

SAP-Tabellenpuffer - Sinnvolle Pufferung
Pufferungsfähige Tabellen :
relativ kleine Tabellen mit meist lesendem Zugriff
Tabellen deren Inhalt sich selten verändert
z.B. Stammdaten, Customizing Parameter ...
Pufferung problematisch :
wenn Daten ständig aktuell sein müssen - Beweguungsdaten
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 Tabelle festgelegt
Residente Pufferung - gesamter Tabelleninhalt komplett gepuffert
Generische Pufferung - nur Bereiche der Tabelle gepuffert
Partielle Pufferung - nur Einzelsätze gepuffert
Nicht alle Tabellen
Puffer - geeignet !

Zusammenfassung & Ausblick
SAP ERP AS :
Betriebliche Anforderungen & Technologische Lösungen
Integrations - Aspekte
Neue Strategische Anforderungen

SAP ERP AS :
Bwl. Anforderungen ↔
↔
↔
↔ Technologische Lösungen
Prozessorientierung
Anpassbarkeit der Prozesse
MultiUser MultiTasking
Begrenzte Ressourcen
Darstellung 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

SAP ERP AS : Integrations-Aspekte
Integrations - Aspekte :
Bwl. Prozess-Integration
System bildet nicht einzelne Funktionen sondern ganze Prozessabläufe ab.
Datenintegration
Einheitliche stets aktuelle Datensicht für alle Prozesse durch zentrale DB.
Systemintegration
Alle Prozesse durch ein System abgebildet (Monolith).
Administrative Integration
Technische Handhabung & Kontrolle erfordert keine separaten Tools.
Wird im System selbst vorgenommen.
Vermeidung von System-, Medien-, Daten- und Organisationsbrüchen
Prozessorientierung & Konsistenz & Transaktionalität

Neue Strategische Anforderungen
Moderne Standards + Technologien :
Web, EAI, WS, SOA, REST, Microservices, Mobile & Social & Cloud, DS & ML & KI …
Internetbasierte Unternehmens-übergreifende Prozesse SOA / Microservices
Integration heterogener Umgebungen + technologische Agilität
Global Commerce
Proprietäre Strukturen hinderlich - Offenheit wichtiger als Performanz
Neue SAP Technologien & Architekturen :
Erweitertung AS-Plattform : SAP Web AS →
→
→
→ Netweaver AS →
→
→
→ SAP S/4HANA
ABAP VM + Java VM als gleichberechtigte Laufzeit- & Entwicklungsumgebungen
Aufgabe DB-Agnostizismus → SAP HANA : IMDB → Integration OLTP & OLAP
Cloud-Modelle / Outside In-Architekturen / Hybrides "postmodernes" ERP …

SAP_Basis_Klassisch.pdf

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie SAP_Basis_Klassisch.pdf

Ähnlich wie SAP_Basis_Klassisch.pdf (20)

SAP_Basis_Klassisch.pdf