Der Universalkonnektor x.con

Transkript

1 Der Universalkonnektor x.con System-/Medien- und Plattformübergreifender Datenaustausch SOAP und WEB-Services alternativ nutzen? Nürnberg Seite 1 von 10

2 Problemstellung: Heutige IT-Systemlandschaften, insbesondere in mittelständischen Unternehmen, sind heterogen gewachsen. Das bedeutet eine Vielzahl von spezialisierten Anwendungen sind mehr oder weniger gut miteinander gekoppelt um die Ablauforganisation im Unternehmen zu unterstützen. Darüber hinaus steigen die Anforderungen im Hinblick auf die Vernetzung dieser Systeme über die Unternehmensgrenzen hinaus zu Kunden, Lieferanten oder externen Dienstleistern. Diesen Forderungen im Markt wurde mit der Entwicklung von funktional orientierten Ansätzen wie z.b. EDI (Electronic Data Interchange) bzw. systemarchitektonischen Ansätzen wie z.b. EAI (Enterprise Application Integration) oder neuerdings die SOA (Service Orientierte Architektur) begegnet. Insbesondere die Modelle EAI und SOA bieten vielfältige Möglichkeiten zur Konsolidierung, sind jedoch nur mit hohem technischem und wirtschaftlichem Aufwand umzusetzen und somit für KMU s oder sogar gehobene Mittelständler nur schwer oder gar nicht zu realisieren. Klassische Schnittstellenprogrammierung ist trotz der bekannten Nachteile (Pflege, Versionierung, Changemanagement, ) in diesem Marktsegment noch immer das Mittel der Wahl. Lösung: Der Universalkonnektor der kann beliebige Daten, Datenstrukturen oder Formate in beliebige andere überführen. Die Erstellung und Abbildung beliebiger Schnittstellen, zwischen beliebigen EDV-Systemen, welche sofort lauffähig sind, ist jetzt mit einem endanwendertauglichen Tool möglich. Dies wird durch ein graphisches Mapping und vordefinierten Funktions- und Attributbibliotheken realisiert. Programmierkenntnisse sind nicht notwendig. Herausragende Eigenschaft ist, entgegen dem aktuellen Stand der Technik, hierbei ohne Codegenerator zu arbeiten, also als Arbeitsergebnis ausdrücklich keinen Code zu generieren. Sei es nun als direkt ausführbarer Programmcode oder als Service im Rahmen einer SOA (Service Orientierte Architektur). Der Konnektor stellt eine Symbiose aus EDI Konverter (Electronic Data Interchange) und modernen Datenintegrationstools aus dem Kontext EAI (Enterprise Application Integration) und SOA (Service Orientierte Architektur) dar. Der Konnektor bildet somit einen Brückenschlag zwischen bewährter Technik (EDI) und modernen, aber noch nicht durchgängig praxistauglichen, IT-Infrastrukturansätzen (EAI/SOA). Abb. 1: Prinzipskizze Datenbank CSV XML html ASCII EDIFACT VDA beliebiges Eingangsformat und Struktur Kovertrierung durch visuelles Mapping (KEIN CODEGENERATOR) Bildung von Funktionsclustern Attributzordnung Manipulation Datenbank EDIFACT ORDERS RECADV... XML CSV... beliebiges Ausgangsformat und Struktur Bisher gab es bekannte Anwendungsgebiete beim Mapping von EDI-Nachrichten und der Datenintegration in SOA-Architekturen nur mit Blickrichtung auf die spezifische Aufgabenstellung. Ein allgemeingültiger übergreifender Standard fehlt bis dato Nürnberg Seite 2 von 10

