Architektur von agree BAP: GENO AZV (Auslandszahlungsverkehr) Einbettung einer AZV-Drittsoftware in agree

Transkript

1 Architektur von agree BAP: GENO AZV (Auslandszahlungsverkehr) Einbettung einer AZV-Drittsoftware in agree

2 Ziel dieses Vortrags Ziel des Projekts agree BAP: GENO AZV ist, den Auslandszahlungsverkehr für alle Banken im BAP verfügbar zu machen Hierzu ist eine existierende AZV-Lösung in das agree-umfeld zu integrieren und Fiducia-spezifisch zu erweitern (z. B. Prüfungen, Datenanreicherung, Schnittstellen) Im Vortrag wird anhand von Beispielen gezeigt, welche Herausforderungen zu lösen waren, welche Lösungsansätze gewählt wurden, und wie sich die gewählte Anwendungsarchitektur in der Entwicklung bewährt hat Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 2

3 Agenda Kurzüberblick agree BAP: GENO AZV Architekturprinzipien Herausforderungen und unsere Lösungen Fazit/Zusammenfassung Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 3

4 Agenda Kurzüberblick agree BAP: GENO AZV Architekturprinzipien Herausforderungen und unsere Lösungen Fazit/Zusammenfassung Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 4

5 Kurzüberlick - agree BAP: GENO AZV agree Eingangsschnittstellen (BAP, DTAZV) Equens Eingangs- Schnittstellen (Zahlungseingänge, Abrechnungsdaten) agree BAP: GENO AZV Equens Ausgangs- Schnittstellen (Zahlungs- Aufträge) agree-ausgangsschnittstellen (Buchung, LDMS) agree-module (BIC-Directory, Kunde) Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 5

6 Agenda Kurzüberblick agree BAP: GENO AZV Architekturprinzipien Herausforderungen und unsere Lösungen Fazit/Zusammenfassung Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 6

7 Architektur- und Entwicklungsprinzipien Architekturprinzipien agree Standardarchitektur (asa) Klare Verantwortlichkeiten Einfache Abstraktionen Open Closed-Prinzip Lose Kopplung Entwicklungsprinzipien DRY Don t Repeat Yourself Kurze Methoden Lesbarer Code Nachvollziehbarkeit (durch Referenzen zur fachlichen Beschreibung) Junit Tests Unterstützung durch Tester schon während der Entwicklung Clean-Code-Prinzipien Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 7

8 Agenda Kurzüberblick agree BAP: GENO AZV Architekturprinzipien Herausforderungen und unsere Lösungen Fazit/Zusammenfassung Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 8

9 Herausforderungen Integration einer Host-basierten Drittsoftware für den AZV Bereits für sechs Banken im Betrieb mit 3270 Oberfläche (Vollanwender) Diese Banken haben einen eigenen SWIFT-Connect BAP-Integration des AZV für alle Banken (Primärbanken) Masken mit gleichartigen Inhalten und Aufbau für sechs verschiedene Auftragsarten Clearing für die Primärbanken über DZ BANK/Equens Spezielle Prüfungen und Anreicherungen je Auftragsart Zur Laufzeit änderbare Prüfungen (konfigurierbar) Integration mit Modulen, die zur Entwicklungszeit noch nicht fertiggestellt sind Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 9

10 Integration einer Drittanwendung für den AZV - Prämissen Soll möglichst ohne größere Änderungen am Produkt in agree integriert werden Datenhaltung ausschließlich im Fremdsystem Standard JBF-IMS-Connect soll verwendet werden Wiederverwendung von Business-Logik im Dialog und Batch Eigenes fachliches Modell Anbindung der Equens/DZ BANK als Clearer Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 10

11 Kapselung der Drittsoftware agreeeingangsschnittstellen (BAP, DTAZV,...) agree agree-daten gespiegelt AZV System Prüfung Anreicherung Equens Eingangs- Schnittstellen (Zahlungseingänge, Abrechnungsdaten, usw.) Buchungslogik Datenhaltung (Zahlungen) Tagesabschluss SWIFT Prüfungen Routing Steuerungsdaten Statushandling Geschäftsarten Marktdaten Entgeltermittlung Stammdaten Benutzerverwaltung Equens Ausgangs- Schnittstellen (Zahlungs- Aufträge) agree-ausgangsschnittstellen (Buchung, LDMS,...) Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 12

12 Kapselung der Drittsoftware Durch das eigene fachliche Modell gibt es Felder in den Schnittstellen zur Drittsoftware, die nur dort vorkommen, aber änderbar sind Daher muss vor dem Speichern von Änderungen ein Auftrag zunächst geladen werden In dem geladenen Auftrag (Bytestrom) werden nur die geänderten Daten überschrieben Auftrag wird wieder gespeichert Die nicht in das eigene Modell übernommenen Felder müssen hierdurch nicht bekannt sein Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 13

