Automatisierungen & Überwachung

„Automatisierungen“ ist die Integrationsschicht von Aptli – die Art und Weise, wie Ihre Bereitstellung auf Ereignisse innerhalb des Systems reagiert und sich mit Systemen außerhalb verbindet. Sie umfasst vier Bereiche: Regeln, die bei bestimmten Ereignissen Aktionen auslösen, Hooks, die Ereignisse an andere Systeme weiterleiten, Datenerfassung, die Sensor- und Gerätedaten einliest, sowie Überwachung, die diese eingehenden Daten in Messwerte, Diagramme und Alarme umwandelt.

„Automations“ ist in jedem Tarif enthalten. Abgerechnet wird die Anzahl der externen Verbindungen, die Sie einrichten – siehe Das Verbindungskontingent weiter unten.

Die Seiten im Überblick

„Automations“ befindet sich in einer eigenen Navigationsgruppe mit vier Seiten:

Hooks – der schnelle Weg, Ereignisse zu versenden

Ein Hook ist ein signiertes Ziel, das die von Ihnen ausgewählten Ereignisse abonniert. Es ist die einfachste Outbound-Integration: Geben Sie ihm einen Namen, eine Ziel-URL, die zu sendenden Ereignisse, ein Signierungsgeheimnis (damit der Empfänger überprüfen kann, dass die Nutzlast von Ihnen stammt) und – optional – eine Nutzlastvorlage. Jedes passende Ereignis wird per POST an diese URL gesendet. Keine Bedingungen, keine Verzweigungen; einfach „diese Ereignisse dorthin senden“.

Verwende einen Hook, wenn ein anderes System lediglich wissen muss, dass etwas passiert ist. Greife auf einen Ereignis-Trigger (siehe unten) zurück, wenn du Bedingungen oder eine Aktion benötigst, die nicht über einen Webhook erfolgt.

Ereignis-Trigger – Regeln, die etwas bewirken

Ein Ereignis-Trigger ist die vollständige Engine nach dem Schema Trigger → Bedingungen → Aktionen. Wenn ein Ereignis ausgelöst wird und die Bedingungen erfüllt sind, werden eine oder mehrere Aktionen ausgeführt. Starten Sie einen neuen Trigger aus der Rezeptgalerie unter „Was soll automatisch passieren?“ oder wechseln Sie in den vollständigen Editor.

Trigger

Trigger sind nach dem Teil von Aptli gruppiert, aus dem sie stammen. Eine Auswahl:

• Arbeit — workOrder.created, workOrder.statusChanged, report.completed, report.validated, report.rejected, validation.statusChanged
• Projekte & Aufträge — project.created, project.statusChanged, job.created, job.removed
• Bestand — inventory.created, stock.adjusted, stock.transferred, stock.low
• Importe & Versionen — geo.import.completed, geo.import.failed, version.submittedForReview, version.committed
• Benutzer, Dateien, Hilfeanfragen — user.invited, file.uploaded, file.quarantine_failed, helpRequest.created, helpRequest.statusChanged
• Sensordaten — sensor.reading (wird einmal pro Batch der Datenerfassung ausgelöst und enthält die Aggregate dieses Batches — die Brücke von der Datenerfassung zur Automatisierung)
• Alarme — alarm.raised und alarm.resolved (§293). Im Gegensatz zu sensor.reading enthalten diese die vollständige Aktionspalette, sodass eine Regelverletzung einen Arbeitsauftrag erstellen, ein Feld aktualisieren oder jemanden benachrichtigen kann – und nicht nur einen Hook auslöst
• Geplant — schedule.daily, schedule.weekly, schedule.monthly
• SLA-Timer — timer.threshold, timer.expired, timer.escalated (ausgelöst durch laufende Lebenszyklus-Timer)

Bedingungen

Bedingungen schränken ein, wann ein Trigger ausgelöst wird; sie werden anhand des Ereigniskontexts ausgewertet und mit „UND“ verknüpft (alle müssen erfüllt sein):

• workOrder.status == 'completed' – nur bei Abschluss
• actor.email endsWith '@myorg.com' – nur interne Benutzer
• job.featureCount > 1000 – nur große Importe

Aktionen

Jeder Trigger verfügt über ein integriertes Testlauf-Fenster – eine Schaltfläche, die die Regel anhand eines synthetisierten Beispielkontexts für den jeweiligen Trigger auslöst. Zwei Dinge, die Sie vor der Verwendung beachten sollten: Es überspringt die Bedingungen (die Aktionen werden direkt ausgeführt), und es handelt sich nicht um einen Probelauf – ausgehende Aktionen (Webhook, Postgres, Artefaktübermittlung) werden tatsächlich an Ihren konfigurierten Zielen ausgeführt, werden in „Deliveries“ jedoch mit einem Test-Symbol gekennzeichnet. E-Mails werden geprüft, aber nicht versendet, und Aktionen, die Datensätze verändern (Erstellen/Aktualisieren), werden übersprungen. Richten Sie einen Test daher auf ein sicheres Ziel aus; er dient zur Überprüfung der Verknüpfungen und ist keine inaktive Vorschau.

