Anbindungsvarianten von ERP und Shopsystemen

Zentraler Knoten zwischen den zwei Systemen, die sich eigentlich nicht kennen wie ERP und Shopsystem ist die Schnittstelle.

Ist man sich also darüber im Klaren, welche Informationen wie geführt und übergeben werden, muss man sich Gedanken machen, wie die Integration agieren soll. Tatsächlich stellt sich also die Frage, wie die Systeme technologisch und in welchem Zeitfaktor zu einander finden.

Technologie

Welche Möglichkeiten des Datenaustausches gibt es? Die Eleganteste Variante ist selbstverständlich ein integriertes System. Also genau das, was dieser Artikel gar nicht beschreibt: Ein ERP System kann tatsächlich ein vollwertiges Shopsystem abbilden oder ein Shopsystem hat die nötige Systemtiefe in den ERP Funktionen. Damit würde also eine Schnittstelle wegfallen und das System ist fertig.

Wie oben in der Zusammenstellung geschrieben, ist das aktuell kaum der Fall. eEvolution mit seinem Direct Shop kann im ersten Fall (ERP als Shopsystem) erste Punkte und Erfolge einheimsen. Die Philosophie des Herstellers, als ERP Anbieter seine gewonnen Erfahrungen im eCommerce direkt in einem integrierten Produkt umzusetzen scheint erfolgreich zu sein. Als Referenz nennt das Unternehmen die Rossmann-online GmbH (www.rossmann.de) seit 1999. Und das ist wahrlich keine kleine Referenz!

Aber! Das ist (noch) die Ausnahme und auch der eEvolution DirectShop wird seine Schwächen haben. Der in mittlerer Zukunft gängigste Weg wird die Verzahnung zweier Systeme, die ihre Aufgabe richtig gut können sein.

API -API

Technologisch am Saubersten funktioniert die Systemanbindung, wenn beide Systeme ein sauber programmiertes und dokumentiertes API (application programming interface) bieten. Dieses API ist eine Programmbibliothek, die das System nach außen hin offen stellt und alle Funktionen bietet um Daten herein oder heraus zu befördern. Dabei sind die Wege der Daten so vorgegeben, dass sie im relevanten System genau dort ankommen wo sie hin sollen, bzw. genau den Prozess anstoßen, der Benötigt wird.

Ein Beispiel: Das API eines Shopsystems stellt die Daten eine Kundenbestellung in einer beschrieben, immer gleichen Form zur Verfügung. Die Integrationsprogrammierung nimmt diese Daten und sendet diese an das API des ERP Systems. Hier wird auf Grund der Programmierung erkannt, dass es sich um einen Auftrag handelt und ein entsprechender Prozess zur Auftragsanlage mit den entsprechenden Daten angestoßen.

Der Vorteil bei dieser Konstellation ist, dass sie am unanfälligsten für Fehler und die Schnittstellenprogrammierung am einfachsten zu kalkulieren ist. Außerdem stehen durch die Dokumentation alle Informationen zur Verfügung, die der Integrator benötigt.

Der Nachteil ist, dass die Hoheit über das API beim jeweiligen Hersteller liegt. Ist eine Funktion nicht oder nur zum Teil vorhanden, kann es sein, dass eine Programmierung neben des API nötig wird (siehe folgende Beschreibungen), was die Systempflege aufwändiger macht. Eine Eingabe an den Hersteller lohnt sich in diesem Fall eigentlich immer. Die Erweiterung des API nützt eigentlich jedem.

API vs. Datenbank

Steht nur auf einer Seite ein API zur Verfügung, steht die Überlegung an, wie die Daten auf der anderen Seite transportiert bzw. umgesetzt werden.