3 Beispiele Werden z.b. Artikelstammdaten aus einem ERP Systems via EDI an ein anderes ERP System übertragen, ist das hierfür verwendete Mapping und das Format nicht geeignet z.b. ein Shopsystem mit den entsprechenden Daten zu versorgen. Hierfür würde eine neue Schnittstelle z.b. im XML oder CSV Format programmiert werden, welche im Grunde die gleichen Daten überträgt. Es fehlte bis heute ein praktikabler Ansatz welcher bewährtes (EDI) mit neuen Architekturen (EAI/SOA) wirtschaftlich sinnvoll und damit für den Mittelstand bezahlbar kombiniert. EDI (Electronic Data Interchange) Beim EDI wird auf Basis bestehender Formate VDA / EDIFACT / ODETTE... und Meldungsarten INVOICE / ORDER / RECADV über Mappings die Beziehung von Feldinhalten aufgebaut. Zugehörige Parameter wie z.b. ein Sprachkennzeichen werden i.d.r. im Rahmen manueller Nacharbeit zugeordnet. => klassischer businessto-business (B2B) Ansatz basierend auf application-to-application (A2A) also der Kommunikation zwischen Anwendungen (innerhalb einer Organisation). Vorteil: bewährte / verbreitete Technologie mit gewissen Grundnormungen im Bezug auf die Datenstrukturen. Unternehmensübergreifender Datenaustausch ist mit Einschränkungen über die o.a. Meldungstypen oder individual Schnittstellen möglich. Nachteil: Der Ansatz ist nicht allgemeingültig und auf den Datenaustausch über EDI Konverter beschränkt. Die Mappings generieren Code in dem bei Abweichungen vom Standard manuell nachprogrammiert werden muss. Die hierfür benutzten Codegeneratoren sind proprietär und i.d.r. Anbieter spezifisch. SOA (Service orientierte Architektur) Beim Mapping im SOA-Umfeld geht es eher um die Datenintegration von Quell- zu Zielsystem mit Sourcegenerierung, um diesen Source gekapselt als Service im Rahmen einer SOA Architektur nutzen zu können. => klassischer EAI/SOA Ansatz basierend auf der Objektorientierung. Vorteil: Allgemeingültiger Ansatz zur Integration verschiedenster Systeme in eine Firmenweite einheitliche IT- Infrastruktur Nachteil: komplex, kostspielig, die beteiligten Systeme müssen zur SOA Architektur kompatibel sein oder in diese überführt werden können. Dies setzt mindestens ein Systemdesign nach objekt-orientierten Regeln voraus. Bestehende IT-Infrastrukturen im Mittelstand oder selbst im gehobenen Mittelstand erfüllen diese Kriterien nicht. Unternehmensübergreifende Integrationen sind selbst dann nicht problemlos möglich, wenn beide beteiligten Partner zwar über eine SOA Architektur aber über unterschiedliche Quell- und Zielsysteme verfügen, da SOA über keinen allgemeingültigen Standard verfügt. Jedes Mapping (auch kleinste Varianzen) generieren einen Source und somit einen neuen Service => die Klassenbibliothek wächst unaufhörlich um proprietäre, nicht wiederverwendbare Services. Resumé Zwar gibt es heutzutage in beiden Umfeldern (EDI / SOA) Mapping Designer, welche Mappings visuell beschreiben und hieraus Code generieren, dieser muß aber i.d.r. im Nachhinein manuell überarbeitet werden. In der Praxis liegt der Anteil der Programmierung im so erzeugten Code bei ca % um die 100%ige Erfüllung der Anforderung zu gewährleisten. Die Versionierungs- und Vererbungsfähigkeiten solcher Tools beschränken sich auf den initial generierten Code, somit auf die benannten ca. 70%. Eine Änderung des visuellen Mappings erfordert dann eine Re-Implementierung der manuell bearbeiteten Programmteile Nürnberg Seite 3 von 10

