Zentraler Adress-Validierungsdienst

Motivation

Die Validierung postalischer Adressen ist sehr wichtig für die Datenqualität Ihrer Geschäftspartner-Adressen.

ERP Softwarehersteller wie SAP bieten in ihrer Software eine integrierte Adressvalidierung . Allerdings basieren diese auf regionalen Referenzdaten, die nicht mitgeliefert werden, sondern eingespielt und regelmäßig aktualisiert werden müssen. Die Funktionalität dieser integrierten Adressvalidierung ist außerdem eher beschränkt. Alternativ kann auf spezialisierte Validierungs-Dienste zugegriffen werden.
Mittels solche Dienste können Adress-Komponenten (Straße, Stadt, PLZ etc.) identifiziert, validiert, automatisch korrigiert und ergänzt werden. Bei Eingabe von ungenauen oder unvollständigen Adressen, kann eine Liste von möglichen zutreffenden Adressen ausgegeben werden, aus der der Anwender die richtige Adresse auswählen kann. Auch „autocomplete”-Funktionen können damit implementiert werden.

Beispiele von Adress-Validierungs-Diensten sind :

  • Uniserv Address Validation
  • Melissa Address Check
  • Google Address Validation
  • Informatica Address Verification (Ehemals Addressdoctor)

Länderabhängige Adress-Validierung ist ein komplexes Thema, deshalb können die Validierungs-Ergebnissen durchaus nicht trivial zu interpretieren sein. Unterschiedliche Länder haben Ihre postalische Adresse Besonderheiten, die sowohl beim Aufbau einer Validierungs-Anfrage als auch beim Interpretieren der Ergebnisse berücksichtigt werden müssen.

Beispiele von Länderabhängigen postalische Adresse Besonderheiten:

  • In den Ländern GB oder CA gibt es die Adress-Komponente „Organisationsname”. Diese spielt bei Firmen oder Organisations-Adressen eine Zentrale Rolle
  • unterschiedliche Postleitzahl-Länge und -Formatierung, mit optionalen Teilen wie z. B. ZIP+4 in den USA
  • unterschiedliche Handhabung und Komponenten für „Hausnummer 1 und 2″: in den USA und CA: Benutzung von Appt/Unit/Suite
  • CEDEX – prioritized delivery address in FR

Falls die Benutzung des externen Validierung Dienstes direkt in jedem unterschiedlichen System vorgenommen wird, entsteht ein hoher Abstimmungsbedarf, um die Dienst-Benutzung und Mapping-Regeln konsistent zu halten. Falls dies nicht oder unzureichend gemacht wird, ergeben sich aus den Unterschieden inkonsistente Adressdaten. Außerdem erfordert die Anbindung in diesem Fall, dass die Entwickler-Teams in den unterschiedlichen Systemen tiefe Kenntnisse im Bereich internationale Adressvalidierung und die eingesetzte Validierung Software aufbauen müssen.

Einsatz von Adressvalidierung ohne zentralen Wrapper: Hohes Risiko von Inkonsistenzen
und erhöhter Implementierungsaufwand

Es ist aus diesem Grund sehr empfehlenswert, einen Zentralen Validierungsdienst-Wrapper anzubieten, der zum einen die Benutzung des externen Dienstes einfacher macht, dessen Ergebnissen gleich Benutzerfreundlich und einsetzbar sind, und zum anderen einheitliche Mapping Regeln und Datenstrukturen einsetzt.

Der Implementierungsaufwand reduziert sich außerdem in jedem Zielsystem und die Adressen werden alle mit gleichen Regeln und Ergebnissen validiert.

Weitere Vorteile von einem Zentralen Validierungsdienst-Wrapper sind:

  • Möglichkeit, zusätzliche Funktionalität einzubauen
    • Logging von Validierungs-Aufrufe
    • Caching von Validierungs-Aufrufen, damit können ggf. die Kosten reduziert werden
  • Möglichkeit, Varianten des Dienstes anzubieten, mit unterschiedlich ausgeprägter Funktionalität: z. B.
    • Minimal, sagt nur ob die Adresse ok ist oder nicht, ohne Validierungs-Fehlermeldungen
    • Standard mit Validierungs-Fehlermeldungen, ggf. Adresskorrekturen und -ergänzungen, aber ohne Rückgabe einer Adress-Treffer-Liste bei ungenaue Adressen
    • Volle Funktionalität: mit Validierungs-Fehlermeldungen, Adresskorrekturen und -ergänzungen und mit Rückgabe einer Adress-Treffer-Liste bei ungenaue Adressen
  • Länderabhängige Validierungsfunktionen können zentral gesteuert werden . Zum Beispiel kann eingestellt werden in Welche Länder die Validierung von Bundesstaaten / Regionen aktiviert sein soll und in welche Länder nicht
Einsatz von Adressvalidierung mit zentralem Wrapper

Implementierung

Für die Implementierung des Validierungs-Dienst-Wrappers als REST API gibt es viele Möglichkeiten. Zum Beispiel kann es mit Node.js + Express oder beliebige ähnliche API Server Software gebaut werden. Für einen reibungslosen produktiven Einsatz parallel zur Weiterentwicklung und Tests wird der Dienst auf Cloud-Foundry oder equivalent (Heroku, Kubernetes ) verwaltet und „deployed”.

Aufbau des Validierungs-Wrappers als REST Dienst

Mit einer Swagger API-Beschreibung kann die Implementierung der Benutzung von dem Dienst auf Zielsysteme schon vor der Finalisierung des Wrappers selbst angefangen werden.

API-Beschreibung mit Swagger

Während der Entwicklung und Tests des Wrappers können bestimmte Adressdaten mit bekannten Validierungsergebnissen gesammelt und in einer Test-Suite aufgenommen werden. Diese Testsuite kann dann später bei Fehlerkorrekturen oder Weiterentwicklung des Wrappers als CI/CD eingesetzt werden und garantiert die Stabilität und Qualität der Adressvalidierung.

Test-Definition im YAML Format

Adressvalidierung im SAP

Der REST-Validierungsdienst muss im SAP aus einer implementierung des BadI ADDRESS_CHECK aufgerufen werden. Die Aufbereitung der REST-Anfrage mit der Adresse in der Payload im JSON Format und die Bearbeitung der Antwort auch im JSON Format, ist mit ABAP unproblematisch.

Validierungsmeldungen können direkt als Ergebnis in der BadI-Implementierung zurückgegeben werden, und werden in der Adress-Management- (z. B. BP- oder Debitor Ändern) -applications angezeigt.

Beispiel mit Adresskorrektur und -ergänzung

Adresseingabe

Validierungsmeldungen und Ergebnis

Beispiel mit Trefferliste

Im Fall ungenauer Adressen mit Rückgabe einer Adress-Trefferliste kann diese in einem zusätzlichen Popup zur Auswahl angezeigt werden: