SAP System R/3 - Technische Informatik
Werbung
Client/Server-Systeme Prof. Dr.-Ing. Wilhelm Spruth SS 2003 Teil 12 SAP System R/3 cs 0800 ww6 sch 02-97 SAP System R/3 Literatur R. Buck-Emden: „Die Client/Server Technologie des SAP System R/3“. Addison-Wesley 1996. L. Will: „Administration des SAP System R/3“. Addison-Wesley 1997. Es existieren zahlreiche Bücher über die System R/3 Programmierung unter ABAP/4 sowie über den betriebswirtschaftlichen Einsatz. cs 1317 ww6 wgs 04-98 R/3 Anwendungen ABAP/4 Development Workbench R/3 Middleware (R/3 Technology Infrastruktur) Betriebssystem Unix, NT, OS/400, OS/390 Schichtenarchitektur des SAP Systems R/3 Das R/3 Laufzeitsystem ist in C und in C++ geschrieben. Alle von SAP vorgefertigten Anwendungsprogramme und alle vom Benutzer selbst erstellten Anwendungsprogramme sind in der SAP proprietären 4GL Sprache ABAP/4 geschrieben. ABAP/4 ist eine interpretative Sprache; die Programme werden interpretativ abgearbeitet. cs 1302 ww6 wgs 04-98 SAP System R/3 Version R/1 (seit 1972) und R/2 (seit 1972) im Einsatz auf S/370 Rechnern. Verwendet CICS als Transaktionsmonitor. System R/3 Entwicklung startet 1988. Erste Anwendung wird 1989 auf der Cebit gezeigt. Im Gegensatz zu System R/2 benutzt System R/3 seinen eigenen Transaktionsmonitor. 1991 erste Kundeninstallation. 1992 graphische Oberfläche SAPGUI verfügbar. 1995 Release 3.0 verfügbar. Sollte ursprünglich System R/2 ablösen. Eine signifikante Anzahl von System R/2 Installationen existiert noch heute, weil System R/3 ursprünglich nur auf Unix Rechnern verfügbar war. 1997 Portierung auf OS/390 Unix System Services. "There are no plans for R/4 today" 7,500+ SAP Kunden in 90+ Länderncountries • 13 000+ R/3 Installationen (15 000 CICS) • 1 400+ R/2 Installationen 60 % der Fortune 500 Unternehmen setzen SAP ein (CICS > 90 %) 81% des Umsatzes ausserhalb Deutschlands (IBM, Microsoft > 90%) cs 0946 ww6 wgs 03-03 R/3 Middleware R/3 Anwendungen ADAP/4 EntwicklungsUmgebung Anwendungsdienste Kommunikations Dienste Präsentations Dienste System Management Sicherheit Daten bank Dienste Betriebssystem OS/400, OS/390, AIX, Sinix, HP/UX, Solaris, NT Rechner Hardware Relationale Datenbank SAP System R/3 System Struktur cs 1333 ww6 wgs 04-98 FF..FF ABAP/4 Anwendungen ABAP/4 EntwicklungsUmgebung Sicherheit Terminal Control Task Program Storage Control Control Control File Control PräsentationsDienste DisAnwen- Speicher Datenpatcher dungsVerbank dienste waltung Dienste System Management Betriebssystem Kernel OS/400, OS/390 USS, LInux, AIX, Sinix, HP/UX, Solaris, Windows 00..00 SAP System R/3 Komponenten Im Gegensatz zu CICS werden für die ABAP/4 Anwendungen eigene Prozesse (z.B. Dialog Work Prozesse) eingerichtet. Es existiert unter R/3 eine eigene ABAP/4 Entwicklungsumgebung. CICS verwendet BMS als „native“ Präsentationsdienst und benutzt BMS zur Darstellung der 3270 „Green Screens“. Die SAP R/3 Präsentationsdienste haben eine vergleichbare Funktion für die SAPGUI. Die Datenübertragung erfolgt mit einem 3270-ähnlichen Protokoll. Im Falle von CICS werden für Sicherheit und System Management die integrierten OS/390 Funktionen benutzt. SAP/ R3 hat hierfür seine eigene Komponenten. cs 0945 ww6 wgs 03-03 R/3 Präsentationsrechner SAP GUI Prozesse LAN, WAN SAP z.B. Oracle, DB/2 Anwendungsserver Datenbankserver modifiziertes 3270 Protokoll Dreistufige SAP R/3 Konfiguration Saubere Trennung zwischen den Funktionen • Präsentation • Anwendung • Datenbank cs 1338 ww6 wgs 04-98 AnwendungsRechner Datenbank Rechner AnwendungsRechner AnwendungsRechner Datenbank Rechner Präsentation Beispiel der dreistufigen R/3 Client/Server Architektur cs 1322 ww6 wgs 04-98 Low End High End Datenbank server Datenbank server z.B. NT z.B. Unix Datenbank server z.B. OS/390 Anwendungsserver Skalierbarkeit von R/3 Installationen cs 1303 ww6 wgs 04-98 Anwendungsserver Datenbank server Zentrale Anwendungsserver Anwendungsserver LAN Router WAN Router Filiale LAN Beispiel für eine R/3 Konfiguration cs 1304 ww6 wgs 04-98 System R/3 SAPGUI Zwischen dem SAP Appplicationsserver und dem Präsentationsrechner werden generische, Plattform unabhängige Beschreibungen der graphischen Darstellung ausgetauscht, nicht aber die bereits komplett aufbereiteten Bildschirmbilder. Die bei einem Bildschirmwechsel zu übertragende Datenmenge liegt typischerweise im Bereich von 1 - 2 KByte. SAPGUI ist der SAP eigene Terminal Prozeß. Er wird für verschiedene Präsentationsumgebungen angeboten, wie z.B. OSF/Motiv oder Microsoft Windows. cs 1345 ww6 wgs 04-03 SAPGUI Mehrfache Fenster und eingebettete Bilder cs 1346 ww6 wgs 04-03 HTTP Internet Transaction Server SAP R/3 Datenbank Server HTML 3-Tier SAP R/3 Konfiguration SAP GUI for HTML Die „SAP GUI for HTML“ ist eine von zwei Möglichkeiten (die andere ist SAP Web Transactionen) für die Implementierung von SAP Internet Anwendungen. Bildet automatisch Screen Elemente in R/3 Transactionen auf HTML ab. Benutzt hierzu „HTML Business Funktionen“ innnerhalb des SAP Internet Transaction Servers (ITS). Das SAP GUI ist das übliche Benutzerfrontend für den Client. Es besteht aus über 150.000 Screens, Dialogboxen und Reports. cs 1344 ww6 wgs 04-03 SAPGUI cs 1235 ww6 wgs 03-03 SAP Begriffe SAP Transaktion Folge betriebswirtschaftlich konsistenter, logisch zusammenhängender Dialogschritte SAP LUW Gesamtheit der Dialogschritte einer Transaktion, einschließlich Verbuchung call transaction commit transaction Dialogschritt cs 0947 ww6 eigenes Bildschirmbild wgs 03-03 Sperr verwaltung Sperre anfordern Sperre freigeben Verbuchung Dialog Transaktion 1 Transaktion 2 Beginn der Transaktion Commit Work Commit Work Logical Unit of Work (LUW) im System R/3 R/3 Anwendungen arbeiten transaktionsorientiert. Ein Logical Unit of Work (LUW) ist die Gesamtheit der Transaktionsschritte, einschließlich der Fortschreibung der Datenbank. Letztere wird als „Verbuchung“ bezeichnet. LUW´s folgen der ACID Maxime. Eine Transaktion besteht aus mehreren Dialogschritten. Ein Dialogschritt wird duch ein eigenes Bildschirmbild repräsentiert und umfaßt die Verarbeitung von eingehenden Daten einschließlich einer Anfangsbildschirmmaske bis zum Abschicken des Reaktionsdatenpaketes und der daraus resultierenden Antwortbildschirmmaske. Die einzelnen Dialogschritte einer LUW können von verschiedenen Prozessen (Workprozesse) verarbeitet werden. Bei der asynchronen Verbuchung wird der Dialogteil einer Transaktion und die dazugehörige Datenbankfortschreibung von unterschiedlichen Prozessen auf unterschiedlichen Rechnern durchgeführt. Die Verbuchung kann aus einer oder mehreren Komponenten bestehen. Aus der Sicht des Datenbanksystems ist jede Komponente eine eigene, unabhängige und vollständige Datenbanktransaktion. (Datenbank LUW im Gegensatz zur SAP R/3 LUW). cs 1306 ww6 wgs 04-98 V1 V2 Datenbank LUW´s Protokollsatz erstellen Dialog schritte R/3 LUW Sperre anfordern Sperre freigeben R/3 Logical Unit of Work Ein Anwendungsprogramm kann mit Hilfe einer Sperre Anforderung einen ausschließlichen Zugriff auf ein spezifisches Objekt erreichen Alle Datenbank Änderungen, die von den Dialogschritten einer R/3 LUW veranlaßt werden, bleiben rücksetzbar, bis die R/3 LUW erfolgreich abgeschlossen wurde. Hierzu erstellen die zu einer Transaktion gehörenden Dialogprogramme einen Protokollsatz für die Datenbankfortschreibung (Verbuchung). Dieser wird nach Abschluß des Dialogteils zur Fortschreibung der Datenbank eingesetzt. Die Verbuchung kann in mehreren Abschnitten, den Verbuchungskomponenten erfolgen. Speziell wird zwischen primären (V1) und sekundären (V2) Verbuchungskomponenten unterschieden. Hiermit können dispositive Datenänderungen (z.B. Reservierungen oder Lagerbewegungen) von statistischen Fortschreibungen (z.B. Ergebnisrechnung) getrennt werden. Erst nach Abschluß der V1 Verbuchungen kann die Sperre eines Objektes wieder freigegeben werden. cs 1312 ww6 wgs 04-98 V1-Komponente Betriebswirtchaftlich zeitkritische Vorgänge, z.B. Bestellungen V2-Komponente V2-Komponente V2-Komponente Betriebswirtschaftlich weniger zeitkritische Vorgänge, z.B. Statistiken V2-Komponente V1-Komponente V2-Komponente V2-Komponente V2-Komponente Zeitachse Abarbeiten der Verbuchungskomponenten cs 1329 ww6 wgs 04-98 V1 V2 Datenbank LUW´s Protokollsatz erstellen Dialog schritte R/3 LUW Sperre anfordern Sperre freigeben Fehlerbehandlung Der Protokollsatz enthält alle für die Datenbankfortschreibung erforderlichen Informationen. Nach Abschluß des letzten Dialogschrittes können logische Fehler, etwa unverträgliche Eingaben, nicht mehr auftreten. Bei Fehlern, die während der Verbuchung auftreten handelt es sich in der Regel um technische Fehler, z.B. Überlauf einer Datei oder eines Pufferbereiches. Handelt es sich hierbei um eine primäre (V1) Verbuchungskomponente, werden alle durchgeführten Änderungen der Datenbank zurückgenommen (existieren mehrere primäre Verbuchungskomponenten gilt dies auch für deren Datenänderungen). Im Falle einer sekundären (V2) Verbuchungskomponente wird nur diese zurückgestellt. Zurückgestellte Komponenten erhalten ein Kennzeichen und können später, nach Bearbeitung der Fehlerursache, erneut bearbeitet werden. Der Benutzer, dessen Dialog den Protokollsatz erzeugt hat, wird per E-Mail vom Abbruch der Verbuchung unterrichtet. cs 1314 ww6 wgs 04-98 Dialog Work Prozesse Task Handler Task Handler Task Handler ABAP/4 Prozessor ABAP/4 Prozessor ABAP/4 Prozessor Dynpro Prozessor Dynpro Prozessor Dynpro Prozessor Dispatcher APPC Server andere Work Prozesse Datenbank Dienste Verbuchung Betriebssystem Kernel R/3 Dispatcher und Task Handler Das R/3 Laufzeitsystem ist als Menge paralleler, kooperierender Systemprozesse realisiert. Auf einem Applications-Server gehören hierzu ein zentraler Dispatcher und eine variable Anzahl von „Workprozessen“. Es gibt Workprozesse für die Verarbeitung von Dialogschritten, für die Verbuchung, Sperrverwaltung, Hintergrundverarbeitung, für das Spooling von Druckaufträgen u.A. Die Aktivitäten innerhalb eines Workprozesses koordiniert ein „Task Handler“. Z.B. aktiviert im Falle eines Dialog-Workprozesses der Task Handler je nach Bedarf den Dynpro-Prozessor für die Verarbeitung der Bildschirm-Ablaufsteuerung und den ABAP/4Prozessor für die Anwendungslogik. cs 1326 ww6 wgs 04-01 R/3 Dialog-Workprozess Dialogprozesse sind umschichtig für die laufenden BenutzerSessions tätig. Der Dialog Workprozess vearbeitet genau einen Dialogschritt. Der Dialogschritt erarbeitet u.A. ein Antwortbild, welches an das Fenster zurückgesendet wird. Die Logik für die bildliche Ablaufsteuerung (Dialogschrittkontrolle) wird durch das „Dynpro“ (Dynamisches Programm) implementiert. ABAP/4 Programme entalten die betriebswirtschaftliche Logik des R/3 Systems. ABAP/4 und Dynpro Programme arbeiten Interpretativ. Hierzu enthält das R/3 Laufzeitsystem die entsprechenden Prozessoren. Der Systemadministrator richtet für einen Anwendungsserver eine endliche Anzahl von (multiprogrammiert arbeitenden) Dialog Work Prozessen ein, etwa ein Prozess pro 5 - 8 Benutzer. Workprozesse können über SQL direkt auf eine Datenbank zugreifen. Diese kann bei einer 3 oder mehrstufigen Client/Server Installation auf einem anderen Rechner liegen. Aller sonstiger Datenverkehr mit der Außenwelt läuft über den Dispatcher. Der APPC-Server (Teil des Dispatcher) erkennt Kommunikationsaufträge der Workprozesse und leitet sie an ein Software Gateway weiter, welches die Schnittstelle von System R/3 zu den verschiedenen Transportprotokollen wie TCP/IP oder SNA-LU6.2 bildet. Die Definitionen von Datenstrukturen sind in einem zentralen Dictionary enthalten. Es enthält die technische und semantische Gesamtsicht der R/3 Datenwelt. Die R/3 Systemstruktur ist sehr gur für den Einsatz auf einem Mehrprozessorsystem geeignet. cs 1315 ww6 wgs 04-01 Workprozesse Task Handler DynPro Bildschirm Ablauf Steruerung ABAP/4 Prozessor Business Logik Datenbank Schnittstelle RDBMS Datenbank Struktur der SAP R/3 Workprozesse cs 1339 ww6 wgs 04-98 System R/3 Anwendungsserver ABAP/4 Programme entalten die betriebswirtschaftliche Logik des R/3 Systems. Die Logik für die bildliche Ablaufsteuerung verwirklicht u.A. die Dialogschrittkontrolle und wird durch Dynpro (Dynamisches Programm) implementiert. cs 1323 ww6 wgs 04-98 Sperrverwaltung Da die als Bestandteil relationaler Datenbank Systeme verfügbaren Sperrmechanismen für die Transaktionsverwaltung nicht ausreichend sind, verfügt System R/3 über eine zentrale Sperrverwaltung. Die Sperrverwaltung stellt sicher, daß Transaktionen, deren Dialogschritte von unterschiedlichen Workprozessen bearbeitet werden, die von ihnen gestzten Sperren über Prozesswechsel hinweg behalten. Das Verbuchungsprogramm löscht nach erfolgter Verbuchung des vom Dialogteils der Transaktion erzeugten Protokollsatzes automatisch alle gesetzten Sperren. In einer verteilten Systemumgebung muß die Sperre nicht nur für denjenigen Anwendungsserver gelten, der die sperrende Transaktion durchführt, sondern für alle beteiligten Server. Jede R/3 Installation enthält deshalb eine zentrale Sperrverwaltung (Enqueue Service). Der zentrale Sperrverwalter kann auf einem beliebigen Server untergebracht werden. zentrale Sperrverwaltung Anwendungs- und Datenbankserver cs 1310 ww6 wgs 04-98 Workprozesse Gemeinsamer Haupt speicher (Shared Memory Laufzeitkomponenten SAP Puffer für Dynpro Prozessor Task Handler ABAP/4 Prozessor Dynpros ABAP/4 Progr. Tabellen Dictionary Objekte Datenbank Schnittstelle Roll und Paging Datei Privater Hauptspeicher Rollbereich Paging Bereich Rollpuffer Paging Puffer R/3 Speicherverwaltung Jedem einzelnen Prozeß ist ein „Privater Hauptspeicherbeeich“ zugeordnet. Alle Prozesse haben Zugriff auf einen gemeinsamen Hauptspeicherbereich (Shared Memory). Im privaten Hauptspeicher liegen Daten, die den aktuellen Verarbeitungszustand der laufenden Transaktion beschreiben. Rollbereiche werden zu Beginn der Verarbeitung automatisch in den privaten Hauptspeicher des bearbeitenden Prozesses geladen, und enthalten nur kleine Datenmengen, z.B. Benutzerberechtigungen, Eingabedaten aus früheren Dialogschritten oder Verwaltungs-information für den ABAP/4 und den Dynproprozessor. Größere Datenmengen, die bei der Bearbeitung der Transaktion anfallen (z.B. interne Tabellen, Reportlisten), nimmt der seitenweise organisierte Paging Bereich auf. cs 1313 ww6 wgs 04-98 ABAP/4 Prozessor Datenbank R/3 Datenbank SQL Schnittstelle Open SQL Puffer SELECT * FROM EXEC SQL SELECT... END SELECT Native SQL z.B. Oracle, Sybase, DB2 RYO Native SQL Relationale Datenbankzugriffe Native SQL Open SQL optimierte SQL Anweisungen Client Cache (LRU) Die Datenbankschnittstelle benutzt keine eigene Netzwerkkomponente, sondern bedient sich der Möglichkeiten des RDBMS, wobei die herstellerspezifischen Verfahren eingesetzt werden. cs 1318 ww6 wgs 04-98 Präsentation 9 SAPGUI 1 2 Request Queues 8 3 Dispatcher Anwendung 4 7 Work Prozeß Paging Bereich Roll Bereich 5 6 SQL Datenbank Datenfluss beim Dialogschritt cs 1325 ww6 wgs 04-98 Zentrales R/3 System (Zentralinstanz) Verteiltes R/3 System 3 Instanzen cs 1331 ww6 wgs 04-98 Abkürzungen D V E B M G S Dialog Verbuchung Enqueue (Sperrverwaltung) Batch Message Gateway Spool WP Workprozess cs 1309 ww6 wgs 04-98 Message Server Bewirkt Kommunikation innerhalb eines verteilten Systems mit mehreren R/3 Rechnern. Nachrichten, die zwischen den Rechnern ausgetauscht werden sind z.B. Verbuchungsanstoß. Batch Job Anstoß oder Enqueue/Dequeue Anwendungsserver melden sich mit einem eindeutigen Namen beim Message Server an. Jeder Server kennt die Namen aller anderen Server. cs 1327 ww6 wgs 04-98 Gateway Server (CPI-C Server) Der CPI-C Server wird eingesetzt, um eine Kommunikation mit Rechnern zu ermöglichen, auf denen andere Systeme als R/3 laufen (zB. R/2 oder CICS-OS/360). Die eingesetzten Transportprotokolle sind wahlweise TCP/IP SNA-LU 6.2 UPIC (Siemens) Oberhalb der Transport Schicht (Schicht 4) wird CPI-C für die ABAP/4 Programm zu Programm Kommunikation eingesetzt. cs 1328 ww6 wgs 04-98 Kommunikations-Protokolle des Systems SAP R/3 cs 1347 ww6 wgs 04-03 Anwendungen CPI - C APPC, LU 6.2 SNA CPI - C, derzeitiger Status Anwendungen CPI - C SNA NetBIOS TCP/ IP IPX/ SPX CPI - C, in Entwicklung css0413 ww6 wgs 12-96 R/3 System Management System R/3 verfügt über eine eigene System Management Funktion, das Computing Center Management System (CCMS). Es umfaßt die Funktionen: Systemüberwachung Alarmdienste (Alert Monitore) Leistungsüberwachung (Performance Monitore) Performance Datenbank (Performance Historie System Steuerung Offene Management Schnittstellen Die Schnittstellen für die Systemüberwachung, Systemsteuerung und Alarmbehandlung durch externe System Management Tools wie HP Openview, CA Unicenter oder Tivoli TME 10 basieren auf SNMP und RMON. Externe System Management Systeme können Management Daten des SAP Systems aus einer speziellen SNMP MIB, der private Enterprise MIB, im Dialog abfragen oder alternativ auf vom R/3 System ausgelöste SNMP Traps reagieren. Über Dienste Schnittstellen kann CCMS externe Dienstleistungen, z.B. die Einplanung von MVS Jobs oder die Ausführung von Datensicherungsaufträgen starten und überwachen, cs 1319 ww6 wgs 04-98 SAP R/3 Anwendungen Finanzwesen Controlling Anlagenwirtschaft Materialwirtschaft Produktionsplanung und -steuerung Vertriebslogistik Qualitätsmanagement Instandhaltung Projektmanagement Servicemanagement Personalwirtschaft Bürokommunikation Workflow-Funktionen Branchenlösungen Information Warehouse cs 1336 ww6 wgs 04-98 Industry Strength Verfügbarkeit Funktionalität der Anwendungen Daten Integrität Vertraulichkeit Authentifikation Skalierbarkeit cs 1320 ww6 wgs 04-98 IBM WebSphere IBM Web Server oder Apache Servlet Engine EJB Container MQSeries CICS CICS Transact. Gateway Kernel Web Application Server als Tranaktionsmonitor Front End SAP Web Applic. Server Internet Communication Manager Web Dynpro Business Layer SAP Exchange SAP R/3 SAP Java Connector Kernel cs 1341 ww6 wgs 03-03 Message Based Queuing (MBQ) Message Oriented Middleware (MOM) Message Queuing ist eine Methode der Programm-zu-ProgrammKommunikation. Programme sind in der Lage, Informationen zu senden und zu empfangen, ohne dass eine direkte Verbindung zwischen ihnen besteht. Die Programme kommunizieren miteinander durch Ablegen von Nachrichten in Message-Queues und durch Herunternehmen der Nachrichten von den MessageQueues. - Zeit-unabhängige (asynchrone) Kommunikation - Verbindungslose Kommunikation Messaging bedeutet, dass Programme durch Senden von Daten in Nachrichten (Messages) kommunizieren und nicht durch wechselseitiges, direktes Aufrufen. Queuing heißt, dass Programme über Queues miteinander kommunizieren. Dadurch ist es nicht notwendig, dass diese Programme zeitlich parallel ausgeführt werden. Eine Queue bezeichnet eine Datenstruktur, die Nachrichten speichert. Auf einer Queue können Anwendungen oder ein QueueManager Nachrichten ablegen. Queues existieren unabhängig von den Anwendungen, die Queues benutzen. Als Speichermedien für eine Queue kommen Hauptspeicher (wenn sie temporär ist), Platte bzw. ähnliche Zusatzspeicher oder beides in Frage. Beim asynchronen Messaging führt das sendende Programm seine eigene Verarbeitung weiter aus, ohne auf eine Antwort seiner Message zu warten. Im Gegensatz dazu wartet beim synchronen Messaging der sendende Prozeß auf eine Antwort, bevor er seine Verarbeitung fortsetzt. Bei einer Anwendung ist es nicht erforderlich, dass sich der Programmierer um das Ziel-Programm kümmert. Es ist belanglos, ob der Server momentan nicht im Betrieb ist oder keine Verbindung zu ihm besteht. cs 0 2853 ww6 wgs 04-02 Eine Message besteht aus zwei Teilen: - Daten, die vom einem Programm zu einem anderen gesendet werden - Message-Deskriptor oder Message-Header Der Message-Deskriptor identifiziert die Message (Message-ID) und enthält Steuerinformationen (Attribute), wie z.B. Message-Type, Zeit-Ablauf, Korrelations-ID, Priorität und Namen der AntwortQueue. Der Queue-Manager überträgt Nachrichten zu einem anderen Queue-Manager über Channels, wobei bestehende NetzwerkFacilities wie TCP/IP, SNA oder SPX verwendet werden. Um die Operationen des Queue-Managers zu verfolgen, können die MQSeries-Instrumentations-Events benutzt werden. Diese Events generieren spezielle Nachrichten (Event Messages) Beim Eintreffen auf einer Queue können die Nachrichten (Messages) automatisch eine Anwendung starten. Dabei wird ein Mechanismus benutzt, der als Triggering bezeichnet wird. Die Anwendungen können wenn notwendig auch in Abhängigkeit von dem Verarbeitungszustand der Nachrichten gestoppt werden. cs 2850 ww6 wgs 04-02 1 2 4 Nachricht 3 Klient Server MBQ - Message Based Queuing, Message Oriented Middleware (MOM Alternative zum RPC, Ersatz für Batch file transfers Eigenschaften • Nachrichten werden bis zur endgültigen Auslieferung an die Zielanwendung in Warteschlangen zwischengespeichert • Asynchron (im Gegensatz zum RPC), Store-and-Foreward Prinzip • Recovery Mechanismen beim Versagen von Knoten oder Verbindungen • Auslieferung wird garantiert • Message Tracking (lokale Platte, entfernte Platte, Annahme der Nachricht durch Anwendung) cs 0835 ww6 wgs 02-99 Message Based Queuing Führende Hersteller: • • • • • BEA (früher DEC) Candle IBM Microsoft Momentum Software MessageQ Roma MQSeries MS Message Queue Server (MSMQ) XIPC Middleware verwendet häufig einen von zwei alternativen Mechanismen für die Kommunikation mit der Transportschicht: RPC oder Message Based Queuing (MBQ, auch als Message based Middleware, MOM, bezeichnet). Beide Alternativen lösen komplexe, System-spezifische Kommunikations- und Konfigurationsaufgaben. Sie machen die Lokation der angeforderten Dienstleistung transparent für den anfordernden Klienten. Sie lösen jedoch diese Aufgabe auf eine sehr unterschieliche Art. Der Einsatz von RPC´s ist vor allem bei der Entwicklung von neuen Anwendungen vorteilhaft, wenn keine oder nur wenige Legacy oder nicht-RPC Anwendungen integriert werden müssen. Message Based Queuing ist besser geeignet, wenn es um die Integration unterschiedlicher, heterogener Anwendungen geht. Middleware verbirgt die Komplexität beim Einsatz von RPC oder MBQ vor dem Anwendungsprogrammierer. Queuing ermöglicht Anwendung zu Anwendung Kommunikation wenn • Netzwerke unzuverlässig • empfangende Anwendung ist nicht immer für synchrone Anforderungen verfügbar SNMP und X.500 electronic Mail sind einfache Message orientierte Anwendungen Literatur: B. Blakeley: „Messaging & Queuing using the MQI“. MvGrawHill, 1995. cs 0816 ww wgs 01-99 Anwendung A PUT Message Anwendung B GET Message MQI MQI API API Disk Queue Disk Queue Queue Manager Queue Manager Message Bus Message based Queuing (MBQ) Message oriented Middleware (MOM) MQI cs 0841 ww6 Message Queue Interface wgs 06-97 Message Based Queuing Message oriented Middleware Header Binary Data Message besteht aus zwei Teilen: - Daten, die vom einem Programm zu einem anderen gesendet werden - Message-Deskriptor oder Message-Header Der Message-Deskriptor identifiziert die Message (Message-ID) und enthält Steuerinformationen (Attribute), wie z.B. Message-Type, Zeit-Ablauf, Korrelations-ID, Priorität und Namen der AntwortQueue. Übertragung von Datenbank Reports, Transaktionen, Audio, Video. 1 Solaris 2 3 Queue Queue A B 4 S/390 DB2 Schritte 1 - 3 : Wenn erfolgreich, Antwort senden Step 4: Wenn S/390 nach DB2 versagt: roll back nach Queue B, dann recover IBM MQSeries ist Marktführer. Für praktisch alle Betriebssysteme verfügbar: AIX, DG/UX, HP-UX, Windows, OS/390, OS/400, Psion Pervasive SOD, Sequent, Sinix, Solaris, Tandem, TPF, TrueUnix, VMS/VAX. cs 2854 ww6 wgs 04-02 *AnwendunsQueue InitiierungsQueue 5 1 6 Anwendung 2 (Trigger) 4 Trigger Monitor Anwendung 3 Queue Manager Trigger Nachrichten Als Triggering wird der Mechanismus bezeichnet, mit Hilfe dessen eine Anwendung bei Bedarf gestartet werden kann. Der Queue Manager erkennt die Ankunft neuer Nachrichten (für die Triggering enabled ist). Er benachrichtigt eine spezielle Anwendung, den Trigger Monitor. Der Trigger Monitor startet die Anwendung, die für die Nachricht zuständig ist. Da mehrere Nachrichten gleichzeitig eintreffen können, werden die Trigger in einer separaten Queue, der Initiierungsqueue, zwischengespeichert. Die Trigger Nachricht enthält die „Prozess Definition“ Information, mit deren Hilfe der Trigger Monitor die gewünschte Anwendung starten kann. cs 0840 ww wgs 01-99 IBM MQSeries Vier Message-Typen: Datagram: Eine Message enthält Informationen, auf die keine Antwort erwartet wird. Request: Eine Message, für die eine Antwort angefordert wird. Reply: Eine Antwort auf eine Request-Message Report: Eine Message, die einen Event beschreibt (z.B. Fehlermeldung oder Bestätigung beim Eintreffen der Nachricht) • Message-Queue-Manager (MQSeries-Run-Time Programm) verwaltet die Queues und Messages zu verwalten. • Stellt das Message-Queuing-Interface für die Kommunikation mit den Anwendungen zur Verfügung. Die Applikations-Programme rufen Funktionen des Queue-Managers durch Ausgabe von APICall´s auf. • MQPUT-API-Call z.B. legt eine Message auf eine Queue, die von einem anderen Programm mit Hilfe eines MQGET-API-Call´s gelesen werden soll. cs 0852 ww6 wgs 04-02 MQSeries Betrieb Request Queue Anwendung A Anwendung B Response Queue Nachrichtenkopf enthält: „Reply to ....“ Asynchroner Betrieb: Request/reply Modus kann synchronen Betrieb simulieren. Wird häufig so benutzt. MQ-CICS Bridge: Receiving queue lädt Nachricht in die CICS Input Queue. CICS behandelt es wie eine 3270 Nachricht, gibt eine 3270 Nachricht zurück. Response Queue B übersetzt Nachricht in das MQSeries Format. Keine Daten Konvertierung, nur binäre Daten werden übertragen. Firmen wenden 40 % ihres eigenen Budgets für Software Entwicklung für Integrationsaufgaben. Wird Software gekauft, kostet die Integration das 9fache des Kaufpreises. es 0807 ww6 wgs 07-00 MQSeries API MQI MQCONN stellt eine Verbindung mit einem Queue-Manager mit Hilfe von Standard-Links her. MQBEGIN startet eine Arbeitseinheit, die durch den Queue-Manager koordiniert wird und externe XA-kompatible Ressource-Manager enthalten kann. Dieses API ist mit MQSeries Version 5 eingeführt worden. Es wird für die Koordinierung der Transaktionen , die Queues (MQPUT und MQGET unter Syncpoint-Bedingung) und Datenbank-Updates (SQL-Kommandos) verwenden. MQGET MQPUT MQPUT1 öffnet eine Queue, legt eine Message darauf ab und schließt die Queue wieder. Dieser API-Call stellt eine Kombination von MQOPEN, MQPUT und MQCLOSE dar. MQINQ fordert Informationen über den Queue-Manager oder über eines seiner Objekte an, wie z.B. die Anzahl der Nachrichten in einer Queue. MQSET verändert einige Attribute eines Objekts. MQCMIT gibt an, dass ein Syncpoint erreicht worden ist. MQBACK teilt dem Queue-Manager alle zurück gekommenen PUT´s- und GET´s-Nachrichten seit dem letzten Syncpoint mit. MQDISC schließt die Übergabe einer Arbeitseinheit ein. Das Beenden eines Programms ohne Unterbrechung der Verbindung zum Queue-Manager verursacht ein "Rollback" (MQBACK). cs 2851 ww6 wgs 04-02 IBM MQSeries Jede Nachricht verfügt über einen eindeutigen 24 Byte Indentifier Die MQI API wird über 10 Kommandos realisiert („Verben“ im IBM-Sprachgebrauch) MQCONN, MQDISC Verbindung zu Queue Manager herstellen und löschen. Anwendungen „melden sich an“. MQOPEN, MQCLOSE Verbindung zu einer spezifischen Queue aufbauen und lösen. MQGET, MQPUT MQCMT, MQBACK für Transaktionverarbeitung MQINQ Status einer Queue abfragen MQSET spezifische Queue Parameter setzen css1151 ww6 wgs 06-97 MQ Series Code Fragment Cs 0899 wgs 04-02*