4 Quer gedacht Beim Universalkonnektor der wird ein abweichender Ansatz verfolgt. Nicht Mapping mit Codegenerierung sondern Mapping durch Bildung von Funktionsclustern ohne Codegenerierung. Kundenindividuelle Funktionen, Attribute, Parameter, Prüfungen werden der Funktionsbibliothek zugeführt. Dies können auch bestehende Funktionen wie z.b. JAVA Beans sein. Der Universalkonnektor wird somit zu einer standardisierten Datendrehscheibe für beliebige Anwendungen innerhalb und außerhalb eines Unternehmens. Ende Start Ausgangsformat z.b. DELFOR oder XML für einen Onlineshop oder CMS (Content Management System) Eingangsformat (Datei / Datenbank) z.b. VDA 4905 oder Artikelstammdaten aus einem ERP System Parser (out) Notationsbeschreibung (out) z.b. EDIFACT 1:1 Mapping der Feldinhalte Parser (in) Notationsbeschreibung (in) z.b. VDA 1:1 Mapping der Feldinhalte Inhouseformat (out) Inhouseformat (in) Übergang / visuelles Mapping / Bildung von Funktionsclustern Abb. 2: Die prinzipielle Funktionsweise des Universalkonverters Der Konvertierungsprozess kann rekursiv erfolgen. D.h. das generierte Ausgangsformat kann wiederum als Eingangsformat in den Prozess einlaufen. Details hierzu unter Beispiel für einen Funktionscluster. Besonderer Bedeutung kommt hierbei den Parsern und dem Übergang / dem grafischen Mapping zu. Die Funktionsweise dieser Module wird unter dem Punkt Technische Funktionalitäten und relevante Parameter näher beschrieben. Die Hauptinnovation ist der Ersatz von Codegenerierung durch die Funktionsbibliothek, welche wiederum Services beinhalten kann. Hierdurch werden SOA-Logiken abgebildet ohne die hierfür sonst notwendige Infrastruktur (Middleware, Servicebus, ) aufbauen zu müssen. Da objektorientierte Regeln und abstrakte Klassen in dem Entwicklungsansatz umgesetzt werden, ist der Universalkonverter ein JAVA basiertes Tool, mit modularem Aufbau Nürnberg Seite 4 von 10

5 Technische Funktionalitäten und relevante Parameter Programmiersprache für die Datendrehscheibe ist JAVA, um einen plattformunabhängigen Einsatz sicherzustellen. Ebenso wurden objektorientierte Ansätze im Hinblick auf den modularen Aufbau, als auch auf die aufzubauenden Klassen beachtet. Zur Realisierung des Universalkonnektors wurde ein Komponenten Framework entwickelt, welches den objektorientierten Ansatz auch bei Nutzung des Tools durch den Endkunden sicherstellt. Der Universalkonnektor ist sowohl Anwendungs- als auch Funktionsseitig modular aufgebaut. Dies wird zum Einen über eine Modulbibliothek erreicht, welche beliebig erweiterbar alle Programmteile der Anwendung beinhaltet und zum Anderen über eine Funktionsbibliothek, welche in sich gekapselte Funktionen für den Aufbau eines dedizierten Funktionsclusters praktisch per drag and drop zur Verfügung stellt. Die Modulbibliothek beinhaltet ebenso eine Workflowengine, welche die zeitliche und sequentielle Steuerung der Programmteile übernimmt. Modulbibliothek Workflowengine Übertragen FTP SFTP EDI http x-400 Box Datenträger Lesen ASCII CSV XML Datenbank VDA EDIFACT Parsen / Verarbeiten Schreiben ODETTE VDA Datenbank XML CSV ASCII Formale Prüfung / Notationsbeschreibungen (lesen / schreiben) Signieren Archivieren Tab. 1: Prinzipieller Aufbau der Modulbibliothek: Da in der Modulbibliothek neben den Modulen: Lesen, Verarbeiten / Parsen, Schreiben auch Module für die Übertragung, Signatur und Archivierung umgesetzt wurden, kann der Universalkonnektor nicht nur als Datendrehscheibe für unterschiedliche Anwendungen innerhalb einer Unternehmens IT-Infrastruktur im Sinne der Enterprise Application Integration arbeiten, sondern auch mit Anwendungen außerhalb dieser Systemgrenzen im Sinne des Electronic Data Interchange. Eine SOA Architektur ist hierfür jedoch nicht mehr notwendig, kann aber mit Services den Universalkonnektor ein- und ausgehend ansprechen. Da beliebige Daten- oder Datenbankformate im In- und Output verarbeitet werden können, kommt dem zugehörigen Parser ein entsprechender Stellenwert zu, da mit Hilfe des grafischen Mappingtools aus beliebigen Eingangsdaten ein Inhouse Format und aus diesem das Zielformat generiert wird. Das Mapping kann rekursiv in Schleifen ablaufen, um bestehende Mappings kombinieren zu können. Bsp. Format A nach B, B nach C, anstatt von A nach C. Im Gegensatz zu der heute üblichen Methode, dies über einen Codegenerator abzuwickeln, greift der Universal-konnektor auf vorhandene Funktionsbibliotheken zu. Mit dem grafischen Mappingtool kann so eine direkte Orchestrierung von Funktionen, Services, Parametern, Prüfungen und Konstanten erfolgen. Die Überführung eines Feldinhaltes in einen anderen ist beliebig. Mit dieser Architektur können Änderungen auf Funktionsebene in übergeordnete Strukturen und Mappings vererbt werden. Somit können auch Datenübernahmen bei einem Systemwechsel mit Funktionen wie der Konsistenz-, Format- und Qualitätsprüfung der zu übernehmenden Daten aus beliebigen Datenquellen heraus erfolgen Nürnberg Seite 5 von 10

