Inhalt
3 Theoretische Grundlagen
3.1 Enterprise Application Integration
3.1.1 Definition
Enterprise Application Integration ist in den letzten Jahren ein wichtiges Schlagwort geworden. Der Begriff ist sehr treffend, denn er beschreibt genau, worauf es ankommt: Unternehmensweite Integration der Anwendungen. Eine scharfe Abgrenzung zu anderen Softwaregebieten ist nicht immer herstellbar. Eine mögliche Definition lautet: "Enterprise Application Integration (EAI) bezeichnet die Planung, die Methoden und die Software, um heterogene, autonome Anwendungssysteme unternehmensweit oder -übergreifend unter Einhaltung bestimmter Protokolle und unter Vermeidung von Abhängigkeiten zu integrieren." (Hasselbring/Reichert 2004, S.I)
Software, die Anwendungsintegration leistet, kann zur Familie der Middleware gezählt werden. Denn Middleware bezeichnet "Mechanismen und Techniken, die dazu dienen, die Interaktion zwischen getrennten Softwarekomponenten zu ermöglichen [...]." (Hansen/Neumann 2002, S.166)
Einen Eindruck von EAI geben die folgenden Mottos (Nußdorfer 2002, S.10ff):
# "Freiheit für Geschäftsprozesse": Die Geschäftsprozesse werden aus der eingeschränkten System- und Unternehmenssicht befreit und eine globale Sicht darauf ermöglicht.
# "Integrieren statt Telefonieren": Manuelle Eingriffe werden reduziert, da täglich anfallende Geschäftsprozesse automatisiert ablaufen können.
# "Generieren statt Codieren": Es ist kein herkömmliches Schreiben von Programmcode notwendig. EAI-Tools bieten die Möglichkeit, durch grafische Oberflächen die betroffenen Geschäftsobjekte und -prozesse sowie die Datenschemata und Mappingregeln möglichst einfach zu definieren.
Integrationsebenen
Application Integration kann auf mehreren Ebenen angesetzt werden. In der Literatur findet man unterschiedliche Einteilungen, die von drei bis zu sechs Ebenen reichen. Diese sind jedoch alle sehr ähnlich und unterscheiden sich nur in ihrem Detailgrad der Unterteilung, daher wird hier beispielhaft eine der zutreffendsten Definitionen ausgewählt (Liebhart 2002, S.25f und Dangelmeier et al. 2001, S.20f):
# Datenintegration:
Datenbanken oder sonstige Datenspeicher tauschen reine Daten untereinander aus, um jeweils mit aktuellen und konsistenten Daten zu arbeiten. Dies wird erreicht, indem durch Migration alle relevanten Daten zwischen den betroffenen Systemen regelmäßig übertragen und abgeglichen werden.
Eine konsequentere Variante der Datenintegration ist die Verwendung eines einzigen Datenhaltungssystems mit einem unternehmensweit integrierten Datenschema. Dies ist jedoch schwierig zu bewerkstelligen, wenn bestehende Applikationen integriert werden sollen und daher nur sinnvoll bei neu zu entwickelnden Anwendungen.
# Methodische / funktionale Integration oder API-Integration:
Bei dieser Art der Integration werden vorhandene Funktionen und Methoden der eingesetzten Systeme automatisiert von anderen Systemen aufgerufen und zur gegenseitigen Kommunikation verwendet. Somit können Funktionalitäten zum Datenzugriff oder zur Prozessausführung an einer Stelle implementiert und von mehreren Stellen aus verwendet werden.
# Integration auf der Ebene der Benutzerschnittstelle:
Diese eher primitivere Art der Integration wird auch als Refacing bezeichnet. Eine einheitliche Benutzerschnittstelle wird verwendet um auf mehrere integrierte Systeme zuzugreifen. Dies wird im Normalfall durch grafische Oberflächen erreicht, meist auf Basis eines Webportals.
Diese Ebene wird häufig mit der funktionalen Integrationssebene zur "Anwendungsintegrationsebene" zusammengefasst.
# Geschäftsprozess-Integration:
Geschäftsprozesse werden in der Integrationssoftware abgebildet und von dieser anhand von Workflows ausgeführt. Die Definition der Prozesse kann oft ohne IT-Kenntnisse erfolgen, indem diese durch Business Rules beschrieben werden. Teilprozesse und einzelne Geschäftsvorgänge, die in mehreren Prozessen Verwendung finden, werden einmalig definiert und an mehreren Stellen eingesetzt. Als Schnittstelle zwischen dem System und dem Benutzer kann eine Art Arbeitskorb (Boles et al. 2004, S.60) dienen, in dem manuell zu behandelnde Dokumente abgelegt und vom Benutzer asynchron bearbeitet werden.
Durch die Einbeziehung der Geschäftsprozesse auf der betriebswirtschaftlichen Ebene unterscheidet sich EAI von der herkömmlichen Middleware. Diese agiert hauptsächlich auf der technischen Ebene.
Gut implementierte Geschäftsprozesse ermöglichen es, Straight-Through-Processing (STP) durchzusetzen. Dies bedeutet einen direkten und raschen Ablauf des Geschäftsprozesses mit einem Minimum an manuellen Eingriffen und Medienbrüchen .
Integrationspartner
Als Integrationspartner kann man sich drei Möglichkeiten vorstellen (Schmidt 2002, S.81):
* Applikationsintegration (A2A) bedeutet, dass unternehmensintern die Applikationen vernetzt werden.
* Partnerintegration (B2B) ermöglicht die automatisierte Kommunikation der eigenen Systeme mit denen von Partnern wie beispielsweise Zulieferern.
* Kundenintegration (B2C) stellt Schnittstellen bereit, über die Endkunden automatisiert mit dem Unternehmen kommunizieren können.
Technische Grundlage
Eine zentrale technologische Rolle im Bereich Anwendungsintegration spielen heutzutage XML-Techniken. XML ist zum etablierten Standard für Datenspeicherung und -austausch geworden. Detailliertere technische Informationen zu XML im Allgemeinen und speziell zu den für diese Arbeit relevanten Techniken siehe Kapitel 3.2. Hier sollen zunächst mögliche Techniken für die Umsetzung der vier beschriebenen Integrationsebenen aufgelistet werden.
Prozessintegration --> WSFL
User-Interface-Integration --> XSLT
Funktions-Integration --> SOAP
Datenintegration --> DTD, XML-Schema
3.1.2 Nutzen für Unternehmen
Jedes Unternehmen besitzt - je nach Größe und Branche - eine Vielzahl an unabhängigen Softwaresystemen: ERP, CRM, SCM, Officeanwendungen, Spezialanwendungen, Webportale und viele mehr. Da diese Systeme im Idealfall mit gleichen Daten arbeiten müssen, ist die logische Konsequenz, diese mit Schnittstellen untereinander zu verbinden. Im Extremfall, das heißt wenn jedes System mit jedem verbunden ist, entstehen hierbei n(n-1)/2 Schnittstellen für n Systeme. Diese sind mit einem sehr hohen Wartungs- und daher auch Kostenaufwand verbunden. Dieser Aufwand entsteht dadurch, dass jede Software ihr eigenes Datenformat zum Importieren und Exportieren verwendet und sich somit jede Schnittstelle von den anderen unterscheidet. Hinzu kommt, dass Schnittstellen, die bereits längere Zeit bestehen, oft schlecht dokumentiert sind und sich daher sehr unflexibel anpassen lassen.
| |
Abb. 3: Reduktion der Schnittstellenzahl beim Hub-and-spokes-Prinzip |
Eine Lösung für dieses Problem ist das "hub-and-spokes"-Prinzip. Ein System
- die Nabe - steht in der Mitte und hat je eine Schnittstelle zu jedem System - die Speichen. Alle Kommunikation zwischen zwei Systemen läuft über den Mittelpunkt ab. Dadurch reduziert sich die Zahl der Schnittstellen auf n (siehe Abbildung 3).
Ähnlich verhält es sich mit dem Bus-Prinzip. Alle angeschlossenen Systeme wandeln ihre Daten in ein gemeinsames Format um und geben sie über den Bus frei. Systeme, die an diesen Daten interessiert sind, greifen diese von dem Bus ab und setzen sie in ihrer Schnittstelle in das systemeigene Format um.
Ein weiterer Aspekt ist die Einbindung der Geschäftsprozesse. Das Vorhandensein eines zentralen Systems ermöglicht es, Geschäftsprozesse, die in diesem System abgebildet sind, auszuführen; und das über alle betroffenen Systeme im Unternehmen hinweg. Dadurch wird die Notwendigkeit vieler manueller Eingriffe reduziert, die bisher zur Überwindung der Lücken zwischen den Systemen notwendig waren. Dies steigert die Produktivität im Unternehmen enorm.
Auch über die Unternehmensgrenzen hinaus bietet EAI Vorteile, die ausgeschöpft werden können. Eine automatisierte Anbindung von Zulieferern, Kunden und sonstigen Partnern beschleunigt die Abwicklung gemeinsamer Geschäftsaktivitäten. Anstatt von Mitarbeitern, die auf herkömmlichem Weg wie Telefon, Telefax, Post oder Email Dokumente austauschen, wird dies automatisch von den IT-Systemen erledigt; und dies schneller und sicherer. Bei der gemeinsamen Ausarbeitung solcher Schnittstellen muss kein Unternehmen befürchten, sich hierbei zu sehr in die Karten schauen zu lassen. Es ist nicht nötig, das System und die internen Datenformate offenzulegen. Einzig die Schnittstelle und das Format der ausgetauschten Daten muss beiden bekannt sein. Der Rest, also das IT-System und die dazugehörigen Prozesse, sind eine Black Box.
Die Vorteile lauten zusammengefasst:
+ Langfristig gesehen werden durch die Reduktion der Anzahl der Schnittstellen Kosten und Zeit gespart.
+ Neue Software lässt sich wesentlich einfacher in die Systemwelt integrieren, da keine große Anzahl an neuen Schnittstellen hierfür entwickelt werden muss.
+ Die Lebensdauer von Legacy-Systemen wird erhöht, wenn sie effektiv in die Systemlandschaft integriert sind.
+ Die Datenhaltung unterschiedlicher Systeme ist besser aufeinander abgestimmt, das heißt die unternehmensweite Datenkonsistenz wird verbessert.
+ Geschäftsprozesse werden systemübergreifend abgebildet, was deren Ablauf deutlich beschleunigt.
+ Die Anbindung von Partnerfirmen und Kunden wird vereinfacht.
3.1.3 Auswahl der geeigneten Software
Der Markt der EAI-Software-Anbieter war in den letzten Jahren starken Fluktuationen unterworfen (Dangelmeier et al. 2001, S.10). Dies wurde vor allem dadurch deutlich, dass neue kleine Firmen auftauchten, andere Firmen übernommen wurden oder fusionierten und auch große Softwareschmieden die Chance nicht verpassen wollten und auf dem Markt einstiegen oder sich einkauften.
Die meisten Anbieter hatten zu Beginn mit ihrer Software nur einen Teil der EAI-Funktionalitäten abgebildet. Erst mit der Zeit haben sie den Trend erkannt und ihr Angebot erweitert, um ein breites Spektrum an Anforderungen erfüllen zu können. Glaubt man den eigenen Angaben der meisten Anbieter, so ist jeweils ihr eigenes Produkt allumfassend und löst alle Probleme. In der Realität liegen jedoch die Schwerpunkte bei den Produkten auf dem Markt unterschiedlich. Manche Lösungen konzentrieren sich eher auf Datenextraktion, -transformation und transport. Andere wiederum bieten mehr Möglichkeiten im Bereich der Geschäftsprozessmodellierung.
Als Kriterien für die Systemauswahl können unter anderem folgende Punkte dienen (nach Dangelmeier et al. 2001, S.3):
# Wie funktioniert die Anbindung der Systeme? Das eingesetzte Produkt muss entsprechende Adapter mitliefern oder diese müssen nachrüstbar oder gegebenenfalls einfach selbst zu programmieren sein.
# Wie sehen die Entwicklungswerkzeuge zur Schnittstellenbearbeitung aus? Es ist wichtig, ob die Implementierung durch eine GUI mit Drag&Drop, eine Programmiersprache oder durch deklarative Methoden anhand von Business-Rules erfolgt. Ebenfalls wichtig ist, wie das Tool one to many-Architekturen abbildet.
# Welche Anzahl an Adaptern lässt sich bei entsprechender Performance einsetzen? Wie gut skaliert das System bei einer großen Anzahl an Transaktionen?
# Wie ist die Architektur der Runtime-Engine? Auf den verschiedenen Integrationsebenen sind die Architekturen jeweils unterschiedlich effektiv.
# Können eigene Geschäftsprozesse modelliert werden? Dies ist nicht bei allen Produkten selbstverständlich.
# Wie ist der zusätzliche Service des Anbieters? Dieser muss angemessene Beratung und Unterstützung bei der Integration bieten können.
# Welche Kosten verursacht das Produkt? Hierbei müssen Anschaffungs-, Lizenz- und Betriebskosten des eigentlichen Systems ebenso beachtet werden wie die Kosten für zusätzliche Komponenten.
Da EAI-Systeme mit hohen Einführungskosten verbunden sind und somit über einen langen Zeitraum im Einsatz bleiben sollen, ist zu beachten, wie die Aussichten sind, dass der gewählte Anbieter auch in Zukunft noch auf dem Markt verfügbar sein wird. Kriterien, dass sich ein EAI-System durchsetzt, sind unter anderem "die Durchgängigkeit der Geschäftsprozesse, die automatisierte Steuerung mehrstufiger Informationsflüsse, die (teil )automatisierte Steuerung von unternehmensübergreifenden Geschäftsprozessen, die Reduktion von Medienbrüchen sowie die einheitliche, integrierte Sicht auf Daten aus unterschiedlichen Systemen" (Schmidt 2002, S.81).
3.1.4 Besonderheiten beim Einführungsprojekt
Es ist so gut wie unmöglich, mit einem einzelnen Projekt ein ganzes Unternehmen zu integrieren. Da ein EAI-System nicht auf der ?grünen Wiese? entsteht, sondern laut Definition in eine heterogene Systemlandschaft integriert wird, wäre es bei einer kompletten Integration nötig, eine große Zahl an Schnittstellen, Prozessen, unterschiedlichen Daten und Wünsche vieler Personen und Abteilungen gleichzeitig zu berücksichtigen.
Dies ist aber gar nicht nötig. EAI-Software eignet sich sehr gut dafür, Stück für Stück eingeführt zu werden. Es bietet sich an, mit einem größeren und wichtigen Integrationsvorhaben zu beginnen und mit diesem erste Erfahrungen zu sammeln.
Modell des Dynamischen Phasenplans
Das Modell des "Dynamischen Phasenplans" (Gunten 2002, S.103) beschreibt dieses Vorgehen. Es werden kleine, klar definierte Releases angestrebt, die in relativ kurzer Zeit erreicht werden können. Hierbei wird ein sequentieller Ablauf verfolgt, der für jedes Release ein- oder mehrfach durchgeführt wird. Änderungen an den Anforderungen werden im nächsten Schleifendurchlauf oder erst im nächsten Release eingebracht. Es besteht die Möglichkeit, zwei Releases gleichzeitig zu bearbeiten, so dass die Anforderungsphase des eines Releases schon begonnen hat, während das vorherige Release sich noch in der Implementierungs- oder Testphase befindet.
Der große Vorteil bei diesem Verfahren ist, dass relativ schnell Resultate sichtbar sind, die produktiv verwendbar sind. Vor allem wird hierbei dem Umstand Rechnung getragen, dass durch Versionsupdates, Schnittstellenänderungen usw. das Umfeld eines EAI-Systems sehr dynamisch ist. Je schneller ein Teilprojekt zu Ende geführt werden kann, umso weniger gleichzeitige Anpassungen sind während der Einführungsphase notwendig. Um den gesetzten Budget- und Zeitrahmen sicher einhalten zu können, wird das Endergebnis des Gesamtprojektes offen gehalten und flexibel an die aktuellen Bedingungen angepasst.
Dieses Vorgehen birgt jedoch auch Gefahren. Es muss auf eine gerechte Kostenverteilung geachtet werden (Pohland/Gutzweiler 2002, S.17). Die Kosten für die Einführung der Software sollten zu einem Großteil vom Unternehmensbudget für die Infrastruktur getragen werden und nicht ausschließlich von dem ersten Integrationsprojekt. Denn für ein einzelnes Integrationsvorhaben wäre die Alternative der eigens dafür programmierten Schnittstelle zwar nicht die bessere, aber sicher die günstigere Entscheidung. Einspareffekte werden jedoch erst bemerkbar, wenn mit einem System mehrere Integrationen durchgeführt werden.
Außerdem sollte man nicht komplett ohne Zielvorgabe die Integration angehen. Eine Übersicht ist notwendig, um anfängliche Integrationsschritte zu vermeiden, die im Nachhinein - im Gesamtkontext betrachtet - unpassend oder unnötig erscheinen.
Ein interessanter Aspekt ist die Tatsache, dass viele Projekte in gewisser Weise auch Integrationsprojekte sind, selbst wenn sie nicht als solche deklariert wurden. Denn ein Teilbereich vieler Projekte ist es, bestehende Systeme, Prozesse und Daten teilweise miteinander und einem neuen System zu verbinden.
3.1.5 Geschichte und Abgrenzung
Historische Entwicklung
Aufgrund der oben beschriebenen Probleme beim Einsatz unterschiedlichster Systeme in einer heterogenen IT-Landschaft war die Entwicklung der Enterprise Application Integration die logische Konsequenz und unausweichlich (Nußdorfer 2002, S.10ff).
Der erste Schritt in diese Richtung war der Einsatz der einst neuen Middleware-Konzepte. Diese Softwarekomponenten unterstützen den Datenaustausch zwischen Applikationen durch ihre Services wie Datenumsetzung, -überprüfung und -pufferung.
Ausgehend von diesen Umsetzungen wurden in den neunziger Jahren erste "Enterprise Application Integration"-Konzepte entwickelt. Entsprechende Plattformen erlaubten die Kommunikation zwischen Anwendungen über Nachrichten. Die Anbindung bestehender Standardsysteme, wie zum Beispiel SAP, geschah über vorgefertigte Adapter. Mit der Zeit wurde darüber hinaus durch die Einbindung von Geschäftslogik der pure Datenaustausch mit der Steuerung von Prozessabläufen erweitert.
Für die Zukunft ist abzusehen, dass EAI in immer mehr Unternehmen und Branchen Einzug halten wird. Es ist wohl keine zu gewagte Prognose zu behaupten, dass sie in einigen Jahren zur Selbstverständlichkeit geworden sein wird.
Webservices
Eine vieldiskutierte Möglichkeit der Anwendungsintegration ist der Einsatz von Webservices.
Bei den Webservices (Bengel 2004, S.267ff) bieten Applikationen über Webserver ihre Dienste an. Die Kommunikation basiert auf dem verbreiteten Übertragungs¬protokoll HTTP, die Daten werden mit dem XML-basierten Simple Objects Access Protocol (SOAP) verpackt. SOAP arbeitet nach dem Request-Response-Prinzip. Eine Applikation sendet per SOAP einen Request und erhält die Response ebenfalls per SOAP. Um die Applikationen untereinander lose zu koppeln, wird ein Namensdienst (= Service Registry) eingesetzt, bei der Anwendungen ihre Dienste registrieren können und andere Dienste abfragen können. Für die Beschreibung der Schnittstellen gibt es die Web Service Description Language (WSDL), welche ebenfalls auf XML basiert.
Wenn alle Systeme im Unternehmen ihre Dienste als Webservices anbieten, können diese untereinander beliebig genutzt werden. Dies ermöglicht eine sehr dynamische Art der Integration, da keine proprietären Protokolle verwendet werden und die Verwaltung der Dienste sehr flexibel über die Service Registry möglich ist. Die HTTP-basierte Kommunikation ermöglicht auch eine Integration über Netzwerkgrenzen hinaus. Es müssen allerdings einige Sicherheitsaspekte besonders beachtet werden.
Webservices sind jedoch keine vollwertige Alternative zu typischen EAI-Lösungen. Sie sind noch nicht komplett ausgereift und decken bisher nur einen Teil der Problematik ab (Boles et al., S.57). Sie können daher nur in speziellen Fällen allein zur Applikationsintegration eingesetzt werden und sollten meist eher als Unterstützung gesehen werden.
3.2 XML und weitere Standards
3.2.1 XML
XML steht für "Extensible Markup Language", was etwa als "erweiterbare Auszeichnungssprache" übersetzt werden kann. Es handelt sich hierbei um eine Metasprache für Textdateien. XML ist ein weltweit geltender Standard, für den sich das World-Wide-Web-Consortium (W3C) einsetzt .
Alle Informationen werden in Textform gespeichert, die auch für den Menschen lesbar ist, und deren Bedeutung anhand Tags beschrieben, welche ebenfalls reiner Text sind. Eine XML-Basiseinheit wird "Element" genannt und besteht aus Daten, einem die Daten umschließenden Tag und dazugehörigen Attributen.
|
 Abb. 5: Aufbau eines XML-Elements (nach Zhao, S.4) |
