Schnittstellenprogrammierung 

Heute steigen wir tief in die Schnittstellentechnologie ein und schauen uns ein international aufgestelltes Projekt mit Beteiligung von SYSTECS genauer an. Ein neu zu entwickelndes, großes Enterprise System soll ein bestehendes, in die Jahre gekommenen Systems in mehreren Schritten ablösen. Die Aufgabe ist nicht nur umfangreich, sondern auch sehr komplex, denn Teile der Bestandssoftware sind annähernd 20 Jahre alt und kommen dazu noch teilweise von Drittanbietern. Eine reibungslose Migration der Bestandssoftware in die Geschäftsabläufe des neuen Systems macht das zu einer Mammutaufgabe. In der Verantwortung von SYSTECS liegt die Sicherstellung der Anbindung dieser Bestandssysteme.
 

Je nach Alter und Qualität der existierenden Schnittstelle entstehen diverse Problem bei der Implementierung

Die verschiedenen Bestandssysteme verwenden diverse Transportschichten und Kommunikationsprotokolle. Ein Teil davon ist standardisiert, der andere wiederum ist proprietär. Wir möchten uns vier Schnittstellenschwerpunkten zuwenden und diese genauer ansehen: 

1. Fehlende oder unzureichende Schnittstellenspezifikation 

Es existiert entweder keine Schnittstellenbeschreibung oder die existierende Beschreibung ist unvollständig bzw. fehlerhaft, weil z. B. die letzten vorgenommenen Änderungen in der Dokumentation nicht nachgezogen wurden. 

• Eine Analyse mittels Netzwerk-Analyse-Tools wie Wireshark oder tcpdump ist unerlässlich. Diese ermöglichen das Protokollieren und Auswerten realen Netzwerkverkehrs, um die Details des Protokolls per Reverse Engineering zu ermitteln.
• Durchführen von Integrationstests zur Überprüfung des Kommunikationsprotokolls. Hierfür kann es auch schon zu einem frühen Zeitpunkt sinnvoll sein, einen Prototypen einzusetzen

2. Schnittstelle enthält benötigte Funktionen nicht 

Hier hängt es davon ab, ob die Möglichkeit für Änderungen an der bestehenden Schnittstelle existiert oder nicht. Für viele Altsysteme sowie für Standardprodukte großer Firmen sind individuelle Anpassungen nicht bzw. nicht mehr möglich. Die Applikationslogik der neuen Anwendung muss notfalls mit den Unzulänglichkeiten umgehen können. 

3. Schnittstelle enthält keinen Heartbeat-Mechanismus

Dies ist leider bei vielen älteren Kommunikationsprotokollen der Fall. Gerade bei TCP/IP-Verbindungen ist es nicht möglich, einen Verbindungsabbruch auf Netzwerkebene zu detektieren. Um das Problem zu überwinden gibt es folgende Optionen: 

• Pings über das ICMP Protokoll können implementiert werden. Diese stellen zumindest die Erreichbarkeit des Zielservers sicher, nicht aber der Zielanwendung. Für die Erkennung von Netzwerkausfällen sind Pings aber bereits ausreichend.
• Je nach Anwendungsprotokoll und Fehlertoleranz des Bestandssystems kann es weitere Möglichkeiten geben, einen fehlenden Heartbeat-Mechanismus zu kompensieren:
  • Es gibt eine „Dummy“-Nachricht, die periodisch verschickt werden kann (z. B. eine Statusabfrage des Zielsystems).
  • Das Zielsystem kommt damit klar, dass periodisch eine Nutznachricht mit ungültigen Werten geschickt wird.
  • Idealerweise wird eine Nachricht gewählt, die vom Zielsystem beantwortet wird. So hat die sendende Anwendung über die Netzwerkerreichbarkeit hinaus die Gewissheit, dass das Zielsystem noch ordnungsgemäß funktioniert.

4. Sicherheit 

Viele ältere Systeme enthalten keine Authentifizierungsmechanismen und keine Verschlüsselung des Datenverkehrs. In vielen Fällen lässt sich dieses Problem lösen, indem man den Netzwerkverkehr durch einen VPN-Tunnel routet. Das macht aber nur dann Sinn, wenn eine physische Zugangskontrolle zu den Serversystemen auf beiden Seiten gewährleistet werden kann.

Nachdem die Schnittstellen programmiert sind geht es nun daran, die Altsysteme Schritt für Schritt in das neue Enterprise Cloud System einzubinden. Hierfür muss zunächst ein Datenmodell für die Nachrichten des Kommunikationsprotokolls implementiert werden, sollte es nicht bereits existieren. Anschließend wird die Kommunikationsschnittstelle implementiert. Im nächsten Schritt müssen die empfangenen Nachrichten in das interne Datenmodell konvertiert werden. Sollte eine bidirektionale Kommunikation stattfinden, so muss das auch in die gegenläufige Richtung geschehen. Diese Nachrichten müssen immer validiert werden, also auf Sicherheit sowie syntaktische und semantische Korrektheit hin überprüft werden. Zum Schluss können diese dann an die Businesslogik des neuen Enterprise Cloud Systems weitergegeben werden.
 

Schnittstellenadapter hält Software Architektur flexibel für zukünftige Änderungen

Für eine modulare, flexible Software Architektur ist es ratsam, die Schnittstellenanbindung als reinen Schnittstellenadapter zu gestalten, der keinerlei Businesslogik enthält. Dies ermöglicht leichte Anpassungen und erlaubt notfalls den vollständigen Austausch gegen einen anderen Schnittstellenadapter, sollte sich die Schnittstelle des Drittsystems fundamental ändern.
 

Umfangreiche Tests sichern die Verlässlichkeit der Schnittstellen

Aufgrund der meist unzureichenden Schnittstellenspezifikation sind umfangreiche Tests unerlässlich. Diese sollten zu einem möglichst frühen Zeitpunkt stattfinden, evtl. bereits im Prototypenstadium. Hierzu kann parallel zum Schnittstellenadapter ein Simulator entstehen, der über eine REST-Schnittstelle mit Testdaten gefüttert werden kann. Darüber hinaus erfolgen umfangreiche Unit Tests, die den Adapter selbst unter die Lupe nehmen. Mit dem Integrationstests wird die korrekte Implementierung der Schnittstelle verifiziert. Die finale Abnahme des Schnittstellenadapters erfolgt schließlich durch einen Test mit dem produktiven Zielsystem unter Verwendung von Originaldaten. Damit ist die Aufgabe von SYSTECS in diesem Großprojekt abgeschlossen und die Anbindung sichergestellt.