Integrationsbus für die Bank SOYUZ (AO): Design und Autotest



Es ist schwierig, die Wichtigkeit des Testens zu überschätzen, insbesondere wenn es um eine Integrationsplattform für das Zusammenspiel von Kreditfördersystemen geht. In diesem Artikel möchten wir darüber sprechen, wie unser Team einen solchen Bus zuerst entworfen und dann Autotests dafür gestartet hat.

Was ist eine Integrationsplattform und warum wird sie benötigt?

In großen Unternehmenssystemen treten häufig Probleme bei der Interaktion zwischen internen Subsystemen auf. Aufgrund endloser Verbindungen und Anfragen wird ein solches Gewirr im Laufe der Zeit immer unübersichtlicher und komplizierter. Es wird schwierig, sich zu entspannen, um es zu warten und zu verwalten.

Jedes Subsystem hat einen eigenen Release-Zyklus: Einige werden einmal pro Jahr und andere einmal pro Woche aktualisiert. Diese Änderungen müssen ebenfalls berücksichtigt und in den Gesamtsystembereich integriert werden. Dazu benötigen Sie einen Vermittler, der Daten zwischen allen Subsystemen des Unternehmens austauscht. Dieser Vermittler ist die Integrationsplattform.

Auf der Suche nach einem Künstler für seine Entwicklung bereitete der Kunde eine Testaufgabe vor, die implementiert und geschützt werden musste. Es war eine ziemlich einfache Aufgabenbeschreibung mit mehreren ausgewählten Systemen: Datenbank, Dienst, Dateiverzeichnisse usw. Innerhalb einer Woche mussten eine fehlertolerante Lösung erstellt und demonstriert sowie die Entwicklungsplattform beschrieben werden. Bei der Durchführung solcher Projekte haben wir anständige Erfahrungen gesammelt, und gemäß den Ergebnissen der Verteidigung wurden wir als Vollstrecker ausgewählt.

Zu dieser Zeit verwendete der Kunde in den meisten Fällen ein Punkt-zu-Punkt-Integrationsschema: Jedes System wurde in ein anderes integriert. Es war unpraktisch und schwierig zu warten. Wir haben drei Aufgaben:

  1. bestehende Integration durch eine Integrationsplattform ersetzen;
  2. neue Bankensysteme integrieren;
  3. Automatisieren Sie den Datenaustausch zwischen ihnen.

Nach erfolgreichem Bestehen der Testaufgabe haben wir das Projekt gestartet. Die Phasenlage für sich selbst wurde folgendermaßen bestimmt:

  • ein Audit durchführen;
  • Finden Sie Kundenmitarbeiter, die den Zielzustand der Geschäftsprozesse verstehen (und nicht nur den aktuellen).
  • Formulierung von Geschäftsanforderungen für IT-Systeme und Bereitstellung einer Roadmap für den Übergang zum Zielzustand von Geschäftsprozessen.

Implementierung


Für die Implementierung wählten sie die modulare Integrationsplattform Red Hat JBoss Fuse.


JBoss-Sicherungsarchitektur

Ein bisschen mehr über die grundlegenden Werkzeuge, die sofort einsatzbereit sind:

Apache Camel basiert auf Corporate Integration Templates (EIP) und bietet Nachrichtenrouting sowie eine große Anzahl vorgefertigter Adapter für die Arbeit mit externen Systemen: Datenbanken, Dateien, Nachrichtenbroker, Verzeichnisdienste, E-Mails usw.

Apache ActiveMQ organisiert den Austausch von Nachrichten und sorgt für deren Übertragung und Speicherung, bis der Abonnent sie abholt.

Der Integrationsprozess selbst (Flow) besteht aus einer Reihe von sequentiellen Aktionen. Beispiel: Um eine Nachricht vom Quellsystem über einen entwickelten / vorhandenen Adapter zu empfangen, konvertieren Sie die Nachrichtendaten, fügen Sie sie hinzu, filtern Sie sie und senden Sie sie über ihre Adapter an die Empfängersysteme weiter.


Integrationsprozess

Gleichzeitig Überprüfung der Daten, garantierte Zustellung, Fehlerbehandlung mit der Möglichkeit, ein Überwachungssystem zu erheben, verantwortliche Ausführende über Fehler zu informieren usw.

Beispiel