XML ist mit HTML vergleichbar (sie entstanden beide aus der gleichen Sprache, SGML). Es besteht jedoch ein großer Unterschied. Während bei HTML die Bedeutung der Tags vorgegeben ist (Beispiel: <u> steht immer für "unterstrichen"), wird diese bei XML individuell definiert. Hier kann <u> viele Bedeutungen haben, wie beispielsweise "Uhrzeit" oder "Untergruppe". Dadurch eignet sich XML sehr gut, um Daten für die verschiedensten Anwendungszwecke zu speichern und zu transportieren. Banken können Tags für Kontoinformationen definieren, Musiker anhand Tags Musiknoten beschreiben oder Softwareprogramme ihre Konfigurationseinstellungen aus XML-Dateien auslesen. Der Vielfalt sind kaum Grenzen gesetzt.
Ein Hauptaspekt von XML ist die strikte Trennung von Daten und deren Darstellungsformat. Während in einer XML-Datei reine Daten stehen, wird die Beschreibung, wie diese angezeigt oder verwendet werden, üblicherweise an anderer Stelle abgelegt. Somit können dieselben Daten für verschiedene Anwendungszwecke verwendet werden, beispielsweise ein Produktkatalog sowohl für das Drucken von Prospekten als auch für einen Onlineshop.
XML Spezifikation
In der XML-Spezifikation wird lediglich die Grammatik der Sprache vorgeschrieben, jedoch nicht der Wortschatz. Sie legt fest, wie Tags aussehen, wo sie in einem Dokument auftreten können und wie deren Name aufgebaut ist. Es wird nicht definiert, welche Elemente bzw. Tags es gibt und welche nicht. Es wäre ohnehin nicht möglich, alle denkbaren Möglichkeiten aufzulisten. Daher werden die erlaubten Elemente und deren Bedeutung pro Anwendung von den beteiligten Parteien festgelegt. Das macht die Sprache erweiterbar, woher das "X" im Namen stammt.
Dokumente, die sich komplett an die Spezifikationen halten, werden "wohlgeformt" genannt. Dokumente, die nicht wohlgeformt sind, sind vergleichbar mit Programmcode, der einen Syntaxfehler aufweist. Ebenso wie ein Syntaxfehler vom Compiler bemängelt wird, werden nicht-wohlgeformte Dokumente von XML-verarbeitender Software nicht angenommen.
DTD und XML Schema
Für jede spezifische XML-Anwendung muss genau festgelegt sein, welche Elemente verwendet werden dürfen, wo und wie verschachtelt sie auftreten dürfen und wie deren Inhalt und Attribute aussehen (Harold/Means 2005, S.29f). Die ursprüngliche Art, dies festzulegen, sind die mit XML 1.0 entwickelten Document Type Definitions (DTD), welche in einer formalen Syntax geschrieben werden.
Als Weiterentwicklung von DTD wurde 2001 XML Schema vom W3C veröffentlicht. XML Schema ersetzt DTD mit der Zeit in immer mehr Bereichen, da es deutlich mächtiger ist.
Dies sind die entscheidenden Vorteile von XML Schema gegenüber DTD: (Vonhoegen 2005, S.109f):
+ XML Schemata selbst sind auch in XML geschrieben, was die Verwendung und das Beherrschen einer separaten Syntax und eines zusätzlichen Editors vermeidet. Auf sie kann mit den gleichen APIs zugegriffen werden wie auf die Dokumente selbst.
+ Mit XML Schema können im Gegensatz zu DTDs detaillierte Angaben über den Inhalt eines Elements gemacht werden, unter anderem zu erlaubten Datentypen, Wertebereichen, Standardwerten usw.
+ DTD ist insgesamt ungeeignet für datensatzähnliche Strukturen. Für solche wurde XML mit der Zeit immer häufiger eingesetzt, obwohl es ursprünglich nicht primär dafür gedacht war.
+ XML Schema ist weniger starr bei der Regeldefinition als DTD.
+ DTDs unterstützen keine Namensräume. Diese werden benötigt, um Elemente gleichen Namens und unterschiedlicher Bedeutungen unterscheiden zu können.
+ XML Schema kann Datenbeschreibungen aus mehreren Dateien zusammenführen, was bei umfangreichen Dateien vorteilhaft ist.
XML-Dokumente können bezüglich einer DTD oder eines Schemas auf ihre Gültigkeit überprüft werden. Das zu überprüfende Dokument wird dann Instanzdokument genannt. Entspricht das Instanzdokument den Vorgaben des Schemadokuments, ist es gültig, ansonsten ungültig.
Parsen
Damit ein Programm den Inhalt einer XML-Datei verstehen kann und ihn nicht nur wie eine übliche Textdatei behandelt, benötigt es einen Parser. Der Parser schlüsselt die Datei in ihre Bestandteile wie Elemente und Attribute auf und übergibt diese der Applikation. Wenn dem Parser der Speicherort des dazugehörigen Schemas oder DTDs bekannt ist, kann er gleichzeitig die Gültigkeit des Dokuments überprüfen. Dann wird er validierender Parser genannt. Stößt ein Parser auf eine Schemaverletzung oder auf einen Fehler in der Wohlgeformtheit, unterbricht er das Parsen und meldet den Fehler der Applikation. Diese kann beliebig darauf reagieren, beispielsweise kann sie das Parsen abbrechen oder weiterführen, um die Fehler selbst zu behandeln (Harold/Means 2005, S.29). Weiterhin ist es jeder Applikation überlassen, wie sie mit den Daten umgeht. Beispiele sind die Präsentation der Daten (Webbrowser), Bearbeitung der Daten (Textverarbeitung) oder Speichern der Daten (Datenbank).
Es gibt zwei grundlegende Möglichkeiten, einen Parser aufzubauen. Diese werden als DOM und SAX beschrieben (Anderson et al. 2000, S.47f).
DOM steht für Document Object Model und wurde vom W3C als offizielle Empfehlung verabschiedet. Ein DOM-Parser liest das XML-Dokument komplett ein und legt es als Baumstruktur im Speicher ab. Um auf die Knoten und Blätter dieses Baumes zuzugreifen und diese zu manipulieren, stellt DOM eine API zur Verfügung.
SAX (Simple API for XML) stellt ereignisbasierte Zugriffsmöglichkeiten auf XML-Dokumente zur Verfügung. SAX arbeitet ein Dokument stückweise ab und gibt Ereignismeldungen an eine Anwendung weiter. Diese haben etwa die Form "hier beginnt dieses Element; hier endet ein Element". SAX wurde unabhängig vom W3C zunächst als Java-API entwickelt, liegt mittlerweile aber auch für viele andere Programmiersprachen vor.
Aufgrund der unterschiedlichen Vorgehensweisen der beiden Parser eignen sie sich für unterschiedliche Anforderungen und keinem von beiden kann pauschal der Vorzug gegeben werden. Ein SAX-Parser hat den Vorteil, dass er relativ klein ist. Außerdem wird bei ihm im Gegensatz zu DOM nicht das komplette Dokument im Speicher gehalten, wodurch er vor allem bei großen Dateien deutlich weniger Ressourcen benötigt. Hingegen bieten nur DOM-Parser die Möglichkeit, problemlos auf wahlfreie Stellen im Dokument zuzugreifen und diese zu manipulieren.
Keine Programmiersprache
Der XML-Hype der letzten Jahre hat extreme Ausmaße angenommen, die der Sprache XML nicht vorhandene Fähigkeiten zugeschrieben haben. XML ist eine Markup-Sprache und keine Programmiersprache. Es existieren keine Elemente für die Steuerung von Programmabläufen. Im Normalfall ist es daher nicht möglich, direkt aus einem XML-Dokument ausführbaren Code zu erzeugen. XML wird höchstens dazu verwendet, Konfigurationseinstellungen zu speichern, wofür es wiederum sehr gut geeignet ist. "Ein XML-Dokument existiert einfach. Es tut nichts." (Harold/Means 2005, S. 5)
Portabilität
Durch die Entwicklung von XML ist es nun möglich, Daten so zu speichern, dass sie auf jeder Plattform gelesen und verarbeitet werden können. Im Gegensatz zu proprietären Binärformaten, in denen noch heute viele Applikationen ihre Daten abspeichern, können die Daten bei XML auch noch verwertet werden, wenn die ursprüngliche Software nicht mehr verfügbar ist. Somit sind die Daten nicht mehr abhängig von der Applikation, mit der sie erstellt wurden oder im Extremfall sogar von der exakten Versionsnummer dieser Applikation. Da XML-Dateien reiner Text sind, kann jede Software, die Textdateien lesen kann, mit XML-Dateien umgehen. Diese Punkte zeigen, dass XML in jeder Hinsicht portable Daten liefert.
"Java versprach portablen Code. XML liefert portable Daten." (Harold/Means 2005, S.7)
Geschichte
Die Ursprünge von XML liegen bei der Standard Generalized Markup Language SGML (Harold/Means 2005, S.9). Diese wurde in den 70er Jahren bei IBM erfunden, von vielen Leuten weltweit entwickelt und schließlich 1986 als ISO-Standard angenommen. SGML ist außerordentlich leistungsfähig und wurde erfolgreich in vielen Bereichen - wie Regierung und US-Militär - eingesetzt, um effizient große technische Dokumente zu verwalten.
HTML ist die bisher erfolgreichste Anwendung von SGML. Hierbei wurde dessen Leistungsfähigkeit in großem Maße beschnitten. HTML ist jedoch für den Bereich, für den es entwickelt wurde - nämlich die Darstellung von Webseiten - bestens geeignet.
Der große Nachteil an SGML ist seine Komplexität. Die offizielle Spezifikation umfasst mehr als 150 sehr technische Seiten. Andere Quellen sprechen von insgesamt 500 Seiten des Standards im Gegensatz zu 40 bei XML. Hierin werden mitunter unwahrscheinliche Spezialfälle berücksichtigt, so dass die meisten Applikationen, die SGML implementieren, aus Gründen der Einfachheit nur einen Teil davon umsetzen. Dadurch sind diese jedoch unter Umständen nicht mehr kompatibel zueinander, was den größten Vorteil der Sprache aushebelt.
1996 wurde damit begonnen, eine weniger komplexe Version von SGML zu entwickeln. Durch die Erfahrung der vorangegangenen 20 Jahre konnten viele unnötige, redundante und zu komplizierte Funktionen ausgeschlossen werden, ohne die Leistungsfähigkeit zu beeinflussen. Als Ergebnis wurde im Februar 1998 XML 1.0 herausgegeben. Da eine derartige Markup-Sprache dringend benötigt wurde, wurde XML schnell von vielen Entwicklern angenommen und zu einem großen Erfolg in vielen unterschiedlichen Bereichen. Anfang 2004 wurde die aktuelle Version XML 1.1 freigegeben, welche hauptsächlich Änderungen im Bereich Unicode umfasst.
3.2.2 CIDX
CIDX (siehe www.cidx.org) ist eine Organisation mit dem Ziel, die elektronische Geschäftsabwicklung zwischen Firmen der Chemiebranche und ihren Handelspartnern zu verbessern. Durch die starke Entwicklung des eCommerce kam die Notwendigkeit auf, Datenformate und Geschäftsprozesse zu standardisieren, um den Informationsaustausch effizienter, schneller und zuverlässiger gestalten zu können.
Die freiwilligen Mitglieder der Organisation, zu welchen erfahrene Experten aus der Chemiebranche gehören, stellen Standards und Richtlinien bereit, ebenso wie weitere Materialien zur Unterstützung, die den Anwendern helfen, die Standards zu implementieren. Hinzu kommen Foren, um den Erfahrungsaustausch und die Kommunikation unter den Firmen, deren Handelspartnern und elektronischen Marktplätzen zu ermöglichen. Der Einsatz der beteiligten Firmen für diese Organisation kommt der kompletten Chemiebranche zugute. Daher sind alle Firmen eingeladen, sich an der Entwicklung zu beteiligen. Dies wird durch die drei folgenden Eigenschaften der Standards verdeutlicht:
-> Offen: Um Mitgliedern und Nichtmitgliedern den Einsatz der Standards ohne Entrichtung von Lizenzgebühren zu ermöglichen
-> Neutral: Um aktuelle und neu aufkommende Geschäftsmodelle zu unterstützen
-> Plattformunabhängig: Um keine spezielle Hard- oder Software vorzuschreiben
CIDX ist unterteilt in zwei Bereiche: Chem eStandards, welcher die Entwicklung von XML-Standards zum Ziel hat und Cybersecurity, welcher sich um Sicherheitsaspekte kümmert. Cybersecurity soll hier nicht weiter behandelt werden.
Chem eStandards
Die Chem eStandards beschreiben definierte Nachrichtentypen, die Unternehmen helfen, elektronische Bestellungen und Transaktionen durchzuführen. Beispiele für Nachrichtentypen, die abgebildet werden, sind: Product Catalog Update, Order Create, Ship Notice, Invoice und viele mehr. Hierfür wird ein XML-basiertes Format verwendet, da XML all das nötige Potential bietet.
Weiterhin werden in letzter Zeit "business process guidelines" (BPGs) erarbeitet, um branchenübliche Geschäftsprozesse zu definieren und damit Unternehmen den Einstieg in den elektronischen Handel zu erleichtern.
Im Jahr 2000 schlossen sich die drei großen Firmen der Chemiebranche BASF, Dow Chemical, und DuPont zusammen und lieferten den ersten Entwurf. Die Standards wurden stetig weiterentwickelt und durch neue Nachrichtentypen erweitert. Die aktuell verfügbare Version 4.0, welche im Mai 2004 herausgegeben wurde, beschreibt 60 Transaktionsarten.
Zu den Veröffentlichungen gehören jeweils ausführliche Dokumentationen und Erläuterungen, ebenso wie die detaillierte Spezifikation der Datenformate. In den ersteren Versionen des Standards wurde diese noch als DTDs herausgegeben. Die aktuelleren Ausgaben verwenden hingegen XML Schema.
3.3 Microsoft BizTalk Server
BizTalk Server 2004 ist die Software, die für einen Großteil des praktischen Teils dieser Arbeit verwendet wird. Daher soll anhand dieser Software nun beispielhaft die Funktionsweise von EAI-Systemen erläutert werden.
Geschichte
Ende der 1990er Jahre wurde von Microsoft zusammen mit vielen Unternehmen aus unterschiedlichen Branchen das BizTalk-Framework ins Leben gerufen (siehe Anderson et al. 2000, S.621ff). Dieses stellte unter anderem Containerdokumente zur Verfügung, um die elektronische Abwicklung von Geschäften zu vereinfachen. Als Softwareimplementierung, um den Datenaustausch tatsächlich durchführen zu können, stand zunächst ein Jumpstart-Kit zur Verfügung. Zeitgleich wurde von Microsoft der BizTalk Server 2000 entwickelt.
Im Laufe der Zeit konnte sich die Verwendung des BizTalk-Frameworks in dieser Art nicht durchsetzen. Die Applikation BizTalk Server wurde hingegen weiterentwickelt. Hinzu kam hauptsächlich die Fähigkeit zur Geschäftsprozessintegration.
Die aktuell verfügbare Version ist BizTalk Server 2004. Der Nachfolger BizTalk Server 2006 ist für November 2005 angekündigt .
Service Oriented Architecture
BizTalk Server verfolgt den Ansatz der Service Oriented Architecture (SOA). SOA bedeutet, dass komplexe Geschäftsvorgänge durch Aneinanderreihen von Dienstaufrufen durchgeführt werden. Hierdurch erreicht man die Kapselung der Daten, Vermeidung von Redundanz und gesteigerte Flexibilität bei der Implementierung und Änderung der Geschäftslogik.
Ein weiterer Aspekt der Service Oriented Architecture ist die Art der Implementierung der Programmlogik. Bei herkömmlicher Programmierung definiert ein Business Analyst die Aktivitäten und Geschäftsregeln, welche ein Programmierer dann in ausführbaren Code umsetzt. Diese Vorgehensweise ist mit dem Problem verbunden, dass durch Unstimmigkeiten zwangsläufig mehrere Revisionszyklen durchlaufen werden müssen, was die Implementierung ineffizient und langwierig macht. Hier wird nun anders vorgegangen: Business Analysten und Programmierer greifen auf einen gemeinsamen Arbeitsbereich zu. In diesem können sie in einer grafischen Benutzeroberfläche - meist mit Drag&Drop - alle benötigten Komponenten anordnen und konfigurieren. Diese beinhalten unter anderem Nachrichten, Ereignisse, Geschäftsregeln und logik, Informationsflüsse, Aktivitäten, Transformationen und Teilprozesse. Die Entwicklungsumgebung erzeugt hieraus direkt den dazugehörigen ausführbaren Code. Dieses Vorgehen bietet einige weitere Vorteile:
+ Die Zusammenarbeit von Business Analysts und Programmierern wird deutlich effektiver.
+ Durch die lose Kopplung der Komponenten wird eine hohe Flexibilität erreicht.
+ Hinzufügen, Entfernen oder Ändern von Aktivitäten sind möglich, ohne einen laufenden Prozess zu zerreißen.
+ Das Modell skaliert sehr gut.
+ Komponenten und Applikationen sind nicht nur leicht erweiterbar, sondern auch wiederverwendbar.
+ Zur Kommunikation können Standardprotokolle und das Internet verwendet werden.
| |
Abb. 6 |
BizTalk Server ist eng mit anderen Microsoftprodukten verbunden. Als Fundament wird stets ein SQL Server benötigt. In diesem sind unter anderem die Messagebox, ein Großteil der Konfigurationseinstellungen und Funktionalität in Form von Gespeicherten Prozeduren abgelegt. Als weiteres Produkt kommt Microsoft Visual Studio .NET zum Einsatz. Bei seiner Installation fügt BizTalk Server in Visual Studio einige Editoren hinzu, mit denen alle benötigten Komponenten erstellt und direkt in die BizTalk-Konfigurationsdatenbank überspielt werden können.
Abbildung 6 gibt einen Überblick über den Ablauf von Nachrichten durch die einzelnen Komponenten eines BizTalk Systems. Diese werden im Folgenden mit den dazugehörigen Editoren und ihrer Funktion beschrieben (siehe Woodgate et al. 2004).
Schemata
Der erste Schritt besteht meist in der Definition der Schemata aller betroffenen Daten. Es wird festgelegt, welche Felder in welcher Anzahl enthalten sein müssen oder dürfen, welche Datenformate sie aufnehmen können und weitere Informationen. Die Beschreibung eines Flatfile-Schemas enthält außerdem den genauen Aufbau dieser Datei, wie beispielsweise Abgrenzungszeichen oder Feldgrößen.
Schemata werden bei BizTalk mit dem BizTalk Server Schema Editor definiert und als XML Schema gespeichert. Es können auch vordefinierte Schema¬beschreibungen - beispielsweise als DTD oder XML-Schema - importiert und verwendet werden.
Nachrichten werden im Verlauf ihrer Behandlung im BizTalk Server zum Großteil als Black Boxes behandelt, das heißt, ohne dass das behandelnde Modul Einblick in die Daten oder sogar deren Bedeutung nimmt. Daher müssen Werte, die im Verlauf verwendet werden sollen, höher gestuft (= "promoted") werden. Dies erfolgt ebenfalls im Schema Editor.
Mapping
Als nächstes definiert man mit dem BizTalk Server Mapper, wie die Daten von einem Schema in ein anderes übertragen werden. Die Felder der Quellseite werden mit denen der Zielseite verbunden (siehe Abbildung 7).
Hierbei gibt es viele Möglichkeiten wie reines Kopieren, einfaches Umwandeln der Daten über Zeichenkettenoperationen oder mathematische Operationen bis hin zu komplexeren Operationen. Diese enthalten auch Schleifen über die Datenstruktur oder Mapping auf Daten, die in einer externen Datenbank abgelegt sind. All diese Operationen werden durch so genannte Funktoide repräsentiert. Durch die enge Integration in Visual Studio lassen sich eigene Funktoide programmieren und verwenden.
|
 Abb. 7: Beispiel Mapping |
