Datentransformationen: Wer braucht sie überhaupt?

Wie die meisten modernen Webanwendungen interagiert die Clientseite unserer App mit JSON-Daten. In ähnlicher Weise haben unsere Entwicklungsteams in der Vergangenheit hauptsächlich mit JSON gearbeitet. Viele unserer Drittanbieter-APIs kommunizieren dagegen über SOAP-XML-Anfragen, die strukturiert sind ganz anders. Die Aufgabe meines Teams bestand darin, Endpunkte zu erstellen, um diese Integrationsdaten in JSON unseren internen Entwicklungsteams zur Verfügung zu stellen. Unser Ziel ist es, ihre Entwicklung so reibungslos wie möglich zu gestalten und zu minimieren, dass sie Daten anders sehen müssen, als sie es gewohnt sind.

Wie sieht das alles aus?

Natürlich müssen wir zunächst herausfinden, wie wir alle Daten und Informationen von Drittanbietern abrufen können, die wir benötigen. Darüber hinaus müssen wir besprechen und festlegen, wie diese Informationen im Rahmen der Anfrage, die wir bearbeiten, weitergegeben werden. Wo gehen die Credits hin? Was ist mit den Parametern? Was wird in der Anfrage, die wir erhalten, angegeben und wo? Wie sollte die Antwort aussehen? Diese Schritte beinhalten in der Regel die meisten Fragen und das notwendige Hin und Her, um Ideen auszutauschen und Klarheit über einen MVP zu schaffen. Ein oder mehrere Mitglieder sollten sein:

• API-Dokumentation lesen
• Senden von Musteranfragen (z. Postbote)
• Sprechen Sie mit einem technischen Berater/Entwickler des Drittanbieters, um das Verständnis der API und ihrer Funktionen/Einschränkungen zu überprüfen

Sobald Sie eine erfolgreiche Anfrage erhalten haben, können wir mit der Änderung und dem Testen beginnen.

Was soll zurückgegeben werden?

Nachdem Sie die API-Antwort gesehen haben, müssen Sie als Nächstes herausfinden, wie Sie sie analysieren, alle einzelnen Datensätze und die gewünschten Felder abrufen oder den Fehlercode und den Kontext abrufen können.

In einer idealen Welt sind alle möglichen Status/Formen der verschiedenen Antworten/Fehler im Voraus bekannt und die Daten sind immer gemäß der Dokumentation vollständig. Dies ist jedoch oft nicht der Fall. In der Regel finden Sie durch umfangreiche Recherchen und Ausprobieren heraus, was Ihr Team benötigt, welche Daten möglicherweise nicht verfügbar sind oder für welche Daten ein Workaround erforderlich ist. Dabei ist es sehr wichtig, eine klare Kommunikation zwischen den Teams über beide Produkte aufrechtzuerhalten (Datenvertrag) und Erwartungen (Timing & Lieferbarkeit/Qualität & Wartung). Stellen Sie sicher, dass alle Daten, die das Team erwartet, verfügbar sind. Stellen Sie andernfalls die Möglichkeit bereit, diese Daten zu aggregieren, um ein vollständiges Produkt zu liefern. Jetzt wird der Code zusammengeführt und veröffentlicht. Ihr Produkt ist in freier Wildbahn und Ihre Daten sind zum Verzehr bereit. Es ist eine großartige Zeit für Ihr Team, andere über die Verwendung Ihres großartigen neuen Produkts aufzuklären. Einige Ideen beinhalten eine funktionierende Demo des Produkts, vielleicht eine Brown-Bag Lunch, um über die Technik oder den Code zu sprechen, und natürlich den guten alten, praktischen Dandy Dokumentation.

Vor Herausforderungen gestellt

Es ist eine Sache, eine erfolgreiche Anfrage senden und als Antwort Daten empfangen zu können. Zu verstehen, was diese Daten sind und wie sich die Parameter der Anfrage im Datensatz widerspiegeln, gefolgt vom Neupacken dieser Daten, damit sie von anderen Teams leichter verwendet werden können (ohne dass diese wissen, wie die Originaldaten tatsächlich aussahen), ist völlig anders.

