Im Rahmen der Umstellungen des Systems für das Adressenrisiko an die neue Vorschriften BCBS 239 ist das bisherige System zu überarbeiten.

Im Rahmen der Umstellung wird die Technik vom Mainframe, also COBOL, JCL, DB2 z/OS auf Linux Systeme mit OSPE-Batch (Spring-Batch) und der Datenbank DB2 BLU Acceleration, also einer In-Memory Datenbank, umgestellt.

Im Vorfeld habe ich das Konzept für die technische Umsetzung erstellt und beispielhaft in einem POC umgesetzt und geprüft.

Im Bereich Spring-Batch habe ich Steps, Tasklets, Chunks auf Basis der Standard-Komponenten erstellt und für spezielle Aufgaben eigene Komponenten erstellt.

Als Beispiele:

Da sehr spezielle Formate für den CSV Export benötigt werden, habe ich einen parametrierbaren RowMapper erstellt, da nur an dieser Stelle die Metadaten der Datenbank zur Verfügung stehen.

Beim JdbcCursorItemReader ist die Verarbeitung von Host-Variablen nicht vorgesehen, eine Text-Ersetzung im SQL Property ist unsicher und kann das Optimieren von SQL Abfragen verhindern. Die Platzhalter ("?") und das manuelle Bereitstellen eines Arrays mit den Variablen in der richtigen Reihenfolge ist bei den geplanten mehrstufigen Common Table Expressions schwer handhabbar. Deshalb habe ich von der Klasse eine eigene Komponente abgeleitet, die wie der JdbcBatchItemWriter Host-Variablen verarbeiten kann.

Der In-Memory Bereich von DB2, also die Column Based Tabellen, ist mit kleinen Ausnahmen (z.B. keine Indizies) syntax-kompatible zu den klassischen Row Based Tabellen, ihre Stärken spielt sie aber erst aus, wenn das Vorgehen beim Datenbank Design und der Abfolge der Statements auf die neue Technik abgestimmt ist.

Hier erarbeitete ich einige Konzept, z.B. SHADOW Tabellen, andere Kombinationen von ROW und COLUMN Based Tabellen, Optimierung des INSERT (HUFFMAN Kompression).

Für die MiFID II Anforderungen liefert WM Daten neue Attribute, insbesondere für PRIIP und KID. Diese Attribute werden untertägig als XML Dateien per SFTP zur Verfügung gestellt.

Die Größe der Daten pro WKN ist übersichtlich, jedoch ist es denkbar, dass eine Datei den Gesamtbestand enthält. Eine XML Datei mit mehreren hundert Megabytes komplett in den Hauptspeicher einzulesen, um das "normale" XML Unmarchalling durchzuführen, kann zu Problemen führen. Aus diesem Grund konzipierte ich ein Design, dass die Datei mittels StAX für jede WKN aufteilt, nur jeweils diesen Bereich mit JAXB in die Java Objekt einliest und per Hibernate in die Oracle Datenbank schreibt.

Das Programm wird auch durch das Batch Framework gesteuert.

Die Umsetzung des Programms erfolgte Off-Shore.

Die Programme zur Datenversorgung des Abteilungs-Daten-Layer laufen auf verschiedenen Linux Server in einer Tomcat Umgebung. Die Server sind gemanagt, es besteht keine Möglichkeit ausser den WAR Files eigene Software zu installieren. Sie verfügen auch über keinen eigenen Speicherplatz oder Verzeichnisse. In der Regel nutzen sie Datenbanken und dienen als WebServer für Benutzerinteraktionen oder stellend WebServices zur Verfügung.

Um auf in einem Verzeichnis (Inbound) eintreffende Datei reagieren zu können, konzipierte ich eine Batch Steuerung, einschliesslich der notwendigen Anwendung für Administratoren und einem Housekeeping.

Da die Inbound Verzeichnisse können auf verschiedenen File-Servern mit unterschiedlichen File-Systemen liegen können, verwendet das Framework eine Abstraktionsschicht.

Die Umsetzung des Programms erfolgte Off-Shore.

Die Wertpapier-Stammdaten werden durch eine zentrale Mainframe Anwendung von WM Daten empfangen, aufbereitet und den verschiedenen Abnehmern bereitgestellt.

Die aufbereiteten Wertpapierdaten sind auch in den Abteilungs-Daten-Layer zu übernehmen.

Die seit mehreren Jahrzehnten laufende Anwendung stellt, wie bei COBOL Anwendungen üblich, Flat-Files mit verschiedenen Satzarten bereit. Einzelne Datensätze können auch per IBM MQ-Series übertragen werden.

Ich konzipierte ein für englischsprachige Java Entwickler verständliches Design zum Einlesen der Daten. Dazu entwickelte ich eine XML Anwendung zur Beschreibung der Host Datenstruktur zum Einlesen in die entsprechenden Java Objekte. Diese werden dann per Hibernate in die Oracle Datenbank geschrieben.

Die Umsetzung des Programms erfolgte Off-Shore.

Für MiFID II sind für die Beratung der Kunden erweiterte gesetzliche Regeln zu beachten. Hierfür sind weitere Informationen über den Kunden sowie die angebotenen Wertpapiere bereitzustellen.

Die Daten sollen in den Abteilungs-Daten-Layer, der für die SAP Anbindung konzipiert wurde, vorgehalten werden. Da mittlerweile viele der damaligen Entwickler die Abteilung verlassen hatte, war meine erste Aufgabe die Zusammenarbeit mit den neu hinzu gekommenen Kollegen.

Die meisten der anlieferten Systeme liefern Notifications und sind per Web Service erreichbar. Somit entspricht die Technik der in 2014 entwickelten Lösung.

Die Programme für die Kursversorgung wurden Anfang 1990ziger Jahre noch in COBOL ANSI-74 erstellt und seit dem bei Bedarf von verschiedenen Entwicklern schnell erweitert.

Die Auswahl des gewünschten Börsenplatzes und damit des Kurses erfolgt über ein komplexes Regelwert. Hierbei werden die Wertpapier-Stammdaten (WM Daten), verschiedene DB2 Tabellen mit Regeln und weiteren Informationen ausgewertet.

Die Programme waren für geplante fachliche Anpassungen und Erweiterungen zu restruktuieren und hierbei zu dokumentieren.

Die Analyse und Umstellung der Programme geschah noch in 2015, da die Kursversorgung bei der Berechnung der Portfolios entscheidend ist, fand über einen Zeitraum von mehreren Monaten ein Paralleltest statt.

Das Portfolio Management System erhält von vielen Systemen Stammdaten sowie Informationen zu Transaktionen.

Diese Informationen werden aufbereitet dem Kunden-Betreuer für die optimale Beratung seines Kunden sowie den Kunden für eine genaue Auskunft über die Entwicklung ihres Portofolios bereitgestellt.

Das Portfolio Management System besteht neben dem GUI (Windows, Java) und einem Server (AIX, C++) aus einer umfangreichen Host-Anwendungslandschaft, die die Daten der Um-Systeme entgegen nimmt, aufbereitet, verbucht und dem Server bereitstellt.

Um den Anpassungsbedarf gering zu halten, sind die notwendigen Anpassungen in den Eingangsschnittstellen auf dem Host durchzuführen.

Meine Aufgabe ist es, sowohl in dem Team, das die WebServices in Java auf dem Unix System, also auch in dem Team, das die Host Anwendungen betreut, mit zu arbeiten.

Aus diesem Grund sind im Folgenden sehr unterschiedliche Teilprojekte aufgeführt, auch wenn ich Vollzeit bei diesen Kunden für einen Projektleiter tätig war.

Neben den hier aufgeführten Projekten werde ich für Bugfixes eingesetzt.

Die Kontokorrent Anwendung lief historisch in verschiedenen Gebiets-Rechenzentren. Im Rahmen der Konsolidierung auf das zentrale Rechenzentrum waren die Schnittstellen zum Portfolio Management System von den bisherigen Rechenzentren auf ein Rechenzentrum zu verlagern.

Hierzu waren OPC (Job Steuerung) Änderungen sowie die Zusammenführung verschiedener Steuerungsinformationen notwendig.

Im Rahmen der Umstellung wurden umfangreiche Tests durchgeführt.

