Werkzeuge & Abläufe · Make
Derselbe Fall. Ein anderer Aufbau.
Make baut Abläufe aus Modulen; dieser Blueprint nutzt neun native Module für dieselbe Aufgabe: Anfrage prüfen, Wiederholung erkennen, Ausgang erzeugen.
7 Anfragen: 3 Aufgaben, 1 Dublette, 3 Fehler
Make läuft nur in der Cloud; dort ist unser Blueprint noch nicht ausgeführt worden.
Nachweisstand im Detail
Die fachliche Regel ist in echter n8n-Laufzeit gemessen: sieben synthetische Anfragen ergeben genau drei Aufgaben, eine Dublette und drei Fehler, Feld für Feld gleich der mitgelieferten Sollmenge. Der Lauf fand in einem isolierten Container ohne Netzzugang statt, und eine absichtlich verfälschte Kopie fällt dabei durch. Er belegt die Regel hinter dem Ablauf, nicht die Make-Umsetzung. Für den Make-Blueprint prüft dieselbe Testdatei maschinell den Aufbau: alle neun Module stammen von Make selbst, und die im Blueprint hinterlegte Eingabe ist dieselbe wie im n8n-Lauf. Make läuft ausschließlich in der Cloud; dort ist unser Blueprint noch nicht ausgeführt worden. Den Import und den ersten Run once machen deshalb Sie. Schritte und erwartete Ausgänge liegen dem Download bei.
Was Sie benötigen
Einen eigenen Make-Testbereich und die Berechtigung, ein neues Szenario anzulegen. Welche Module und Ausführungsmöglichkeiten Ihr Konto zulässt, prüfen Sie dort. Aus dem kostenlosen Download folgt kein kostenloser oder unbegrenzter Make-Tarif.
In einem neuen Szenario beginnen
- Blueprint importieren. Legen Sie ein leeres Szenario an und wählen Sie im Szenario-Builder den Blueprint-Import. Öffnen Sie
make-blueprint.json. - Module kontrollieren. Prüfen Sie die im Download dokumentierten Modulversionen, Felder, Formeln und Zuordnungen. Ein Importdialog ohne Fehler ist noch kein verifizierter Ablauf.
- Nur Testdaten einsetzen. Übernehmen Sie die mitgelieferten synthetischen Eingaben. Verbinden Sie keine Kundentabelle, kein echtes Postfach und keinen Nachrichtenversand.
- Einmal ausführen und Ausgänge öffnen. Verwenden Sie Run once. Prüfen Sie die tatsächlich verarbeiteten Daten an jedem Ergebniszweig und gleichen Sie sie mit der Cloud-Prüfprozedur ab.
Fair vergleichen heißt: denselben Fehler prüfen
Was Sie sehen können
Die Normalisierung und Ergebniszuordnung liegen in lesbaren Ausdrücken in den Modulen. Die Ergebnisliste sammelt Aufgaben, Dubletten und Fehler. Das erleichtert die Prüfung, wenn Sie einen visuellen Ablauf bevorzugen. Ob die konkrete Konfiguration korrekt arbeitet, zeigt erst die Ausführung mit allen Testfällen.
Was Sie zusätzlich klären müssen
Tarifgrenzen, Verbrauch pro realem Vorgang und dauerhafte Zustände sind kontobezogen. Eine Demo mit einer Testliste belegt keine ausfallsichere Dublettensperre zwischen zwei Läufen.
Wir vergeben keine Geschwindigkeitsnote und keinen Testsieger. Dafür fehlen vergleichbare Cloudmessungen mit gleichem Tarif, gleicher Last und denselben angeschlossenen Systemen.
Ein Fehlerzweig braucht einen Empfänger
Öffnen Sie nach jedem Fehlerfall die aggregierte Ergebnisliste und lesen Sie den Datensatz mit seiner Kennung und seinem Status. Für den unterstützten Testvertrag gelten Stapel von 1 bis 100 Anfragen mit Textfeldern. Ein ungültiger Textwert muss ein Fehlerergebnis erhalten. Zusätzliche Eingangsguards für leere Stapel, Übergröße und falsche Datentypen sind in dieser Make-Fassung noch nicht enthalten: Eine leere Liste kann ohne Ausgabe enden. Verwenden Sie den Blueprint deshalb nicht ungeprüft für beliebige fremde JSON-Eingaben. Wenn das spätere Zielsystem nicht erreichbar ist, muss die Anfrage in einer lesbaren Fehlerablage bleiben. Das ist eine zusätzliche Integrationsprüfung.
Bewahren Sie Ihre Cloud-Testresultate getrennt von den Soll-Daten auf. Tragen Sie Konto-/Tarifstand, Datum, Modulversionen und Abweichungen ein. Das gemeinsame Testpaket erklärt die Grenze zwischen erwarteten und beobachteten Ergebnissen.
Cloud, Selbstbetrieb oder manuell abwägen
Mit KI-Unterstützung erstellt; den Inhalt prüft und verantwortet ein menschlicher Herausgeber. So arbeiten wir
