10. Integrationen

Die API

Alles, was eine Integration braucht, ist JSON über HTTPS auf der eigenen Subdomain der Firma, authentifiziert mit einem API-Schlüssel, den ein Administrator anlegt und der einmal angezeigt wird. Dezimalzahlen sind Strings – JSON-Zahlen sind Gleitkommazahlen, Mengen und Geldbeträge sind es nicht. Die API-Referenz listet jeden Endpunkt auf.

Eine Anwendung, die viele Firmen nutzen, etwa Syncomatic, fragt nicht nach einem Schlüssel: Sie schickt den Benutzer zu Foudra, der Benutzer meldet sich an und erlaubt sie, und sie erhält ein Token, das als dieser Benutzer handelt und unter Verbundene Anwendungen aufgeführt ist, wo jeder trennen kann, was er erlaubt hat.

Die durchgängige Entwurfsregel: Die API ist die Wahrheit, und Schreibzugriffe sind vorsichtig. Skripte legen Entwürfe an, die ein Mensch genehmigt; Maschinen melden, was sie getan haben; nichts außerhalb des Systems kann Geld verbindlich ausgeben oder Bestand erfinden.

Benutzerdefinierte Daten

Jeder Artikel, jeder Arbeitsplatz und jeder Fertigungsauftrag trägt einen undurchsichtigen JSON-Block, den das System prüft, speichert und nie auswertet. Er ist für Integrationen gedacht: wo der G-Code eines gedruckten Artikels liegt, die Netzwerkadresse eines Druckers, die Dichte eines Filaments. Bearbeiten Sie ihn auf der Seite Custom data (benutzerdefinierte Daten) des Objekts oder über die API, und halten Sie das System unabhängig von seinem Inhalt.

Drei Muster

ETL von einem Lieferanten. Ein Skript nimmt den Bestellexport eines Lieferanten, löst dessen Artikelnummern über GET /api/sourcing auf und legt mit POST /api/purchase-orders eine Bestellung als Entwurf an. Unbekannte Nummern lassen die ganze Anfrage scheitern, mit Nennung der Position; ordnen Sie sie unter den Bezugsquellen zu und versuchen Sie es erneut. Nach einigen Bestellungen ist Ihre Bezugsquellentabelle die Querverweisliste.

Eine Maschine, die Dinge herstellt. Eine Druckfarm-Verwaltung fragt GET /api/workstations/{id}/next ab, solange ihr Drucker frei ist, startet den Arbeitsgang, druckt, schließt mit der Menge ab (und bald mit dem tatsächlich verbrauchten Filament) und setzt den Arbeitsplatz auf frei. Braucht sie einen Menschen, geht sie auf blockiert und spielt mit PUT /api/tasks/{source} eine Aufgabe ein. Der vollständige Entwurf liegt im Repository unter docs/integrations/print-manager.

Daten abholen. Ein Vertriebssystem, das Mengen braucht, liest GET /api/stock; eine Übersicht anderswo liest GET /api/parts. Schlüssel nur mit Lesezugriff für reine Lesezwecke.

Benachrichtigt werden

Webhooks sind das System, das von sich aus meldet, wenn etwas geschieht: Ein Fertigungsauftrag wird abgeschlossen, Bestand ändert sich. Ein Administrator gibt eine URL und die gewünschten Ereignisse an; jede Nachricht wird signiert, erneut gesendet, wenn der Empfänger nicht erreichbar ist, und protokolliert. Das Ereignis wird in derselben Transaktion geschrieben wie die Änderung, die es meldet, sodass nichts angekündigt wird, was nicht geschehen ist.

Ein System, das Arbeit anfordert und hören will, wenn sie erledigt ist. Die Einsatzleitung beauftragt eine Wartung mit POST /api/work-orders und gibt den Rumpf als Referenz des Auftrags an. Wenn der letzte Arbeitsgang abgeschlossen ist, trägt der Webhook work_order.completed diese Referenz zurück, und das Boot kann wieder in Dienst gehen. Foudra erfährt nie, was ein Rumpf ist.

Abfragen funktioniert weiterhin für alles und ist immer korrekt; ein Webhook erspart nur das Warten.

Weiter: Rhythmus.