Die auf einer Oracle Datenbank in dem neuen Daten Layer der Abteilung eingespielten SAP Partner Stammdaten sind per SOAP (WebService), REST (JSON und XML im Browser) sowie als Datei zeitgesteuert per SFTP an die Zielsysteme auszuliefern.

Es sind regelmäßige Änderungen der Datenstrukturen zu erwarten, deshalb soll der Programmieraufwand für die Wartung minimiert werden.

Die Lösung besteht aus "Contract-Last" WebServices sowie "Contract-First" Flat-Files für SFTP.

Basis ist eine XSD Datei, generiert aus den Strukturen der Views in der Oracle Datenbank. Die Realisierbarkeit der Lösung ist zu prüfen.

Über ein Tool werden die Strukturen von zehn Oracle Views in einer XSD Datei geschrieben. Beim Build des Projektes mit MAVEN wurde mit dem maven-hyperjaxb3-plugin die entsprechenden Hibernate JAVA Klassen generiert.

Das Interface und die Klasse für die Hibernate-Abfragen mit den Zugriffsbedingungen wurden erstellt. Diese sind nicht von Strukturänderungen in den Views (neue Felder) betroffen.

Ebenso sind das Interface und die Klasse für SOAP sowie der CustomerController, der Request Mapper für REST, nicht von Strukturänderungen betroffen und wurde deshalb erstellt.

Auf die Generierung der Klassen auf Basis einer Business-Anforderungen wurde im PoC verzichtet.

Für die Contract-First Erstellung der Dateien für SFTP wurden Klassen auf Basis der generierten Hibernate Klassen erstellt und mit fixedformat4j Annotationen angereicht.

Als Klebstoff zwischen den Klassen setzte ich Spring ein, ebenso für verschiedenen Dependency Injections um z.B. die Parameter für den Datenbank Connection oder den JSCH SFTP Client an den Service zu übergeben.

Für den MAVEN Build erstellte ich verschiedene JUNIT Testklassen, über die auch in Eclipse ausführbar sind.

Ich testete den Service mit SOAPUI, im Browser und per FTP auf meiner lokalen Tomcat Installation und deployte dann 

das WAR File auf einem UAT Web-Server.

Die Eingangsschnittstelle von Kontokorrent, also den Gegenkonto für die Wertpapier-Transaktionen im Portfolio, wurde vor vielen Jahren entwickelt und durch verschiedene Entwickler immer wieder an die geänderten Erfordernisse, Jahr 2000, Euro, Abgeltungssteuer, ... angepasst.

Damit die Bewertung eines Portfolios nicht durch eventuell unterschiedliche Buchungstage der Wertpapier-Handelssysteme und des Kontokorrent Systems beeinträchtigt wird, werden schon bei der Verbuchung von Wertpapier-Transaktionen die zu erwartenden Kontokorrent Transaktion vermerkt. Diese müssen beim Verbuchen der Transaktionen aus Kontokorrent gematcht werden.

Enthaltende Steuern und Gebühren müssen aufgeteilt werden, um später den Wert des Portfolios darstellen zu können.

Da Kontokorrent eines der ersten Systeme war, das auf SAP DM umgestellt werden sollte, war die Dokumentation durch eine genaue Analyse der vorhandenen Programme zu prüfen.

Die Bank wird zentral mit WM-Stammdaten sowie mit Daten für "Futures and Options" versorgt. Das Portfolio Management bereitet auf der Produktions-Instanz diese Daten für sich und andere Systeme auf und speichert sie in eigenen DB2 Tabellen.

Um die identischen Daten auch in den Test- und Entwicklungs-Systemen zur Verfügung zu haben, habe ich zwei COBOL Programme entwickelt.

Das eine Programm liest in Produktion für eine WKN / ISIN und eine Zeitspanne die Daten aus den DB2 Tabellen und speichert sie in einer sequentiellen Daten. Diese Datei wird dann vom Operating auf das Test System kopiert und mittels des zweiten von mir entwickelten COBOL Programms in die dortigen DB2 Tabellen geschrieben.

Die Stammdaten für Partner, also Portfolio Inhaber, Bevollmächtigte und auch Kundenbetreuer wurden von einer Host-Anwendung bereit gestellt. Im Rahmen der Vorbereitung einer Migration werden diese Daten in ein SAP System gespiegelt.

