Odoo stock.quant und RFID: Das Gateway ist das Produkt

Die erste Version jeder RFID-Odoo-Integration sieht gleich aus. Ein Leser wird so konfiguriert, dass er jede Etikettenlesung an einen Controller sendet, der Controller schreibt direkt in stock.quant, und innerhalb einer Woche sperrt die Datenbank, die Odoo-Worker sind ausgelastet, und der Bestand ist auf eine Weise falsch, die niemand reproduzieren kann.

Der Fehler ist architektonisch, nicht technisch. Ein Leser ist ein Sensor, keine Transaktionsquelle. Zwischen einem Sensor, der tausendfach pro Sekunde meldet, und einem ERP, das ein durchdachtes Geschäftsereignis erwartet, muss etwas stehen, das denkt. Dieses Etwas ist das Gateway, und in einem funktionierenden Einsatz ist es der Teil, den man pflegt, versioniert und überwacht — das Produkt, nicht der Klebstoff.

Warum Leser direkt an Odoo zu verdrahten ein Anti-Pattern ist

Die Zahlen belegen es, bevor eine Zeile Code geschrieben wird.

• Ein einzelner fest installierter Leser in einer Tür liefert beim Palettendurchlauf mehrere hundert TagRead-Ereignisse pro Sekunde.
• Jedes Etikett wird typischerweise fünf- bis zwanzigmal innerhalb einer Sekunde gesehen, mit unterschiedlicher Signalstärke.
• Der Odoo-ORM berechnet und schreibt eine Quant-Zeile pro Produkt, Lagerort und Los, mit Zeilensperren und Cache-Invalidierung bei jedem Schreiben.
• Nebenläufige Schreiber auf demselben Quant serialisieren in Sperrwartezeiten, und Mehrzeilen-Updates in falscher Reihenfolge erzeugen Verklemmungen.
• Ein Leserausfall spielt danach einen Schwall ab, und der Schwall trifft genau dann ein, wenn das ERP am wenigsten aufnehmen kann.

Die drei Aufgaben des Gateways: parsen, deduplizieren, aggregieren

Ein Gateway, das diese drei Dinge gut macht, kann zweihundert Zeilen haben. Eines, das sie schlecht macht, wird zweimal neu geschrieben.

• Parsen: einen rohen EPC in Produkt, Los und Seriennummer verwandeln, ohne Datenbankzugriff auf dem heißen Pfad.
• Deduplizieren: eine Beobachtung pro Etikett und Zeitfenster behalten, nicht zwanzig, und die stärkste Signalstärke mitnehmen.
• Aggregieren: Beobachtungen in vorzeichenbehaftete Deltas pro Lagerort und Produkt umwandeln — die einzige Größe, die Odoo je sehen sollte.
• Puffern: Deltas in einer dauerhaften Warteschlange halten, damit ein Neustart nichts verliert und ein Wiederholungsversuch sicher ist.
• Anwenden: in Stapeln in Odoo schreiben, mit einem Idempotenzschlüssel, der ein wiederholtes Anwenden zu einem Nichts macht.

Vom EPC zum Produkt: eine deterministische Abbildung

Das EPC-Parsing ist der Ort, an dem Integrationen still brechen, weil es durch Zeichenkettenmanipulation statt durch ein Schema geschieht.

• Ein 96-Bit-SGTIN kodiert Firmenpräfix, Artikelreferenz und Seriennummer; die Trennstelle hängt von der Präfixlänge ab, nicht von der Zeichenkette.
• Dekodieren Sie zuerst den Header, dann die Partition, dann die Felder; Feldbreiten zu raten funktioniert, bis es nicht mehr funktioniert.
• Halten Sie eine zwischengespeicherte Abbildung von Artikelreferenz zu Produkt und Los; aktualisieren Sie sie per Timer, nicht bei jeder Lesung.
• Behandeln Sie unbekannte EPCs als explizite Warteschlange, nicht als null; ein unbekanntes Etikett ist ein Kennzeichnungsfehler, der gesehen werden sollte.
• Versionieren Sie die Abbildungsregeln, denn ein Lieferant, der seine Kodierung ändert, sollte kein Code-Deployment erzwingen.

stock.quant schreiben ohne Verklemmung

Der Schreibpfad ist der Ort, an dem die meisten Projekte ein Wochenende verlieren. Die Regeln sind einfach und handeln meist von Reihenfolge.