6 Grafisches Mapping Feld 1 (in) Funktionscluster Feld 1 (out) Feld 2 (in) Funktionscluster Feld 2 (out) Feld 3 (in) Funktionscluster Feld 3 (out) Feld 4 (in) Funktionscluster Feld 4 (out).. Feld n (in) Funktionscluster Feld n (out) Funktionsbibliothek Funktionen zur Datenmanipulation Gruppe 1 Gruppe 2 Funktion 1 Funktion 2 Funktion 3 Funktion 4 Funktion 5 Funktion 6 Funktion n Funktionen zur logischen Prüfung Gruppe 1 Gruppe 2 Funktion 1 Funktion 2 Funktion 3 Funktion 4 Funktion 5 Funktion 6 Funktion n Parameter Parameter 1 (in) Parameter 1 (out) Parameter 2 (in) Parameter 2 (out) Parameter n (in) Parameter n (out) Konstanten Konstante 1 (in) Konstante 1 (out) Konstante 2 (in) Konstante 2 (out) Konstante n (in) Konstante n (out) Tab. 2: Prinzipieller Aufbau des grafischen Mappingtools und der Funktionsbibliothek Funktionsbeispiele Copy, Delete, Insert, MwSt. berechnen, EAN Nr. generieren / prüfen, Prüfziffern generieren / prüfen, USt-ID. prüfen, Format umstellen, Termine berechnen, Währungen umrechnen, Wechselkurse ermitteln,.. Funktionsweise der Grafischen Abbildung der Strukturen Es wird die Struktur einer Schnittstelle in Ihre Wiederholungsgruppen (Satzarten) und deren Datenelemente (Felder) im System definiert. Hierbei können unterhalb einer Satzart - Felder und auch weitere Satzarten existieren. Dieser Prozess ist einmalig notwendig. Diese Vereinheitlichung der Schnittstellenstrukturen bildet die Basis der Strukturabbildung. Die Pflege der Strukturen erfolgt mittels eines hierfür entwickelten grafischen Editors. Der Anwender wird mittels dieses Editors in die Lage versetzt werden z.b. die Struktur einer eingehenden Standard EDI Meldung anhand der Schnittstellenbeschreibung abbilden zu können Nürnberg Seite 6 von 10

7 Das Prinzip soll an folgendem Screenshot erläutert werden: Schnittstelle (in) zerlegt in Satzarten und Feldinhalte Funktionscluster Schnittstelle (out) zerlegt in Satzarten und Feldinhalte Der Funktionscluster welcher die eigentliche Transformationsleistung erbringt, kann nach dem Legoprinzip aus einzelnen Funktionen, Parametern und Konstanten aus der Funktionsbibliothek mittels drag & drop vom Anwender, vergleichbar zur Erstellung komplexer Formeln in EXCEL, generiert werden. (Siehe hierzu auch: Tab. 2: Prinzipieller Aufbau des grafischen Mappingtools und der Funktionsbibliothek) Fehlende Konvertierungsfunktionen Fehlende Funktionen können über einen Editor im Bausteinsystem zusammengeklickt werden und als Funktionscluster abgespeichert werden. Bausteinsystem heißt hierbei, dass der Ausgabewert einer Funktion wiederum der Eingabewert einer weiteren Funktion sein kann. Die Bausteine sind Funktionen und Funktionscluster aus der vorhandenen Bibliothek. Wir möchten hierfür als Prinzipvergleich Microsoft EXCEL bemühen. Die originären Funktionen werden zur Verfügung gestellt. Diese sind selbstverständlich programmiert, wie diese jedoch verkettet oder verschachtelt werden und welche Parameter / Variablen eingesetzt werden obliegt dem Anwender. (Siehe hierzu auch: Tab. 2: Prinzipieller Aufbau des grafischen Mappingtools und der Funktionsbibliothek) Die Funktionen werden entweder von ELDICON, Entwicklungspartnern oder vom Kunden selber erstellt, welche über die entsprechenden Programmierkenntnisse (JAVA) verfügen. ELDICON übernimmt dabei die Konformitätsprüfung und Versionierung von durch Kunden oder Partnern Nürnberg Seite 7 von 10

