Netzwerkkommunikation von SAP R/3 10.11.1999

Client/Server-Architektur Übersicht Client/Server-Architektur TCP/IP-Protokoll Höhere Protokolle / Schnittstellen Datenaustausch / Verteilungsstrategie Übersicht : Netzwerkprotokolle 10.11.1999

Client / Sever - Konzept R/3 : dreistufige Client/Server-Architektur. Grundlegende Client/Server-Konfigurationen 10.11.1999

Client/Server : Übertragungsraten (I) R/3 führt die gesamte Netzwerkkommunikation (keine Großrechner-Anbindung) über TCP/IP (Transmission Control Protocol / Internet Protocol) Präsentation <-> Application-Server: 1,5-2,0 KB / dialog step (nur GUI-Verkehr, keine Druckvorgänge, Grafiken, Uploads) -TCP/IP : Übertragungsraten hängen im wesentlichen auch vom Netzwerktyp ab. (Ethernet, Token Ring , ATM, FDDI) - Präsentations-Sever <-> Appl. : Übertragung nur der sichtbaren Daten. Wenn der Nutzer sich eine Liste anguckt, werden nur diese paar Zeilen übertragen. Wenn gescrollt wird, ist dies eine neue Anfrage -> neue Zeilen Das gleich gilt für einen Texteditor. dialog step = screen change - Appl. <-> DB-Server : hängt von einer Vielzahl von Faktoren ab. Wobei aus dem Paper nicht klar geworden ist, was in dieser Situtation unter einem Dialog-step zu verstehen ist. Application-Server <-> DB-Server : ca. 20 KB / dialog step mindestens 10Mbit / s ab mittelgrossen Anwendungen : 100Mit / s (bzw. FDDI) 10.11.1999

Client/Server : Übertragungsraten (II) - optional : LSC (low speed connection) für WANs dieses flag wird beim anmelden der Präsentationseinheit beim App. Server dann gesetzt, wenn es sich um eine wirklich "langsame" Verbindung handelt : (Abgespeckter Zugang) *die Menüs werden nur noch auf Anfrage geladen *Background Bitmaps werden nicht übertragen *Dynamische Netzwerkspezifische Reaktionmöglichkeiten R/3 Network Load : Compressed Data Stream 10.11.1999

Client/Server : Übertragungsraten (III) Definitionen: C := Erforderliche Leitungskapazität, gemessen in bit/s L := Auslastung der Leitung (0 <L< 1) Tverarb := Verarbeitungszeit zwischen zwei Dialogschritten Treak := Reaktionszeit N := Gesamtanzahl der Benutzer, die mit der Verarbeitungszeit TVerarb und bei einer Reaktionszeit TReak arbeiten - benötigte Netzwerkkapazitäten lassen sich aus folgender Formel (von Susanne Janssen, SAP) berechnen - Eingabeparameter : Leitungsauslastung / Verarbeitungszeit zwischen den Dialogschritten / Reaktionszeit / Anzahl der Nutzer - Um akzeptable Netzwerkantwortzeiten sicherzustellen sollte die Auslastung nicht mehr als 50 % betragen, da die Daten sonst nicht mehr in einem zusammenhängenden Stream übertragen werden - Kapazität nicht weniger als 9600 bits /s C =16.000 * N / [L * (TVerarb + TReak)] bit/s 10.11.1999

Client/Server : Übertragungsraten (IV) 15 Benutzer, 10 s Verarbeitungszeit, 2 s Reaktionszeit, N = 15, L = 0,5, C = 16.000 *30 / [ 0,5 (30 s +2 s)] bit/s = 40.000 bit/s => 64.000 bit/s Leitung Beispiel 1: Beispiel 2: 30 Benutzer, 30 s Verarbeitungszeit, 1 s Reaktionszeit, N = 30, L = 0,5, C = 16.000 *30 / [ 0,5 (30 s + 1 s)] bit/s = 31.000 bit/s => 64.000 bit/s Leitung 10.11.1999

Client/Server-Architektur TCP/IP-Protokoll Höhere Protokolle / Schnittstellen Datenaustausch / Verteilungsstrategie Übersicht : Netzwerkprotokolle 10.11.1999

TCP/IP-Protokoll im R/3 Netzwerk Das ISO-OSI Modell 7 6 5 4 3 Open System Interconnection (nur der Vollständigkeit halber) Schichten : 1- Bitübertragung : RS 232, ISDN 2- Sicherung : Ethernet, FDDI, Token-Ring, ATM 3- Vermittlung : IP 4- Transport: TCP, UDP 5- Sitzung 6- (Sun-spezifisch) 7- Anwendung 2 1 10.11.1999