• Ein Schreiberprozess pro Datenbank; Nebenläufigkeit kauft hier Durchsatz, den man nicht braucht, und Verklemmungen, die man bekommt.
• Bevorzugen Sie die ORM-Methode, die eine atomare Mengenaktualisierung mit der richtigen Sperre durchführt, und niemals Lesen-Ändern-Schreiben in Python.
• Wenn SQL nötig ist, sperren Sie Zeilen in deterministischer Reihenfolge — Produkt, dann Lagerort, dann Los — damit zwei Transaktionen sich nicht kreuzen.
• Stapeln Sie nach Lagerort, nicht nach Etikett: fünfzig Deltas in einem Gang gehören in eine Transaktion, nicht in fünfzig.
• Vermerken Sie den Geschäftsgrund bei jeder Anpassung, denn eine unerklärte Mengenänderung ist in einer Prüfung nicht von einem Fehler zu unterscheiden.

Konfliktlösung, wenn zwei Wahrheiten sich widersprechen

Leser und ERP werden sich widersprechen, und die Designfrage ist, wer gewinnen darf und wann.

• Eine Lesung ist Evidenz über die Gegenwart; ein ERP-Datensatz ist eine Behauptung über die Vergangenheit. Das sind nicht dieselben Fakten.
• Lassen Sie niemals eine einzelne Lesung eine Menge überschreiben; wenden Sie ein Delta nur an, wenn die Beobachtung vollständig und die Zone geschlossen ist.
• Verwenden Sie die Ereigniszeit des Lesers, nicht die Ankunftszeit am Gateway, damit ein verspäteter Stapel nicht wie eine neue Bewegung aussieht.
• Last-Write-Wins ist bei doppelten Ereignissen unsicher; bevorzugen Sie eine monotone Sequenz pro Leser und verwerfen Sie alles Ältere als das zuletzt Angewendete.
• Wenn die Abweichung strukturell ist — eine ganze Zone um zehn Prozent daneben — lösen Sie eine Ausnahme aus, statt still zu korrigieren.

Durchsatztechnik bei 100.000 Ereignissen pro Tag

Hunderttausend Ereignisse sind im Mittel eines pro Sekunde und zweihundert pro Sekunde an der Rampe, also sind Mittelwerte nutzlos.

• Dimensionieren Sie für die Spitze und prüfen Sie dann den Mittelwert; die Spitze bricht das System und der Mittelwert lässt es in einer Demo gut aussehen.
• Stapeln Sie in einem Fenster von einer halben bis zwei Sekunden; darunter zahlen Sie Transaktionsoverhead, darüber Latenz.
• Halten Sie den heißen Pfad frei von berechneten ORM-Feldern, Onchange-Logik und Mail-Threading; nichts davon gehört in einen Inventarschreibvorgang.
• Betreiben Sie den Anwendungs-Worker in der Job-Queue auf einem dedizierten Kanal, damit ein langsames ERP die leserseitige Seite nicht blockiert.
• Messen Sie die Deduplizierungsrate; liegt sie unter zehn zu eins, ist das Zeitfenster zu kurz und Odoo leistet unnötige Arbeit.

Beobachtbarkeit: was protokollieren, was alarmieren

Eine Inventarpipeline, die man nicht beobachten kann, wird bis zur ersten Prüfung geglaubt und danach nicht mehr.

• Protokollieren Sie jedes rohe Ereignis einer Stichprobe und jedes angewendete Delta aller Ereignisse, mit angehängtem Idempotenzschlüssel.
• Verfolgen Sie Lesungen pro Antenne, damit eine tote Antenne wie ein Einbruch in einer Reihe aussieht und nicht wie eine ruhige Woche.
• Alarmieren Sie bei Anwendungslatenz über einem Schwellenwert, bei wachsender Warteschlangentiefe und bei steigender Ablehnungsrate.
• Stimmen Sie täglich ab: Vergleichen Sie Gateway-Deltas mit Odoo-Mengenänderungen und erklären Sie jede Abweichung über einem Schwellenwert.
• Halten Sie ein abspielbares Ereignisarchiv bereithalten, denn der häufigste Vorfall ist kein Absturz, sondern eine falsche Regel über drei Tage.

Rollout-Reihenfolge und Rollback

Der sichere Weg, einen Schreibpfad in ein ERP einzuführen, besteht darin, ihn das Recht zu schreiben verdienen zu lassen.

• Stufe eins: Shadow-Modus. Deltas berechnen, protokollieren, nichts schreiben und zwei Wochen mit den Erwartungen vergleichen.
• Stufe zwei: mit Produktionsverkehr in eine Sandbox-Datenbank schreiben und den Abgleichsbericht dagegen laufen lassen.
• Stufe drei: Schreiben für eine Zone per Feature-Flag aktivieren und den alten Prozess parallel weiterlaufen lassen.
• Stufe vier: zoneweise erweitern und dabei die Ausnahmenrate beobachten, nicht die Erfolgsrate.
• Rollback ist keine Datenbankwiederherstellung: Schreiben stoppen, die Warteschlange mit korrigierter Regel abspielen und idempotent erneut anwenden.