In diesem Beitrag
Odoo und n8n: Aufträge idempotent anlegen
Angenommen, Odoo hat den Auftrag gespeichert. Die Antwort erreicht n8n jedoch nicht. Ein Mitarbeiter sieht eine fehlgeschlagene Ausführung und startet sie erneut. Dein Wiederanlauf entscheidet jetzt, ob aus dem Kauf ein Auftrag oder zwei werden.
Damit du das Anlegen eines Odoo-Auftrags sicher wiederholen kannst, braucht der beabsichtigte Vorgang eine dauerhafte Identität, die das schreibende Zielsystem durchsetzt. Kläre nach einer ungewissen Antwort zuerst das Ergebnis im Ziel. Verwende bei Wiederholungen denselben Schlüssel und dieselben Nutzdaten. Geänderte Inhalte oder ungeklärte Ergebnisse gehen zur Prüfung, statt einen weiteren Datensatz auszulösen.
Idempotenz bedeutet, dass eine Wiederholung dasselbe beabsichtigte Geschäftsergebnis hinterlässt. Diese Eigenschaft muss der implementierte Vorgang besitzen. Eine Einstellung für erneute Versuche stellt sie allein nicht her.
Recherchestand: 5. November 2026. Produktangaben beruhen auf offiziellen Quellen zu Odoo 20 und n8n. Wir haben zehn synthetische Python/SQLite-Fälle ausgeführt, darunter eine absichtlich verworfene Antwort nach einem lokalen Commit. Odoo, n8n und PostgreSQL liefen dabei nicht. Wir haben weder ein laufendes Netzwerk unterbrochen noch eine Kundenintegration vermessen.
Warum kann nach einem n8n-Fehler bereits ein Odoo-Datensatz existieren?
Nach einem n8n-Fehler kann bereits ein Odoo-Datensatz existieren, weil das Ziel den Schreibvorgang beendet, bevor der Aufrufer die Antwort erhält. Behandle eine verlorene Antwort als ungeklärtes Ergebnis, bis Nachweise den Zustand auflösen. Die Fehleranzeige beschreibt die beobachtete Ausführung. Sie beweist nicht, dass alle vorherigen Geschäftseffekte zurückgenommen wurden.
In unserem Beispiel fordert der Shop für Gesellschaft A einen Auftrag mit Quellreferenz SO-77 über 125,00 € an. Das Ziel legt den Datensatz an, danach geht die Antwort verloren. Eine normale Create-Anfrage erneut zu senden, kann einen zweiten Datensatz für denselben Kauf erzeugen. Dieser Versuch kann erfolgreich antworten, obwohl bereits ein Duplikat entstanden ist.
Die n8n-Dokumentation zu Retry On Fail beschreibt automatische Wiederholungen und die Wartezeit zwischen Versuchen. Diese Einstellungen bestimmen den Zeitpunkt des nächsten Versuchs. Was eine Wiederholung fachlich bedeutet, muss der empfangende Vorgang festlegen.
Auch der umgekehrte Fehler zählt. Ein Workflow speichert vor dem Anlegen des Auftrags den Status „verarbeitet“ und bricht dazwischen ab. Beim Wiederanlauf überspringt er den Vorgang wegen dieses Eintrags. Es gibt kein Duplikat, aber auch keinen Auftrag. Trenne den Empfang vom Abschluss und prüfe den Zieldatensatz, bevor du den Vorfall schließt.
Welcher Schlüssel kennzeichnet genau einen neuen Odoo-Auftrag?
Kennzeichne das beabsichtigte Anlegen eines Odoo-Auftrags mit einem dauerhaften Geschäftsschlüssel für die Quelle und die zuständige Gesellschaft. Bewahre die freigegebenen Nutzdaten dazu auf. Zustellungs- und Ausführungs-IDs kennzeichnen Versuche, nicht zwingend den Kauf dahinter. Lege vor automatischen Wiederholungen fest, wie sich eine erlaubte Änderung von einer erneuten Zustellung unterscheidet.
Der folgende Vertrag ist ein Vorschlag. Die Feldnamen sind keine eingebauten Odoo-Felder und versprechen nicht, dass Odoo einen bestimmten HTTP-Header auswertet.
| Feld | Beispiel | Zweck |
|---|---|---|
| Quelle und Gesellschaft | shop, A | Unabhängige fachliche Eigentümer in getrennten Namensräumen halten. |
| Geschäftsreferenz der Quelle | SO-77 | Den Kauf über Zustellungen und manuelle Wiederholungen hinweg erkennen. |
| Befehl und Revision | create_draft_order, 1 | Diese Erstellung von einer später freigegebenen Änderung oder einer anderen Geschäftsaktion unterscheiden. |
| Fingerabdruck der Nutzdaten | Prüfwert der vereinbarten Geschäftsfelder | Denselben Schlüssel mit verändertem Inhalt zurückweisen. |
| Referenzen der Versuche | Webhook-Zustellungs-ID und n8n-Ausführungs-ID | Einzelne Versuche nachvollziehen, ohne daraus jeweils einen neuen Kauf zu machen. |
| Nachweis im Ziel | Odoo-Datensatz-ID, Gesellschaft und abgenommener Zustand | Zeigen, welcher Datensatz den Vorgang erfüllt hat. |
Der Idempotenz-Leitfaden von n8n weist darauf hin, dass manuelle Wiederholungen oder erneute Auslösungen eine neue execution.id erhalten. Für die Wiederaufnahme über mehrere Läufe empfiehlt er Schlüssel aus den Eingabedaten. Speichere die Geschäftsidentität dauerhaft, bevor dein Wiederanlauf davon abhängt.
Lege fest, welche Felder in den Prüfwert eingehen. Ein anderer Betrag oder eine andere Währung darf nicht hinter derselben Auftragsnummer verschwinden. Zustellungsmetadaten, die sich bei jedem Versuch ändern dürfen, gehören nicht hinein. Normalisiere nur nach vereinbarten Regeln: Führende Nullen aus einer Kundenkennung zu entfernen, kann deren Bedeutung ändern.
Im Modell liefert die Wiederholung mit 125,00 € den ursprünglichen Datensatz zurück. Derselbe Schlüssel mit 130,00 € erzeugt einen Inhaltskonflikt; der ursprüngliche Betrag bleibt erhalten. Ein Verantwortlicher muss klären, ob die neue Eingabe eine Korrektur, eine freigegebene Revision oder einen Fehler der Quelle darstellt.
Wo muss die Integration Duplikate verhindern?
Verhindere Duplikate an der Stelle, die den Geschäftsdatensatz verbindlich speichert. Der empfangende Vorgang muss den Schlüssel beanspruchen und sein Ergebnis konsistent mit dem Datensatz festhalten. Eine getrennte n8n-Tabelle kann Versuche koordinieren. Sie kann einen späteren Odoo-Schreibvorgang allein aber nicht in dieselbe Datenbanktransaktion aufnehmen.
Laut offizieller JSON-2-Transaktionsbeschreibung laufen Aufrufe in getrennten Transaktionen. Zusammengehörige Schritte, die eine Transaktion benötigen, sollen in einer Servermethode ausgeführt werden. Der bestehende Leitfaden zur Odoo-API-Architektur behandelt die Hosting- und Protokollgrenzen der möglichen Umsetzung.
Eine eigene empfangende Methode könnte den aktuellen Aufrufer prüfen, einen Vorgangseintrag lesen, den erlaubten Datensatz bei Bedarf erstellen und das Ergebnis in einer Transaktion speichern. Gleichzeitige Anfragen muss sie ebenfalls sicher auflösen. Eine Suche nach SO-77 vor dem Anlegen reicht nicht: Zwei Worker können beide suchen, bevor einer schreibt.
Die Referenz des n8n-Odoo-Nodes nennt CRUD-Operationen für Custom Resources. Das belegt keinen Vertrag zur wiederholbaren Erstellung. Prüfe den installierten Node und die empfangende Methode. Ein Header Idempotency-Key hilft nur, wenn der Empfänger ihn implementiert.
Kannst du einen solchen Vertrag nicht umsetzen oder nachweisen, dokumentiere die schwächere Zusage. Kontrollierte Serialisierung und Abfragen im Ziel können Unsicherheit verringern. Dafür müssen jedoch alle schreibenden Pfade und Wiederholungen dieselben Regeln beachten. Bleibt „nicht angelegt“ von „angelegt, aber noch nicht gefunden“ ununterscheidbar, braucht der Vorgang eine Untersuchung.
Externe Effekte haben eigene Grenzen. Ein zusammen mit dem Auftrag gespeicherter Eintrag beweist nicht, dass eine spätere E-Mail genau einmal versendet wurde. Der Leitfaden zur Wiederherstellung nach doppelten E-Mail-Versuchen behandelt diesen separaten Vorgang. Eine Zusage zur Auftragserstellung darf Versand oder Zahlung nicht stillschweigend einschließen.
Was zeigen die zehn lokalen Fehlerfälle?
Die zehn lokalen Fälle zeigen, dass die Vermeidung von Duplikaten und die Wiederaufnahme fehlender Arbeit unterschiedliche Nachweise brauchen. Das Modell erzeugte sowohl doppelte als auch fehlende Datensätze und stellte danach den ursprünglichen Datensatz über einen atomaren Vorgangseintrag im Ziel wieder bereit. Alle Erwartungen trafen ein. Die Ergebnisse gelten für unser Python/SQLite-Modell einschließlich seiner Sperrlogik, nicht für Odoo oder n8n.
Das Zielmodell enthält eine Auftragstabelle und eine Tabelle für Vorgangseinträge in derselben SQLite-Datenbank. Im erfolgreichen Pfad schreibt es beide in einer Transaktion. Ein Fehlerpunkt verwirft absichtlich die Antwort nach dem Commit; ein anderer unterbricht davor. Der Parallelfall startet zwei lokale Worker. Der unsichere Suchfall verwendet eine dokumentierte Reihenfolge überlappender Lese- und Schreibschritte.
| Fall | Erwartete Beobachtung | Beobachtet |
|---|---|---|
| Blinde Wiederholung nach dem ersten Commit | Zwei Datensätze für eine beabsichtigte Erstellung | 2 Datensätze |
| „Verarbeitet“ vor dem Effekt gespeichert, danach Unterbrechung | Wiederanlauf überspringt fehlende Arbeit | 0 Datensätze |
| Zwei Suchen enden vor dem ersten ungeschützten Anlegen | Beide Versuche legen einen Datensatz an | 2 Datensätze |
| Atomarer Eintrag im Ziel, Antwort nach Commit verloren | Wiederholung liefert den ursprünglichen Entwurf | 1 Datensatz; dieselbe ID |
| Gleicher Vorgangsschlüssel, geänderter Betrag | Konflikt; ursprünglicher Datensatz bleibt unverändert | Konflikt; 125,00 € bleiben erhalten |
| Gleiche Quellreferenz in getrennt autorisierten Gesellschaften A und B | Ein unabhängiger Datensatz je Gesellschaft | 2 Datensätze in getrennten Namensräumen |
| Wiederholung nach Entzug der Berechtigung für A | Aktuelle Berechtigung verhindert den Zugriff | Abgewiesen |
| Fehler vor dem Commit der atomaren Transaktion | Kein gespeicherter Datensatz; Wiederholung erzeugt einen | 0 vor Wiederholung; 1 danach |
| Zwei gleichzeitige Anfragen an das geschützte Modellziel | Beide erhalten denselben Datensatz | 1 Datensatz; dieselbe ID |
| Lokaler Vorgangseintrag vorhanden, Zielabfrage nicht eindeutig | Ergebnis bleibt ungeklärt | unknown |
Lade das ausführbare Wiederholungsmodell und die protokollierten Modellergebnisse herunter. Speichere die Python-Datei lokal und führe sie aus:
python3 retry-model.pyDas Skript verwendet temporäre lokale Datenbanken und kein Netzwerk. Es ist kein Odoo-Modul. Sein Zustand draft ist ein eigenes Modellfeld. Der Lauf hat in Odoo weder ein Angebot erstellt noch Bestand reserviert, Buchungen vorgenommen oder Nachrichten versendet. Prüfe damit deinen Entwurf und teste anschließend die tatsächliche empfangende Operation.
Wie klärst du ein unbekanntes Ergebnis?
Kläre ein unbekanntes Ergebnis, indem du den beabsichtigten Vorgang zuerst mit Nachweisen im Ziel abgleichst. Prüfe die aktuelle Berechtigung und die Nutzdatenrevision erneut. Behalte den ursprünglichen Schlüssel während der Untersuchung bei. Liefert die Abfrage keinen eindeutigen Nachweis, bleibt der Zustand UNKNOWN mit einem zuständigen Bearbeiter. Fehlende Belege dürfen keine neue Erstellung rechtfertigen.
| Nachweis | Entscheidung | Nächster Schritt |
|---|---|---|
| Ein passendes Zielergebnis mit freigegebener Gesellschaft und Inhalt | Erstellung abgeschlossen | Zielreferenz speichern und nur separat autorisierte Folgeschritte fortsetzen. |
| Gleicher Schlüssel mit geändertem Geschäftsinhalt | Konflikt | Revision prüfen; beim Wiederanlauf das ursprüngliche Ergebnis nicht überschreiben. |
| Mehr als ein Treffer im Ziel | Duplikatvorfall | Weitere Schreibvorgänge stoppen und abhängige Datensätze vor einer Korrektur untersuchen. |
| Aktueller Aufrufer hat keine Berechtigung mehr | Gesperrt | Über den zuständigen Eigentümer eskalieren, ohne erhöhte Zugangsdaten wiederzuverwenden. |
| Kein eindeutiges Zielergebnis | Ungeklärt | Eine nachweislich wiederholbare Zieloperation nutzen oder vor erneutem Anlegen manuell untersuchen. |
„Erstellung abgeschlossen“ ist ein Integrationsergebnis. Daraus folgt kein Auftrag, ein Angebot zu bestätigen oder eine Rechnung zu buchen. Halte den Lebenszyklus des Vorgangseintrags vom Zustand des Geschäftsdatensatzes getrennt.
Ein n8n-Fehlerworkflow wird einem Workflow zugeordnet und beginnt mit Error Trigger. Leite damit den Vorgangsschlüssel und die Zielnachweise an den Verantwortlichen weiter. Eine Wiederholungswarteschlange braucht begrenzte Versuche und einen sichtbaren ungeklärten Zustand. Eine Meldung allein repariert den Schreibvorgang nicht.
Dokumentiere den Suchbereich. Eine Suche unter der falschen Gesellschaft oder einer eingeschränkten Rolle kann keinen sichtbaren Treffer liefern, obwohl der Datensatz existiert. Der Bearbeiter braucht die Quellreferenz, die genaue Zielidentität und Nachweise aus einem autorisierten Kontext. Für Browseraktionen behandelt der Leitfaden zur Prüfung authentifizierter Aktionen das entsprechende Nachweisproblem.
Welche Abnahmenachweise brauchen Odoo und n8n?
Nimm die Odoo-n8n-Integration erst ab, wenn wiederholte Befehle in ihrer tatsächlichen Konfiguration getestet und die resultierenden Geschäftsdatensätze geprüft wurden. Dazu gehören Antwortverlust nach gespeichertem Ergebnis und gleichzeitige Versuche mit berechtigten sowie unberechtigten Nutzern. Gefordert ist der beabsichtigte Datensatz im vorgesehenen Zustand, ohne unautorisierte oder ungeklärte zusätzliche Effekte.
Nutze die vorgeschlagenen Abnahmefälle für die echte Integration. Jeder Fall beginnt mit NOT_RUN. Halte Odoo-Version und Modulrevision, n8n-Version und Node-Einstellungen sowie Testidentitäten, freigegebene Eingabe, Zielabfrage und Beobachtung fest. Ein Workflow-Screenshot unterstützt den Nachweis, ersetzt aber keinen Datensatzvergleich.
Teste die vorgesehenen Wiederanläufe: automatisch, manuell nach einer Workflow-Änderung und nach dem Neustart eines Workers. Ergänze einen geänderten Betrag unter dem alten Schlüssel und eine berechtigte zweite Gesellschaft mit derselben Quellreferenz. Prüfe, dass ein gesperrter Nutzer nicht wegen eines früher erfolgreichen Versuchs geschützte Details abrufen kann.
Bei Rechnungen muss der erlaubte Zustand feststehen. Odoos Rechnungsdokumentation unterscheidet das Anlegen im Entwurf von der Bestätigung zu Posted, bei der der Buchungssatz entsteht. Eine zurückgegebene Rechnungs-ID beweist weder die Buchung noch deren fachliche Freigabe. Teste die spätere Bestätigung als eigenen autorisierten Befehl.
Führe die Probe in einer isolierten Umgebung mit kontrollierten externen Diensten aus. Für doppelte Zahlungen oder E-Mails braucht es einen sicheren Ersatz für den echten Empfänger. Finanz- und Fachverantwortliche nehmen ihre Geschäftsergebnisse ab. Die Aussage eines Entwicklers, der Node sei erfolgreich durchgelaufen, reicht dafür nicht.
Wann sollten automatische Wiederholungen ausgeschaltet bleiben?
Lass automatische Wiederholungen für ungeklärte Schreibvorgänge ausgeschaltet, bis die Zieloperation nachweislich wiederholbar ist und ein Verantwortlicher das Ergebnis abgleichen kann. Lesezugriffe oder ausdrücklich wiederholbare Befehle können einer eigenen begrenzten Regel folgen. Ändere die Entscheidung, wenn deine tatsächliche Integration die relevanten Fehlerfälle besteht und sowohl abgeschlossene Arbeit als auch verweigerte Zugriffe belegt.
Wir würden mit einem Befehl zur Auftragserstellung und seinem Abnahmenachweis beginnen. Bestätigung oder Versand folgen erst mit einer eigenen Wiederanlaufregel. Vereinbare die erwarteten Datensätze in der Discovery und Anforderungsarbeit. Dazu gehört auch, wer ein ungeklärtes Ergebnis außerhalb der Arbeitszeit übernimmt.
Wavects API-Integration ist das passende Angebot für diese Übertragungslogik. Bring eine fehlgeschlagene Ausführung und ihre Nachweise im Ziel mit. Das erste brauchbare Ergebnis ist ein reproduzierbarer Wiederherstellungsfall mit einer klaren Freigabeentscheidung.