Datenintegration mit Azure Functions: Erfahrungsbericht und Tipps

Bei der Wahl der einer passenden Integrationslösung in Azure kommt man an den Azure Functions nicht umher, wenn man schnell und einfach starten möchte. Dabei bietet die Einfachheit sowohl Vor- als auch Nachteile. So können zwar die eigentlichen Herausforderungen der Datenintegration zwischen den Systemen schnell gelöst werden, doch existieren im Betrieb einige Herausforderung.

In diesem Beitrag möchte ich auf ein etabliertes Vorgehen einer Datenintegration bei einem vollständigen Datenabgleich eingehen. Außerdem möchte ich Tipps für die erweiterte Nutzung des Loggings um fachliche Informationen geben. Als Monitoring wird ein Beispiel für die Erstellung einer Alerting-Regel verwendet.

Dabei liegt der Fokus des Beitrags nicht auf der technischen Implementierung des Ganzen (Abruf und Speichern der Daten u.ä.), sondern legt viel mehr Wert auf den Grundsätzen der Anwendung bspw. des Vorgehens und des Loggings.

Integrationsszenario

Um die angesprochenen Faktoren besser anwenden zu können, verwende ich für diesen Beitrag ein Beispiel. Betrachten wir hierzu eine Urlaubsverwaltung, welche auf einer einfachen Liste in SharePoint basiert. Darin können Mitarbeiter Ihren Urlaub eintragen (Start- und Endedatum). Beim speichern des Eintrags werden die Urlaubstage berechnet. Außerdem wird im Eintrag der Vorgesetzte gesetzt, welcher den Urlaub genehmigen muss.

Nun möchten wir diese Daten an ein anderes System im Unternehmen senden. Zum Beispiel möchte man diese Daten in einem Datawarehouse weiterverarbeiten, oder man benötigt diese Daten zur Ressourcenplanung der Mitarbeiter in dem jeweiligen Planungstool. So können beispielsweise Abwesenheiten automatisiert im Zielsystem angezeigt werden, ohne dass sich die Mitarbeiter z.B. weniger in ein Projekt einplanen.

In unserem Beispiel nehmen wir an das Ziel sei eine SQL Datenbank mit zwei Tabellen. Ein davon enthält die Übersicht aller Urlaubseinträge der Mitarbeiter mit den berechneten Urlaubstagen (also quasi eine Spiegelung der Datenhaltung in der SharePoint-Liste). Die andere Tabelle stellt die Planungstabelle der konkreten Tage dar.

Beim Transfer der Daten von SharePoint in Richtung der SQL-Datenbank ergeben sich folgende Aufgaben:

• Abruf aller Daten der SharePoint-Liste mit den benötigten Feldern (Mitarbeiter, Vorgesetzter, Startdatum, Enddatum, Berechneter Urlaub, Genehmigungsstatus)
• Tabelle Urlaubsübersicht:
  • Mapping auf die Felder/ Spalten der Zieltabelle
  • Berechnung der Urlaubstage und Validierung mit der Eingabe aus der SharePoint-Liste
• Tabelle Planungsübersicht:
  • Aufteilen der Urlaubstage auf die jeweiligen Arbeitstage
  • Je ein Eintrag für jeden Urlaubstag der erstellt wurde.
  • Für Tage, an denen der Mitarbeiter verplant ist, darf kein Urlaubseintrag gesetzt werden. Hier ist ein (fachlicher) Fehler zu erwarten.

Um die Anforderungen besser nachzuvollziehen betrachten wir nun einen exemplarischer Eintrag in der Urlaubsliste in SharePoint und wie die resultierenden Datensätze in den Zieltabellen dargestellt.

SharePoint:

Mitarbeiter: Waldemar Felde

Vorgesetzter: Manfred Manager

Startdatum: 26.01.2022

Enddatum: 30.01.2022

Berechnete Urlaubstage: 3 (Tage)

Genehmigt: True

Tabelle Urlaubsübersicht:

Mitarbeiter | Vorgesetzter | Startdatum | Enddatum | Berechnete Urlaubstage | Genehmigt

[weitere Einträge]

Waldemar Felde | Manfred Manager | 26.01.2022 | 30.01.2022 | 3 | true

[weitere Einträge]

Tabelle Planungsübersicht:

Mitarbeiter | Projekt | Tag | Eingeplante Stunden

[weitere Einträge]