Datenerfassung – Einlesen von Sensor- und Gerätedaten

Ein Erfassungskonnektor ist eine externe Datenquelle, die Messwerte in Aptli einspeist. Jeder Konnektor verfügt über einen Modus:

• Pull (geplante Abfrage) – Aptli fragt die REST-API eines Anbieters in einem Intervall (mindestens 30 Sekunden) ab. Sie legen die URL, eine Anmeldeinformation und eine kleine Antwortzuordnung fest (Messwertpfad, Zeitstempel-Schlüssel, Wert-Schlüssel, Metrik-Schlüssel), damit Aptli die JSON-Daten des Anbieters auslesen kann.
• Push (POST-Anrufe des Absenders) – Der Absender sendet JSON-Stapel per POST an den eigenen Eingangs-Endpunkt des Konnektors (wird angezeigt, sobald Sie den Konnektor speichern), authentifiziert mit einem Ingest-API-Schlüssel. Es muss nichts abgefragt werden; das Gerät oder das Gateway sendet die Daten nach eigenem Zeitplan.

In beiden Fällen gibt jeder Konnektor eine Stations-Feature-ID (das Karten-Feature, zu dem die Messwerte gehören – siehe Überwachung & Alarme) und eine Einheit an, und jeder eingelesene Batch löst den Trigger sensor.reading aus. Die Registerkarte „Ingestion“ zeigt außerdem eine Live-Ansicht der geplanten Abfragen an (wie viele aktiv, verzögert oder fehlgeschlagen sind).

Anmeldedaten, Schlüssel und das Verbindungslimit

Ausgehende Anmeldedaten

Ausgehende Aktionen, die ein externes System erreichen (Webhooks, Postgres, S3/SFTP-Artefaktübertragung), authentifizieren sich über eine gespeicherte Anmeldeinformation statt über Inline-Geheimnisse. Erstellen Sie diese einmalig auf der Seite Anmeldeinformationen und verweisen Sie mit dem Namen darauf. Geheimnisse werden im Ruhezustand verschlüsselt und nach dem Speichern nie wieder angezeigt; nicht geheime Konfigurationsdaten (Basis-URLs, Hostnamen, Regionen) bleiben lesbar. Typen: Bearer / Basic / API-Schlüssel für HTTP, S3, SFTP und Postgres.

Eingangs-Ingest-Schlüssel

Maschinelle Bearer-Schlüssel, mit denen ein Absender Daten an Aptli übermitteln kann. Sie dienen ausschließlich der Dateneingabe und sind auf die zulässigen Aktionen beschränkt (Einlesen von Messwerten oder Abrufen von Portal-Einreichungen); der Rohschlüssel wird einmalig bei der Erstellung angezeigt – kopieren Sie ihn dann.

Das Verbindungslimit

Das kommerzielle Kontingent bezieht sich auf die Anzahl der externen Verbindungen, nicht auf die Funktion selbst. Jeder Import-Konnektor, jeder API-Schlüssel und jeder wiederverwendbare Outbound-Hook verbraucht eine Einheit aus einem gemeinsamen Pool (interne, ereignisgesteuerte Regeln sind unbegrenzt). Ein Zähler auf den Seiten „Automationen“ und „Anmeldedaten“ zeigt „{verwendet} von {insgesamt} Konnektoren/Schlüsseln“ mit einer Aufschlüsselung nach Konnektoren, API-Schlüsseln und Hooks an. Das Standardkontingent beträgt 3; wenn Sie dieses erreichen, werden Sie beim Erstellen eines weiteren Konnektors aufgefordert, einen ungenutzten zu widerrufen oder den Support zu kontaktieren, um weitere hinzuzufügen. Bereits bestehende Verbindungen laufen weiter, auch wenn das Kontingent später reduziert wird.

Überwachung & Alarme

Die Datenerfassung holt Sensordaten herein; die Überwachung ist das, was Sie sehen und worüber Sie warnend informiert werden.

Stationen und Messwerte

Eine Station ist einfach ein Kartenobjekt, für das ein Sensor Daten meldet. Standardmäßig entspricht die Stations-Objekt-ID eines Konnektors der ID des Objekts selbst, sodass Messwerte direkt diesem zugeordnet werden; Sender, die eigene Stationscodes verwenden, können explizit verknüpft werden.

Sobald Messwerte eingehen, wird der Datensatz des Objekts um einen Abschnitt „Sensormesswerte“ erweitert: Für jede Messgröße werden der aktuellste Wert und die Einheit sowie eine 7-Tage-Sparkline angezeigt. Wenn eine Station stillsteht, ihre Quelle aber weiterhin unter anderen IDs Daten sendet (ein Sensor wurde an der Quelle umbenannt), kennzeichnet Aptli dies und bietet eine Neuverknüpfung mit einem Klick an, damit Sie den Verlauf nicht verlieren.

