Node-RED
Visueller Integrations- und Transformationslayer.
Node-RED ist ein grafisches Entwicklungswerkzeug für ereignisgesteuerte Anwendungen. In einem browserbasierten Low-Code-Editor werden nach dem Baukastenprinzip vorgefertigte Nodes zu Flows verbunden und anschließend in der integrierten Laufzeit ausgeführt. Die Nodes reagieren auf Nachrichten oder externe Ereignisse, verarbeiten und transformieren Inhalte und geben Ergebnisse an weitere Systeme weiter. Die Open-Source-Software wurde ursprünglich von einem Team bei IBM entwickelt und wird heute als Projekt der OpenJS Foundation gemeinschaftlich weiterentwickelt.
Die visuelle Entwicklung lässt sich gezielt durch eigenen Programmcode ergänzen. Function Nodes führen JavaScript innerhalb eines Flows aus und ermöglichen dadurch individuelle Prüfungen, Berechnungen, Transformationen und Steuerungslogik. Ein Flow kann beispielsweise HTTP-Endpunkte bereitstellen, MQTT-Nachrichten verarbeiten, Datenbanken ansprechen, Dateien verarbeiten oder externe APIs miteinander verbinden.
Die grundlegenden Konzepte sind:
- Nodes reagieren auf Nachrichten oder Ereignisse und übernehmen einen einzelnen Verarbeitungsschritt.
- Messages transportieren Informationen als JavaScript-Objekte zwischen den Nodes.
- Wires verbinden Nodes und bestimmen den Weg der Nachrichten durch den Flow.
- Flows organisieren zusammengehörige Nodes und bilden den ausführbaren Ablauf.
- Subflows kapseln mehrere Nodes als wiederverwendbaren Baustein.
- Configuration Nodes verwalten gemeinsam genutzte Verbindungen und Einstellungen.
- Context speichert Zustände auf Node-, Flow- oder globaler Ebene.
Optional können Projects Flow-Dateien, Abhängigkeiten und weitere Konfigurationen in einem Git-Repository versionieren. Sensible Credentials speichert Node-RED getrennt von der eigentlichen Flow-Definition.
Node-RED in der UDSP
Innerhalb der UDSP bildet Node-RED die Integrations- und Orchestrierungsschicht zwischen heterogenen Datenquellen und den fachlich zuständigen Plattformdiensten. Die Komponente nimmt Daten aus Fachverfahren, APIs, MQTT-Brokern, Dateien oder Datenbanken entgegen und überführt sie in den für das Zielsystem benötigten technischen und fachlichen Aufbau.
Ein Node-RED-Flow trägt damit die Verantwortung für den konkreten Datenweg: Er prüft eingehende Payloads, ordnet Quellfelder einem vereinbarten Datenmodell zu, behandelt fehlerhafte Datensätze und übergibt nur das aufbereitete Ergebnis. Die fachlich führende Datenhaltung bleibt anschließend bei Stellio, FROST, PostgreSQL oder MinIO.
Mehrere Node-RED-Instanzen können Datenwege nach Mandant, Projekt oder Sicherheitsbedarf voneinander trennen. Dadurch bleiben Credentials, Ressourcenlimits, Netzwerkregeln und Releasezyklen eines Integrationsvorhabens unabhängig von anderen Flows steuerbar.
Welche Plattformkomponenten beteiligt sind, bestimmt der jeweilige Flow. Node-RED kann beispielsweise Daten aus MinIO oder PostgreSQL lesen und dorthin schreiben, Quellformate auf NGSI-LD für Stellio abbilden oder Messwerte für den FROST-Server aufbereiten. Keiner dieser Dienste ist eine pauschale Abhängigkeit jeder Node-RED-Instanz. Wird ein projektspezifischer HTTP-Endpunkt veröffentlicht, kann APISIX dessen externen Zugang und Tokenprüfung übernehmen.
Technische Abhängigkeiten
Jede Node-RED-Instanz besitzt einen festen Identitätsbezug. Fachliche Quell- und Zielsysteme bleiben dagegen flowbezogen und sind deshalb keine pauschalen Abhängigkeiten jeder Instanz.
Keycloak
Schützt Editor und Admin API über den instanzbezogenen Keycloak-Client.
Komponente öffnen
APISIX
Veröffentlicht einen projektspezifischen Flow-Endpunkt, wenn dieser von außerhalb des Clusters erreichbar sein soll.
Komponente öffnenKonfiguration und Deployment
Node-RED wird mandanten- beziehungsweise projektbezogen als eine oder mehrere getrennte Instanzen konfiguriert. Das Inventory legt unter anderem Instanzname, Flow-Quelle, Git-Zugang, Netzwerkprofil, Umgebungsvariablen, Ressourcenlimits und Deployment-Strategie fest.
Die verfügbaren Inventory-Felder und zulässigen Werte sind unter Mandanten konfigurieren: Node-RED beschrieben. Projektspezifische HTTP-Endpunkte werden ergänzend unter Weitere Integrationswege eingeordnet.
Rollen und Rechte
Für jede bereitgestellte Node-RED-Instanz erzeugt die UDSP einen eigenen Keycloak-Client mit dem Namen <INSTANZ>-nodered. An diesem Client können Benutzern oder Keycloak-Gruppen zwei Rollen zugewiesen werden:
admin
Vollzugriff auf den Node-RED-Editor und die Admin-API. Die Rolle darf Flows lesen, bearbeiten und deployen sowie die Instanz administrieren.
viewer
Lesender Zugriff auf den Editor und die Admin-API. Die Rolle kann vorhandene Flows einsehen, aber nicht verändern oder deployen.
Der beim Rollout angelegte Plattformadministrator erhält automatisch die Rolle admin. Weitere Benutzer oder Gruppen müssen dem Client der jeweiligen Node-RED-Instanz in Keycloak ausdrücklich als admin oder viewer zugeordnet werden. Eine Rolle an einer Instanz gilt nicht automatisch für weitere Node-RED-Instanzen.
Diese Rollen schützen ausschließlich den Node-RED-Editor und seine Admin-API. Sie bestimmen nicht, auf welche Fachdaten ein laufender Flow zugreifen darf. Dafür verwendet der Flow die in seiner Instanz hinterlegten technischen Credentials, Token und Zielsystemberechtigungen. Auch ein über APISIX veröffentlichter Flow-Endpunkt benötigt eine eigene Zugriffsregel.
Das übergreifende Prinzip zur Vergabe und Weitergabe von Berechtigungen ist unter Rollen- und Rechtekonzept beschrieben.