Client/Server-Systeme

Transkript

1 Client/Server-Systeme Prof. Dr.-Ing. Wilhelm Spruth SS 2004 Teil 12 SAP System R/3 cs 0800 ww6 sch 02-97

2 SAP System R/3 Literatur R. Buck-Emden: Die Client/Server Technologie des SAP System R/3. Addison-Wesley L. Will: Administration des SAP System R/3. Addison-Wesley 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

3 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

4 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 Erste Anwendung wird 1989 auf der Cebit gezeigt. Im Gegensatz zu System R/2 benutzt System R/3 seinen eigenen Transaktionsmonitor erste Kundeninstallation graphische Oberfläche SAPGUI verfügbar 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 Portierung auf OS/390 Unix System Services. "There are no plans for R/4 today" 7,500+ SAP Kunden in 90+ Länderncountries R/3 Installationen ( CICS) 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

5 R/3 Middleware R/3 Anwendungen ADAP/4 Entwicklungs- Umgebung Anwendungsdienste Kommuni- Präsenta- System Sicher- Daten kations tions Manage- heit bank Dienste Dienste ment 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

6 FF..FF ABAP/4 Anwendungen ABAP/4 Entwicklungs- Umgebung Sicherheit Terminal Task Program Storage File Control Control Control Control Control System Management Präsen- Dis- Anwen- Speicher Datentations- patcher dungs- Ver- bank Dienste dienste waltung Dienste Betriebssystem Kernel OS/400, OS/390 USS, LInux, AIX, Sinix, HP/UX, Solaris, Windows 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

7 R/3 Präsentationsrechner SAP GUI Prozesse LAN, WAN SAP z.b. Oracle, DB/2 Anwendungs- Datenbankserver server modifiziertes 3270 Protokoll Dreistufige SAP R/3 Konfiguration Saubere Trennung zwischen den Funktionen Präsentation Anwendung Datenbank cs 1338 ww6 wgs 04-98

8 Anwendungs- Datenbank Rechner Rechner Anwen- dungs- Rechner Anwendungs- Datenbank Rechner Rechner Präsentation Beispiel der dreistufigen R/3 Client/Server Architektur cs 1322 ww6 wgs 04-98

9 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

10 SAPGUI Mehrfache Fenster und eingebettete Bilder cs 1346 ww6 wgs 04-03

11 Daten- Datenbank bank Anwendungs- Anwendungsdienste dienste Internet enabling Layer WEB Server Präsentations- WEB Dienste Browser (SAPGUI) GUI Implementierung mit Hilfe eines WEB Browsers cs 0920 ww wgs 02-97

12 HTTP Internet Transaction SAP R/3 Server 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 Screens, Dialogboxen und Reports. cs 1344 ww6 wgs 04-03

13 IBM WebSphere IBM Web Server oder Apache Servlet Engine EJB Container CICS MQSeries CICS Transact. Gateway Kernel SAP Web Applic. Server Internet Communication Manager Web Dynpro Web Application Server als Tranaktionsmonitor Front End Business Layer SAP R/3 SAP SAP Java Exchange Connector Kernel cs 1341 ww6 wgs 03-03

14 SAPGUI cs 1235 ww6 wgs 03-03

15 Logical Unit of Work (LUW) im System R/3 LUW 1 Sperr- Sperre Sperre verwaltung anfordern freigeben Verbuchung Dialog Schritte LUW 2 Dialog Transaktion 1 Transaktion 2 Beginn der Commit Commit Transaktion Work Work SAP Transaktion Dialogschritt SAP LUW Folge betriebswirtschaftlich konsistenter, logisch zusammenhängender Dialogschritte eigenes Bildschirmbild Gesamtheit der Dialogschritte einer Transaktion, einschließlich Verbuchung call transaction commit transaction cs 0947 ww6 wgs 03-03

16 Sperr Sperre Sperre verwaltung anfordern freigeben Verbuchung Dialog Transaktion 1 Transaktion 2 Beginn der Commit Commit Transaktion Work 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

17 Datenbank LUW s V1 V2 Protokollsatz erstellen Dialog schritte R/3 LUW Sperre Sperre anfordern 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

18 V1-Komponente V2-Komponente V2-Komponente V2-Komponente Betriebswirtchaftlich zeitkritische Vorgänge, z.b. Bestellungen 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

19 Datenbank LUW s V1 V2 Protokollsatz erstellen Dialog schritte R/3 LUW Sperre Sperre anfordern 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 vom Abbruch der Verbuchung unterrichtet. cs 1314 ww6 wgs 04-98

20 andere Work Dialog Work Prozesse Prozesse Task Task Task Handler Handler Handler ABAP/4 ABAP/4 ABAP/4 Prozessor Prozessor Prozessor Dynpro Dynpro Dynpro Prozessor Prozessor Prozessor Dispatcher Datenbank Dienste APPC Server 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/4- Prozessor für die Anwendungslogik. cs 1326 ww6 wgs 04-01

21 R/3 Dialog-Workprozess Dialogprozesse sind umschichtig für die laufenden Benutzer- Sessions 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

22 Workprozesse Task Handler DynPro ABAP/4 Datenbank Prozessor Schnittstelle Bildschirm Business Ablauf Logik RDBMS Steruerung Datenbank Struktur der SAP R/3 Workprozesse cs 1339 ww6 wgs 04-98

