Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

24.11.2000 - 

"Es gibt keine Standardadapter"

EAI-Beispiele im R/3-Umfeld

Künftig Schnell und flexibel reagieren zu können, wünschen sich Anwender nicht nur im Hinblick auf die Abwicklung von Unternehmensprozessen, sondern in zunehmendem Maß auch für die Verbindungen zwischen den Applikationen. Laut Dirk Blum* hilft ein geordnetes Infrastrukturdenken, um ein Enterprise Application Integration (EAI) sicher zu erreichen.

Bedeutete der Begriff Aktualität gestern noch, exakte Verfügbarkeitsaussagen erst am Ende eines Tages tätigen zu können, so müssen heute oft die gleichen Informationen innerhalb von Sekunden bereitstehen. Darüber hinaus ermöglichen neue Applikationen, wie sie derzeit zum Beispiel für das Web entstehen, die Gestaltung ganz neuer Prozesse. Gleichzeitig sind viele alte Applikationen noch produktiv und müssen mit den neuen Welten in Verbindung treten. Historisch gewachsene Systeme haben jedoch aufgrund ihrer komplexen und teils Batch-orientierten Verbindungsstrukturen nicht das Potenzial, den Anforderungen an eine moderne Prozessgestaltung gerecht zu werden.

EAI hat nun zum Ziel, betriebswirtschaftliche Systeme sowohl auf technischer, vor allem aber auf logischer Ebene zu einem Gesamtsystem zu integrieren. Denn der Vorteil einer strategischen Position liegt in der Organisiertheit der internen Prozesse. Nur wenn man durch solche Prozesse schneller, geordneter und effizienter werden kann, lassen sich Vorteile gegenüber der Konkurrenz erreichen.

Prozesse zentral modellierenDas Modell einer zentralen, dreischichtigen Schnittstellen-Infrastruktur hilft dabei, Prozesse zwischen unterschiedlichsten Applikationen zu gestalten. Grundgedanke des Modells ist die Schaffung eines "Single Point of Controls" für alle Schnittstellen, oder anders ausgedrückt: Zu jeder Applikation wird nur eine technische Schnittstelle aufgebaut. Darüber hinaus soll möglichst kein Eingriff in die Applikationen nötig sein. So werden zeitkritische Projekte möglich, da man die Integrationslogik nur einmal an zentraler Stelle implementieren muss.

In dem Modell sorgt die untere Ebene (siehe Grafik Seite 30) für das System-Management. Sie wacht über die Verfügbarkeit und Performance aller Ressourcen, Applikationen und Systeme. Die mittlere Ebene übernimmt das Message-Handling beziehungsweise den Transport der Daten. Die obere Ebene hat schließlich die Aufgabe von Broking und Conversion: Sie koppelt Anwendungen auf betriebswirtschaftlicher Ebene (siehe Kasten "Drei-Ebenen-Architektur").

Eine in dieser Weise installierte Infrastruktur bietet die Möglichkeit, Integrationsprojekte als Big Bang oder Schritt-für-Schritt umzusetzen. Hierzu gibt es diverse Techniken oder Werkzeuge für die einzelnen Ebenen. Die Wahl der Ausstattung der einzelnen Ebenen sollte unter dem Stichwort "Best-of-Breed-Technology" stehen: Für jede Aufgabe das beste Werkzeug - und zwar bezogen auf das vorhandene beziehungsweise zu integrierende Applikationsumfeld. "Non invasive" lautet das Schlagwort: Die Infrastruktur sollte in Applikationen weder inhaltlich, sachlich noch funktionell eindringen. Das verhindert Release-Problematiken und erhält die Modularität. In dieser Form wird eine größtmögliche Beweglichkeit erreicht, um auch neue Applikationen schnell zu integrieren.

Dennoch gibt es genug zu tun, denn Standardadapter zwischen zwei Applikationen - zum Beispiel für den Austausch eines Materialstamms - kann es nicht geben. Allein durch das Customizing eines Systems ergeben sich unterschiedliche semantische Abbildungen. Ein Adapter erleichtert zwar die technische Abbildung, berücksichtigt jedoch keine inhaltlichen Vereinbarungen. Hier muss in jedem Fall eine individuelle Anpassung erfolgen. Spätestens, wenn Applikationen geändert werden, steht die Arbeit in der Broking- und Conversion-Ebene an.

Typische Beispiele aus unterschiedlichen Branchen verdeutlichen, wie eine Infrastrukturentscheidung schrittweise umgesetzt werden kann, wo der Aufwand steckt und welche Vorteile sie letztlich mit sich bringt. Wächst die IT über viele Jahre mit dem Unternehmen mit, entsteht schnell ein Schnittstellen-Spaghetti, bei dem Daten außer Tritt geraten und gesteigerte Marktanforderungen nicht mehr abgebildet werden können. In solch einer Situation befanden sich die Dalli-Werke Mäurer + Wirtz, Stolberg. 15 Systeme und ein Batch-orientiertes SAP R/2 - zentral und nicht gekoppelt - erschwerten die Einhaltung kurzfristiger Liefertermine. Das Vertriebssystem verfügte erst nach einem Tag über die aktuellen Produktionsbestände.

Die Einführung einer R/3-Software für die Vertriebsabwicklung und -logistik inklusive Fakturierung nutzte Dalli als Trägerprojekt, um parallel eine zentrale Schnittstellen-Infrastruktur zu installieren, an die alle Systeme angeschlossen wurden. Die Broking- und Conversion-Ebene koppelt jetzt den transaktionsorientierten Ansatz von R/3 mit dem Batch-Verfahren von R/2 und integriert alle anderen Applikationen. Beim Mapping wurden dafür Daten, die die Vertriebssteuerung, die Produktionslogistik oder die Rechnungserstellung betreffen, aus den Applikationen heraus exakt aufeinander abgestimmt. Im Ergebnis stellt der Broker jetzt Produktionsbestände aus R/2 der neuen R/3-Software sofort zur Verfügung. Die Bestandsprüfung ist schneller erfolgreich, Lieferung und Fakturierung können unmittelbar stattfinden.

Ein weiterer Vorteil der installierten Infrastruktur: Der geplante Austausch des R/2-Systems durch eine R/3-Software ist deutlich schneller möglich, da die 15 Fremdsysteme über dieselben Methoden und Verfahren integriert bleiben.

Ein anderes Beispiel kommt aus der Finanzwelt. Dort unterliegen Banken der gesetzlichen Verpflichtung, die zum Beispiel mit neuen Geschäftsarten eingegangenen Risiken zeitnah zu beurteilen.

Batch-orientierte Informationswege sind nicht geeignet, diesem Anspruch gerecht zu werden. Die LB Kiel hat deshalb für die Kommunikation eine Infrastruktur aus Broking- und Conversion- sowie Messaging-Ebene eingeführt. Daran angeschlossen sind unter anderem auf der einen Seite die Software "Kondor+" von Reuters zur Erfassung der Geschäfte durch die Handelsbereiche sowie auf der anderen Seite die Module für "Strategic Enterprise Management" (SEM) von SAP zur Risikoüberwachung. Die Broking-Ebene erhält aus Kondor+ via Messaging nicht mehr nur Files, sondern einen kontinuierlichen Strom abgeschlossener Handelsgeschäfte, den sie für das SAP-System nach unterschiedlichen betriebswirtschaftlichen Zuordnungen aufteilt.

Ist bereits eine der drei Ebenen installiert, können neue Prozesse zügig eingeführt werden. Ein neuer Prozess im Handel ist zum Beispiel die Ermittlung des Käuferverhaltens aus den Kassen-Bon-Daten. Damit lassen sich Disposition, Sortimentsgestaltung und Warenpräsentation verbessern. Für ein Lebensmittel-Handelsunternehmen wie Tegut bedeutet dies, dass Bon-Daten aus den Filialen heraus in ein neu anzubindendes Warehouse-Tool geleitet werden müssen - hier das BW von SAP. Da bereits eine Broking- und Conversion-Ebene existiert, erfolgte das Andocken direkt über den transaktionsorientierten Datenaustausch.

Aufgrund der geforderten Transportsicherheit zwischen der Zentrale und den Filialen wurde als Message-Handling-Ebene "MQ Series" von IBM installiert. Über das Message-Handling erhält der Broker die Kassen-Bon-Daten, die sonst als File geschickt würden. Nach den Regeln, die im vorangegangenen Mapping hinterlegt sind, selektiert der Broker die Daten und wandelt sie in eine ebenfalls zuvor im BW-System individuell eingestellte Datenstruktur um. Informationen zu Stammdaten und deren Änderungen erhalten sowohl das BW-Tool als auch die Filialen entsprechend aufbereitet durch die Broking-und Conversion-Ebene. Der Broker entnimmt sie direkt aus einer vom zentralen Warenwirtschaftssystem versorgten SQL-Datenbank. Durch die Verknüpfung der neu installierten Applikation über die Broking- und Conversion-Ebene ist gleichzeitig sichergestellt, dass die Datenströme aus Filialen und Zentrale synchron ankommen.

Das Ziel einer EAI-fähigen Infrastruktur im Bereich Dienstleistungen sollte die schnelle Verbindung zum Kunden sein. Der Logistikspezialist Newwave zum Beispiel will als Lager- und Transportdienstleister seinen Auftraggeber über jede Phase einer Warenbewegung rund um das Lager umgehend informieren können. Dem Kunden Pioneer als Produzenten von elektronischen Endkundengeräten meldet Newwave die Fertigstellung gepackter Systeme aus Radio, CD-Wechsler und Lautsprecherboxen, gibt den Auftragsstatus weiter oder weist auf unverlangte Wareneingänge hin, die dann bei Pioneer in den Workflow einfließen. Die Applikationsintegration zwischen dem Lagerverwaltungssystem "Marc" bei Newwave und dem bei Pioneer eingesetzten R/3 wird über eine Broking- und Conversion-Ebene umgesetzt, in die Newwave investierte.