SO VIELE MÖGLICHKEITEN, DASSELBE ZU BEKOMMEN

In einem Fall, in dem wir Anfragen nach Buchhaltungssaldendaten testeten, stellten wir fest, dass der Ausschluss bestimmter Feldzuordnungen dazu führt, dass die Abfrage unter der Haube diese Salden aggregiert und die besagten Felder ignoriert. Aufnahme von Abteilungen, könnte beispielsweise keine Auswirkung auf das Datenvolumen haben oder es drastisch erhöhen, je nach Granularität der Abteilungszuordnungen.

SO VIELE ARTEN DERSELBEN SACHE

Manchmal weist sogar ein einzelner Datensatztyp Abweichungen zwischen den Datensätzen auf und erfordert eine differenziertere Analysestrategie. Beispielsweise kann eine API einen einzelnen Endpunkt bereitstellen, um alle Geschäftstransaktionen abzurufen. Es gibt jedoch über 40 verschiedene Arten von Transaktionen — jede mit ihrem eigenen, etwas einzigartigen Schema. Diese Transaktionen werden alle in derselben Tabelle gespeichert, und Transaktionen verschiedener Typen können je nach Abfrage in beliebiger Kombination zurückgegeben werden. Ein Teil unserer Entdeckung hier war:

• bestimmt alle gemeinsamen und einzigartigen Eigenschaften
• finde heraus, wie man für sie analysiert
• entscheide, was unserem JSON-Schema zugeordnet werden soll

SO VIELE NAMEN FÜR DASSELBE

Die Idee, die anderen Teams von diesem Drittanbieter-Fachwissen zu trennen, dient den Teams, indem sie ihnen Zeit erspart, etwas Neues lernen zu müssen. Indem Sie Rohdaten nehmen und sie umformen, gestalten Sie jedoch auch die Konversation rund um die Daten neu. Neue Verweise werden auf Felder mit unterschiedlichen Benennungskonventionen oder auf abgeleitete Felder erstellt, die in den Rohdaten nicht vorhanden sind. Andere Entwicklerteams sprechen möglicherweise immer in Bezug auf das JSON-Schema und seine Namenskonventionen — Konventionen, die leicht (oder vollständig) von den API-Daten abweichen können. Beide können auch von der Benutzeroberflächensprache des Drittanbieters abweichen. Die für die Integration verantwortlichen Ingenieure müssen das Wissen über diese Parität aufrechterhalten.

Tipps und Hinweise:

Kommunizieren, Kommunizieren, Kommunizieren! Wie bereits erwähnt, stellen Sie sicher, dass Sie durchgehend klare, dokumentierte Hinweise zum Datenvertrag und zur Datenentdeckung aufbewahren. Teilen Sie Wissen und informieren Sie sich gegenseitig über Status, Fortschritte und Hindernisse. Auf diese Weise können Sie sicherstellen, dass Ihre Teams auf dem gleichen richtigen Weg zum Erfolg sind. Es könnte hilfreich sein, wenn Sie versuchen, Daten so zu kodifizieren, dass sie eine maschinengeschriebene Sprache verwenden, wie Typoskript. Auf diese Weise sind Sie immer über die Ausgänge informiert und wissen, dass die Daten validiert werden, sobald alles verkabelt ist. Manche empfinden eingetippte Sprachen als umständlich, aber die manuelle Fehlerbehebung bei unerwarteten fehlerhaften Daten (die sonst gefunden worden wären) kann weitaus schmerzhafter sein. Vergessen Sie nicht, zu testen!

Für Komponententests empfehle ich dringend Tests, um sicherzustellen, dass Ihre Strategien zur Erstellung von Anfragen und zum Analysieren von Antworten wie gewünscht funktionieren. Bei Integrationstests kann es sich lohnen, Zeit in die Einrichtung von Tests für die verschiedenen Randfälle von Datenvarianzen zu investieren, um sicherzustellen, dass die für den Verbrauch erwarteten Daten korrekt sind. Lassen Sie uns nun mit der Transformation beginnen, Leute!