8 erstellten Funktionen. Die neu erstellten Funktionen werden dann im Rahmen von Updates der Community zur Verfügung gestellt. Die Community kann dann diese Funktionen wieder in eigene Funktionscluster einbinden. Das Prinzip der Funktionsbibliothek folgt objektorientierten Strukturen. Sehr komplexe Funktionen können zusätzlich mit externen Programmen kommunizieren, z.b. auch als /mit Webservices um die gewünschte Funktion zu gewährleisten. Das Ergebnis wird im Anschluss wieder als Ausgabewert der Funktion bereitgestellt. Beispielsweise könnte eine solche Funktion mit einem externen Server kommunizieren um eine USt.-Ident-Nr. zu validieren. Der Hauptunterschied zu bestehenden Mappingtools liegt im Wegfall eines Codegenerators begründet. Funktionscluster werden out of the box aus der Funktionsbibliothek gebildet. Beispiel für einen Funktionscluster bei der Konvertierung eines Formates in ein anderes: Im Feld 1 des Eingangsformates steht ein Mindesthaltbarkeitsdatum im Format dd.mm.yyyy. Das Zielformat benötigt dieses jedoch im Feld 4 im Format yy-mm-dd und zusätzlich im Feld 5 die Anzahl der verbleibenden Tage bis zum Erreichen des Mindesthaltbarkeitsdatums. Über das grafische Mappingtool würden jetzt die benötigten Funktionen zur Formatänderung, Konstanten (z.b. das heutige Datum) und Berechnungsfunktionen per drag and drop orchestriert und so Schritt für Schritt ein komplettes Mapping abgebildet. Da mit dieser Vorgehensweise kein Code generiert wird, welcher abgearbeitet wird, können Änderungen auf Ebene der Einzelfunktionen auf alle bestehenden Aggregationsebenen (Funktionsgruppen, Cluster, Mappings) vererbt werden ohne aufwendig in bestehenden Codes nach genau diesen Änderungsständen suchen zu müssen. Da das Endprodukt keine Programmierkenntnisse voraussetzt und über eine grafische Oberfläche Mappings erstellt werden können, ist ein weiterer innovativer Ansatz im Verteilen der Ergebnisse über eine Community zu sehen. Vom Kunden erstellte Erweiterungen der Funktionsbibliothek oder fertige Mappings werden über einen Schneeballeffekt zur Erweiterung der konvertierbaren Formate führen. Beispiel: Kunde A erstellt ein Mapping vom XML-Format in eine VDA Meldung 4905 (Lieferabruf). Kunde B erstellt ein Mapping von VDA 4905 (Lieferabruf) auf EDIFACT DELFOR (Lieferabruf). Kunde C erstellt ein Mapping von EDIFACT DELFOR (Lieferabruf) auf CSV. Der Community stehen damit durch den rekursiven Mappingprozess sämtliche Konvertierungen in die Formate VDA 4905, EDIFACT DELFOR und CSV oder aus den Formaten VDA 4905, EDIFACT DELFOR, XML in beliebiger Kombination zur Verfügung Nürnberg Seite 8 von 10