Das TCP/IP-Protokoll : Begriffsklärung 5-7 4 3 - IP-Adresse : 131.234.***.*** - Host-Name - es ex. Namensauflösung : DNS 10.11.1999

(in den Anfängen des Internet : das ARPA-Netz) Das TCP/IP-Protokoll TCP/IP ist eine Protokollfamilie, sie deckt die Schichten 3 bis 7 des OSI- Modells ab TCP/IP hat sich in den 70ern als offener Standard für verteilte Systeme durchgesetzt (in den Anfängen des Internet : das ARPA-Netz) Wird von der Internet Engineering Task Force (www.ietf.org) weiterentwickelt (IPv4 -> IPv6) 10.11.1999

Client/Server-Architektur TCP/IP-Protokoll Höhere Protokolle / Schnittstellen Datenaustausch / Verteilungsstrategie Übersicht : Netzwerkprotokolle 10.11.1999

Höhere Protokollschichten von R/3 COM / DCOM - R/3 ist ein offenes System. Es ist in verschiedene applicationen integriert und daher nicht isoliert. Daher kann R/3 auch mit nicht-SAP Produkten kommunizieren. (selbstgeschriebenes Programm ist überall (also mit jedem Protokoll) in der Lage zu kommunizieren. Die Integration von Standard-Software ist immer wichtiger geworden. - LU 6.2 von IBM entwickelt, Mainframe-basiert (für R/2-Systeme) - nexte folie :Genauere Aufsplittung 10.11.1999

Höhere Protokollschichten von R/3 CPI-C - program-to-program : ein Prg. ruft direkt einen Kommunikationspartner - event-driven communication : ein Prg. veröffentlicht einen event. Dieser wird von einem event management system an angemeldete Programme geliefert. - Data-oriented interface : sind für Datenzugriffe, die in Dateien oder DBs gespeichert sind (Datenübermittlungen) - interfaces for application : application Semantik (einen Auftrag entgegennehmen oder einen request auslösen) - basis technology : Grundlage für die interfaces for appl. ----------------------------------------------------------------------- EDI Electronic Data Interchange ALE Application Link Enabling IDOC Intermediate Documents RFC Remote Function call BO Business Objects BDC Batch Data Communication (insert external data into the application database via SAP transactions) R/3 External Interfaces / Protocols 10.11.1999

Das CPI-C Protokoll (I) (Common Programming Interface - Communication) Kommunikation : R/3-R/2 -Systemen oder R/3-außerhalb CPI-C war bereits in R/2 implementiert. Dient zur rechnerübergreifenden Programm- Programm-Kommunikation. (z.B. aus ABAP heraus) Low-Level Programmierschnittstelle : Byte-orientiert. Verbindungsdefinition ohne explizite Login-Funktion - war bereits in R/2 implementiert, da gab es aber kein RFC (alles vor R/3 Release 2.0) Historisch bedingt : CPI-C ist ein Vorläufer von höherer Protokolle 10.11.1999

Das CPI-C Protokoll (II) Ursprünglich eine Implementierung für das LU 6.2 Protokoll auf IBM Mainframe CPI-C Komm. wird über ein SAP-Gateway gerouted. Sprachneutrale Kommunikationsumgebung aber fehleranfällig (EBCDIC oder ASCII, Big oder Little Endian) CPI-C ist „schwierig zu handhaben“ - CPIC ist "schwierig zu handhaben" Es gibt nur die Möglichkeit auf einer sehr niedrigen Ebene Daten zu senden. Call Function, destination, export, import Um dem Nutzer das Schreiben von Kommunikationsroutinen abzunehmen wurde RFC generiert. 10.11.1999

Das CPI-C Protokoll (III) - Gateway-Server ist notwendig um die Grenzen eines R/3-Systems verlassen zu können, Auf dieser Grafik nicht zu erkennen: - jedes R/3-System hat mindestens ein Gateway - evtl. ist auf jedem Appl-Sever ein Gateway-Server installirt. Gateway-Server (oder CPIC-Server) 10.11.1999

(Remote Function Call) RFC Das RFC-Protokoll (I) (Remote Function Call) Von SAP definierter Standard : Funktionen werden auf einem entfernten Rechner aufgerufen. in ABAP wurde dazu die RPC (Remote Procedure Call)-Schnittstelle implementiert (aus UNIX). subs : Schnittstellen zwischen Client bwz. Server und dem Laufzeitsystem Einen einheitlichen Standard für RPC gibt es nicht, daher hat SAP den RFC implementiert 10.11.1999

Client wartet bis der Server die Daten zurückliefert. RFC Die RFC-Typen (II) Synchrone RFCs : Client wartet bis der Server die Daten zurückliefert. Asynchrone RFCs : Client arbeitet weiter, Server initiiert Callback Transaktionale RFCs : (secure asynchon communication) ACID-Bedingungen 10.11.1999

Das RFC-Protokoll (III) RFC übernimmt : Kommunikationssteuerung Parameterübergabe Fehlerbehandlung 4 periods in an RFC : CALL step CALL RECEIVE step -((Verweiss auf die vorherigen Folien)) CPIC ist "schwierig zu handhaben" - 4 steps : Zeitlicher Ablauf : spätere Folie RETURN step RETURN RECEIVE step 10.11.1999

Das RFC-Protokoll (IV) Kommunikationsübersicht - Richtungen : Extern, R/2, R/3 - R/3-System hat RFC-Interface (basiert auf CPIC-Interface) - R/2-System ebenfalls RFC-Interface aber LU 6.2 Das Gateway convertiert dies zu TCP/IP - Externe Programme : RFC library (RFC API) (innerhalb R/* möglich durch ABAP/4 (call function)) - generierung von stubs (s. RPC) (hier nicht sichtbar) - seideinfo table : initialisierungs-Infos (heisst in R/3 : RFCDES, R/2: TRFCD) Das RFC-Konzept 10.11.1999

2- die weiteren Kommunikationspartner über GatewayI 1- Nutzer mit SAPGU 2- die weiteren Kommunikationspartner über GatewayI 3- Applications-Server mit seinem einen Dispatcher und ver 4- schiedenen Work-Prozessen Die eigentliche RFC-Server funktionalität ist in einem speziellen abap system Programm (SAPMSSY1) implementiert und wird ausgeführt wenn ein RFC-Request empfangen wird. Der Work-Prozess enthält die Komponenten : Taskhandler (CPIC Interface), DYNP und ABAP Prozessor . Sie sind für das ABAP runtime system zuständig. Der APAP Prozessor nutzt für die Versendung und den Empfang Dienste, die im Taskhandler implementiert sind Die CPIC-Schnittstelle ist im Taskhandler implementiert. Client und Server programs (stellen Anfragen und beantworten sie) werden in die PXA (Program Execution Area) geladen. (Zuständig für die Speicherverwaltung). Roll Area : Enthält alle Informationen für jede aufgebaute (offene) RFC-Verbindung. Für eine wiederholte RFC-Anfrage an das gleiche Ziel, wird die gleiche offene Verbindung genutzt. 10.11.1999

RFC Processing on the Client and Server Side 4 Prozess-Schritte : CALL: Der Dispatcher empfängt einen APPC-Request (Advanced Program-to-Program-Communication) vom Gateway. Verbindung zum 1. mal : thaskhandler inizialisiert die work prozess area und veranlasst den DYNP das RFC-server modul SAPMSSY1 zu laden (INIT) CALL RECEIVE: die Verbindungsoptionen werden gelesen und eine Nutzerauthentifizierung findet statt. Dann wird der "Function Modul Stub" (nicht sichtbar) initialisiert. RETURN: die Daten werden zum Client geschickt. RETURN RECEIVE: Client empfängt ROLL IN / OUT : Speichermanagement 10.11.1999

RFC Processing on the Client and Server Side (with call back possibility) 10.11.1999

Das OLE-Protokoll (I) von MS definierte Standards zur Programm- OLE / COM Das OLE-Protokoll (I) von MS definierte Standards zur Programm- Kommunikation 10.11.1999

Das OLE-Protokoll (II) OLE / COM Das OLE-Protokoll (II) (Object Linking and Enbedding) RFC - die Applikationen melden sich beim OLE-Automation-Server an - Anfragen werden an den automation-server gestellt R/3 als OLE-Client 10.11.1999

Das OLE-Protokoll (III) OLE / COM Das OLE-Protokoll (III) (Object Linking and Enbedding) Objekte in Form von EXE, DLL oder OCX-Dateien Verbesserungen : COM, DCOM (Distributed) - Component Object Model in der Windows-Welt entstanden, aber Betriebssystem unabhängig (COM) 10.11.1999

Client/Server-Architektur Übersicht Client/Server-Architektur TCP/IP-Protokoll Höhere Protokolle / Schnittstellen Datenaustausch / Verteilungsstrategie Übersicht : Netzwerkprotokolle 10.11.1999

Application Link Enabling (ALE) Datenbank von R/3 ist (bisher) immer eine Zentralsystem Dies bietet Nachteile wenn : Organisationseinheiten räumlich getrennt sind Unternehmen-übergreifende Prozesse vorhanden sind die Leistungsfähigkeit stößt an ihre Grenzen Lösung ist ALE : Verteilung von betriebswirtschaftliche Funktionen und Anwendungen auf lose R/3-Sysmteme - Datenverteilung findet permanent zwischen mindestens zwei aktiven Systemen statt. - Datenübernahme spielt dagegen eher bei der Ablösung eines Fremdsystems wie R/2 eine Rolle (oder Übernahme von Daten von eimem Geschäftspartner) - ALE <-> Workflow-Management - es werden nicht nur Daten übertragen, sondern es werden Folgereaktionen ausgelöst ------------- - weiterer Nachteil : evtl. Sicherheitsaspekte Kopplung von R/2, R/3 und anderen Systemen Vorbereitete Szenarien 10.11.1999

Beispiel für ALE - SAP hat schon viele verteilte Modelle im Angebot, an denen sich Firmen orientieren können. Diese können komplett übernommen werden oder sie werden (geringfügig) modifiziert. (reference distribution model) 10.11.1999

Technische Grundlagen von ALE 1. Verteilung mit Hilfe von Nachrichtentypen Anwendungsereignisse werden durch Nachrichten im R/3-System ausgelöst. (Nachricht = betriebswirtschaftliche Funktion + Daten) Diese werden durch sog. Intermediate documents (IDoc) verteilt (basierend auf tRFC). 2. Verteilung mit BAPIs BAPIs ermöglichen den Zugriff auf Business-Objekte mit bel. Hilfsmitteln und Programmiersprachen. IDocs = container für die Daten. 10.11.1999

Der Aufbau von IDOCs Bei R/2 oder R/3 möglich - dynamischer Headder => Kommunikation ist unabhängig von Versionen und kompatieble Erweiterungsmöglichkeiten. - IDOCs basieren auf RFCs, genauer transaktionale RFCs -------------------- Aufbau : - Kopf : Sender, Empfänger, Stuktur - Datensegmente : jedes Segment enthält einen Informationskopf und eine bis zu 1000 Zeichen lange Feldliste - Statussätze : beschreiben die bisherigen Verarbeitungsschritte 10.11.1999

Technischer Ablauf von ALE mittels IDOCs Unterschied : Master IDoc und Communication IDoc System 1 sendet an System 2 / Es wird ein Master-IDoc erzeugt (kann auch für EDI genutzt werden) ALE-Layer verbindet das "business level" mit dem technischen Level : Daten werden mit einer betriebswirtschaftlichen Fkt. zusammengefasst Übertragung findet statt... --------------- Meistens finden die Übertragungen mittels IDocs asynchron statt. Wenn keine Verbindung zustande kommt wird es später noch einmal probiert (aber aufgezeichnet) ((Im synchonen Fall, werden nur Informationen benötigt. Es werden keine Daten rausgeschickt)) 10.11.1999

ALE - Verteilung mit BAPIs 10.11.1999

Client/Server-Architektur Übersicht Client/Server-Architektur TCP/IP-Protokoll Höhere Protokolle / Schnittstellen Datenaustausch / Verteilungsstrategie Übersicht : Netzwerkprotokolle 10.11.1999

Übersicht : Transport-Services TCP/IP Transport Control Protocol / Internet Protocol IEEE 802 Protokoll und Hardware-Schnittstelle für Ethernet X.25 Kommunikationsprotokoll, WAN (Datex-P) ISDN Integrated System Digital Network, WAN Ethernet Netz-Hardware im LAN-Bereich Token Ring Netz-Hardware im LAN-Bereich FDDI Fibre Distributed Data Interchange 10.11.1999

Übersicht : die Protokolle LU 6.2 Logical Unit - IBM Netzwerkprotokoll CPI-C Common Programming Interface-Communication (Low-Level) RFC Remote Function Calls (High-Level) (auch RPC) OLE Object Linking and Embedding ALE Application Link Enabling (Verteilung betriebswirtschaftlicher Objekte) EDI Electronic Data Interchange (Austausch von Handelsnachrichten) X.500 Electronic Mail (auch SMTP, POP3, IMAP) DDE Dynamic Data Exchange ODBC Open Data Base Connectivity Q-API Queue Application Interface 10.11.1999