Zum Hauptinhalt springen
Daten integrieren · Eingang

Daten laden

Laden Sie die Rohdaten mit Node-RED kontrolliert aus einer konkreten Quelle in msg.payload. Die Beispiele zeigen denselben fachlichen Datensatz über HTTP, MQTT, S3 und PostgreSQL.

Diese Anleitung beginnt, nachdem Erreichbarkeit, Ressource und – bei einer geschützten Quelle – der technische Lesezugang unter Datenquelle prüfen nachgewiesen wurden. Sie endet bewusst vor dem fachlichen Mapping und dem Schreiben an ein Ziel.

Ladeweg auswählen​

Wählen Sie denselben Quellenweg wie im vorherigen Schritt. Jeder Tab zeigt, welche Node benötigt wird, wie die Quelldaten geladen werden und woran Sie ein verwendbares Ergebnis in msg.payload erkennen.

Die Standard-Node http request ruft den bereits geprüften Endpunkt ab. Das Beispiel übernimmt das items-Array aus der Antwort:

Inject → Function „Abruf vorbereiten“ → http request → Function „Antwort prüfen“

1. Abruf vorbereiten

Setzen Sie Methode, URL und fachliche Parameter in einer Function Node. Das Beispiel lädt einen kleinen, reproduzierbaren Ausschnitt:

Function: Abruf vorbereiten
msg.method = "GET";
msg.url = "https://data.beispiel-organisation.de/v1/traffic-counts"
  + "?updated_since=2026-08-19T07%3A55%3A00Z&limit=100";
msg.headers = {Accept: "application/json"};
return msg;

Konfigurieren Sie http request mit Methode aus msg.method, einer leeren Node-URL für die URL aus msg.url und der Rückgabe als parsed JSON object.

Produktive API-Zugänge nur über einen geprüften Authentifizierungsweg verwenden

Die Administration stellt für geschützte APIs den technischen Client und den abgesicherten Secret- oder Tokenweg bereit. Speichern Sie Client-Secret, Passwort oder langlebiges Token weder in einer Function Node noch in msg. Verwenden Sie auch die Credentialfelder der HTTP-Node erst, wenn deren Schutz für die konkrete Node-RED-Instanz geprüft wurde. Kurzlebige Access Tokens dürfen nur im vorgesehenen Authentifizierungspfad verarbeitet und niemals im Debug-Fenster ausgegeben werden.

2. Status und Antwort prüfen

Die Function Node hinter http request akzeptiert nur die erwartete Antwort und legt das fachliche Array in msg.payload ab:

Function: Antwort prüfen
if (msg.statusCode !== 200) {
  throw new Error(`API-Abruf fehlgeschlagen: HTTP ${msg.statusCode}`);
}

const rows = msg.payload?.items;
if (!Array.isArray(rows)) {
  throw new Error("API-Antwort enthält kein items-Array");
}

msg.payload = rows;
msg.source = {type: "http", receivedAt: new Date().toISOString()};
return msg;

Soweit die API diese Mechanismen verwendet, muss der produktive Flow außerdem Pagination, Rate Limits und 429 Too Many Requests behandeln. Wiederholen Sie Fehler nur begrenzt und schreiben Sie den nächsten Abrufzeitpunkt erst nach erfolgreicher Verarbeitung fort. Debuggen Sie Status, Lauf-ID und eine ungefährliche Fehlerbeschreibung – nicht das Access Token oder die vollständige Antwort.

Die HTTP-Daten sind geladen, wenn

msg.statusCode den erwarteten Erfolg anzeigt und msg.payload das fachliche Array der Beispielantwort enthält. Fehlerstatus müssen in einen kontrollierten Fehlerpfad laufen, statt als leere Datenlieferung weiterverarbeitet zu werden.

Passende Referenzen

Gemeinsamer Ausgang der vier Beispiele​

Nach jedem Beispiel enthält msg.payload ein Array mit demselben Rohdatenvertrag:

[
  {
    "counting_station_id": "zaehlstelle-017",
    "observed_at": "2026-08-19T08:00:00Z",
    "vehicle_count": 126
  }
]

Die einheitliche Schreibweise hält den Beispielweg über HTTP, MQTT, S3 und PostgreSQL vergleichbar. Liefert eine reale Quelle andere Feldnamen oder eine andere Struktur, wird diese Abweichung im nächsten Schritt ausdrücklich als Mapping behandelt.

Fahren Sie mit Daten verarbeiten fort. Dort werden Pflichtwerte und fachliche Regeln geprüft. Wenn Quell- und Zielstruktur voneinander abweichen, wird das Mapping als Teil dieser Verarbeitung festgelegt und umgesetzt. Der validierte Ausgang wird anschließend unter Daten speichern an das vereinbarte Ziel geschrieben.

Allgemeine Referenzen​