Wir stellen vor: Der Alumio Route Builder
Integrationen zentral über eine visuelle Oberfläche steuern
Bestellungen und Kundendaten von Shopware landen in PostgresQL in der Form, die ihnen vorher vorgegeben wurde. Was dort ankommt, ist also genau auf die Aufgabe zugeschnitten, für die dieser spezielle Shop eingerichtet wurde.
Eine Datenbank hat keine Meinung zu Ihrem Unternehmen. Sie akzeptiert die ihr übergebenen Daten in der vorgegebenen Form und verarbeitet fehlerhafte genauso problemlos wie korrekte. Daher ist die erste Frage, wofür der Shop eigentlich gedacht ist, denn Berichterstellung und die Datenbereitstellung an andere Anwendungen benötigen unterschiedliche Informationen aus derselben Shopware-Bestellung. Bleibt diese Frage unbeantwortet, wird alles in einer einzigen, unübersichtlichen Struktur gespeichert, und die ursprüngliche Bedeutung geht verloren. Die Verbindung von Shopware und PostgreSQL beginnt mit der Festlegung dieser Struktur – sie ist die einzige Vereinbarung zwischen den beiden.
DATEN, DIE ZWISCHEN IHNEN FLIESSEN
Bestellungen
Bestellpositionen
Kunden
Produkte
Ladereferenzen
Ladezeitstempel
PostgreSQL wird in Alumios veröffentlichter Datenbankunterstützung erwähnt, sodass Shopware-Daten direkt in die von Ihnen definierte Struktur geschrieben werden und nicht über einen von jemandem gepflegten Loader.
Jede Bestellung trifft auf das zu, was sie identifiziert. Daher aktualisiert ein zweiter Ladevorgang das bereits Vorhandene, anstatt ein nahezu identisches Duplikat hinzuzufügen, das niemand bemerkt, bis eine Zählung fehlerhaft erscheint.
Die Ladezeitstempel werden mit den Daten übertragen, sodass jeder, der sie liest, erkennen kann, wie aktuell eine Zahl ist, anstatt anzunehmen, dass sie irgendwann heute Morgen geschrieben worden sein muss.
Da Shopware nach einem Zeitplan gelesen und bereitgestellt wird, wird der Shop nicht von jedem Prozess, der die gleichen Bestellungen benötigt, erneut abgefragt, wodurch die Berichtslast vom Shop reduziert wird.
Alumio schreibt Shopware-Bestellungen und deren Positionen in der von Ihnen festgelegten Form und anhand der von Ihnen verwendeten Identifikationskriterien in PostgreSQL, sodass der Shop das erhält, wofür er konzipiert wurde, und nicht das, was der Shop zufällig zurückgegeben hat.
Bei einer wiederholten Ladung werden die bereits vorhandenen Daten abgeglichen, anstatt sie erneut einzufügen. Dadurch sammeln sich in einem für Berichtszwecke genutzten Speicher nicht langsam doppelte Bestellungen an, die die später daraus abgeleiteten Zahlen unbemerkt verfälschen würden.
Wenn der Shop eine andere Anwendung mit Daten versorgt, anstatt einen Bericht zu erstellen, werden nur die Daten hineingeschrieben, die diese Anwendung benötigt. So bleibt es etwas, worauf sich ein Entwickler verlassen kann, und es wird keine Kopie von allem erstellt, was Shopware zufällig speichert.
Alumio fungiert als zentrales Integrations-Backbone zwischen Vertriebskanälen und Fulfillment-Systemen. Bestellungen werden weitergeleitet, transformiert und validiert, während Status-Updates an jeden Kanal zurückgemeldet werden.
Authentifizieren Sie Ihre Systeme mit den vorgefertigten Connectoren von Alumio. Wählen Sie aus über 200 Connector-Paketen im Marketplace oder erstellen Sie unbegrenzt viele individuelle Integrationen.
Definieren Sie in einer visuellen Oberfläche, wie Datenfelder zwischen Systemen zugeordnet werden. Passen Sie Formate an, reichern Sie Datensätze an und wenden Sie Geschäftslogik an – ganz ohne eigenen Programmcode.
Konfigurieren Sie Abläufe so, dass sie in Echtzeit bei bestimmten Ereignissen, nach einem Zeitplan oder beidem ausgeführt werden. Reduzieren Sie die manuelle Dateneingabe und überlassen Sie Alumio den Datentransfer und die Transformation zwischen Ihren Systemen.
.svg){kind=icon}
Sobald Ihre erste Integration live ist, können Sie Ihr ERP, PIM, WMS oder CRM einfach an denselben Hub anschließen. Bestehende Abläufe laufen nahtlos weiter. Kein Neuerstellen von Grund auf.
Der Zweck des Speichers sollte vor der weiteren Anbindung anderer Verbindungen festgelegt werden, da dies die Antwort beeinflusst. Wenn PostgreSQL eher als Archiv denn als Datenfeed dient, wird üblicherweise ein Aufbewahrungs- und Archivierungsdienst hinzugefügt, da die dauerhafte Speicherung jeder Shopware-Bestellung Kosten und Verbindlichkeiten statt Vorteile mit sich bringt. Alumio verwaltet beide Verbindungen, sodass die Entscheidung, welche Daten aufbewahrt und welche weitergeleitet werden, in einem Schritt getroffen werden kann.
Zuerst werden der Zielort und die zugehörigen Identifikationsmerkmale ermittelt, alles andere ist zweitrangig. Alumio liest die von Ihnen festgelegten Shopware-Bestellungen und Kundendaten gemäß Ihrem Zeitplan und schreibt sie in der von Ihnen definierten Form in PostgreSQL. Dabei werden die Daten anhand ihrer Identifikationsmerkmale abgeglichen, sodass wiederholte Ladevorgänge Aktualisierungen und keine neuen Einträge ermöglichen. Nur relevante Änderungen werden verarbeitet, wodurch sowohl der Shop als auch das Lager keine doppelte Arbeit leisten müssen.
Nein, und die Struktur entspricht dem Vertrag, nicht dem Code. Welche Shopware-Details wo in PostgreSQL landen und wie sie dort identifiziert werden, ist in der Alumio-Schnittstelle definiert und dort auch dokumentiert. Da ein internes Design die vom Autor bevorzugten Konventionen beibehält, steht der Code-Transformer für alle Fälle zur Verfügung, in denen kein Wert direkt angenommen wird.
Beides trifft in der Regel zu, und es als eine einzige Sache zu behandeln, ist der Fehler. Ein PostgreSQL-Speicher, der Shopware-Daten empfängt, ist sowohl Ziel für Schreibvorgänge als auch Quelle für alle nachfolgenden Lesevorgänge. Daher hängt die benötigte Struktur vollständig von der zweiten Hälfte ab, und niemand kann die erste Hälfte korrekt abbilden, ohne diese zu kennen. Die Frage, was die Daten liest, bevor entschieden wird, was landet, verhindert eine unübersichtliche Struktur, der niemand vertrauen kann.
Ein erfolgreicher Schreibvorgang am falschen Ort ist ein Fehler, über den sich eine Datenbank nicht beschwert, da es keinen Grund dazu gibt. Alumio fängt einen fehlgeschlagenen Schreibvorgang sofort ab und protokolliert, wo jeder Shopware-Ladevorgang in PostgreSQL ausgeführt wurde und welche Daten er enthielt. Bei einem fehlgeschlagenen Schreibvorgang wird umgehend eine Warnung ausgegeben, der Grund genannt, gegebenenfalls ein Wiederholungsversuch unternommen und der Ladevorgang so lange protokolliert, bis er abgeschlossen ist. Dadurch werden keine Daten doppelt eingefügt und es gehen keine Daten verloren.
Sprechen Sie mit einem Alumio-Integrationsspezialisten. Wir entwerfen die passende Architektur für Ihre Systeme und die richtige Skalierung, damit Ihre Betriebsabläufe bei jeder Veränderung zuverlässig bleiben.
.svg)
