Geschäftslösungen für das Enterprise Resource Planning (ERP) und die Steuerung von Kundenbeziehungen oder Lieferketten (CRM, SCM) bilden im Unternehmen ein komplexes Beziehungsgeflecht. Über unzählige Schnittstellen werden Prozesse abgewickelt und Daten transferiert, firmenintern und mit externen Partnern. Für eine reinrassige SAP-Welt stehen dafür etablierte Verfahren wie ALE oder BAPI zur Verfügung.

Zur Kopplung von heterogenen Systemlandschaft und deren proprietären Schnittstellen eignen sich unabhängige Integrationswerkzeuge (Enterprise-Application-Integration-Tools, EAI). Solche Plattformen sind oftmals besser als die individuelle Programmierung der vielfältigen Datenanbindungen.

Das Integrations-Tool Netweaver XI kann grundsätzlich Schnittstellen zwischen SAP-Lösungen ersetzen und auch Fremdsysteme mit ERP-Lösungen verbinden. Galten SAP-Umgebungen bislang als IT-Inseln, denen proprietäre SAP-Standards wie ABAP oder IDOC zugrunde lagen, soll sich das durch XI ändern. Die Plattform baut auf Web-Services, XML-Messaging, Java und J2EE (Java 2 Enterprise Edition) auf.

Die älteren SAP-Techniken werden jedoch nicht verschwinden, auf absehbare Zeit wird es zu einer Koexistenz und Kombination kommen. Ein gutes Beispiel liefert XI selbst: Hier werden bewährte, robuste Methoden wie beispielsweise ABAP als Programmiersprache für die Integration-Engine kombiniert mit Java zur Abbildung von Transformationsregeln.

Mit SAP XI ergeben sich eine Reihe interessanter Fragestellungen: Zum Beispiel, ob ein Unternehmen seine gesamte Integrationsarchitektur von Grund auf neu ausrichten sollte, ob es die SAP-Innovationen ignorieren kann, oder ob sich Modelle für einen schrittweisen Wandel finden.

Grundsätzlich sollte ein EAI-Tool nur dort eingesetzt werden, wo es echten Mehrwert liefert. Das ist zum Beispiel bei Nachrichtentransformationen der Fall. Traditionell wird dabei entweder ein ABAP-Funktionsbaustein erstellt oder die Standard-IDOC-Verarbeitung mit einer entsprechenden ABAP-Transformationsregel in einem "User Exit" erweitert. Damit entsteht jedoch eine feste Koppelung zwischen Sender- und Empfängersystem, die zu unerwünschter Inflexibilität führt. Spätestens beim nächsten Upgrade einer der beiden Anwendungen müssen die Schnittstellen neu programmiert werden. Dazu sind häufig nur die Spezialisten für diese Anwendungen in der Lage. Die Transformationsregeln selbst bleiben bei dieser harten Programmierung auch nicht transparent. Im Gegensatz vermag XI Quell- und Zielsysteme über einen neutralen Austausch koppeln, bei dem sich Transformationsregeln in einer transparenten Form ablegen lassen.

Anwendungsübergreifend

Ein weiterer XI-Anwendungsfall sind anwendungsübergreifende Geschäftsprozesse. Gleiches gilt für Szenarios mit mehreren Empfängern ein und derselben Nachricht. Anstatt das Datenobjekt mehrfach vom Quellsystem aus an die Adressaten zu schicken und dadurch unnötigen Aufwand im Quellsystem zu erzeugen, kann eine zentrale Schnittstelle eingerichtet werden. In einem ersten Schritt wird die Nachricht aus dem Ausgangssystem übertragen, bevor in einem zweiten Schritt die "Receiver Determination" von XI die Empfänger bestimmt.

