Neues aus HORIZON Lessons Learned Karlheinz Hartkorn, Anwendungsentwicklung/Technische Architektur | JBFOne 2009

Ziel dieses Vortrags Anhand einiger Beispiele soll gezeigt werden, wie sich die HORIZON-Architektur weiterentwickelt Meistens wurden durch „Lessons Learned“ die Konzepte schlanker und damit einfacher gemacht Um die Hintergründe der Weiterentwicklung deutlich zu machen, wird im Vortrag immer das ursprüngliche Konzept mit den gemachten Erfahrungen und anschließend das weiterentwickelte Konzept dargestellt

Agenda Kopplung der Queueing-Systeme Datenaustausch zwischen agree Basis und HORIZON Verwendung der LOB-Tabelle Gruppenverarbeitung Fazit

Agenda Kopplung der Queueing-Systeme Datenaustausch zwischen agree Basis und HORIZON Verwendung der LOB-Tabelle Gruppenverarbeitung Fazit

Kopplung der Queueing-Systeme (ursprüngliche Version) Topologie der Queues und Fluss der Messages HORIZON  agree Basis die HORIZON-Anwendung stellt ihre Messages in Teildatenbank-bezogene Queues (entsprechend der Zielarchitektur in agree Basis) je Fachlichkeit 35 Queues in AQ und MQ (z. B.10 Fachlichkeiten = 700 Queues) gelernt Inflation der Queues enormer Administrationsaufwand dadurch fehleranfällig

Kopplung der Queueing-Systeme (ursprüngliche Version) Mainframe agree 1 PS PPS CPS 1 2 4 5 J MQ01 Remote Queue agree 2 XCPH 7 8 9 A D MQ02 agree 3 MQGW L Q S T Z BAP-Portale AQ MQ03 agree 7 E H I K N Oracle MQ07 HORIZON  agree Basis

Kopplung der Queueing-Systeme (weiterentwickelte Version) Topologie der Queues und Fluss der Messages HORIZON  agree Basis die HORIZON-Anwendung stellt ihre Messages in Subsystem-bezogene Queues ein MQ-Exit in den integrierten Systemen führt die Teildatenbank-bezogene Zuordnung durch Überlegung Transport der Message ohne MQ-GW in der Oracle-DB !

Kopplung der Queueing-Systeme (weiterentwickelte Version) Mainframe agree 1 PS PPS CPS 1 2 4 5 J MQ01 Remote Queue Exit agree 2 XCPH 7 8 9 A D MQ02 Exit agree 3 MQGW L Q S T Z BAP-Portale AQ MQ03 Exit agree 7 E H I K N Oracle MQ07 Exit HORIZON  agree Basis

Kopplung der Queueing-Systeme (ursprüngliche Version) Topologie der Queues und Fluss der Messages agree Basis  HORIZON die Anwendung in agree Basis schreibt die Message in eine Queue je Fachlichkeit der Dispatcher auf dem CPS verteilt die Message auf die portalbezogenen Queues gelernt lange Laufzeit durch viele Hubs Polling auf der AQ durch JMS (Systembelastung)

Kopplung der Queueing-Systeme (ursprüngliche Version) Mainframe Remote Queues agree 1 PS PPS CPS 1 2 4 5 J MQ01 Message Dispatcher agree 2 XCPH 7 8 9 A D MQ02 agree 3 L Q S T Z MQGW BAP-Portale MQ03 AQ agree 7 E H I K N Oracle MQ07 HORIZON  agree Basis

Kopplung der Queueing-Systeme (weiterentwickelte Version) Topologie der Queues und Fluss der Messages agree Basis  HORIZON die Anwendung in agree Basis schreibt die Message in eine allgemeine Queue je Subsystem ein COBOL-Programm (KOEX-Gateway) liest die Queue aus und verteilt die Messages auf die portalbezogenen fachlichen Queues Erfahrung bessere Performance weniger Systembelastung geringere Anzahl Queues

Kopplung der Queueing-Systeme (weiterentwickelte Version) Mainframe agree 1 KOEX- Gateway PS PPS CPS 1 2 4 5 J MQ01 agree 2 KOEX- Gateway XCPH 7 8 9 A D MQ02 agree 3 KOEX- Gateway L Q S T Z BAP-Portale AQ MQ03 agree 7 KOEX- Gateway E H I K N Oracle MQ07 HORIZON  agree Basis

Agenda Kopplung der Queueing-Systeme Datenaustausch zwischen agree Basis und HORIZON Verwendung der LOB-Tabelle Gruppenverarbeitung Fazit

Datenaustausch zwischen agree Basis und HORIZON (ursprüngliche Version) File-Austausch über die LOB-Tabelle File-Dispatcher auf dem CPS die LOB-Tabelle dient in der dezentralen Welt als File-System sie wird sowohl von HORIZON-Anwendungen als auch von agree Basis-Anwendungen gelesen und geschrieben die mandantenübergreifenden Files (meist Teildatenbank-bezogen) werden vom File-Dispatcher auf dem CPS in mandantenreine Files (je CustomerID) aufgeteilt und dann auf den PPSen weiterverarbeitet Erfahrung viele I/Os unnötiger Netztraffic

