(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