Die gespiegelten Daten werden via WebServices bereitgestellt und in einer Oracle Datenbank auf einem Unix System gespeichert.

Der Inhalt der Oracle Datenbank ist mit dem Datenbestand in der z/OS DB2 Datenbank, die über die bisherige Schnittstelle versorgt wird, zu vergleichen.

Ich entwickelte eine Java-Anwendung, die beiden Datenbanken liest, Feldinhalt bei Bedarf nach Regeln des Fachbereichs aufbereitet, Differenzen ermittelt und entweder als Excel-Sheet oder in einer eigenen Datenbank dem Fachbereich zur Kontrolle zur Verfügung stellt.

Sehr viele Banken setzen neben den bankfachlichen Lösungen meines Kunden, die dem Anwender über ein Portal zur Verfügung gestellt werden, auch ein angepasstes SAP HR (PARISplus) für die Mitarbeiterbetreuung ein.

Um den Mitarbeitern einen direkten Zugriff auf die Daten des HR Systems in dem ihnen vertrauten Portal zu ermöglichen, wurde eine Anbindung entwickelt.

Ein direkter Zugriff aus dem Portal auf die SAP Systeme schied aus Performance-Gründen aus, so dass in der bankfachlichen Anwendungslandschaft ein Daten-Cache eingerichtet wurde, auf den das Portal zugreifen kann.

Die Anlieferung der Daten aus dem SAP HR steuert das SAP System und verwendet hierzu WebServices, die von OSPlus bereitgestellt werden.

Ich konzipierte den Daten-Cache (DB2) sowie der Anbindung der WebServices an das SAP System.

Zu meinen Aufgaben gehörte auch die Konzeption, Realisierung und das Testen der OSPlus Prozesse in COBOL zur Datenlieferung aus dem Daten-Cache an das Portal.

Mein Kunde entwickelte Host-Anwendungen über 20 Jahren mit IBM VAGen und den Vorgänger-Sprachen. Im Laufe der Jahren sind so über 18.000 produktive Programme und etwa 100.000 Module entstanden.

IBM hat VAGen aus der Wartung genommen.

Deshalb beschloss die Versicherung, künftig die Weiterentwicklung in der Standard Programmiersprache COBOL durchzuführen.

Die bestehenden Programme und Module wurden mittels eines am Markt erhältlichen Konverters von VAGen nach COBOL umzustellen. Der Konverter war an die Notwendigkeit der vorhandenen Softwarelandschaft anzupassen. Hierzu bildete in der IT-Tochter der Versicherung ein Projektteam aus erfahrenen COBOL und VAGen Entwicklern, das die Vorgaben erstellt und die Umsetzung validiert. Ein Teil meiner Aufgaben in dem Projektteam war die Unterstützung bei der Validierung.

Primär wurde ich jedoch für die Konzeption und Entwicklung von Tools in Java eingesetzt.

Der Konverter-Prozess benötigt neben den VAGen Sourcen viele weitere Informationen, die ich mit Tools aus der bisherigen Softwarelandschaft zu gewinnen hatte.

Bedingt durch die hohe Anzahl an Modulen bedurfte es eines automatischen Konvertierungsprozess, der auch den Import in die neue Entwicklungsumgebung IBM RDZ (Eclipse basierende Entwicklungsumgebung für Host-Programme) beinhaltet. Im Rahmen dieses Prozesses sind verschiedene formale und auch inhaltliche Prüfungen am COBOL Code notwendig.

Wenn mehrere hundert Anwendungsentwicklern über 20 Jahre eine Anwendungslandschaft erstellen, ist diese sehr heterogen. Die produktiven Programme beinhalten den Stand der Module zur Zeit der Generierung. Die Module im Laufe der Jahren weiterentwickelt, wobei nicht immer eine Generierung aller betroffener Programme erfolgt ist. Um hier Fallstricke zu erkennen wurden mit von mir entwickelten Tools die vorhandenen Modul Sourcen geparst und verschiedene Reports zur Qualitätssicherung erstellt.

Eine Umstellung aller Sparten in einem "Big-Bang" ist nicht möglich, somit hatte ich Sperr-Mechanismen, insbesondere in der bisherigen VAGen Entwicklungsumgebung (basiert auf "IBM VisualAge for Java"), zu implementieren.