Zum Inhalt springen

Wiki-Quellcode von N8n Workflow Engine

Version 17.2 von Daniel Herrmann am 2026/02/22 21:09
Verstecke letzte Bearbeiter
Daniel Herrmann 1.1 1 n8n ist ein **Open-Source-Tool zur Workflow-Automatisierung**, das man selbst hosten kann. Über eine **visuelle Oberfläche** baut man Workflows per Drag-and-drop aus sogenannten „Nodes“, die verschiedene Dienste und Aktionen miteinander verbinden. Es gibt Hunderte vorgefertigte Integrationen, z. B. für Slack, Mail oder MQTT. Ebenfalls gibt es eine große Auswahl an für uns relevante Community Nodes (Vikunja, Listmonk, und so weiter) sowie die Möglichkeit, eigene Nodes zu schreiben (beispielsweise Paperless oder NATS).
2
Daniel Herrmann 9.1 3 = Inhaltsverzeichnis =
4
5 {{toc/}}
6
Daniel Herrmann 3.1 7 = Workflow Übersicht =
Daniel Herrmann 1.1 8
Daniel Herrmann 3.2 9 Workflows bestehen grundsätzlich aus einem oder mehreren **Triggern** und einer oder mehreren **Aktionen**. Im Folgenden werden nur die für die Mitgliederverwaltung relevanten Workflows beschrieben, N8n kann aber natürlich auch für andere Automatisierung verwendet werden.
10
Daniel Herrmann 3.4 11 == Workflows für Dokumente ==
12
13 === Document Consumed Workflow ===
14
Daniel Herrmann 14.1 15 Dieser Workflow wird durch das [[Paperless Post-Consume Script>>doc:PROJ.Digitale Mitgliederverwaltung.Paperless NGX.WebHome]] ausgelöst, immer dann, wenn ein **QR Code mit dem korrekten Inhalt **erkannt wird. Die Idee hier ist, dass **ausgedruckte und handschriftliche Dokumente **automatisch verarbeitet werden können.
Daniel Herrmann 3.4 16
Daniel Herrmann 14.1 17 Im Prinzip ersetzt dieser Workflow den Docuseal Webhook, der automatisch dem Backend bescheid gibt, wenn alle Parteien unterschrieben haben. Bei ausgedruckten Dokumenten passiert dies stattdessen hierüber.
18
19 [[image:1771785973968-394.png||height="150"]]
20
21 Der Workflow:
22
23 * wird über ein Webhook vom Post Consume Script ausgelesen. Als Inhalt wird der Inhalt des dekodierten QR Codes übergeben
24 * nur handschriftlich unterschriebene Dokumente werden verarbeitet
25 * dem Backend wird signalisiert, dass das Dokument erfolgreich verarbeitet wurde
26
27 Als Konsequenz kann das Backend weitere automatische Aktionen ausführen, beispielsweise vorläufige oder dauerhafte Berechtigungen eintragen.
28
Daniel Herrmann 3.4 29 === Paperless Papierkorb ===
30
Daniel Herrmann 14.1 31 **In Paperless kann nur der Owner Dokumente in den Papierkorb verschieben**. Dies lässt sich leider nicht anders konfigurieren, sodass wir uns hier mit einem Workaround behelfen: die Mitgliederverwaltung und/oder der Vorstand können dem Dokument **ein Tag zuweisen**. **Dieses Tag löst einen Workflow in Paperless aus:**
Daniel Herrmann 3.4 32
Daniel Herrmann 14.1 33 [[image:1771786279823-587.png||height="250"]]
34
35 Dieser Workflow löst zwei Dinge aus (leider ist Dokument löschen keine verfügbare Aktion):
36
37 * er entfernt das Tag wieder, um Rekursion zu vermeiden
38 * und löst ein N8n Webhook aus
39
40 **Der N8n Workflow löscht dann das Dokument.**
41
42 [[image:1771786234093-932.png||height="150"]]
43
Daniel Herrmann 3.4 44 == Cron Jobs - Sync von Daten ==
45
Daniel Herrmann 3.3 46 === Sync Tags für Einweisungen ===
47
Daniel Herrmann 16.1 48 In Paperless unterscheiden wir verschiedene Arten von Dokumente, diese sind [[hier im Wiki beschrieben>>doc:PROJ.Digitale Mitgliederverwaltung.WebHome]]. Es wäre aber nicht zweckmäßig, für jede Einweisung ebenfalls einen eigenen Typ zu erzeugen, daher verwenden wir Tags. **Dieser Workflow liest die verfügbaren Einweisungen vom Backend der Homepage aus und erzeugt die Tags.**
Daniel Herrmann 14.2 49
Daniel Herrmann 16.1 50 [[image:1771790486089-157.png||height="150"]]
Daniel Herrmann 3.3 51
Daniel Herrmann 16.1 52 Dieser Workflow **regelmäßig als Cronjob ausgeführt**.
53
54 * liest verschiedene Informationen aus Paperless aus
55 ** Alle Gruppe, und findet die ID der Gruppen für Mitgliederverwaltung und IT-Admins
56 ** Alle User, und findet die ID des MV Owner Users
57 ** Alle bestehenden Tags
58 * Dann werden die verfügbaren Einweisungen aus dem Backend ausgelesen
59 * Im Merge Node werden Tags herausgefiltert, die noch nicht in Paperless existieren
60 * Diese werden dann erzeugt.
61
Daniel Herrmann 3.3 62 === Sync Document Types ===
63
Daniel Herrmann 17.2 64 Die verfügbaren Dokumenten-Typen werden [[in Directus verwaltet>>https://assets.makerspace-darmstadt.de/admin/content/paperless_document_types]], und können dort einfacher verändert werden. Dieser Workflow synchronisiert die Dokumenten-Typen ähnlich der Tags für Einweisungen.
65
66 [[image:1771790995906-398.png]]
67
Daniel Herrmann 3.3 68 ToDo
69
Daniel Herrmann 3.4 70 == Backend Event Workflows ==
Daniel Herrmann 3.3 71
Daniel Herrmann 3.5 72 Bestimmte Events aus dem Backend werden über NATS als Event gepublished. Details dazu sind auf der [[Seite zu NATS>>doc:PROJ.Digitale Mitgliederverwaltung.Technische Dokumentation.NATS Setup.WebHome]] beschrieben. Hier werden die Events beschrieben, die Paperless betreffen:
Daniel Herrmann 1.1 73
Daniel Herrmann 4.1 74 === mksp.docuseal.signature.completed ===
Daniel Herrmann 3.5 75
Daniel Herrmann 9.2 76 Dieses Event wird ausgelöst, wenn im Backend ein Signatur-Prozess abgeschlossen ist (d.h. alle Parteien haben unterschrieben und die Unterschrift wurde im Backend erfasst). Dies kann auf zwei Arten passieren:
Daniel Herrmann 3.3 77
Daniel Herrmann 14.1 78 * Bei **rein digitalen Signaturen** durch einen über **Docuseal ausgelösten Webhook**
79 * Bei **handschriftlich** unterschrieben Zetteln durch **Einscannen** und den oben beschrieben **"Document Consumed" N8n Workflow**
Daniel Herrmann 9.2 80
Daniel Herrmann 14.1 81 [[image:1771785764191-239.png||height="150"]]
82
83 **Der Workflow löst nur bei digitalen Dokumenten eine Aktion aus**. Bei handschriftlich unterschriebenen Dokumenten ist das Dokument bereits eingescannt. Für digital unterschriebene Signaturen:
84
85 * wird der Status der Submission aus Docuseal ausgelesen
86 * wird das PDF mit den Unterschriften aller Parteien runtergeladen...
87 * und anschließend in Docuseal hochgeladen und dort verarbeitet.
88
Daniel Herrmann 4.1 89 === mksp.backend.user.created ===
Daniel Herrmann 3.5 90
Daniel Herrmann 5.3 91 Dieser Workflow wird immer dann getriggert, wenn im Backend ein **neuer User** angelegt wird. Die Informationen aus der NATS Nachricht werden dann verwendet, um den **Korrespondenten in Paperless anzulegen**.
Daniel Herrmann 3.5 92
Daniel Herrmann 5.2 93 [[image:1771784637258-114.png||height="200"]]
94
Daniel Herrmann 5.3 95 Die folgenden Aktionen werden ausgeführt:
Daniel Herrmann 5.2 96
Daniel Herrmann 8.1 97 1. Parallel werden **alle Gruppen und Benutzer **aus Paperless ausgelesen
98 1. Es wird auf die relevanten Gruppen und Benutzer gefiltert. Ziel ist es, **die ID der entsprechenden Gruppen und Benutzer auszulesen**. Wir sind **interessiert an den Gruppen für die Mitgliederverwaltung und die IT Admins** sowie dem statischen **MV Owner**.
99 1. Zuletzt wird der Subflow "Create Paperless Correspondent" angelegt. Dieser bekommt als Info:
100 11. **firstname** - aus NATS Trigger
101 11. **lastname** - aus NATS Trigger
102 11. **isGuest** - true wenn membership_number in NATS Trigger = null, false otherwise
103 11. **membership_number** - aus NATS Trigger
104 11. **user_id** - aus NATS Trigger
105 11. **owner_id** - ID des MV Data Owner Benutzers
106 11. **permissions** - siehe unten
107 11. **backend_url** - URL des Makerspace Backends
Daniel Herrmann 5.3 108
Daniel Herrmann 8.1 109 Der Subflow erzeugt dann den Display-Namen des Korrespondenten und **speichert die Paperless-ID über die Backend-API zurück ins Backend.** Der **Display-Name **setzt sich wie folgt zusammen:
110
111 |=Nutzer-Typ|=Format|=Beispiel
112 |Mitglied|Vorname Nachname (#Mitgliedsnummer)|Daniel Herrmann (#250)
113 |Gast|Vorname Nachname (Gast #Nutzer-ID)|Daniel Herrmann (Gast #1)
114
115 Die **Berechtigungen** werden dabei wie folgt gesetzt:
116
117 {{code language="none"}}
118 {"view":{"users":[],"groups":[{{ $('Static Data').item.json.mv_group_id }}]},"change":{"users":[],"groups":[{{ $('Static Data').item.json.it_admin_group_id }}]}}
119 {{/code}}
120
121 D.h. Owner (und damit alle Rechte) hat der statische MV Owner Nutzer. Alle Mitglieder der Gruppe "Mitgliederverwaltung" können den Korrespondenten sehen (notwendig für Zuweisung und Filterung), IT-Admins können diese verändern.
122
Daniel Herrmann 4.1 123 === mksp.backend.user.converted_to_guest ===
Daniel Herrmann 3.5 124
Daniel Herrmann 8.1 125 Dieser Workflow wird dann ausgelöst, wenn ein Mitglied den Verein verlässt und daher zum Gast wird.
Daniel Herrmann 4.1 126
Daniel Herrmann 8.1 127 [[image:1771785245954-780.png||height="150"]]
128
129 Alle notwendigen Daten (inklusive der Paperless Korrespondent-ID) sind im NATS Event vorhanden. Es wird also lediglich ein neuer Display-Name erzeugt (Format: siehe Tabelle oben) und der Korrespondent wird aktualisiert.
130
Daniel Herrmann 4.1 131 === mksp.backend.user.converted_to_member ===
132
Daniel Herrmann 9.1 133 Dieser Workflow wird dann ausgelöst, wenn ein neues Mitglied dem Verein beitritt.
Daniel Herrmann 8.1 134
135 [[image:1771785309574-242.png||height="150"]]
136
137 Alle notwendigen Daten (inklusive der Paperless Korrespondent-ID) sind im NATS Event vorhanden. Es wird also lediglich ein neuer Display-Name erzeugt (Format: siehe Tabelle oben) und der Korrespondent wird aktualisiert.
138
139 == Subflows ==
140
Daniel Herrmann 4.1 141 ToDo
142
Daniel Herrmann 3.1 143 = Community Nodes =
Daniel Herrmann 1.1 144
145 asd