Alarme

Alarmregeln werden im Ingest-Konnektor verwaltet. Aktivieren Sie Alarme auslösen und legen Sie Folgendes fest:

• Alarm auslösen, wenn der Wert — über oder unter einem Schwellenwert liegt
• Löschspanne — wie weit ein Messwert unter den Schwellenwert fallen muss, bevor der Alarm automatisch gelöscht wird (Hysterese, damit ein Wert, der sich nahe am Schwellenwert bewegt, nicht zu vielen Alarmen führt)
• Alarm stummschalten nach (Minuten) — einen Stummschaltungsalarm auslösen, wenn so lange keine Daten eintreffen (Erkennung eines defekten Sensors)
• Alarmempfänger — wer benachrichtigt wird
• Eskalieren, wenn nach (Minuten) nicht bestätigt + Eskalationsempfänger — eine zweite Ebene, falls niemand rechtzeitig bestätigt

Die Seite Alarme ist das Live-Protokoll. Jeder Alarm ist Aktiv, Bestätigt oder Gelöst; man bestätigt ihn, um zu signalisieren, dass sich jemand darum kümmert, und löst ihn, wenn er bearbeitet wurde (Alarme werden auch automatisch gelöscht, wenn der Messwert wieder über die Sicherheitsmarge steigt). Schwellenwertalarme und Stillealarme („keine Daten empfangen“) werden deutlich voneinander getrennt angezeigt, und ein Alarm enthält seinen Wert/Schwellenwert/Spitzenwert, den Namen des Bestätigers sowie – falls er eskaliert wurde – eine Zeile „Eskaliert {Datum}“ mit einem Badge zum Zustellstatus. Eine Karte auf dem Start-Dashboard zeigt aktive Alarme an, damit sie nicht unbemerkt bleiben. Die Seite „Alarme“ ist für jeden angemeldeten Vorgesetzten sichtbar, nicht nur für Automatisierungsadministratoren, sodass die Personen, die die Arbeit überwachen, auch die Alarme im Blick haben.

Bidirektionale Ticket-Schleife

Ein Hook kann bei jedem Alarm eine Write-Back-URL enthalten: Ihr externes Ticket-System sendet Statusänderungen per POST zurück, um den Alarm zu bestätigen oder zu beheben, und die Ticket-Referenz wird im Alarm als Link angezeigt. Dadurch wird die Schleife geschlossen, wenn Alarme in einem anderen Tool bearbeitet werden.

Ergebnisse und Freigabelinks

In einem Projekt stellt die Registerkarte Ergebnisse die überwachten Metrikreihen den Meilensteinen der abgeschlossenen Arbeit gegenüber – siehe Projekte. Sie können einen schreibgeschützten, tokenisierten Freigabelink dieser Diagramme für externe Personen veröffentlichen und diesen jederzeit widerrufen. Die Messwerte werden zur Kontextualisierung neben den Arbeitsdaten angezeigt; Aptli erhebt keinen Anspruch auf Kausalität, und die Seite enthält ausdrücklich keine zertifizierten Messdaten.

Lieferungen – das Aktivitätsprotokoll

Die Seite Lieferungen ist ein schreibgeschützter Verlauf, der in zwei Registerkarten unterteilt ist:

• Ausgehende Lieferungen – eine Zeile pro ausgehendem Versuch: Datum, Workflow, Aktion, Ziel, Ergebnis (Erfolgreich / Fehlgeschlagen / Wiederholung / Dead Letter), Anzahl der Versuche, Dauer und etwaige Fehler. Testläufe sind entsprechend gekennzeichnet.
• Eingehende Läufe – der Importverlauf: Quelle, Ergebnis, Datum, Dauer, Zeilen und Fehler.

Schnellverbindung

Für gängige Integrationen führt Sie der Schnellverbindung-Assistent anstelle des Raw-Editors durch ein Rezept – z. B. „Neue Portal-Einreichungen an mein System senden“, „Mein System benachrichtigen, wenn der Lagerbestand zur Neige geht“, „Ein Ticket erstellen, wenn ein Alarm ausgelöst wird“ oder „Messwerte von meinen Sensoren oder meinem Gateway empfangen“. Er richtet den Konnektor, den Hook oder die Regel für Sie ein.

Berechtigungen

„Automations“ nutzt nicht das globale Raster für Administratorrechte. Die drei Konfigurationsseiten („Automations“, „Anmeldedaten“, „Übermittlungen“) sind durch eine Zulassungsliste für Betrachter/Bearbeiter in den Automations-Einstellungen geschützt, sodass Sie den Zugriff explizit gewähren. Die Seite Alarme ist bewusst für jeden angemeldeten Benutzer zugänglich – das Überwachen von Alarmen ist eine Betriebsaufgabe, keine Konfigurationsaufgabe. Inhaber der Berechtigung für Anwendungseinstellungen haben immer einen Wiederherstellungsweg, falls die Listen leer sind.