Hallo zusammen,
Ich suche nach einer Möglichkeit, zur Laufzeit dynamisch zu bestimmen, welche gespeicherte Anmeldedaten ein Knoten verwendet, basierend auf Daten im Workflow (zum Beispiel ein eingehendes Feld wie „cluster
Hey @ntoll01, während du auf eine Antwort wartest, findest du hier ein paar hilfreiche Ressourcen:
Vorgeschlagene Ressourcen
Automatisch zu deiner Frage abgestimmt.
Dokumentation:
Forum:
@jabbson, @Anshul_Namdev, @Ezequiel_Perez_Rovir - ihr habt bei ähnlichen Problemen schon geholfen, könnt ihr da mal schauen?
Automatisch vorgeschlagen von n8ns Community-Bot. Das ist ein Pilotprojekt – gib hier bitte Feedback.
Hallo @ntoll01 ,
Es gibt keine dynamische Option zur Auswahl einer Anmeldeinformation. Du kannst jedoch einen Unter-Workflow erstellen, der einen Knoten mit einer vordefinierten Anmeldeinformation basierend auf Kriterien deiner Wahl auslöst.
Z. B. habe ich mehrere HTTP-Knoten mit eigenen Anmeldeinformationen, die Vorgänge automatisch basierend auf der Eingabe verarbeiten
Hi @ntoll01
Der wählbare Teil kann der Sub-Workflow sein, anstatt der Anmeldedaten. Ein Workflow pro Cluster, jeder mit einem einzelnen Node, der die Anmeldedaten des Clusters enthält, aufgerufen vom Triage-Workflow mit Execute Sub-workflow auf Source: Database gesetzt und einem Ausdruck im Feld Workflow ID, der den eingehenden Cluster-Namen seiner ID zuordnet. Das Hinzufügen eines Clusters ist dann ein neuer Workflow plus eine Zeile in dieser Map, ohne dass auf der Triage-Seite etwas wächst.
Jeder dieser Sub-Workflows benötigt die Einstellung „This workflow can be called by
Hi @ntoll01
Nicht nativ unterstützt. Du kannst keinen Ausdruck auf dem Credential Picker platzieren, und die Feature Request dafür ist seit 2021 offen. Native Nodes sperren die Credential zur Designzeit.
Das kannst du stattdessen tun:
Wenn du Enterprise nutzt, schau dir Dynamic Credentials und External Secrets an. Das ist die richtige Version von dem, was du beschreibst – Credentials werden zur Laufzeit aufgelöst statt auf dem Node festgelegt.
Wenn nicht, gibt es einen Workaround mit n8ns eigener API, um Credentials während der Ausführung zu wechseln: Workaround for Dynamic Credentials in n8n (Using the Built-in API)
Für Elastic gibt es speziell eine einfachere Option. Nutze stattdessen einen HTTP Request Node anstelle des Elastic Nodes, speichere jeden Cluster-Endpunkt und Schlüssel in einer Nachschlagetabelle und setze den Auth Header durch einen Ausdruck. Du verlierst die Convenience des Nodes, aber ein Node verwaltet alle Cluster. Der Kompromiss ist, dass der Schlüssel in den Ausführungsdaten sitzt statt im Credential Store, was angesichts dessen, was du über die verwalteten Secrets gesagt hast, möglicherweise nicht akzeptabel ist.
Nutzt du Enterprise? Das entscheidet, welche dieser Optionen dir tatsächlich offensteht.
Danke an alle für die Antworten.
@barn4k Ich habe über mehrere HTTP-Knoten nachgedacht, aber in unserer Situation haben wir 5 HTTP-Knoten zum Erstellen des Falls, zum Hinzufügen von Alerts, zum Festlegen des Status usw. Für 4 Cluster sind das bereits 20 HTTP-Knoten.
@Lopez Wir haben eine Business-Lizenz, daher leider keine Möglichkeit, External Secrets zu verwenden. Ich habe mir den Workaround angeschaut und er sieht vielversprechend aus, werde mich da näher damit befassen.
@Anshul_Namdev Das wird wahrscheinlich unser erster Workaround sein, mit einem Router-Workflow mit Sub-Workflows pro Kunde.
@n8n Gibt es derzeit eine technische Herausforderung, einen Ausdruck auf den Credential Picker zu setzen? Alle diese Workarounds scheinen viel komplexer zu sein als ein Problem, das einfach mit einem Ausdruck gelöst werden könnte, und die Skalierbarkeit unserer API-Aufrufe wäre damit viel besser.