Das Team, das dies nutzt, fragt nach dem, was es braucht, anstatt das zu erhalten, was jemand veröffentlicht hat. Das ist der Unterschied zwischen Fragen und Empfangen und der eigentliche Grund dafür.
Ein Team, das eine Anwendung auf Basis der Geschäftsprozesse entwickelt, benötigt eine zentrale Anlaufstelle für Fragen. Üblicherweise erhält es jedoch eine Liste von Endpunkten, die jeweils ein vom Entwickler festgelegtes, festes Format zurückgeben. So führt die Anwendung vier Anfragen durch, um einen Bildschirm zu erstellen, und eine fünfte, da die ersten vier den Preis nicht enthielten. SAP war nie für eine solche Abfragemethode konzipiert – ein Problem, das niemandem anzulasten ist, aber alle betrifft. Die Verbindung von SAP und GraphQL schafft eine zentrale Anlaufstelle für Fragen, sodass das nutzende Team seine Anforderungen beschreiben kann, anstatt sich mit den verfügbaren Funktionen auseinandersetzen zu müssen.

Ein konsumierendes Team fragt einmalig nach den benötigten Daten für einen Bildschirm, anstatt diese aus vier separaten Aufrufen zusammenzusetzen. Genau hier liegt der Ursprung der meisten Latenzzeiten in diesen Anwendungen.
Eine zweite Bewerbung bedeutet nicht, dass eine zweite Anordnung erforderlich ist, denn es geht lediglich um eine andere Form desselben Objekts und nicht darum, dass etwas speziell dafür angefertigt werden muss.
Wie weit eine einzelne Anfrage in SAP hineinreichen darf, wird bewusst festgelegt, damit aus einer praktischen Anfrage nicht unbemerkt eine teure wird, die erst am Ende des Quartals jemandem auffällt.
Die Daten, die SAP speichert, müssen nicht für eine Anwendung umstrukturiert werden, da die Übersetzung zwischen den beiden Systemen erfolgt und nicht innerhalb eines der beiden.
Wenn eine Anwendung einen Kunden, dessen Preise und offene Aufträge benötigt, fragt sie diese gemeinsam ab und empfängt sie auch gemeinsam, sodass die Anzeige aus einer einzigen Börse erstellt wird und nicht aus vier, die einzeln zusammengefügt werden müssen.
Wenn ein anderes Team mit der Entwicklung von etwas beginnt, fragt es nach der benötigten Form, anstatt darauf zu warten, dass jemand etwas dafür veröffentlicht. Daher kostet die zweite Anwendung nur einen Bruchteil dessen, was die erste gekostet hat.
Wenn eine Anfrage mehr verlangt, als sie sollte, ist der von Ihnen festgelegte Umfang die Antwort und nicht die Anfrage selbst. So kann sich eine einzelne, bequeme Frage nicht unbemerkt in eine verwandeln, die das halbe ERP-System mit sich reißt.
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.
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.
Die Anwendungen, die diese Fragen stellen, benötigen selten nur das ERP-System. Ein Kundenbildschirm zeigt üblicherweise an, was er gekauft, was ihm zugeschickt wurde und wozu er zuletzt eine Supportanfrage gestellt hat – drei Systeme. Alumio verwaltet diese Verbindungen zusätzlich zu diesem System, sodass eine Frage von mehreren Stellen aus beantwortet werden kann, ohne dass das zuständige Team weiß, woher die einzelnen Informationen stammen.
Ja, und die Art der Anfrage unterscheidet dieses System von anderen: Der Nutzer stellt eine Frage, und Alumio antwortet, anstatt dass Daten zeitgesteuert veröffentlicht und später gesammelt werden. Es werden keine Daten übertragen. Wie tiefgründig eine Frage sein kann, bestimmen Sie durch Ihre Konfiguration; die Antwortmöglichkeiten hängen davon ab, welche Informationen SAP bereitstellt.
Nein, und die zweite Verbindung kostet nur einen Bruchteil der ersten, da die Strukturen und Bereiche bereits festgelegt sind, wenn das nächste Team eintrifft. Das gilt nicht für Endpunkte, die individuell für jeden Nutzer erstellt werden; deshalb sammeln sich diese in Unternehmen an. Wenn ein Wert zusammengesetzt statt gelesen werden muss, übernimmt der Code Transformer diese Aufgabe.
Der Umfang ist enger gefasst, als es einem Entwickler lieb wäre, und weiter gefasst, als es einem ERP-Team lieber wäre. Deshalb muss er klar definiert werden, anstatt ihn dem jeweiligen Programmierer zu überlassen. Eine Frage, die jeden Kunden mit jeder seiner Bestellungen erfasst, ist zwar leicht zu formulieren, aber teuer zu beantworten. Durch die zentrale Festlegung des Umfangs wird die Grenze bewusst festgelegt und nicht erst unter Last entdeckt.
Irreführend ist eine Frage, die unvollständig beantwortet wird, da die Anwendung zwar Daten liefert, der Bildschirm aber leerer wirkt als er sein sollte. Alumio gibt den Umfang der Antwort an, sodass auch eine Teilantwort als solche sichtbar ist. Jeder Austausch wird live überwacht und mit den übermittelten Daten protokolliert. Bei einer Ablehnung wird eine Benachrichtigung mit Begründung ausgegeben, Wiederholungsversuche werden gemäß Konfiguration durchgeführt, und es gehen keine Daten unbemerkt 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.