Datenaustausch zwischen agree Basis und HORIZON Mainframe agree 1 PS PPS CPS 1 2 4 5 J MQ01 FU306A File Dispatcher agree 2 7 8 9 A D MQ02 agree 3 LOB-Tabelle L Q S T Z BAP-Portale MQ03 Mandanten- reine Files agree 7 E H I K N Oracle MQ07

Datenaustausch zwischen agree Basis und HORIZON (weiterentwickelte Version) File-Austausch über die LOB-Tabelle File-Dispatcher in agree Basis die mandantenübergreifenden Files werden vom FU306A bereits in mandantenreine Files (je CustomerID) aufgeteilt und in die LOB-Tabelle geschrieben

Datenaustausch zwischen agree Basis und HORIZON Mainframe agree 1 PS PPS CPS 1 2 4 5 J MQ01 FU306A File Dispatcher agree 2 7 8 9 A D MQ02 agree 3 LOB-Tabelle L Q S T Z BAP-Portale MQ03 Mandanten- reine Files agree 7 E H I K N Oracle MQ07

Agenda Kopplung der Queueing-Systeme Datenaustausch zwischen agree Basis und HORIZON Verwendung der LOB-Tabelle Gruppenverarbeitung Fazit

Verwendung der LOB-Tabelle LOB-Verarbeitung zuerst geplant HORIZON hat kein File-System; alle Flat-Files werden als LOB in der LOB-Tabelle gespeichert um die LOB-Tabelle eventuell durch ein File-System ersetzen zu können, darf nur nontransaktional gelesen und geschrieben werden gelernt die LOB-Tabelle funktioniert hervorragend Anwendungen schreiben aber transaktional und nutzen den LOB als restartfähige File-Ausgabe sowohl transaktionale als auch nontransaktionale Verwendung muss möglich sein File-API in weiterentwickelter Form es wird ein erweitertes File-API bereit gestellt, das transaktionales und nontransaktionales Schreiben unterstützt die transaktionale Variante dient ausschließlich der Ausgabe von sequentiellen Ergebnissen unter Verwendung des Standard Restartverfahrens die transaktionale Variante wird auch im DB2 etabliert werden weiteres Einsatzgebiet die LOB-Tabelle im Oracle wird auch für den agree File-Transfer verwendet werden zum Datenaustausch zwischen agree Basis und den JBF-Servern und zum Datenaustausch zwischen BI-Servern und JBF-Servern

Agenda Kopplung der Queueing-Systeme Datenaustausch zwischen agree Basis und HORIZON Verwendung der LOB-Tabelle Gruppenverarbeitung Fazit

Gruppenverarbeitung in HORIZON zuerst geplant bankbezogene Verarbeitung Erfahrung Inflation an JJs – 800 je JJ Scheduler beschäftigt sich mit sich selber (Locking-Thema in der Cronacle-DB) Batchverarbeitung in weiterentwickelter Form Einführung der Gruppenverarbeitung auf Basis TDB (BatchBasis) submit aller TDB auf allen Portalen jeder JJ arbeitet nur die Banken ab, die folgende Bedingungen erfüllen: ist die Bank auf dem Portal? ist die Bank in der TDB? bedeutet: Anzahl TDB X Anz. Portale = Anzahl JJs 35 x ~20 = 700 JJs Ausblick JJ je SW-Stack Version neue Rechnung: 35 x (3 Versionen + 2 Piloten) = 175 JJs

Gruppenverarbeitung in HORIZON Mainframe Cronacle agree 1 TWS (OPC) FU314A TDB 1 PS PPS 1 2 4 5 J TDB 1 MQ01 agree 2 7 8 9 A D MQ02 agree 3 L Q S T Z Chains TDB1 BAP-Portale MQ03 agree 7 E H I K N MQ07

Gruppenverarbeitung in der gesamten JBF-Welt klassische Anwendungen steigen mit ihrer Batchverarbeitung auf BatchBasis um die Cronlet-Verarbeitung kann damit abgelöst werden Erfahrung die Datenorganisation lässt nicht immer in voller Breite die parallele Verarbeitung zu die Ablösung des Cronletservers wird angestrebt

Agenda Kopplung der Queueing-Systeme Datenaustausch zwischen agree Basis und HORIZON Verwendung der LOB-Tabelle Gruppenverarbeitung Fazit

Fazit HORIZON-Konzepte finden auch in der klassischen Entwicklung und in Produktion Verwendung die klassische Welt und die HORIZON-Welt verschmelzen miteinander die vorgestellten Konzepte helfen beiden Welten, die Produktion im dezentralen Umfeld kontrollierbar und beherrschbar zu machen

Fragen? – Diskussion? Karlheinz Hartkorn Anwendungsentwicklung Technische Architektur karlheinz.hartkorn@fiducia.de 07 21 / 40 04 – 14 59, mobil: 01 70 / 910 30 26

Ihr IT-Partner Vielen Dank