NETVERSYS die Integrationsmaschine
NETVERSYS bietet eine Vielzahl von Möglichkeiten an, wie Versandaufträge von Vorsystemen wie ERP, WMS oder Shopsystemen übertragen werden können. Der Vorsprung zu anderen Marktteilnehmern wird hier besonders deutlich, da dort oft nur ein Weg der Übertragung angeboten wird, welcher für die aktuell genutzte Umgebung nicht immer ideal sein muss. Wir skizzieren in den nächsten Absätzen die verschiedenen Möglichkeiten mit NETVERSYS eine Dateninteraktion herzustellen.
##Möglichkeit 1: Übertragen von Aufträgen via HTTP REST Webservices
NETVERSYS bietet mit seiner HTTP/REST Webservice Schnittstelle eine moderne und einfache Möglichkeit Aufträge in das System zu übertragen. Dabei unterstützt NETVERSYS sowohl JSON, als auch XML als Payload. Die Struktur zwischen den beiden Formaten ist hierbei natürlich einheitlich. Der Vorteil von HTTP/REST liegt auf der Hand: Im Gegensatz zu SOAP basierten Webservice Schnittstellen, ist es bei REST viel einfacher möglich Daten zu übermitteln. Es reicht hierbei schon ein einfacher Kommandozeilenaufruf unter Linux mit cURL oder mit Putty unter Windows. Weitere Testclients wie Insomnia erleichtern das Testen im noch größerem Maßstab.
Nutzer von NETVERSYS sind also in der Lage in sehr kurzer Zeit eine funktionstüchtige Schnittstelle herzustellen und das von jedem System, welches das HTTP Protokoll beherscht.
Abbildung 1: "REST Testclient Insomnia mit JSON Payload"
##Möglichkeit 2: NETVERSYS holt periodisch Aufträge von einem FTP Server
Eine Variante zur Übertragung via HTTP/Rest stellt das Pollen von definierten JSON oder XML Dateien auf Kunden-FTP Servern dar. Hierbei nutzt der Kunde die gleichen Formate wie bei HTTP/Rest, legt diese jedoch nur auf dem Filesystem ab. Es entfällt also das aktive Übertragen des Kundensystems zu NETVERSYS, da sich in diesem Fall NETVERSYS über einen periodischen Auftrag die Dateien selbst über FTP herunterlädt. Nach dem Herunterladen verarbeitet NETVERSYS diese Aufträge genauso wie einen via REST eingelieferten Auftrag, sodass der Prozessflow zu 100% identisch ist.
Die Entscheidung ob ein Auftrag direkt prozessiert und gedruckt wird, oder in einem Auftragspool zur späteren Verarbeitung via Scannen eines Barcodes plaziert wird, kann übrigens als einfaches Flag in dem Request ausgedrückt werden. Diese Möglichkeit gilt für viele Schnittstellenvarianten von NETVERYS. Das sehr mächtige Feature des NETVERSYS Auftragspools kann an einer anderen Stelle nachgelesen werden.
Abbildung 2: "Organisations- und Vertriebssysteme"
##Möglichkeit 3: NETVERSYS holt Aufträge on Demand über kundengetriebene NETVERSYS-Listener
Das Plugin- und Listenersystem von NETVERSYS erlaubt weit mehr als nur die Datenanlieferung und geht hin bis zur Erweiterung von NETVERSYS Funktionalitäten innerhalb der Anwendung mit eigenen Bildschirmmasken. Hier wollen wir uns aber mit das Konzept der individuellen Datenanlieferung mit eigens für den Kunden geschriebenen Code befassen.
Es ist in NETVERSYS mittels Implementierungen spezieller Interfaces möglich, individuelle Systeme mit Hilfe von komplett individuellen Code zu integrieren. Für die reine Datenanlieferung sind sogenannte Listener vorgesehen. Nach dem Scan eines Barcodes im NETVERSYS-Versandbereich wird automatisch ein Event ausgelöst und NETVERSYS schaut sofort, ob es einen registrierten Listener gibt, der dieses Event bedienen möchte. Als Rückgabe dieses Events können unter anderem die Versanddaten ein Bestandteil sein. Diese Daten werden dann für den weiteren Prozessflow benutzt.
Die Vorteile liegen auf der Hand. Durch den Einsatz von Java Code gibt es praktisch keine Grenzen mehr woher die Daten kommen können. Im einfachsten Fall ist es eine Datenbank des Kunden. Es können aber auch Message-Queues, Webservice-Endpoints oder noch ausgefallenere Integrationen sein. Alle aktiven Listener in NETVERSYS kann man unter dem Menüpunkt "Systemintegration" -> "Listener" einfach einsehen.
##Möglichkeit 4: NETVERSYS fragt periodisch definierte Kundendatenbanken ab
Neben der vorher genannten Möglichkeit mit eigens programmierten NETVERSYS-Listenern auf Kundendatenbanken zuzugreifen hat NETVERSYS das Thema "fremden Datenbankzugriff" auch als Standardfeature integriert. Hierbei ist es möglich ganz ohne Code via Einstellungen in NETVERSYS einen Datenbank-Pollermechanismus einzurichten.
Hierbei wird in periodischen Intervallen die Kundendatenbank auf neue Datensätze abgefragt. Werden neue Datensätze gefunden, so werden diese automatisch in den Auftragspool gelegt. Die Zuordnung von kundenspezifischen Datenbankfeldern zu den relevanten Werten Objektattributen in NETVERSYS wird über kundenindivuelle Mappings bewerkstelligt. Der Vorteil ist hierbei, das ein Feldmapping einfacher zu handhaben ist als eine eigens zu entwickelnde Schnittstelle in Java.
Abbildung 3: "Übersicht der TCPIP Verbindung zum E+P System"
##Möglichkeit 5: NETVERSYS Standardimplementierungen von speziellen Vorsystemen
Mit der Ehrhardt + Partner Schnittstelle bietet NETVERSYS eine tiefe Integration zum E+P WMS an. Hierbei ist es möglich bis auf TCPIP Socketebene die Schnittstelle zu betrachten und sogar die letzten Telegramme, die über die jeweiligen Verbindungen transferiert wurden, zu betrachten. Auch bei dieser Schnittstelle kann entschieden werden ob die Aufträge direkt prozessiert oder aber in den Auftragspool transferiert werden sollen.
Neben der Betrachtung der Schnittstelle ist es außerdem möglich mit Hilfe des E+P Interface Simulators (siehe Link im ersten Screenshot ganz unten) die Schnittstelle mit eigenen Telegrammen zu testen, die nicht originär aus einem echten E+P System kommen. Dies eröffnet sehr gute Testmöglichkeiten in Systemumgebungen, wo entweder nur ein E+P Produktivsystem zur Verfügung steht oder wo ein Nachstellen innerhalb des E+P System zu aufwendig ist.
Abbildung 4: "Übersicht der TCPIP Verbindung zum E+P System"
Abbildung 5: "Telegrammansicht (letztes Telegramm) einer ausgewählten Verbindung"
##Fazit
NETVERSYS ist mit hoher Wahrscheinlichkeit die Versandsoftware am Markt mit den meisten Optionen wie Versandauftragsdaten in das System kommen können. Darüberhinaus ist die Standardschnittstelle über HTTP/Rest auf dem Stand der Zeit und orientiert sich nicht zwingend an Logistiksystemen am Markt, sondern an Systemen wie Twitter oder Google, die ähnliche Technologien für System-zu-System Kommunikation einsetzen.
