1

Make.com - Problem mit IDs als "Variablen"

Ich verwende zahlreiche, relativ umfangreiche Make-Szenarien mit teils dutzenden Ninox-Nodes. Wenn diese Szenarien dupliziert und für eine andere Datenbank verwendet werden sollen, möchte ich es künftig vermeiden, jedes Ninox-Node anzufassen, um das statisch ausgewählte Team, die Datenbank, und ggf. die Tabelle ändern zu müssen.

 

Idee ist es also, im ersten Node Team und Datenbank statisch festzulegen, um dann alle erforderlichen Variablen (TeamID, databaseID, tableID´s) als Make-Variablen zu mappen, weil diese in der Datenbank abgelegt sind und abgerufen werden.

Das scheint allerdings nicht zu funktionieren. Obwohl die TeamID und DatabaseID absolut korrekt in der Datenbank hinterlegt sind und mit dem ersten Node abgerufen werden, können die nachfolgenden Nodes damit nicht umgehen.

Ein Node (lookup record) lädt beispielsweise kein einziges Datenfeld.

Ein anderes Node (update record) bringt eine Fehlermeldung, dass das Team gar nicht existieren würde.

Hat jemand eine Idee, was ich falsch mache? Vielen Dank vorab.

Ralf

4 Antworten

null
    • T_Bartzsch
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Wie sehen denn die abgerufenen Daten eines erfolgreich ausgeführten Flows aus? Ich meine mich zu erinnern, dass Make beim abrufen zB. einer Datensatz ID ( Nr) statt zB. 43  ... B/43 macht und man die im ersten Node abgefragten Daten im späteren Verlauf dann zB mit parseNumber(VARIABLE) weiter behandeln muss...

      • Icarus_Ralf_Becker
      • vor 1 Jahr
      • Gemeldet - anzeigen

      T. Bartzsch das mag ja sein, aber ich frage ja gar keine record IDs ab, sondern TeamID, databaseID und tableID. Diese will ich in anderen Nodes gemappt und anstelle der statischen Auswahl verwenden. Und das geht nicht. Hat also nix mit dem Format der record IDs zu tun. Oder ich habe deinen Tipp nicht richtig verstanden. 

      • T_Bartzsch
      • vor 1 Jahr
      • Gemeldet - anzeigen

      Icarus - Ralf Becker das mit der RecordID war ja nur ein Beispiel... deshalb fragte ich ja nach der Datenausgabe eines Flows. Vielleicht sieht die TeamID augenscheinlich gut aus, muss aber evtl. mit parseNumber oder parseText usw. umgewandelt werden, damit die Variable innerhalb des Flows im korrekten Format vorliegt. Das soll nur ein Denkanstoss sein, keine Lösung ;)

    • Selbständig
    • Fabian_Wieland
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Hi Ralf, den Sachverhalt habe ich auch schon festgestellt. Die Module funktionieren scheinbar nicht mit dynamischen Werten. Meine - leider sehr technische - Alternative war daher, alle Module durch ein Ninox-Modul MAKE AN API CALL oder gar durch ein allgemeines HTTP-REQUEST-Modul zu ersetzen. Um auf einen Record zuzugreifen, nutzt du dann z. B: dieses MAKE AN API CALL Modul:

Anmelden, um zu antworten

Content aside

Kategorien

Alle Themen anzeigen
  • 1 „Gefällt mir“ Klicks
  • vor 1 JahrZuletzt aktiv
  • 4Antworten
  • 73Ansichten
  • 5 Folge bereits