Weniger geeignet ist XI hingegen, um beispielweise ein Standardobjekt wie einen Kundenstamm ohne Transformationslogik zwischen zwei SAP-Systemen auszutauschen. In diesem Fall empfiehlt sich eine Synchronisierung nach traditionellem Muster. Ebenso wenig ratsam ist es, bereits vorhandene, proprietäre Systemkoppelungen in XI nachzubilden (beispielsweise die Verteilung von Lieferantenstammdaten zwischen R/3 und E-Procurement-Programm "Enterprise Buyer Professional (EBP)".

XI empfiehlt sich auch nicht dort, wo besonders hohe Datenvolumina anfallen oder sehr komplexe Nachrichtentransformationen vorliegen. Schwerpunkt und Stärke von XI liegt auf der zeitnahen, inkrementellen Datenübermittlung ("near realtime"). Deshalb verwendet man zum Füllen von Data Warehouses ergänzend zu EAI-Mechanismen ETL-Tools (Extract, Transform, Load). Massendaten werden dann über ETL, inkrementelle Daten über EAI versendet. Eine typische EAI-Aufgabe wäre etwa bei einer Einzelhandelskette die Ad-hoc-Verteilung der Kundenstammdatenänderung von der zentralen Stammdatenverwaltung in die dezentralen Filialsystemen (zum Beispiel Bonus- oder Promotioninformationen für Kassensysteme) während die kompletten Verkaufsinformationen in einem monatlichen Batch-Prozess per ETL-Software in einem zentralen Data Warehouse konsolidiert werden.

XI ist grundsätzlich für alle Unternehmen attraktiv, die bereits einen hohen Anteil an SAP-Anwendungen betreiben und in das Thema EAI einsteigen wollen. Aufgrund der vergleichsweise geringen Lizenzkosten eröffnen sich hier günstige Optionen.

Neben den Basisfunktionen zur Anwendungsintegration lässt sich in XI vordefinierter "Business Content" verwenden. Die Walldorfer bieten unter diesem Slogan Standardschnittstellen und komplette Integrationsszenarien an, die der Anwender installiert und konfiguriert. Teilweise handelt es sich hierbei um Schnittstellen zwischen verschiedenen SAP Komponenten, teilweise um solche zur Anbindung externer Systeme und Datenformate. Ein Beispiel für Business Content sind die Methoden zum Upload von Katalogdaten in die Katalog-Engine "CCM" in verschiedenen XML-Formaten wie BMECat. Selbst wenn hier anwenderspezifische Erweiterungen nötig sind, lassen sich diese günstiger bewerkstelligen, als wenn die Firma alles selbst programmiert.

Vordefinierte Prozesse

Ein Knackpunkt ist hier allerdings die noch geringe Anzahl der derzeit verfügbaren Standardprozesse. Zu denen zählt etwa der Branchenstandard Chemical Industry Data Exchange (CIDX). Marktgewicht und die Größe der Entwicklerbasis bei SAP lassen jedoch auf weiteren Content hoffen, was die Attraktivität von XI zunehmend erhöhen würde.

Angesichts der hohen Verbreitung sowohl von etablierten EAI-Tools stellt sich für viele SAP-Nutzer die Frage, für welches Tool sie sich nun entscheiden sollen - oder ob eine Koexistenz unterschiedlicher EAI-Werkzeuge in Kauf genommen werden soll. Die Praxis zeigt, dass Kunden an ihren EAI-Lösungen festhalten, SAPs XI-Entwicklung aber aufmerksam abwartend verfolgen. In Großunternehmen mit ausgeprägter IT-Governance, die eine strikte Vereinheitlichung ihrer IT-Infrastruktur und Ausrichtung auf strategische Partner verlangt, wird unter Umständen auf den Einsatz von SAP XI bewusst verzichtet.

Unternehmen mit vielen SAP-Anwendungen sollten sich für eine zeitweilige Koexistenz von XI mit anderen EAI-Tools entscheiden. XI empfiehlt sich zum Beispiel für die Integration verschiedener SAP-Anwendungen, während der Nachrichtenaustausch mit weiteren Anwendungen (zum Beispiel mit der CRM-Lösung eines Drittanbieters) über den unternehmensweiten EAI-Server stattfindet. Selbstverständlich birgt der Einsatz verschiedener EAI-Systeme immer auch Nachteile. Insbesondere ist ein durchgängiges, zentrales Monitoring der Nachrichtenverarbeitung nur mit erheblichem Zusatzaufwand möglich.

Letztendlich kann hier noch keine universelle Empfehlung gegeben werden. Es gilt, unternehmensspezifische Indikatoren wie Unternehmensgröße, IT-Strategie und -Governance, Bindung an SAP und ihre Anwendungen sowie das Know-how der Mitarbeiter abzuwägen. Eine Vielzahl von Unternehmen entscheidet sich zunächst für eine Koexistenz unterschiedlicher EAI-Systeme.

Fragezeichen bei der Performance

Als vergleichsweise junges Produkt bietet XI naturgemäß noch nicht den Reifegrad langjährig etablierter EAI-Tools. Gartner positioniert SAPs Integrationstechnik- neben Microsofts "Biztalk" - als "Herausforderer" der Marktführer Tibco, Webmethods, Seebeyond und IBM.

Ein kritischer Punkt der XI-Architektur ist ihre begrenzte Skalierbarkeit. Im Gegensatz zu Konkurrenzprodukten weist XI keine Bus-Architektur auf, die eine dynamische Verteilung von Diensten ermöglicht. Vielmehr läuft jedes Integrationsszenario auf einem dedizierten Integrationsserver. Zwar erlaubt XI verteilte Architekturen, doch müssen dazu mehrere, separate XI-Installationen aufgebaut werden. Gerät eine solche Konstellation an ihre Lastgrenze, müssen Systemspezialisten einzelne Integrationsszenarien verschieben, um sie auf einer Parallelinstanz zu betrieben.

Lasten verteilen

Eine Alternative dazu sind Integrationstools, die über einen eigenen Nachrichten-Bus verfügen. Dieser kann eine Vielzahl von Infrastrukturkomponenten in Form einer verteilten Architektur aufnehmen. So lässt sich die Last einer Transformationslogik auf unterschiedliche Server verteilen - der jeweils freie Server holt sich dann vom Bus das nächste anstehende Paket. Bei Engpässen kann der Bus dynamisch um weitere Server erweitert werden und ist damit nahezu linear skalierbar.

Um die Performance von XI abschließend beurteilen zu können, fehlt es noch an Erfahrungswerten. Der Hersteller hat den Bedarf erkannt: Einerseits bezeichnet SAP das Produkt als "hochperformant" ein, führt jedoch gleichzeitig die Performancesteigerung als ein zentrales Entwicklungsziel an.

Natürlich schwankt der Durchsatz einer XI-Installation je nach Konfiguration, Hardware, Betriebssystem und Integrationsszenario. Daher sollten Anwender vor der Entscheidung für ein bestimmtes Szenario ausgiebig testen. Nur so lassen sich die Charakteristik und Einflussfaktoren verstehen und bewerten.

Für die grobe Einschätzung der Leistungsfähigkeit einer Integrationsplattform sind zwei Kenngrößen besonders relevant: Der Datendurchsatz der Integration-Engine und die maximale Größe des einzelnen Nachrichtenpakets.

Zum Durchsatz: In Versuchsreihen mit XI auf einer Minimalplattform (Windows 32 Bit, zwei CPUs) führte die Verarbeitung einer sehr hohen Zahl kleiner Datenpakete zu einem ziemlich schwachen Gesamtdatendurchsatz. Mit Steigerung der Paketgröße verbesserte sich der Durchsatz erheblich, um dann ab einem bestimmten Wert wieder deutlich abzufallen und sich später wieder zu erholen. Bei einem Labortest lag die geeignete Nachrichtengröße auf dem 32-Bit-System zwischen 1 und 5 MB, der Gesamtdurchsatz belief sich somit auf 1 bis 1,2 GB pro Stunde. Bei einer optimalen Nachrichtengröße kann der Gesamtdurchsatz um ein Vielfaches höher sein als bei Verwendung nicht optimaler Paketgrößen. Die durchschnittliche Paketgröße ist jedoch nur ein Faktor von vielen, die Durchsatz und Performanz beeinflussen.

Zur Nachrichtengröße: Allgemein stellen EAI-Werkzeuge hohe Anforderungen an Arbeitsspeicher, wodurch häufig ein Flaschenhals entsteht. Um die Speicherlimitationen von 32-Bit-Systemen zu vermeiden, empfiehlt sich für XI ausschließlich der Einsatz auf 64-Bit-Betriebssystemen. (fn)