Durchgängige Prozesse entstehen wieder beim Mapping, wenn Daten, die eine Einlagerung, eine Auslagerung oder eine unkontrollierte Warenbewegung in den Systemen betreffen, exakt aufeinander abgestimmt werden. Zum Beispiel entstehen in R/3, das in seinem Customizing nicht verändert werden sollte, bei Aufträgen zwei getrennte Informationen: ein Transport- und ein Lieferauftrag. Das Marc-System erwartet jedoch nur einen einzigen Auftrag. Die Broking- und Conversion-Ebene sorgt hier für die entsprechende Aufbereitung der Daten, selbst wenn Liefer- und Transportauftrag mehrere Tage auseinander liegen und dieser Fall hundertfach vorkommt. Mit der vorhandenen Infrastruktur kann Newwave nun an den Markt gehen und sich innerhalb weniger Wochen bei jedem anderen Kunden individuell in den Workflow einbinden.

Einzelne Funktionen nicht isolierbarÜber EAI können Anwender mit einem überschaubaren Aufwand jederzeit auf Anforderungen reagieren, die sich aus dem E-Business ergeben. Erste Ansätze der IBM zeigen bereits die weitere Entwicklung des Drei-Ebenen-Modells auf: Workflow-Server, in denen ganze Prozesse über unterschiedlichste Applikationen hinaus als Objekte gespeichert sind, bilden eine vierte Ebene. Das Problem: Kaum eine Anwendung erlaubt es derzeit, eine beliebige Funktion herauszunehmen, um sie über Applikationsgrenzen hinweg zu einem Teil einer ganz neuen Prozesslogik werden zu lassen.

*Dirk Blum ist Vorstandsmitglied des auf EAI-Tools spezialisierten Dienstleisters CAS AG, Hamburg.

Drei-Ebenen-ArchitekturSystem-Management überwacht und steuert sämtliche physischen und logischen Ressourcen wie Leitungsverbindungen, Hardware, Plattenplatz, Datenbank-Space oder Tabelleneinträge für interne und externe Verbindungen.

Message-Handling sorgt für den physischen Transport von Daten zwischen Applikationen und Systemen unter der Prämisse eines "guarantied delivery". Die Technik arbeitet mit so genannten Daten-Queues, die den Umschlag für einen Dateninhalt bilden. Sie übernimmt Aufgaben wie sammeln, verteilen und zuordnen der Queues und bestätigt deren Übermittlung. Message-Handling arbeitet als asynchrone Nachrichtenverteilung, berücksichtigt Prioritäten und Reihenfolgen und ermöglicht damit die Kommunikation zwischen Systemen unterschiedlicher Verfügbarkeit.

Broking und Conversion - immt vom Inhalt abhängige Steuerungs- und Umsetzvorgänge wahr und arbeitet damit auf betriebswirtschaftlicher Ebene syntaktisch und semantisch. Bei Integrationsprojekten steckt hier der größte Aufwand. Der betriebswirtschaftliche Prozess muss über Applikationen hinweg verstanden sein, damit die DV-Spezialisten die Regeln und Vorgehensweisen, nach denen die Anwendungsfunktionen der Systeme verbunden werden, hier hinterlegen können. Diese Arbeit - das Gegeneinanderhalten von Datenstrukturen - nennt man "Mapping", sie kann mit geeigneten Werkzeugen sehr komfortabel objektorientiert auf der Ebene der Anwendungsobjekte erledigt werden. Die Inhalte der unterschiedlichen Datenformate werden grafisch aufbereitet und per Mausklick miteinander verbunden. So genannte Templates - Mapping-Logiken, die aus den Applikationsverbindungen vorangegangener Projekte vorliegen - bieten teilweise einen ersten Anhaltspunkt für die Arbeit und können den Aufwand verringern. Es ist jedoch möglich, dass allein das Customizing von Applikationen zu großen semantischen Veränderungen einer Nachricht führt. Beim objektorientierten Mapping ist der Neuaufbau einer individuell optimierten Schnittstelle dann in der Regel schneller als die Modifizierung eines Templates.

Schließlich muss die Ebene das Message-Handling unterstützen sowie das System-Management einbinden. Je inhomogener das vorhandene Applikations- und Systemumfeld ist, desto mehr Adapter werden benötigt.

Abb: Eine moderne Infrastruktur baut auf drei Ebenen auf und ermöglicht so eine vergleichsweise komfortable Applikationsintegration. Quelle: CAS