13 Maskendesign Viele Masken mit gleichartigem Aufbau Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 14

14 Lösung - Frontlet Parts Reiter sind technisch entkoppelt und können bei anderen Auftragsarten wiederverwendet werden z. B. Kundenabrechnung, Leitweg oder weitere Weisungen Lediglich die Anbindung an das Datenmodell ändert sich abhängig von der Auftragsart Hierdurch wurde ein hoher Wiederverwendungsgrad erreicht Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 15

15 Lösung - Frontlet Parts Gesamt-Frontlets Reiter Frontlets Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 16

16 Spezielle Prüfungen und Anreicherungen je Auftragsart Prüfschritt ZA DA IB IA Teilnahme bestimmen x x x x Zeichen prüfen x x x x Beträge prüfen x x x x Habenvaluta prüfen x x - x Geschäftsart bestimmen x x x x Zahlungsbeteiligte prüfen x x x x Pflichtfelder prüfen x 1 x 2 x 3 x 4 Weisungsschlüssel prüfen x x x x Konditionsmodell ermitteln x 1 x 2 x 3 x 4 Entgeltregelung prüfen x 1 x 2 x 3 x 4 Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 17

17 Lösung Kapseln der Prüfungen und Anreicherungen Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 18

18 Zur Laufzeit änderbare Prüfungen Sind notwendig für TIPANET-Fähigkeit STP-Fähigkeit EU-Standard-Fähigkeit SEPA-Fähigkeit Qualitätsermittlung Diese Prüfungen müssen täglich änderbar sein: z. B. Betragsgrenzen, teilnehmende Länder, Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 19

19 Lösung konfigurierbare Regelprüfungen Definition von Regelsätzen und Regeln STP-Fähigkeit (besteht aus 7 Regeln) Tipanet Fähigkeit (pro Land, Anzahl der Regeln ist länderspezifisch) EU-Standard-Fähigkeit (eine Regel) SEPA-Fähigkeit (eine Regel) Jeder Regel definiert Regelprüfungen Prüfungen auf Feldebene (größer, gleich, kleiner, enthält, ) Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 20

20 Abbildung der Regeln in der Datenbank Regelsatz Regel Regel Attribut Prüfung Wert Fehlermeldung Qualtiät Regel 1 Identifikation Typ Konto Ist gefüllt agree_0042 Tipanet Qualtität Regel1 Qualität Regel1 Identifikation Typ Iban Ist nicht gefüllt Qualität Qualität Regel 2 Qualtität Regel1 BIC des Begünstigten Ist gefüllt STP Fähigkeit Qualität Regel n Qualtität Regel 2 Kontonummer Ist gleich ABC Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 21

21 Lösung konfigurierbare Regelprüfung Ablauf der Prüfung prüferegeln(regelsatz regelsatz, Prüfobjekt prüfobjekt) { for (Regel regel : regelsatz) { for (RegelPruefung regelpruefung : regel) { if (istattributpruefungnichtok(regelpruefung)) { fehlerrelevanzfuerregel.addiererelevanz(regelpruefung); fehlerrelevanzfuerregel.fuegeaufgetretenefehlerderstatuslistehinzu(); } fehlerrelevanzfuerregel.berechnesortierwert(); } } return ermittlegewichtigstenfehler(fehlerrelevanzlistedergesamtpruefung); } Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 22

22 Integration von Modulen, die zur Entwicklungszeit nicht fertig gestellt sind Fiducia BIC-Directory (BIC-Plus-Verzeichnis) Konto Vertragsprüfung IKESA-Tabellen Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 23

23 Lösung Stützschnittstellen zur Integration mit den Modulen Eigene Schnittstellen zur Entkopplung definiert Gegen diese Schnittstellen konnte entwickelt und getestet werden Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 24

24 Agenda Kurzüberblick agree BAP: GENO AZV Architekturprinzipien Herausforderungen und unsere Lösungen Fazit/Zusammenfassung Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 25

25 Fazit/Zusammenfassung Die iterative Herangehensweise hat sich bewährt Die fachlichen Anforderungen konnten mit den gewählten Abstraktionen einfach umgesetzt werden Prüfungslogik -> Konzept ist wiederverwendbar Frontlet-Parts -> Prinzip ist allgemein wiederverwendbar Frühes Einbinden des Testteams in Erstellung von JUnit-Tests zahlt sich aus CCD-Prinzipien und -Techniken sind eine gute Richtschnur für die Entwicklung einer Architektur Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 26

26 Fragen? Diskussion? Ihr Logo Andreas Werner Cirquent GmbH 0172 / Architektur von agree BAP: GENO AZV Andreas Werner JBFOne 2010 Seite 27

27 Ihr IT-Partner Vielen Dank