Waldemar Felde | Projekt A | 24.01.2022 | 8

Waldemar Felde | Projekt A | 25.01.2022 | 8

Waldemar Felde | Urlaub | 26.01.2022 | 8

Waldemar Felde | Urlaub | 27.01.2022 | 8

Waldemar Felde | Urlaub | 28.01.2022 | 8

[weitere Einträge]

Alerting

Eine ganz zentrale Rolle beim Betrieb von Cloud-Ressourcen ist das Alerting. Im Zusammenhang mit der Datenintegration bedeutet das, fehlerhafte Ausführungen sofort erkennen zu können und entsprechende Fehlerkorrekturen durchzuführen.

Hier bieten Azure Functions mehrere Möglichkeiten, um nach bestimmten Metriken Alerting einzustellen. Eine hilfreiche einfache Search Query kann hierbei bereits die Grundsätzliche Benachrichtigung für den empfohlenen Nutzerkreis (via E-Mail) definieren, um Informiert zu werden, ob es Probleme mit der Ausführung der Azure Function gab.

Im folgenden Listing werden die Requests nach fehlerhaften Durchläufen für den entsprechenden Functionhost und der Function gefiltert, welche als Basis für die Benachrichtigung dient.

requests 
| where success == false 
| where cloud_RoleName =~ 'func-sync-SharePoint2Db' and operation_Name =~ 'RecurrentSyncFunc' 
| order by timestamp desc

Im Alerting sollte lediglich definiert werden, wie oft diese Query evaluiert wird. Bei wiederkehrenden Synchronisierungen (Recurrent Sync) hat sich eine aggregierte Granularität (Aggregation granularity) von 6 Stunden bei einer Frequenz von Einer Stunde als guter Richtwert bewährt. Dabei ist der Threshold allerdings bereits auf größer/ gleich 1 gesetzt. Das bedeutet, dass bereits beim ersten Auftreten des Fehlers eine Benachrichtigung versandt wird (bzw. die Search-Query für den definierten Betrachtungszeitraum mind. ein Ergebnis anzeigt).

Vorgehen

Das Vorgehen bei einer vollständigen Datenintegration zwischen zwei Systemen ist unabhängig vom verwendeten Tool (Azure Function, Logic App, etc.) grundsätzlich immer gleich. Zunächst einmal ermittelt man alle Datensätze aus dem Quellsystem und anschließend die aus dem Zielsystem.

Ausgehend hiervon kann nun festgestellt werden, welche Einträge neu erstellt (Create), aktualisiert (Update) oder gelöscht (Delete) wurden. Es empfiehlt sich hier für jede Art (CRUD) einen entsprechenden Stack (Liste) an Entitäten aufzubauen, welche im weiteren Verlauf der Integration Abgearbeitet werden sollen.

Falls die Daten auch in weiteren Zielsystemen importiert und vorher noch in ein anderes Datenformat gebracht werden sollen, empfiehlt es sich hier diese auch gekoppelt durchzuführen. Auf unser Beispiel bezogen wären das z.B. bei der Urlaubsbuchung auch die Anlage eines Datensatzes in der Urlaubsübersicht und drei Datensätze die in der Planungsübersicht.

Logging

Um bereits im Logging feststellen zu können, warum Daten nicht modifiziert, transferiert und gespeichert werden konnten, empfiehlt es sich auch hier strukturiert vorzugehen und das Logging auch mit fachlichen Informationen zu versehen.

Zunächst einmal sollte man das oben erwähnte Vorgehen um ein entsprechendes Logging anreichern. Hierbei ist es wichtig mit Schlüsselwörtern zu arbeiten. Der Logeintrag für den Vergleich zwischen Quell- und Zielsystem kann beispielsweise so aussehen:

Fetch Data – SharePoint (SRC): 1337 / DB (DST): 1234

Mittels der Schlüsselwörter vor dem Bindestrich kann man damit direkt im Code die Entsprechende Stelle suchen, an der der Logeintrag entsteht und mögliche Bugs schneller ausfindig machen.

Das Durchführen der entsprechenden CRUD-Datensätze kann auch nach einem ähnlichen Schema geloggt werden:

Start Create 1 Vacations:
 
Vacation-Entry (ID: 353134) : [Start: 26-01-2022, End: 30-01-2022, Calculated Vacation Days: 3, Employee: Waldemar Felde (ID: 254543)] successfully inserted in Urlaubsuebersicht-Table
 
