Netzwerkkommunikation von SAP R/3

Präsentation zum Thema: "Netzwerkkommunikation von SAP R/3"—  Präsentation transkript:

1 Netzwerkkommunikation von SAP R/3

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

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

4 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)

5 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

6 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 = * N / [L * (TVerarb + TReak)] bit/s

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

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

9 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 Das TCP/IP-Protokoll : Begriffsklärung
5-7 4 3 - IP-Adresse : ***.*** - Host-Name - es ex. Namensauflösung : DNS

11 (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 ( weiterentwickelt (IPv4 -> IPv6)

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

13 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

14 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

15 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

16 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.

17 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)

18 (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

19 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

20 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

21 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

22 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.

23 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

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

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

26 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

27 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)

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

29 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

30 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)

31 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.

32 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

33 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))

34 ALE - Verteilung mit BAPIs

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

36 Ü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

37 Ü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