Pipelines
Im BizTalk Server Pipeline Designer werden Pipelines erstellt, die für die Vor- und Nachverarbeitung von Nachrichten zuständig sind.
Es gibt zwei Arten von Pipelines: Receive-Pipelines und Send-Pipelines. Eine Receive-Pipeline nimmt eine eingehende Nachricht entgegen, entpackt und entschlüsselt diese, zerlegt sie in ihre Einzelteile und authentifiziert den Empfänger. Send-Pipelines führen dieselben Aktionen in umgekehrter Reihenfolge durch: Sie erhalten eine Nachricht im XML-Format von der Runtime-Engine, zertifizieren diese, fügen mehrere Nachrichten zusammen und komprimieren und verschlüsseln die Nachricht. Die meisten dieser Schritte sind optional, je nach Anforderung der Applikation und des Nachrichtenempfängers. Wenn keiner der Schritte benötigt wird, kann eine der beiden Standardpipelines verwendet werden, die BizTalk Server bereitstellt und die die Nachrichten in ihrer ursprünglichen Form durchreicht oder als XML-Nachricht behandelt.
Business Rules
Für die Definition der Geschäftslogik wird ein separates Programm mitgeliefert, das Microsoft Business Rule Composer heißt. Hiermit können umfangreiche Geschäftsregeln implementiert werden. Diese hiermit definierten Regeln werden schließlich in Orchestrierungen eingebunden und verwendet.
Orchestrierungen
Orchestrierungen (= "Orchestrations") sind die Stelle, an der der Ablauf definiert und andere Komponenten miteinander verbunden werden. Sie bilden daher das "Herz" der Integrationsapplikation. Hierfür stehen Kontrollstrukturen wie Schleifen, parallele Abläufe und bedingte Ausführungszweige zur Verfügung. Bestehende Nachrichten werden verarbeitet und transformiert oder neue Nachrichten werden erzeugt. Dabei kann auf Nachrichtenattribute zugegriffen werden, die in den Schemata entsprechend höher gestuft wurden. In der Orchestrierung kann in gewissen Grade damit auch Geschäftslogik abgebildet werden. Bei umfangreicheren Abläufen bietet es sich an, die Logik mit dem oben beschriebenen Business Rule Composer zu definieren und in der Orchestrierung lediglich einzubinden.
Alle Teile einer Orchestrierung werden als so genannte Shapes angeboten und können einfach per Drag&Drop an die entsprechende Stelle der Arbeitsfläche gezogen werden.
Ports
Receive- und Sendports werden in Orchestrierungen angelegt. Hierbei besteht die Möglichkeit, diese bereits komplett zu konfigurieren, beispielsweise zu einem Fileadapter die genauen Angaben wie das Ablageverzeichnis festzulegen ("specify now"). Alternativ dazu kann man diese Angaben zunächst offen lassen ("specify later"). Dies bietet die Möglichkeit, diese virtuellen Ports unabhängig von der Entwicklungsumgebung erst in der Produktivumgebung zu binden und detailliert zu konfigurieren. Dadurch kann die Entwicklung unabhängig von den genauen Begebenheiten der Umgebung durchgeführt werden, auf der das System schließlich laufen soll.
Für einige Fälle bieten sich Mehrfachports an. Ein Receiveport enthält eine oder mehrere Receivelocations. Diese Locations können komplett unabhängig voneinander auf unterschiedliche Einstellungen und Adapter konfiguriert und mit unterschiedlichen Mappings belegt werden. Dadurch können Daten aus verschiedenen Quellen im System gleich behandelt werden. Das Gegenstück dazu sind Sendportgruppen. Hierin werden mehrere Sendports zusammengefasst, an die alle jeweils eine ausgehende Nachricht geschickt wird, gegebenenfalls wieder mit verschiedenen Mappings.
Sowohl Receive- als auch Sendports gibt es in einer Request-Response-Ausführung. Receiveports dieser Art schicken nach Erhalt einer Nachricht eine Bestätigungsmeldung über einen definierten Sendport. Bei Sendports bedeutet dies, dass der Ablauf nach dem Versenden blockiert wird, bis eine Antwort zurückkommt.
Ein weiteres Feature sind dynamische Sendports. Bei diesen erfolgt das Binden an einen konkreten Adapter und eine konkrete Adresse erst zur Laufzeit, beispielsweise abhängig von Werten aus einer behandelten Nachricht.
MessageBox
Das Routing zwischen den einzelnen Modulen innerhalb des BizTalk Servers geschieht über einen Publish- und Subscribe-Mechanismus. Alle Nachrichten werden in die Messagebox gestellt und daran interessierte Module können diese hieraus abholen. Daraus ergeben sich zwei mögliche Nachrichtenwege:
Einerseits direkt vom eingehenden Adapter und der verknüpften Pipeline über die ausgehende Pipeline und den Adapter. Das Mapping wird in diesem Fall direkt beim Durchlaufen eines der Adapter durchgeführt.
Der andere Weg führt nach der eingehenden Pipeline in eine Orchestrierung - welche unter anderem das Mapping durchführt - und anschließend in die ausgehende Pipeline und den dazugehörigen Adapter.
Adapter
Im Normalfall wird der meiste Kontakt zur Außenwelt, also ein- und ausgehende Nachrichten, von Adaptern durchgeführt. In der Grundausstattung enthält BizTalk Server bereits einige wichtige Adapter:
+ EDI: Zur firmenübergreifenden Kommunikation nach EDI-Standards
+ File: Zur Verarbeitung beliebiger XML-Dateien und Flatfiles
+ HTTP: Zur Kommunikation über das HTTP-Protokoll, für welches die meisten Firewalls durchlässig sind und mit dem sich Webformulare und ähnliches anbinden lassen
+ FTP: Zum Lesen und Schreiben von Dateien auf FTP-Servern
+ SMTP: Zum Versenden von Emails über einen SMTP-Server
+ SOAP: Zur Anbindung von Webservices
+ SQL: Zur Anbindung eines SQL-Servers
+ MSMQT: Zur Verwendung von BizTalk Message Queuing, einer Erweiterung von MSMQ
Weitere Adapter zur Kommunikation mit verbreiteten Systemen (Bsp. SAP) oder über branchenspezifische Standards und Marktplätze (Elemica, RosettaNet) sind von Microsoft oder dessen Partner erhältlich.
Je nach Art des Adapters wird ein Ablageplatz auf neue Nachrichten überwacht (beispielsweise ein Verzeichnis mit dem Fileadapter) oder in definierten Zeitabständen ausgelesen (beispielsweise der SQL-Adapter, der ein SELECT-Statement verwendet). Wenn eine oder mehrere neue Nachrichten vorhanden sind, werden diese an die entsprechende Receive-Pipeline übergeben.
Testen und Einsetzen
Wenn alle für das Projekt benötigten Komponenten in Visual Studio erstellt sind, muss man das Projekt kompilieren und erhält als Ergebnis eine Bibliothekdatei, "Assembly" genannt. Diese wird nun in den Global Assembly Cache (GAC) des .NET-Frameworks aufgenommen (= "deploy"). Daraufhin wird, falls noch nicht bei der Entwicklung geschehen, das Binding zwischen den virtuellen Ports der Orchestrierung und den reellen Ports durchgeführt. Nach dem anschließenden Eintragen (= "enlist") kann die Orchestierung gestartet werden. Für diese Schritte werden der BizTalk Explorer im Visual Studio, der BizTalk Server Deployment Wizard und die BizTalk Administration Console verwendet.
Dehydrierung
BizTalk unterstützt langlaufende Prozesse. Ein Partner - beispielsweise ein Lieferant - erhält eine neue Bestellung. Als Antwort darauf wird eine Versandbestätigung geschickt. Der Zeitraum zwischen Bestelleingang beim Partner und Ausgang der Bestätigung kann mehrere Tage betragen. Um Ressourcen zu sparen, die von einer hierauf wartenden Instanz belegt wären, "dehydriert" BizTalk Server solche Orchestrierungen beim Eintreten bestimmter Aktionen. Dehydrierung bedeutet, dass der Status der Orchestrierung einschließlich des Status der involvierten Komponenten und allen Nachrichten und Variablen serialisiert und in eine Datenbank geschrieben wird. Hierdurch werden alle belegten Ressourcen freigegeben. Sobald die Nachricht eintrifft, auf die die Orchestrierung wartet, wird dies von der Runtime Engine erkannt und die Orchestrierung rehydriert.
Ein weiterer Vorteil dieser Funktion ist die Erhaltung langlaufender Prozesse auch dann, wenn in der Zwischenzeit der BizTalk Server geplant oder ungeplant beendet wurde. Nach dem Neustart können dehydrierte Orchestrierungen wieder rehydriert werden, ohne von der Systemunterbrechung betroffen zu sein.
3.4 Microsoft Business Solutions Navision
Das ERP-System Navision wurde ursprünglich von der gleichnamigen dänischen Firma entwickelt. Im Jahr 2002 hat Microsoft die Firma Navision übernommen und sich mit dieser Anwendung auf den ERP-Markt gebracht. Die Software wurde mit der Zeit weiterentwickelt und in Microsoft Business Solutions Navision umbenannt. Der aktuell verfügbare Stand ist die Version 4.0.
Navision ist eine umfangreiche und verbreitete Enterprise-Ressource-Planning-Software. Sie wird ausschließlich über Microsoft Business Solutions Partner vertrieben und an unternehmensspezifische Anforderungen angepasst.
Commerce Gateway
Commerce Gateway ist eine Navision-Komponente zur Enterprise Application Integration. Es ist eng mit dem BizTalk Server gekoppelt und bietet die Möglichkeit, Navision an andere Systeme zum elektronischen Datenaustausch anzubinden.
Hierzu werden im Navision-Client beispielsweise Schaltflächen angezeigt, um einen Beleg per BizTalk zu versenden. Daraufhin wird ein XML-Dokument des Belegs von Commerce Gateway erzeugt und an den Commerce Gateway Request Server auf dem BizTalk Server weitergegeben (siehe Abbildung 8).
Application Server
Der Microsoft Navision Application Server (nicht zu verwechseln mit dem Applikations- und Datenbankserver von Navision, welcher "Navision Server" genannt wird) ist eine Software, die wie ein Client lesend und schreibend auf die Navision-Datenbank zugreifen kann. Hierdurch können Geschäftsprozesse automatisiert durchgeführt werden, indem Navision Application Server als Schnittstelle zum ERP-System dient. Er kann in Gegenrichtung zum Commerce Gateway verwendet werden, um eingehende Daten vom BizTalk Server in die Navision Datenbank zu schreiben.
|
 Abb. 8: Überblick Integration Navision und BizTalk |