Dieser Artikel ist outdated. Schnittstellen und Services zum Datenaustausch mit Fremdsystemen bietet die logistische Integrationsplattform loggPRO.net.
Zu den wohl am häufigsten zu beobachtenden – oder mittels processPRO feststellbaren (!) – Unstetigkeiten (nennen wir es mal so) im alltäglichen betrieblichen Ablauf aus der Sicht der IT gehören Doppelerfassungen von Daten. Der volkswirtschaftliche Schaden, der dabei entsteht, ist so immens, dass man inzwischen die Güte eines Systems völlig zu Recht u.a. an dessen Fähigkeit zu einer möglichst aktiven Kooperation mit anderen Systemen misst.
Der nachfolgende Artikel belegt, dass TransObjects® ein sehr offenes System ist, dass diverse Möglichkeiten in dieser Hinsicht bietet und die Interaktion mit anderen Systemen aktiv eingeht.
Vor ein paar Jahren hat einer unserer Kunden bei einem der führenden und börsennotierten Anbieter von ERP-Lösungen wegen einer Schnittstelle angefragt. Die Antwort lautete „selbstverständlich“, die Schnittstelle werde verfügbar gemacht, unter lizenzrechtlichen Auflagen (insb. Geheimhaltung) und gegen eine Lizenzgebühr in Höhe von 50’000,- € !
Ein Größenwahn? Das sicherlich auch, zumal das betreffende Unternehmen unaufhaltsam wächst, was dem Management, das derartige Verträge eingeht nicht gerade das beste Zeugnis ausstellt. Aber eine nicht minder wichtige Ursache hierfür liegt klar auf der Hand: das betreffende System ist schlicht nicht up-to-date! Es ist veraltet, daher nur unter schier unermesslichem Aufwand mutierbar und ausserdem unter sicherheitsrelevanten Gesichtspunkten nicht richtig konzipiert, weshalb die Geheimhaltung eine so wichtige Auflage darstellt.
Wir können den Leser beruhigen. Nachfolgend findet er eine (kostenlose ) Beschreibung der TransObjects®-Schnittstellen, ferner von Szenarien, in denen eine Interaktion mit anderen Systemen zustande kommen kann und dies zu bewerkstelligen ist.
Zu den wohl häufigsten Szenarien, in denen sich die Ausgangsfrage stellt, gehört in etwa das Folgende: Ein Unternehmen verfügt über ein betriebsinternes System für Auftragsbearbeitung, das über Jahre hinweg, gewissermassen organisch, gewachsen ist, so dass man sich hiervon nur ungern trennen möchte. Mangels Alternativen legt man sich aber TransObjects®-Software für Warenabfertigung zu, etwa atlasPRO, edecPRO oder was auch immer. Nach erfolgreicher Inbetriebnahme stellt man rasch fest, dass viele Daten, obwohl diese schon einmal im Auftragswesen erfasst worden sind, zwecks Warenabfertigung erneut erfasst werden müssen.
Ein anderes Szenario: Ein Unternehmen, mit dem ein TransObjects®-Anwender kooperiert, möchte diesem Auftragsdaten auf elektronischen Wege zukommen lassen und den fertig bearbeiteten Auftrag wieder zurückbekommen, um ihn z.B. finanzbuchhalterisch weiterverarbeiten zu können.
Beide Fälle sind ähnlich gelagert. Es geht im Wesentlichen um zweierlei Fragen: Wie kann ich eine TransObjects®-Datenbank mit Daten versorgen bzw. wie kann ich aus der TtansObjects®-Datenbank Daten herauslesen. Beides sollte natürlich ohne Informationsverlust stattfinden und möglichst automatisiert ablaufen.
Um Letzterem zu genügen, bedarf es zu allererst einer gemeinsamen Sprache, die allseits verstanden werden kann, also geht es um ein Datenformat. Da der sog. „Object Dump“ doch recht proprietär war, schwenkte die K&S Anfang der 2000’er auf das XML ein, was das Format für multidimensionale (also auch objektorientierte) Datensätze schlechthin war und inzwischen einen beachtlichen Bekanntheitsgrad errungen hat. So gibt es inzwischen unzählige Softwareprodukte, die – ein bestimmtes Schema vorausgesetzt – Daten in XML-Form aufbereiten bzw. diese aus einem XML-File herauslesen können. Das senkt schon mal vorab den anstehenden Programmieraufwand in einem nicht unbeträchtlichen Masse.
Verständigt man sich also bei den Formaten auf einen inzwischen weit verbreiteten Standard á la XML, so kann man mit dem Aufbau eines Interaktiven Systems zur Koppelung des eigenen TransObjects®-Systems an externe Systeme (oder umgekehrt) beginnen. Als mögliche Datenaustauschwege gibt es wie bei den Formaten auch schon eine Vielzahl von unterstützten Protokollen, deren bloße Auflistung den Rahmen des vorliegenden Artikels völlig sprengen würde. Aber auch hier gibt es eines dem der Vorzug zu geben ist und das gerade im Zusammenhang mit dem XML immer wieder genannt wird (www.xml.org, vgl. auch SOAP), nämlich das HTTP(S), darunter insbesondere die sog. Webservices.
Es gibt eine ganze Reihe von Vorteilen, die die Webservices mit sich bringen. In einem Satz: Sie sind verhältnismässig einfach in eigene Umgebung zu integrieren, weisen aber gleichzeitig ein akzeptables Sicherheitsniveau auf und sind bidirektorial einsetzbar, d.h. auch um bestimmte Daten aus der TransObjects®-Datenbank herauszulesen.
Was muss also letzten Endes jemand tun, der z.B. Auftragsdaten einem Beauftragten User zur Weiterverarbeitung (etwa Verzollung) in dessen TransObjects®-Datenbank schicken möchte? Ganz einfach: diese in XML-Form lt. Schema aufbereiten und aufs „DFÜ“ legen, wobei dieses „DFÜ“ vorzugsweise ein Webservice sein sollte und nur in zweiter Linie evtl. etwas anderes, wie z.B. SMTP(S), FTP(S), FTAM, X.400, WEBDAV oder was auch immer.