RESTful Web Services miteinander verbinden

stromerome

Kabelverknoter(in)
Hey,
ich google mich nun schon seit einigen Tagen durch sämtliche Themen zu RESTful Web Services.
Der Hintergrund ist, dass ich ein cloudbasiertes ERP System (Actindo Core One) via RESTful Web Services mit der eines Lieferanten verbinden möchte. Es sollen Daten in beide Richtungen synchronisiert werden.
Vermutlich kann ich das nicht selber, daher habe ich bereits bei Twago ein Gesuch gestartet, jedoch möchte ich schon verstehen wie es funktioniert.

Wenn ich beide Schnittstellen miteinander verbinden möchte, benötige ich dann einen eigenen Webserver oder geht das auch direkt?

Gruß
Jérôme
 
Wenn ich beide Schnittstellen miteinander verbinden möchte, benötige ich dann einen eigenen Webserver oder geht das auch direkt?
Es kommt darauf an, ob es eine bidirektionale Synchronisierung oder eine unidirektionale sein soll. Aber du schreibst, das diese in beide Richtungen erfolgen soll. Das einfachste wäre dann wirklich, das auch auf beiden Seiten ein entsprechender Webserver mit einem für diesen Zweck entwickelten REST-Service läuft. Aber das wichtigste wird werden, die Daten auf beiden Seiten richtig aufzuarbeiten und zu interpretieren. Denn meistens kennt die eine Seite seine Datenbank und seine API's, aber nicht die der anderen Seite. Aus diesem Grund arbeiten wir in der Zulieferer-Logistik auch nicht mit einem automatisierten Avisierungsverfahren über Services, sondern entweder teilanalog oder über Speditions- und/oder kundeneigenen Portalen. Für ein solches Vorhaben muss die Partnerschaft schon sehr eng und vor allem sollte man aufeinander komplett angewiesen sein, damit sich so ein technischer Aufwand lohnt.

Aber in den allermeisten Fällen stirbt diese Idee relativ schnell. Denn Kunden sowie Zulieferer arbeiten meist nicht nur für/mit einem Partner, sondern meist mit mehreren dutzend Partnern und es wird schwierig, eine Umstellung/Erweiterung der IT des jeweils anderen einzufordern. Die Kosten für solche Schritte sind meist erheblich und gerade dem Lieferanten/Zulieferer bringt es am wenigsten. Und am schlimmsten wird es, wenn er es auf Teufel komm raus nicht schafft, seinen Datenbestand in ein sinnvolles übertragbares Format bekommt, welches von der anderen Seite verstanden wird. Dann wird nämlich mit manueller Eingabemaske gearbeitet, was den Verwaltungsaufwand erhöht und dadurch noch unatraktiver wird.

Oder anders gesagt. Was im ersten Moment wie eine gute Idee klingt, wird meist zu einem erheblichen Kostenfaktor und die Wahrscheinlichkeit ist groß, das die andere Seite das ganze abschmettert.

Sollte aber tatsächlich auf beiden Seiten das gleiche System sitzen, dann kommt es darauf an, in wie weit das ganze konfiguriert werden kann. Können beide Cloud-Services Daten über die REST-API empfangen sowie REST-Anfragen selbst tätigen (REST-/HTTP-Client) und die Authentifizierung bedienen, dann sollte es auch direkt und vergleichsweise leicht möglich sein. Da ich aber das Actindo Core One überhaupt nicht kenne, kann ich dazu nicht mehr sagen. Sollte die API aber keinen Client haben (also selbst keine REST-Requests absetzen können), wirst du über einen Server als Vermittler nicht drumherumkommen. Denn dieser muss als Client und Schleuse für die Daten dienen. Er fragt in regelmäßigen Abständen auf beiden Seiten an, ob es neue Daten gibt und wenn ja, holt er sie ab und schickt sie an die andere Seite. Und dann wird das ganze unter Umständen heftig. Denn du musst in diesem Falle dann auch vorab prüfen, ob du die Integrität der Daten gewährleisten kannst und ob die API dazu Funktionen bietet, die es beiden Seiten ermöglicht, den Datenbestand auf Korrektheit und Vollständigkeit zu prüfen. Und daran scheitert es oft und wird zur erheblichen Fehlerquelle.

Unzuverlässiger Datentransfer kann Unternehmen viel Geld kosten. Sehr viel Geld! Bei solchen Vorhaben ist Datenintegrität alles! Sind Mitarbeiter auf Grund unzuverlässiger Daten 1.000 Stunden im Jahr damit beschäftigt, das ganze gerade zu rücken, dann wird das Teuer. Und es fällt im ersten Moment vielleicht nicht einmal auf. Aber bei 230 Arbeitstagen sind das 4,3 Stunden pro Tag. verteilt sich das auf mehrere Mitarbeiter, sind das vielleicht pro Mitarbeiter nur 15 Minuten. Aber am Ende des Jahres sind es gesamt eben 1.000 Stunden auf der Verlustrechnung und je nach Stundenlohn macht das 15.000 bis 25.000 € nur dafür, weil das System die Integrität nicht gewährleisten kann und dadurch Fehler ausgebessert werden müssen.

Validiere also alles genau, bevor du dich zu früh an die Umsetzung machst. Je mehr du in die Wege leitest, bevor du genug darüber weißt, umso heftiger wird der Auschlag, wenn das ganze fällt. Teures Lehrgeld ;)
 