Nehmen Sie den Prozess der Kreditvergabe bei einer Bank. Ein Kunde in der Internetbank füllt einen Antrag aus, sendet Daten aus dem Formular und wartet auf das Ergebnis. Was passiert darin? Über die restliche API, die der Internetbank zur Verfügung gestellt wird, akzeptiert der Bus die Anfrage mit den Hauptdaten. Ferner fordert er über die Seifenschnittstelle im MDM-System zusätzliche Informationen über den Kunden an, kombiniert die empfangenen Informationen zu einem gemeinsamen Satz und überträgt sie über die dedizierte ActiveMQ-Warteschlange an das RTDM-System, um im Rahmen bestehender Darlehensprodukte ein Angebot zu formulieren. Anschließend wird das Ergebnis von RTDM zurückgesendet und der Bus sendet das Angebot für den Kunden an die Internetbank zurück.

Testen


Bei der Übergabe des Integrationsbusses an die Tester wurde zunächst die Frage des Produkttests manuell entschieden. Dabei wurde jedoch beschlossen, den gesamten Prozess zu automatisieren und eine Testplattform zu erstellen.

Wir haben Emulatoren für alle Banksysteme geschrieben. Da Clients nicht immer gleichzeitig Zugriff zum Testen von Arbeitsdaten und Systemen bereitstellen, wurden Emulatoren für jedes Projekt separat entwickelt. Die Komplexität dieser Arbeit ist vergleichbar mit der Entwicklung der Integrationslösung selbst. Die Testplattform hatte die Aufgabe, die Ergebnisse zu sammeln, bereitzustellen, den Test auszuführen und an TestRail zu senden.

Wir haben zwei Skriptsätze erstellt, die bei jedem Build (CI / CD) ausgeführt wurden. Dem Commit zufolge wurde die Versammlung initiiert und auf dem Stand eingesetzt. Nach dem Deployment-Vorgang wurde ein kurzes Skript (Rauch-Test) ausgeführt, das uns mitteilte, dass keine Integrationsinteraktionen unterbrochen wurden.

Wir verfolgten ein erweitertes Szenario für Nachtversammlungen, das uns eine vollständige Antwort auf die Frage gab: Was ist mit dem Bus und wie interagiert er mit externen Systemen? Im Morgenbericht sahen wir erfolgreiche Tests oder aufgetretene Probleme. Wir haben das Testen der Integrationsplattform mit externen Systemen jedoch nicht automatisiert, da es sehr schwierig ist, die Ergebnisse solcher Tests zu überprüfen. Aus diesem Grund ließen sie die manuellen Tests: Die Mitarbeiter des Kunden führten Abnahmetests ihrer Systeme durch, und unser Spezialist überprüfte anhand von Protokollen, ob die Informationen korrekt übermittelt wurden.

Dadurch konnte eine 100% ige Testautomatisierung auf Emulatoren erreicht werden. Bei der Aktualisierung eines der externen Systeme übernahm der Bus die Aufgabe, die Funktionsfähigkeit der Geschäftsprozesse aufrechtzuerhalten, weshalb Änderungen direkt daran vorgenommen wurden. Auf diese Weise konnten Sie Änderungen schnell testen.

Anstelle einer Schlussfolgerung


Nachdem alle Phasen abgeschlossen waren, baute unser Team schnelle und transparente Prozesse mit Auftragnehmern und Kunden auf, und die Prozesse für die Weiterentwicklung, das Testen, die Implementierung und den Support verliefen einfach. Infolgedessen wurden 12 Geschäftsprozesse automatisiert, die im Wesentlichen die Arbeit der Hauptsysteme der Bank vereinten: ABS, MDM, Verarbeitung, RTDM usw. In solchen Projekten versuchen wir immer nur automatisiertes Testen, praktisch ohne Einbeziehung von Funktionstestern. Dies reduziert die endgültigen Kosten für die Projektentwicklung und -integration, verkürzt die Markteinführungszeit und gleicht den Faktor Mensch aus.

Alexander Sadykov, stellvertretender Leiter der Testabteilung, Zentrum für Softwarelösungen, Jet Infosystems

Pavel Ivanov, Entwicklungsteamleiter, Zentrum für Softwarelösungen, Jet Infosystems

Source: https://habr.com/ru/post/de479316/


All Articles