23 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

24 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

25 getrennte Rechner, häufig SMP Unix, Linux, z/os Unix System Services Sperrverwaltung Anwendungs- Datenbank Server Server Anwen- dungs- Server Anwendungs- Datenbank Server Server TCP/IP LAN SAP Protokoll (SNA) Präsentation System R/3 Sperrverwaltungs-Server Sperrverwaltungs-Server (Lock Server) ist ein normaler Unix oder Linux Rechner, über normales Netzwerkprotokoll angeschlossen. z/os CICS, IMS und DB/2 Stored Procedures verwenden stattdessen Coupling Facility, mit speziell für die Transaktionsverwaltung optimierter Hard- und Software. Höhere Skalierung. cs 1322 ww6 wgs 04-98

26 ABAP/4 Prozessor R/3 Datenbank SQL Datenbank Schnittstelle Open Puffer Native z.b. Oracle, SQL SQL Sybase, DB2 SELECT * FROM RYO EXEC SQL Native SQL SELECT... END SELECT 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

27 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 Industry Strength Verfügbarkeit Funktionalität der Anwendungen Daten Integrität Vertraulichkeit Authentifikation Skalierbarkeit cs 1320 ww6 wgs 04-98

28 Message oriented Middleware (MOM) Message based Queuing (MBQ) MQSeries Implementierungsbeispiel

29 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

30 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, cs 0816 ww wgs 01-99

31 Message Based Queuing (MBQ) Message Oriented Middleware (MOM) Message Queuing ist eine Methode der Programm-zu-Programm- Kommunikation. 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 Message- Queues. - 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 Queue- Manager 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 ww6 wgs 04-02

32 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 Antwort- Queue. Der Queue-Manager überträgt Nachrichten zu einem anderen Queue-Manager über Channels, wobei bestehende Netzwerk- Facilities 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

33 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 Antwort- Queue. Übertragung von Datenbank Reports, Transaktionen, Audio, Video Solaris Queue Queue S/390 DB2 A B 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

34 *Anwenduns- Initiierungs- Queue Queue 1 5 Trigger 6 Anwendung 4 Monitor Anwendung 2 (Trigger) 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

35 MQSeries Betrieb Request Queue Anwendung Anwendung A 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

36 Anwendung A PUT Message Anwendung B GET Message MQI API MQI API Disk Disk Queue Queue Queue Queue Manager Manager Message Bus Message based Queuing (MBQ) Message oriented Middleware (MOM) MQI Message Queue Interface cs 0841 ww6 wgs 06-97

37 Anwendungsprogramm Anwendungsprogramm mit mit MQSeries API Calls MQSeries API Calls z.b MQPut z.b MQGet MQI MQI Sender Receiver Queue1 MQ Channel Queue2 Queue Manager 1 Queue Manager 2 MQSeries Rechner 1 MQSeries Rechner 2 MQSeries Arbeitsweise Das Anwendungsprogramm auf Rechner 1 stellt mit Hilfe eines Message Queue Interface (MQI) API Aufrufs (z.b. MQPut) eine Nachricht in Queue 1. Die als Queue Manager (QM) bezeichnete MQSeries Laufzeitumgebung (Runtime) bewirkt unter ACID Bedingungen den Transport der Nachricht nach Queue 2 auf Rechner 2. Der Transport erfolgt über einen MQ-Channel. Hierfür unterhält Queue Manager 1 einen Channel Sender und Queue Manager 2 einen Channel Receiver. Queues, Queue Manager, Channel Sender/Receiver und Channels repräsentieren Schicht 5 Middleware. Der Channel kann z.b. mit Hilfe von Sockets in Schicht 4 TCP/IP verwenden. Das Anwendungsprogrogramm auf Rechner 2 kann nun asynchron mit Hilfe eines MQI Aufrufs MQGet die Nachricht aus Queue 2 auslesen. Evtl. unterhält Queue Manager 2 eine Trigger Funktion, welche die Anwendung beim Eintreffen einer Nachricht informiert. cs 0927 ww 6 wgs 04-04

38 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

39 Windows 2000 JAVA Application Java MQGet MQPut MQI 14 Reply-To Queue Response Message Response Data 1 Server Connection Channel Request Data Remote Queue Definition 2 Transmission Queue 3 Request Message MQSeries v b Receiver Queue Manager TBUSSE.NACT Sender 4a Response Channel Request Channel 13a Sender Queue Manager MQA1 Receiver 4b Transmission Queue Remote Queue Definition Response message MQPut response Response data Request data 8 MQGet MQI request MQI Request Message Request Queue MQSeries CICS Bridge Queue 5 MQGet Browse request MQSeries v2.1 CICS COBOL Program EXEC 9 CICS LINK EXEC CICS RETURN 10 CICS DPL bridge task 7 EXEC CICS START 6 MQSeries CICS bridge monitor task CICS Region CICS TS v1.3 OS/390 MQSeries Zugriff auf CICS Java Präsentationslogik greift mit Hilfe von MQSeries auf CICS COMMAREA zu cs 0928 ww6 wgs 04-04

40 MQ Series Code Fragment Cs 0899 wgs 04-02*