9 Kunde A: Eingangsformat: XML Ausgangsformat: VDA 4905 Kunde B: Kunde C: Eingangsformat: VDA 4905 Eingangsformat: EDIFACT DELFOR Ausgangsformat: EDIFACT DELFOR Ausgangsformat: CSV => Kunden A/B/C: Eingangsformate: XML VDA 4905 EDIFACT DELFOR Ausgangsformate: VDA 4905 EDIFACT DELFOR CSV Abb. 3: Mapping in der Community Vorhandene Mappings werden kopiert, geändert, versioniert und können historisiert werden. Durch den Aufbau des Mappings aus der Funktionsbibliothek heraus, können Vererbungslogiken von Einzelfunktionen über Funktionsgruppen bis hin zu den Funktionsclustern und dem eigentlichen Mapping umgesetzt werden. Eine bedeutende Effizienzsteigerung kann somit durch die Wiederverwendung einmal erstellter Konvertierungen erzielt werden. Eine vorhandene Schnittstelle zwischen zwei Anwendungen welche z.b. Artikelstammdaten von einem ERP System (ORACLE Datenbank) z.b. in einen WEB-Shop (MySQL Datenbank) überträgt kann kopiert, abgeändert und dann z.b. zur Übertragung der Artikelstammdaten in ein Katalogerstellungstool oder Contentmanagementsystem (MS-SQL Datenbank) genutzt werden. Produkte, Verfahren, im direkten Vergleich Führende Anbieter von Integrationsplattformen sind z.b. BEA mit dem WEBLOGIC Server, jetzt ORACLE WEBLOGIC Server, oder auch SAP netweaver. Im Grunde dienen diese Produkte im IT-Markt der Erstellung einer SOA als Grundvoraussetzung für die Nutzung der standardisierten Konnektivität zwischen Systemen, welche in dem jeweiligen Technologieumfeld kompatibel sind. Umgekehrt bedeutet dies aber auch, dass es keinen allgemeingültigen Standard gibt. Eine mit netweaver erzeugte SOA ist nur mit entsprechender Anpassung wiederum für eine mit dem WEBLOGIC Server erzeugte SOA kompatibel. Allen Ansätzen gemein ist die Nutzung von Services welche über Codegeneratoren erzeugt werden. I.d.R. werden diese Services als gekapselte WEB-Services zur Verfügung gestellt. Das heißt aber auch, wenn in einer IT Landschaft 8 von 10 genutzten Systemen auf SOA umgestellt werden können, müssen für die 2 Systeme welche dies z.b. aus technischen Gründen nicht können, weiterhin manuelle Schnittstellen erzeugt werden oder diese Systeme ausgetauscht werden. Im Grunde genommen sind diese Integrationsplattformen, sehr komplexe, Entwicklungswerkzeuge um in einem mittlerweile etablierten Schichtenmodell aus Daten, Logik und GUI (Graphic Userinterface / Dialog) eine zusätzliche Schicht, die sogenannte Middleware, zwischen Daten und Logik einzuziehen. Aus diesem Grund kommen diese Produkte überwiegend im Konzernumfeld oder bei Großfirmen zum Einsatz. Unser Entwicklungsansatz nutzt zwar die einer SOA zu Grunde liegenden Ideen, macht eine SOA aber Nürnberg Seite 9 von 10

10 nicht zur Grundvoraussetzung. Der Universalkonnektor kann ohne Eingriff in die vorhandene IT-Infrastruktur eines Unternehmens oder Unternehmensnetzwerkes, als Datendrehscheibe zwischen fremdartigen Systemen fungieren und proprietäre Schnittstellen durch systematische Abbildung in einem Standard ersetzen. Die Kernaufgabe von EAI und SOA Ansätzen, nämlich beliebige Systeme miteinander kommunizieren zu lassen, wird auch hiermit, aber zu einem Bruchteil der Kosten, erfüllt. Die Grundidee ist hierbei SOA-Architekturen in die Schnittstelle zu verlagern, anstatt die Quellsysteme auf diese Architektur zu stellen. ELDICON verfolgt hiermit den Einstieg in den Markt für Integrationsplattformen im EAI Umfeld ebenso wie in Randbereiche der SOA Thematik durch Abdeckung der Integrationslücken welche durch nicht zur SOA kompatible EDV-Systeme innerhalb einer IT-Infrastruktur entstehen. Es wird hier jedoch ein im Vergleich zu diesen Architekturen weniger theoretischer, denn ein praktischer Ansatz mit entsprechendem wirtschaftlichen Mehrwert insbesondere für mittelständische Unternehmen erzielt. Für weitere Informationen stehen wir Ihnen gerne jederzeit zur Verfügung: 2011 alle Rechte vorbehalten Nürnberg 0911 / (Tel.) 0911 / (FAX) info@eldicon.de Nürnberg Seite 10 von 10