Eine Pandemie als Innovationstreiber
Der Austausch von Daten zwischen IT-Systemen unterschiedlicher Organisationen spielt in der Logistik seit jeher eine entscheidende Rolle. Logistikprozesse umfassen in der Regel mehrere Teilnehmer aus unterschiedlichen Organisationen mit eigenständigen Systemen. Diese Organisationen oder Unternehmen möchten natürlich möglichst effizient Daten austauschen, wie zum Beispiel Aufträge, Bestellungen oder Rechnungen, aber immer häufiger auch Echtzeitdaten wie aktuelle Statusinformationen zu einem Transport. Doch wie geht das eigentlich am besten?
Die papierlose Kommunikation zwischen Kunden, Lieferanten, Herstellern und Transportunternehmen war schon früh ein Treiber für die Etablierung von Prozessen und Standards der Datenkommunikation, wie zum Beispiel Fortras, ODETTE oder EDIFACT.
Durch die kontinuierlich fortschreitende Digitalisierung von Geschäftsprozessen, nicht zuletzt getrieben durch die Covid-19-Pandemie, weltweite Lieferengpässe oder Containerknappheit, steigt der Druck zur immer engeren Verzahnung von Systemen entlang der Supply Chain weiter an. Ziel dieser sind unter anderem die daraus entstehenden Wettbewerbsvorteile. Zum Beispiel können Ausschreibungen für Transportaufträge auf eine entsprechende Plattform vollautomatisch übermittelt und abgearbeitet werden. Dadurch gewinnen alle am Transport beteiligten Seiten einen entscheidenden Vorteil an Geschwindigkeit, Flexibilität und Transparenz.
Auch die Etablierung von vollständig kontaktlosen Prozessen entlang der Lieferkette, ebenfalls maßgeblich beeinflusst durch die Covid-19-Pandemie, hat den Bedarf an papierlosen Übergängen zwischen Systemen und Prozessen in einem Tempo vorangetrieben, das so nicht vorhersehbar gewesen ist. Flexible, schnell adaptier- und integrierbare Systeme, die sich leicht an Änderungen in Geschäftsprozessen anpassen lassen, sind hier ein entscheidender Wettbewerbsfaktor.
EDI ist tot, lang lebe EDI!
Lange Zeit war Electronic Data Interchange (EDI) das etablierte Verfahren, um Geschäftsprozesse über Systemgrenzen hinweg abzubilden. Standards wie SWIFT und EDIFACT sind weit verbreitet und aus der Kommunikation zwischen großen Unternehmen oder Banken nicht mehr wegzudenken. EDI selbst ist nichts anderes als ein Sammelbegriff für unterschiedliche Verfahren und Standards zum Datenaustausch zwischen Unternehmen und Organisationen.
EDI setzt auf standardisierte Datenaustauschformate und Protokolle, die von allen Beteiligten eingehalten werden müssen. Der Vorteil der Standardisierung, nämlich ein genau spezifiziertes und genormtes Protokoll, ist gleichzeitig auch der Nachteil geworden: Durch die unterschiedlichen Anforderungen von Branchen und Ländern, sind mittlerweile eine Vielzahl von Versionen und Abwandlungen der Standards im Umlauf. Gerade im internationalen Datenaustausch werden oftmals unterschiedliche, landes- und branchenspezifische Standards verwendet.
Auch sind die verwendeten Protokolle und Formate oftmals sehr komplex, wodurch bei der Umsetzung von EDI-Projekten oftmals hohe Aufwände entstehen. Gerade für kleine und mittlere Unternehmen wird es daher schwierig, die Kommunikation mit den größeren Partnern über EDI zu etablieren.
Ein weiterer Nachteil von EDI ist, dass der Datenaustausch in der Regel im Batch-Verfahren abgewickelt wird. Das bedeutet, dass die Geschäftsvorfälle gesammelt und dann in einem Stapel übermittelt werden. Dadurch ist die Verarbeitung von Daten in Echtzeit oder nahe an der Echtzeit mittels EDI nicht oder nur stark eingeschränkt möglich.
Die Daten der EDI-Standards sind sehr stark strukturiert und normiert. Auf der einen Seite hat dies den Vorteil, dass das Datenformat einheitlich ist und es oftmals schon schlüsselfertige Implementierungen gibt. Auf der anderen Seite erweisen sich die normierten Formate oft als unflexibel und machen Anpassungen an die Geschäftsprozesse schwierig und langwierig. Dennoch sind Standards wie ODETTE oder EDIFACT heute sehr weit verbreitet und große Anbieter wie SAP bieten für ihre Systemwelten heute entsprechende Adapter und Konverter an, um zwischen EDI und neueren Methoden, wie IDoc- bzw. API-basierten Systemen, Daten austauschen zu können.
Microservices und API - der Beginn einer wunderbaren Freundschaft
In der IT-Welt haben in den letzten Jahren mehrere tiefgreifende Paradigmenwechsel stattgefunden, die starke Auswirkungen darauf haben, wie IT-Systeme kommunizieren und Daten austauschen können. Bei all diesen Veränderungen stehen immer die Grundprinzipien Flexibilität, Agilität und Elastizität im Mittelpunkt. Das bedeutet, dass Unternehmen mit ihrer IT schneller und flexibler auf Veränderungen am Markt und somit ihrem Geschäftsmodell reagieren wollen. Die IT soll hier nicht Hemmschuh und Kostentreiber sein, sondern soll im höchstmöglichen Maße die Veränderungen im Unternehmen unterstützen.
Die Grundlage für diese Flexibilität der IT-Systeme wird durch die drei Paradigmen Microservices, Cloud Computing und API First am besten beschrieben. Die Abkehr von monolithischen Architekturen hin zu einzelnen Services, die einen bestimmten Teil eines komplexen Geschäftsprozesses abbilden, macht es möglich, diese in beliebiger Form an einen neuen Geschäftsprozess anzupassen, auszutauschen, anderen Unternehmen zur Verfügung zu stellen oder von anderen Unternehmen zu nutzen.
Geschäftsprozesse können so auf Basis einzelner Module anhand fest definierter Schnittstellen, den APIs, abgebildet und flexibel geändert werden. Das bedeutet, ein Partner kann einen einzelnen Geschäftsprozess nutzen, ohne eine komplette Anwendung integrieren zu müssen.
„L’API c’est moi“ - oder warum dreht sich der Code um die API
Durch das Aufkommen der neuen Paradigmen in der IT, vor allem Microservices, Service-Oriented-Architecture (SOA) und Cloud Computing verschiebt sich der Fokus hin zu API-zentrischen Architekturen, auch “API first” bezeichnet. Vereinfacht ausgedrückt bedeutet dies, dass bei der Entwicklung eines Service die API, also die Schnittstelle, mit der dieser Service genutzt wird, als erstes entworfen wird und sich die Funktionalität dahinter immer an dieser API orientiert. Damit soll gewährleistet werden, dass die Schnittstellen jederzeit stabil sind und den höchstmöglichen Wert für die jeweiligen Nutzer:innen der API bieten.
Moderne APIs basieren auf dem so dem sogenannten REpresentational State Transfer (REST)-Prinzip. Die Grundlage hierfür ist das HTTP-Protokoll, das heute die Grundlage des Datenverkehrs im Internet darstellt und daher weit verbreitet ist. Die Nachrichten selbst werden in einem vom Betreiber der API definierten Format mittels JSON oder XML dargestellt. Dies ist sicherlich der größte Unterschied zu EDI. Während EDI klar standardisierte Nachrichten pro Geschäftsvorfall zur Verfügung stellt, muss der Anwender einer API diese jeweils in seinem System einbinden. Das REST-Prinzip kommt dieser Herausforderung jedoch entgegen, indem es ein einfaches, klares Prinzip auf Basis von weit verbreiteten, offenen und sicheren Standards anwendet.
Mehr Business, mehr API: APIs und die Cloud
Der Einsatz von APIs und Microservices im Cloud Computing bietet nun ein hohes Maß an Skalierbarkeit und Elastizität. Durch saisonale Einflüsse oder unvermittelt auftretende Ereignisse kann sich das Aufkommen an Geschäftsvorfällen geplant oder auch sehr kurzfristig verändern. Zum Beispiel kann ein Online-Händler absehen, wann ein neues Modell eines beliebten Mobiltelefons verfügbar ist oder ein Automobilhersteller, wann er in einem bestimmten Markt eine Kampagne für ein neues Modell startet. So kann er auch absehen, wann ein erhöhtes Datenaufkommen der APIs zu erwarten ist. Andererseits hat sicherlich niemand voraussehen können, wie schnell und umfassend ein Virus das Konsumverhalten hin zum Online-Handel verschieben kann, mit allen Auswirkungen auf die Lieferketten dahinter.
Um diese Nachfragespitzen oder Plateaus weiterhin performant und stabil bedienen zu können, war es früher notwendig, zusätzliche Hardware, „Bleche“ für den Betrieb der Anwendung zur Verfügung zu stellen und so das erhöhte Aufkommen an Anfragen bei gleichbleibender Verfügbarkeit der Anwendung sicherstellen zu können.
Mit dem Aufkommen von Cloud-Plattformen und der damit verbundenen Elastizität der Anwendungen ist es nun möglich, solche Änderungen im Nutzungsprofil eines Services kurzfristig beantworten zu können, ohne den langwierigen Prozess der Hardwarebeschaffung und der damit verbundenen Kapitalbindung: Denn wenn das Weihnachtsgeschäft vorüber ist, hat man die extra neu angeschaffte Hardware ja immer noch im Rechenzentrum stehen.
APIs spielen hierbei wiederum eine entscheidende Rolle. Die API ist als Endpunkt einer Anwendung definiert und wird durch die Cloud-Plattform entsprechend überwacht (API Monitoring, API Management). Stellt die Plattform nun fest, dass die API bestimmte Grenzwerte erreicht, zum Beispiel eine definierte erwartete Antwortzeit überschritten wird oder die Anzahl der Anfragen pro Minute einen bestimmten Grenzwert erreicht, kann automatisch zusätzliche Hardware aktiviert werden und gezielt derjenige Service der mehr Leistung braucht, verstärkt werden.
Wenn die definierten Grenzwerte wieder unterschritten werden, läuft die Skalierung dann in die entgegengesetzte Richtung ab. Somit bleibt die Anwendung zu jeder Zeit elastisch, ohne die Kosten für den Betrieb dauerhaft zu erhöhen. Durch die Kopplung der einzelnen Services über eine API können so sogar nur Teile einer Anwendung in die Cloud verlagert werden oder man kann Services eines Anbieters in der Cloud in die eigenen Geschäftsprozesse einbinden.
Stell mit uns den Status quo des Supply Chain Managements in Frage!
Bewirb dich jetzt und gestalte die Logistik der Zukunft.
Der Tanz auf vielen Hochzeiten - die technische Integration von heterogenen Prozesspartnern
Eine moderne, cloud-basierte Logistikplattform stellt ihre Services einer Vielzahl unterschiedlicher Partner eines Geschäftsprozesses zur Verfügung. Die Bandbreite der beteiligten Partner an diesen Prozessen umfasst hierbei nahezu jede Größenordnung von Unternehmen: vom produzierenden Großunternehmen, über internationale Logistikdienstleister und kleine Speditionsbetriebe bis hin zum Endkunden. Genauso heterogen sind daher auch die beteiligten IT-Systeme. Von unternehmensweiten SAP-Installationen, über ERP Lösungsanbieter wie Oracle, Sage oder Microsoft bis hin zum kleinen Familienbetrieb mit einer selbstentwickelten Logistiklösung oder Excel-Tabellen, ist das ganze IT-Spektrum vorhanden.
Um nun möglichst viele Partner in eine Plattform integrieren zu können, muss die gewählte Integrationsform möglichst einfach implementier- und skalierbar sein. Wie oben schon erwähnt, stellt EDI hier für kleine und mittlere Unternehmen eine fast unüberwindbare Hürde dar. Die notwendigen Investitionen in die Implementierung und den Betrieb einer EDI-Anbindung dürften für die meisten Unternehmen in dieser Größenordnung nicht realisierbar sein.
Eine Anbindung mittels API hingegen ist ein überschaubarer, leicht zu realisierender Aufwand. Es ist nicht erforderlich, eine eigene Plattform zu betreiben, da die meisten Anwendungen heute schon die Möglichkeit bieten, REST-basierte APIs zu integrieren. Im einfachsten Fall kann eine API durch einen einfachen Standalone-Client bedient werden.
Die größte Herausforderung bei der API-Integration stellt in der Regel das sogenannte Mapping der Daten eines Geschäftsprozesses auf das Zielformat der zur Verfügung gestellten API dar. In den meisten Fällen ist dieses Format heutzutage JSON, ein leicht verständliches und anwendbares Datenformat. Aber auch XML spielt hier eine entscheidende Rolle, nicht zuletzt setzt SAP mit IDoc auf diesen Standard. Unabhängig von Datenformat sollten APIs wohldokumentiert sein und beinhalten Beschreibungen der verwendeten Methoden und des Datenformats.
Doch wie stellt sich nun eine solche API-Integration technisch dar? Da mit HTTP ein etabliertes Kommunikationsprotokoll verwendet wird, können hier bereits bewährte Methoden und Standards verwendet werden, die wir im Folgenden kurz skizzieren:
Sicherheit - Authentifizierung, Autorisierung und Verschlüsselung
Selbstverständlich muss stets gewährleistet sein, dass nur authentifizierte Partner eine API nutzen können, und, dass die Kommunikation zwischen den Systemen nicht manipuliert werden kann und vertraulich bleibt. Hierzu gibt es mit OAuth, OpenID und JSON Web Token (JWT) bewährte Methoden zur Authentifizierung und Autorisierung.
Als Beispiel muss sich der Client einer API mittels Anmeldeinformationen am Zielsystem authentifizieren und erhält dann einen JWT zurück. Dieser JWT wird dann beim Aufruf der entsprechenden API-Methode mitgesendet und vom Zielsystem ausgewertet. Die JWTs enthalten sowohl Informationen zur Authentifizierung des Clients als auch zu den Berechtigungen, die dieser Client besitzt (Autorisierung). In der Regel haben die Tokens eine definierte Gültigkeit, beispielsweise fünf Minuten, nach der der Token ungültig wird und vor dem nächsten Aufruf der API ein neuer Token erstellt werden muss. Dadurch wird gewährleistet, dass die Autorisierung der Nutzer:innen immer wieder neu geprüft werden kann.
Um nun die Vertraulichkeit und Integrität einer Verbindung zwischen zwei Systemen zu gewährleisten, wird HTTPS als verbreiteter und verlässlicher Standard verwendet. Dadurch wird garantiert, dass die Kommunikation zwischen den Partnern verschlüsselt ist und nicht durch einen Dritten manipuliert werden kann.
Ressourcen und Methoden – RESTful APIs
Eine auf REST basierende API benutzt die im HTTP-Protokoll definierten Methoden wie POST (Erstellen), GET (Lesen), PUT (Ändern) und DELETE (Löschen) einer Ressource. Eine Ressource ist in diesem Kontext ein bestimmtes Geschäftsobjekt, auf das sich die Methode beziehen soll. Solche Geschäftsobjekte können zum Beispiel Frachtaufträge, Bestellungen, Rechnungen, Kunden oder Lieferanten sein.
So könnte eine REST API für ein Konto beispielsweise die folgenden Operationen zur Verfügung stellen:
- GET https://somecompany.com/accounts /a341422 zum Abruf von Kontoinformationen zum Konto a341422.
- POST https://somecompany.com/accounts /m865532 erzeugt ein Konto mit der Nummer m865532.
Die eigentlichen Informationen zum Geschäftsobjekt werden dann im sogenannten Body oder Payload der Nachricht übermittelt.
Mapping - JSON /XML
JSON benutzt eine einfache, leicht lesbare Form der Darstellung von strukturierten Daten. Es orientiert sich an der JavaScript-Programmiersprache und kann leicht erstellt und verarbeitet werden.
Eine Adresse in JSON-Notation kann zum Beispiel die folgende Notation haben:
„address“ : {
“name” : “Leogistics GmbH”,
“city” : “Hamburg”,
“country” : “DE”,
“street” : “Borselstraße”,
“streetNumber” : “26”,
“zip” : “22765”
}
Die gleiche Information würde in XML so dargestellt werden:
<adress>
<name> leogistics GmbH </name>
<city>Hamburg</city>
<country>DE</country>
…
</adress>
Die Herausforderung bei der Integration ist nun eine geeignete Umsetzung der Daten aus dem Client-System auf das jeweilig verlangte Format der API zu definieren – das sogenannte Mapping.
Direkte Anbindung oder Middleware
Grundsätzlich können die oben beschriebenen Aufgaben der API-Integration direkt durch das Client-System, also die Anwender:innen der API, implementiert werden. Da aber auch grundsätzliche Überlegungen, wie zum Beispiel Protokollierung, die Reaktion auf Fehler oder die Zusammenfassung mehrerer API-Aufrufe zu einem Geschäftsvorfall eine Rolle spielen, wird hier in der Regel noch eine sogenannte Middleware zwischen den Systemen eingesetzt. Diese Middleware übernimmt dann die „Übersetzung“ der jeweiligen Geschäftsvorfälle des Client-Systems auf die entsprechenden Methoden der API. Auch das Mapping der Daten zwischen den Systemen und die Verkettung einzelner API-Aufrufe kann durch Middelware-Systeme elegant gelöst werden. Beispiele für solche Middleware-Komponenten sind (C)PI von SAP oder Tibco.
Cloud, Microservices und API – darum sind APIs die Zukunft
Cloud Computing ist mittlerweile viel mehr als ein Buzzword in der IT. Immer mehr Unternehmen transformieren ihre IT in Richtung Cloud, da dort die notwendige Flexibilität, Elastizität und Effizienz zur Verfügung steht, um die IT als Wettbewerbsvorteil einsetzen zu können.
Die Kombination aus API, Microservices und Cloud ermöglicht es, schnell und effizient auf Änderungen in den Geschäftsprozessen zu reagieren und Partner in die Abläufe integrieren zu können.
Der API, also den Schnittstellen, kommt hier eine besondere Bedeutung zu: Sie stellt den zentralen Punkt dar, über den die einzelnen Services, Partner und Unternehmen miteinander kommunizieren können. Der Einsatz moderner, REST-basierter APIs ermöglicht die Kommunikation über Unternehmensgrenzen hinweg, in Echtzeit. Die Onboarding-Zeiten neuer Partner können durch den Einsatz von wohldokumentierten APIs, etablierten Protokollen und unterstützenden Middleware-Komponenten auf ein Minimum reduziert werden.
Wir sind für Sie da!
API First stellt nicht nur eine moderne Herangehensweise bei der Softwareentwicklung dar, sondern ist auch DAS Paradigma der Zukunft bei der Prozess- und Systemintegration über Unternehmens-, Branchen- und Landesgrenzen hinweg. Haben wir Ihr Interesse an modernen Datenaustauschmethoden rund um APIs geweckt? Bei leogistics verfügen wir über umfassende Expertise in diesem Bereich und der Integration von Anwendungen mit unterschiedlichsten vor- und nachgelagerten Systemen. Sie haben Fragen? Sprechen Sie uns einfach an unter blog@leogistics.com.
Marc Gutekunst
Senior Solution Architect Digital Supply Chain
Was ist Kitting und wie wird es in SAP EWM umgesetzt?
Das RF-Framework ist tot – lang lebe das RF-Framework
4 Varianten der Produktionsintegration mit SAP S/4HANA EWM – welches ist die richtige für Sie?
SAP S/4HANA 2020 FPS01: viele neue Funktionen auf Lager
Sie fragen sich, ob eine Machbarkeitsanalyse Kostentransprenz bringt?