Start Create 3 corresponding Planning-Entries:
 
Create Planning-Entry (ID: 12234): [Employee: Waldemar Felde (ID: 254543), Type: Urlaub, Date: 26-01-2022, Planned Hours: 8] successfully inserted in Planungsübersicht-Table
 
Create Planning-Entry (ID: 12235): [Employee: Waldemar Felde (ID: 254543), Type: Urlaub, Date: 27-01-2022, Planned Hours: 8] successfully inserted in Planungsübersicht-Table
 
Create Planning-Entry (ID: 12236): [Employee: Waldemar Felde (ID: 254543), Type: Urlaub, Date: 28-01-2022, Planned Hours: 8] successfully inserted in Planungsübersicht-Table
 
Finished Creating corresponding Planning Entries: Should: 3 / Was: 3
 
Finished Creating Vacation Entries - Should: 1 / Was: 1 

Somit erhält man bereits viele Informationen über den Import.

Schauen wir uns nun mal an, wie der selbe durchlauf mit einem möglichen Fehlerlogging aussehen könnte. Nehmen wir hierzu an, dass am 27.01.2022 bereits eine Planung für das Projekt A vorliegt, demnach erwarten wir hier im Logging einen (fachlichen) Fehler:

Start Create 1 Vacations:
 
Vacation-Entry (ID: 353134) : [Start: 26-01-2022, End: 30-01-2022, Calculated Vacation Days: 3, Employee: Waldemar Felde (ID: 254543)] successfully inserted in Urlaubsuebersicht-Table
 
Start Create 3 corresponding Planning-Entries:
 
Create Planning-Entry (ID: 12234): [Employee: Waldemar Felde (ID: 254543), Type: Urlaub, Date: 26-01-2022, Planned Hours: 8] successfully inserted in Planungsübersicht-Table
 
ERROR - Create Planning-Entry (ID: Error): Could not insert Entry [Employee: Waldemar Felde (ID: 254543), Type: Urlaub, Date: 27-01-2022, Planned Hours: 8] in Planungsübersicht-Table / Reason: Planning-Entry for Employee: Waldemar Felde (ID: 254543) already exists (Project: Projekt A).
 
Create Planning-Entry (ID: 12236): [Employee: Waldemar Felde (ID: 254543), Type: Urlaub, Date: 28-01-2022, Planned Hours: 8] successfully inserted in Planungsübersicht-Table
 
Finished Creating corresponding Planning Entries: Should: 3 / Was: 2
 
Finished Creating Vacation Entries - Should: 1 / Was: 1

Wie man im Listing sehen kann, erhält man sofort alle Informationen, um beurteilen zu können, ob der Fehler ein technischer oder ein fachlicher ist. Mit den entsprechenden Präfixen kann auch in LogAnalytics/ AppInsights nach den entsprechenden Einträgen gesucht werden, was eine einfachere Möglichkeit der Fehleranalyse gibt.

Man muss hierbei allerdings darauf achten, dass keine sensiblen Daten der Mitarbeiter zu sehen sind, die dem Datenschutz unterliegen. So wäre z.B. das Loggen des Impfstatus eines Mitarbeiters höchst Sensibel und darf nicht in den Logs erscheinen. Auch sollte die Menge an Informationen bewusst gewählt werden. Bei vielen Datensätzen erhält man so ein sehr großes Logging und verliert hier unter Umständen den Überblick.

Fazit

Mit einigen wenigen Grundsätzen zum Vorgehen und dem Logging kann man bereits eine sehr gute und leistungsfähige Integrationslösung bereitstellen, welche sich gut und einfach warten lässt. Die Verwendung von Alerting in Azure Functions lässt mögliche Fehler frühzeitig erkennen, welche dann zeitnah behoben werden können. Es empfiehlt sich also bei der Umsetzung ein umfangreiches Logging einzusetzen, welches im späteren Betrieb die Verwaltung, Wartung und Nachvollziehbarkeit von Zusammenhängen deutlich erleichtert und mögliche Fehlerursachen schnell ausfindig machen lässt.

Natürlich gibt es hier kein Allheilrezept, allerdings sollte man sich an den Grundsatz berufen: so viel wie nötig; so wenig wie möglich. Wenn z.B. zwischen zwei Systemen mehrere Tausend Datensätze ausgetauscht werden und man somit jedes Mal sehr viele Log-Einträge mit einer entsprechenden Größe generiert.