Das Fundament: Wie die SharePoint-Liste die LKW-Überwachung überhaupt erst möglich macht

Das eigentliche Fundament der LKW-Überwachung sieht auf den ersten Blick unspektakulär aus. Zwei SharePoint-Listen und ein paar Spalten, die ziemlich genau überlegt sein mussten.

Der Hilfsschlüssel als eigentlicher Dreh- und Angelpunkt

Eine einzelne Spalte wie das Kennzeichen reicht nicht aus, um eine Fahrt eindeutig zu identifizieren. Dasselbe Fahrzeug kann mehrfach am Tag unterwegs sein, oder die Abladestelle über den Monat hinweg mehrmals anfahren. Deshalb entsteht beim Import ein Hilfsschlüssel, der mehrere Felder kombiniert und durch ein Pipe-Zeichen trennt, um doppelt hochgeladene Datensätze zuverlässig zu erkennen.

Dieser Schlüssel wird gleich doppelt genutzt. Beim Import verhindert er, dass dieselbe Fahrt aus Versehen zweimal in die Liste geschrieben wird. Beim täglichen Überwachungsflow ist er die Grundlage dafür, Fahrten pro Tor zu zählen und Grenzüberschreitungen zu erkennen.

Die Sache mit dem Semikolon

Eine der unerwartetsten Erkenntnisse betraf eine ganz gewöhnliche berechnete Spalte. Um das Ankunftsdatum sauber verarbeiten zu können, wurde eine Formel mit MID() gebraucht, die Datum und Uhrzeit aus einem zusammengesetzten Textfeld extrahiert.

Die Formel wollte einfach nicht funktionieren, obwohl die Syntax auf den ersten Blick korrekt aussah. SharePoint akzeptiert bei berechneten Spalten zwar die englischen Funktionsnamen, erwartet als Trennzeichen zwischen den Parametern aber ein Semikolon statt eines Kommas.

=MID([Ankunft an Position_Text];1;10)&" "&MID([Ankunft an Position_Text];12;5)

Erst nachdem das Datum als Text importiert und über diese Formel wieder in Datum und Uhrzeit zerlegt wurde, ließ sich der Wert zuverlässig weiterverarbeiten. Und wer sich fragt, warum ich nciht die deutsche Bezeichnung nahm… nun, diese habe ich gar nicht zum Laufen bekommen. Ich habe hier nur mit den englischen Formeln in den berechneten Spalten gearbeitet. Ich bin mir auch unsicher, ob es real deutsche Formeln gibt, oder diese nur von der automatischen Übersetzung auf Microsofts Dokumentationen „erfunden“ wurden.

Positionen vereinheitlichen mit einer Hilfsspalte

Die Positionen in den Rohdaten sind feiner aufgeschlüsselt, als es für die Auflage relevant ist. Ein Tor taucht je nach genauer Zufahrt unter mehreren leicht unterschiedlichen Bezeichnungen auf, für die Überwachung zählt aber nur, an welchem übergeordneten Tor eine Fahrt angekommen ist.

Deshalb gibt es eine zusätzliche Hilfsspalte, die Position und Ankunftszeit zusammenführt und die feineren Bezeichnungen auf die relevante übergeordnete Kennung vereinheitlicht. Die eigentliche Positionsspalte bleibt dabei unverändert, die Vereinheitlichung passiert ausschließlich in der Hilfsspalte.

Eine Statusspalte, die Ressourcen spart

Ohne eine Statusspalte müssten die Flows bei jedem Durchlauf die komplette Liste neu laden und komplett neu bewerten. Deshalb bekommt jede Zeile einen Status. Der Überwachungsflow setzt den Status automatisch, wenn eine Grenzüberschreitung erkannt wurde, auf eine entsprechende Markierung. Solange eine Zeile in diesem Zustand ist, weiß jeder nachfolgende Flow sofort, dass hier noch eine menschliche Prüfung über die Power App aussteht, ohne die gesamte Liste erneut analysieren zu müssen.

Diese kleine Ergänzung hat gleich zwei Dinge gebracht. Die Flows laufen schneller und verbrauchen weniger Ressourcen und der Monatsabschluss kann am Ende einfach danach filtern, ob noch offene Prüfungen vorhanden sind, bevor der finale Bericht erstellt wird. Genau darum geht es im letzten Artikel dieser Serie, der Power App und dem Monatsabschluss.

Martin Reichelt ist Spezialist für Microsoft-Automatisierung und Verfechter der Citizen Developer Bewegung. Bei XelUp zeigt er, wie man das volle Potenzial von Excel ausschöpft und durch Power Automate effiziente Cloud-Workflows schafft, um wertvolle Lebenszeit im Job zurückzugewinnen.