Betrieb

Hinter einem Reverse Proxy

Für den Zugriff von anderen Rechnern und für HTTPS setzt du einen Reverse Proxy (IIS, nginx, Traefik, …) vor die App. Die App selbst lauscht auf einfachem HTTP.

• Leite / an die App weiter. Der Editor nutzt eine Live-Verbindung (Blazor Server, WebSockets): Schalte WebSocket-Weiterleitung ein und trenne ruhende Verbindungen nicht zu früh.
• Webhooks liegen unter /webhook/<Pfad>. Willst du nur Webhooks ins Internet geben, leite nur /webhook/ weiter und halte den Editor intern.
• Ohne Anmeldung (Pipe:Auth:Mode = none) kann jeder, der den Editor öffnet, Workflows anlegen und alles ausführen, was du freigegeben hast. Schalte eine Anmeldung ein (siehe Anmeldung) oder schütze den Editor mit dem Proxy (Authentifizierung, IP-Beschränkung) oder einem VPN.
• Mit dem Anmeldemodus oidc hinter einem Proxy, der HTTPS beendet, setze Pipe:Auth:UseForwardedHeaders auf true und lass den Proxy X-Forwarded-Proto und X-Forwarded-Host senden. Sonst schickt die App http://-Redirect-URIs an den Identity Provider, der sie ablehnt.

Webhooks im Betrieb

• Webhooks funktionieren nur, solange der Workflow Active ist. Nach einem Neustart werden alle aktiven Workflows wieder scharf geschaltet.
• Ein Pfad gehört in der ganzen App genau einem Workflow. Ein zweiter Workflow mit demselben Pfad lässt sich nicht aktivieren, und der Editor zeigt nach dem Speichern den Grund.
• Setze bei von außen erreichbaren Webhooks immer ein Credential (Basic Auth, Bearer Token oder API Key Header). Ohne eines kann jeder, der die URL kennt, den Workflow starten.
• Die maximale Body-Größe beträgt 10 MB (Antwort 413). Aufrufer, die auf den Workflow warten, haben je Webhook ein Timeout (Vorgabe 30 Sekunden). Danach bekommen sie 202, und der Lauf geht weiter.
• Ein Workflow läuft standardmäßig immer nur einmal gleichzeitig. Weitere Aufrufe bekommen 429, solange er läuft. Erhöhe Max concurrent runs im Workflow-Panel, wenn Aufrufe parallel laufen sollen, oder Max queued runs, wenn sie warten dürfen. Die Warteschlange liegt im Speicher: Ein Neustart verwirft wartende Läufe.
• Läufe werden nicht abgebrochen, wenn der Aufrufer die Verbindung trennt.

Wie Aufrufer Fehler sehen, steht unter Trigger und Webhooks und Fehlerbehandlung.

Execution-Historie

Die letzten 50 Executions je Workflow bleiben in data/executions/ erhalten; Pipe:ExecutionRetention und Pipe:ExecutionRetentionDays (siehe Konfiguration) und das Workflow-Panel ändern das. Schaltest du im Workflow-Panel Save item data of executions aus, werden nur Status, Zähler und Logs gespeichert. Das ist nützlich, wenn Items sensible Daten enthalten.

Laufende Executions liegen im Speicher des Prozesses. Ein Neustart beendet sie, und ein wartender Wait-Node verliert seinen Lauf.

Audit-Log

Die Seite Audit (nur admins) zeigt, wer wann etwas geändert, gelöscht, ausgeführt oder sich angemeldet hat:

Bereich	Aufgezeichnet
Workflow	angelegt, gespeichert (mit Zusammenfassung: Nodes hinzugefügt, entfernt und geändert, Verbindungen, Einstellungen), gelöscht, aktiviert, deaktiviert, verschoben, über die API deployt
Group	angelegt, geändert, gelöscht
Credential	angelegt, geändert, gelöscht; nie die Werte
Variables	die Instanz-Variablen geändert; nur Namen
API key	angelegt, gelöscht
Login	angemeldet; fehlgeschlagene Anmeldungen und abgelehnte API-Schlüssel, höchstens ein Eintrag pro Minute und Adresse, mit der Zahl weiterer Versuche
Execution	von Hand oder über die API gestartet, gestoppt, wiederholt

Getriggerte Läufe stehen nicht im Audit-Log; dafür gibt es die Execution-Historie. Wer ist der Benutzername, api:<Schlüsselname> für die REST API oder anonymous ohne Anmeldung.

Filtere nach Person, Bereich, Objekt-Id und Zeitraum und exportiere das Angezeigte als CSV (Export CSV). Das Workflow-Panel des Editors zeigt unter History die letzten Änderungen des Workflows. Skripte lesen das Log mit GET /api/v1/audit.

Die Einträge liegen als eine Datei mit JSON-Zeilen pro Monat in data/audit/ und werden nach Pipe:AuditRetentionDays (365, in ganzen Monaten) gelöscht. Jeder Eintrag geht zusätzlich ins Anwendungslog (Kategorie gView.Pipe.Audit). Wer den Datenordner schreiben kann, kann die Dateien ändern; brauchst du Nachweise, bewahre die Einträge eines zentralen Log-Systems auf.

Backup

Sichere den ganzen Ordner data, dazu files und scripts, wenn du sie nutzt:

Ordner	Inhalt
data/workflows/	Eine JSON-Datei je Workflow. Geeignet für Git.
data/groups.json	Gruppen der Startseite.
data/credentials/	Credentials, verschlüsselt.
data/keys/	Die Schlüssel, die die Credentials entschlüsseln.
data/executions/	Historie. Optional.

Important

Stelle credentials/ und keys/ gemeinsam wieder her. Ohne die Schlüssel lassen sich gespeicherte Credentials nicht lesen, und du musst sie neu eingeben.

Sichere auch _config (pipe.config, auth.config); dort stehen die Einstellungen und im Anmeldemodus forms die Benutzer. Die Schlüssel in data/keys/ schützen auch die Anmelde-Cookies: Neue Schlüssel melden alle ab.

Für eine konsistente Kopie hältst du die App an oder kopierst, solange nichts läuft. Dateien werden über eine temporäre Datei geschrieben und dann an ihren Platz verschoben.

Updates

ZIP: Entpacke die neue Version neben der alten, halte die alte App an und starte das neue Startskript. data, files und scripts bleiben, wo sie sind. Behalte den alten Versionsordner, bis die neue Version läuft; zum Zurückgehen startest du sein Skript wieder.

Docker: Ziehe das neue Image und erzeuge den Container mit denselben Volumes neu.

Nodes speichern die Version ihrer Parameter und werden automatisch migriert, wenn ein älterer Workflow läuft. Sichere vor einem Update trotzdem data.

Logs

Die App schreibt ins Konsolen-Log (und ins Aspire-Dashboard, wenn du sie mit Aspire startest). Achte im Log auf Plugin-Warnungen beim Start und auf Node-Fehler. Die Log-Stufe stellst du im Abschnitt Logging von appsettings.json ein.