Hallo DataDino,
da ich noch weitere Lieferanten anbinden möchte, die sicherlich alle die Daten unterschiedlich liefern werden, ist es wohl das sinnvollste wenn ich
a: meinen ERP Anbieter die Anbindungen machen lasse
oder b: die Daten erst über eine eigen Webschnittstelle speichere und dann für Actindo aufbereite.
Wenn ich die Daten nun bei mir importieren möchte, welche Möglichkeiten kannst du da empfehlen? Ich persönlich komme eher mit Microsoft als mit Linux klar.
Habe mich schon ein bissle eingelesen, MS Server 2016 Lizenzen, Hardware, Feste IP usw. ist natürlich vorhanden. Oder wäre sowas wie XAMPP deutlich einfacher?
Gruß
Jérôme

PS: vielen Dank für deine mega ausführliche Antwort.
 
XAMPP ist für einen Einsatz im produktiven Umfeld nicht geeignet. Ansonsten würde ich es mir so einfach wie möglich machen und entweder einen NGINX oder einen Hiawatha nutzen. Die sind leicht zu konfigurieren und sicher, wenn du auch an die Verbindungsverschlüssellung und das Zertifikat denkst.

Bei den Datenbanken kannst du ebenfalls auf die offenen/freien Varianten setzen. Eine MySQL, MariaDB oder PostgreSQL ist schnell installiert, eingerichtet und auch für Winndows verfügbar. Je nachdem, was du für Daten und wie strukturiert ablegst, kann man auch auf ein Datenbank-System verzichten.

Die Frage ist nur eben, was du wie auf welchem Wege "importieren" willst. Hast du dir schon Gedanken über den Workflow gemacht? Davon ist jede weitere Entscheidung abhängig. Wie sollen die Lieferanten damit arbeiten? Was wird an Daten übermittelt? Bestellungen? Transportavisierungen? Technische Dokumente? Für präzisere Eingebungen bedarf es also doch ein paar mehr Informationen ;)

PS: Die Schnitstellen auf die IT der Lieferanten anzupassen ist ein Fass ohne Boden. SAP, MS Dynamics, Averp und tausende andere Tools müssen nach und nach beachtet werden. Je nach Einsatzzweck freunde dich auch unter Umständen damit an, für diesen Zweck eher eine RIA zu liefern, als nach und nach die IT-Abteilungen der Lieferanten antanzen zu lassen, bis ihr alles synchron habt.
 
Zuletzt bearbeitet:
PS: Die Schnitstellen auf die IT der Lieferanten anzupassen ist ein Fass ohne Boden. SAP, MS Dynamics, Averp und tausende andere Tools müssen nach und nach beachtet werden. Je nach Einsatzzweck freunde dich auch unter Umständen damit an, für diesen Zweck eher eine RIA zu liefern, als nach und nach die IT-Abteilungen der Lieferanten antanzen zu lassen, bis ihr alles synchron habt.

Es ist ja nicht nur der Initialaufwand.
Die Systeme werden laufend angepasst und da ist schnell eine Schnittstelle geändert ohne das dir jemand Bescheid gibt.
Was dann wieder in fehlerhaften Daten endet.
 
Es ist ja nicht nur der Initialaufwand.
Die Systeme werden laufend angepasst und da ist schnell eine Schnittstelle geändert ohne das dir jemand Bescheid gibt.
Was dann wieder in fehlerhaften Daten endet.

Was dann aber nicht unbedingt für die Entwickler der Schnittstellen spricht, wenn diese (die Schnittstellen) extra dafür gemacht wurden, um "Fremde" (bzw. Kunden/Geschäftspartner) mit dem System kommunizieren zu lassen.
Normalerweise baut man solche Schnittstellen nämlich so, dass es möglichst keine "breaking changes" gibt. Besipielsweise, indem man bei einer REST-API in der URL eine Versionsnummer einbaut (z.B. /api/v1/items) und diese nach *zwingenden* Inkompatibilitäten erhöht, damit eben auch ältere Programme noch mit der Schnittstelle klar kommen können. Eine Ausnahme wäre es natürlich, wenn die Änderungen zwingend aufgrund von Systeminterna gemacht werden müssen, sodass die alte Schnittstelle nicht mehr verwendet werden kann.
 
Ich würd mal behaupten, dass es nicht wirklich soweit kommt, dass SAP oder MS eine Schnittstelle für das Vorhaben des TE in ihre Applikationen integriert.
Also bleibt nur die Möglichkeit, die Daten direkt aus der DB von SAP, MS Dynamics oder was auch immer zu fischen (was oben als ich als Schnittstelle bezeichnete).
Jedoch tritt dann das von mir genannte Problem auf, dass wenn man die Daten aus 100 Systemen fischt man immer schauen muss ob die Datenbankstruktur oder die Daten darin geändert haben.
Was dann eben einen ziemlichen Aufwand darstellt um das im Auge zu behalten.
 
Hallo,
ich danke euch für die nützlichen Infos.
Der aktuelle Stand ist wie folgt:
Am 07.11 bekommen wir das update auf Actindo Core 1. Dann bekommen wir auch die Doku zu der Actindo Schnittstelle. Wir haben nun einen Entwickler der sich dann der Sache annimmt. Ich würde seinen Vorschlag zu Umsetzung dann hier nochmal posten.
Gruß
Jérôme
 
Zurück