Zum einen könnten die Daten direkt in die Datenbank geschrieben werden, bzw. direkt daraus gelesen werden. Wobei das Lesen das kleinere Übel ist. Das direkte Schreiben in die Datenbank aus einer Drittanwendung (in diesem Fall die Schnittstelle) sieht kein System gerne, egal ob Shop oder ERP. Es birgt große Gefahren und kann Daten inkonsistent werden lassen. Außerdem löst das direkte Schreiben eines Datensatzes in eine oder mehrere Tabellen meist noch keine Systemaktion aus, wie z.B. die korrekte Anlage eines Auftrages mit entsprechender, fortlaufender Auftragsnummer und Eintrag in die Kundenhistorie. Das muss aufwändig nachprogrammiert werden, was oftmals zu Fehlern führen kann.

Als technische Schnittstelle für den Datenbankzugriff werden noch oft die Datenbankschnittstellen JDBC (Java Database Connectivity) oder ODBC (open Database Connectivity) für den Datenaustausch genutzt. Diese beiden offenen Schnittstellenstandards ermöglichen strukturierten Zugriff auf die Inhalte der Datenbanken und sind sehr weit verbreitet. Sie gelten aber bei den Profis als langsam und unsicher und werden immer mehr durch die direkten Datenanbindungsobjekte der Programmierframeworks ersetzt.

API vs. Datenfile

Besser als direkt in die „fremden“ Datenbanken zu schreiben ist es sicher, über gängige Importmechanismen der Systeme zu agieren (wenn denn vorhanden). Die zu erstellende Schnittstelle erzeugt dazu ein Datenfile in einem definierten Format, welches vom entsprechenden System gelesen und verarbeitet werden kann. Z.B. über ein Import/Export Modul. Hier ist das Timing wichtig, die zur Verfügung gestellten Daten müssen entsprechend nach der Generierung abgerufen werden, bzw. muss das gegnerische System darüber informiert werden, dass Daten zur Verfügung stehen.

Als definierte Beschreibungssprache für die Files bietet sich XML (Extensible Markup Language) an. XML ermöglicht auf Grund seiner Architektur die Beschreibung aller Datenebene und ist mittlerweile zum Standard in allen möglichen Bereichen geworden, in denen Daten kommuniziert und ausgetauscht werden müssen. Je nach System werden XML Exportfiles im Standard mit ausgeliefert. Es ist aber in jedem Fall Hand anzulegen, um die entsprechenden Files auf die Systeme einzustellen.

 

Spezialfall EDI

Ein seit langen Jahren als Standard beschriebenes Protokoll, welches meist zum Austausch von Daten zwischen zwei oder mehreren Unternehmen verwendet wird ist EDI (Elektronic Data Interchange). Dabei kommt EDI als eine extrem flexible Kopplung den Systemen her und verspricht, durch Standarddefinitionen die Anbindung jedes EDI sprechenden Systems an ein anderes EDI sprechendes System. Nur: Man muss sich auf die jeweiligen Nachrichtenstandards einigen. Die gängigsten sind EDIFAKT im Handel, ODETTE bei den Automobilzulieferern oder RosettaNet, mit dem nochmal wieder versucht wird einen neuen offen Standard für das eCommerce zu etablieren. Fakt ist, dass jeder Nachrichtenstandard für sich wiederum meist Untersprachen und Spezialfälle hat, so dass meist immer etwas getan werden muss, um zwei EDI sprechende Systeme miteinander kommunizieren zu lassen. Wenn man aber schon eine EDI Schnittstelle am ERP system hat, solltem an auf jeden Fall prüfen, ob diese Schnittstelle evtl. geeigent ist, ohen viel Aufwand Informationen für das Shopsystem zur Verfügung zu stellen (z.B. Artikelstammdaten) oder sogar Aufträge aus dem Shop anlegen kann.

 

In allen Fällen ist auf jeden Fall eine saubere Programmierung nötig, wobei der Programmierer beide Systeme genau kennen muss. Das gilt natürlich auch dann, wenn kein System eine API zur Verfügung steht und folgende Szenarien erfüllt werden müssen:

– Datenbank vs. Datenbank
– Flatfile vs. Flatfile
– Datenbank vs. Faltfile

Eine Frage der Zeit

Die Kopplung der Systeme ist in drei Varianten denkbar:

– Online – Eine Kommunikation in Echtzeit. Es werden genau dann Daten transferiert, wenn sie sich geändert haben.
– Nearline – Ein zeitgesteuerter Abgleich in Intervallen
– Offline – Ein manueller Abgleich bei Bedarf

Wann und wie nun die Systeme miteinander sprechen ist eine Glaubensfrage. In der heutigen Zeit und mit den heutigen Möglichkeiten ist es sicherlich immer denkbar, einen Onlinelösung zu etablieren. Es spricht sehr viel dafür. Aber auch die anderen Varianten sind immer noch gängig und denkbar.

Online-Anbindung

Bei der Online-Anbindung muss es eine permanente Datenverbindung beider System geben. Das heißt das ERP im Unternehmen und der Shop im WWW müssen über entsprechend gesicherte Leitungen direkt und ständig kommunizieren. Ein Aufbau der Datenverbindung bei Bedarf scheidet meist aus, da die Echtzeitdatenübermittlung voraussetzt, dass Änderungen am System in Bruchteilen von Sekunden übermittelt werden.

Durch eine solche direkte Kommunikation zwischen den Systemen können Transaktionen,

die durch das Shopsystem ausgelöst wurden, direkt im ERP angestoßen werden.

Der große Vorteil hier ist, dass der Shop dadurch fast schon ein Client des ERP Systems geworden ist. Denn alle Aktionen, die auf dem Shopsystem durchgeführt werden schlagen unmittelbar auf das ERP durch.

Der Nachteil ist sicherlich die hohe Anforderung an die Datensicherheit, was aber heutzutage mit einem einigermaßen gut aufgestelltem Firewallsystem und einer entsprechend ausgerüsteten, entmilitarisierten Datenzone kein Hexenwerk mehr sein sollte.

Nearline-Anbindung

Eine Nearline-Anbindung basiert auf einem automatisierten Datenaustausch zwischen dem Shopsystem und dem ERP. Das passiert jedoch nicht in Echtzeit sondern in entsprechenden Zeitintervallen.

Meist werden in jedem Intervall die relevanten Daten im- bzw. exportiert und dann entsprechende Aktionen auf den jeweiligen Systemen angestoßen. Die Zeitintervalle werden frei gewählt und können der Nearline-Anbindung durch enge Abstände fast schon die Charakterzüge eine Onlien- Anbindung geben.

Der Vorteil ist, dass der Datenkanal nicht permanent geöffnet ist und so potentiellen Angreifern kein offenes Tor zur Verfügung steht. Nichts desto trotz muss auch hier peinlichst geanu auf die Datensicherheit der Anbindung geachtet werden.

Der Nachteil bei dieser Art der Anbindung ist, dass immer, zu jedem gewählten Zeitpunkt, die Datenverbindung neu aufgebaut werden muss. Ob nun Daten fließen oder nicht. Dadurch kann ein erhöhter Traffic auf der Leitung entstehen und zu Lasten der Performance der Systeme führen, da immer wieder neu auf die Daten zugegriffen werden muss.

Offline-Anbindung

Eine Offline Anbindung ist heute nicht mehr relevant und macht eine Kopplung der Systeme recht unattraktiv. Sobald die Daten nur noch auf Anweisung des Sachbearbeiters transferiert werden, kann es ganz schnell zu differierenden Systemen kommen, dessen Datenbestand nichts mehr mit einander zu tun hat.

FacebookXINGGoogle+TwitterLinkedInweitere
Dieser Eintrag wurde veröffentlicht in eCommerce/eShops, ERP/Warenwirtschaft. Fügen Sie den permalink zu Ihren Favoriten hinzu.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *