Unternehmen wollen ihre Geschäftsprozesse überregional standardisieren und harmonisierte Systemlandschaften betreiben. Viele Firmen verwenden SAP-Produkte. Doch die Walldorfer decken nicht immer das gesamte Geschäftsprozessspektrum ab. Applikationen anderer Anbieter sowie Eigenentwicklungen müssen zu leistungsfähigen Prozessen zusammengeschmiedet und Daten formatiert, verteilt und ausgetauscht werden.

Projektsituation

Genau in diesem Umfeld befand sich ein Unternehmen aus dem Maschinen- und Anlagenbau. Gewachsen über viele Fusionen und Zukäufe, war eine heterogene Applikations- und Systemlandschaft entstanden. Integriert war sie nur in wenigen Bereichen über IBMs "MQ Series". Die Firma wollte Geschäftsprozesse auf Basis von SAPs "R/3 Enterprise" (4.7) mit Unicode-Option standardisieren und ihre alten, selbst programmierten Produktionssteuerungssysteme und Kundenportale ablösen.

Mit SAPs "Exchange Infrastructure" bot sich eine Integrationsplattform an. Sie verfügt über Funktionen zur Anbindung von anderen SAP-Systemen sowie Standardadapter für JMS, Soap und Dateiintegration. Gegen XI sprachen die schon vorhandene und erprobte Integration von Applikationsinseln über MQ Series und der Wunsch des Unternehmens, nicht erneut in Interimslösungen zu investieren.

Das Projektteam konnte darlegen, dass XI zum einen eine leistungsfähige und effiziente Unternehmensintegrationsplattform sein kann und sich zum anderen bestehende MQ-Series-Installationen in die Netweaver-Plattform einpassen lassen. Das Projekt wurde mit XI 2.0 begonnen, mittlerweile ist die Version 3.0 im Einsatz.

Die Wiederverwendbarkeit von MQ Series hatte den Vorteil, dass auch die vorhandene Dokumentation und Schnittstellenbeschreibung genutzt werden konnte, so dass "nur" noch die SAP-Welt zu evaluieren war. Damit war es möglich, sich auf die weiteren Systeme zu konzentrieren. Mit Hilfe von XI ließen sich Verteilungsszenarien definieren und so die Anzahl von Schnittstellen reduzieren. Insgesamt wurden 37 Schnittstellen mit einem Datenvolumen von etwa 15000 Messages pro Tag implementiert. Eine Nachricht umfasst rund 150 MB.

Der Anwender hatte SAP-seitig RFC-Schnittstellen für die synchrone Kommunikation entwickelt. Über den JMS-Adapter lässt sich MQ Series lediglich asynchron an SAP anbinden. Aus diesem Grund musste das Projektteam ein spezifisches Fehlerbehandlungs- und Monitoring-Werkzeug entwickeln. Hier waren einige Kunstgriffe notwendig. Sobald XI eine Nachricht via RFC an SAP übergibt, kennzeichnet das der Integration-Broker als erfolgreiche Übertragung. Die Botschaft lässt sich nicht erneut schicken, was auch grundsätzlich so sein sollte. In dem konkreten Fall jedoch kann nach einer fehlgeschlagenen Buchung sehr wohl der erneute Versand via MQ Series an R/3 via XI notwendig sein.

Das asynchrone JMS ermöglicht keine effektive Fehlermeldung. Daher wurde auf R/3-Seite eine Monitoring-Funktion implementiert, in der Fehler direkt verbessert und die Buchung erneut angestoßen werden können. Diese Problematik ist der SAP bekannt. In anderen Projekten hat sie bereits "Workarounds" geschaffen, allerdings nur für das Monitoring, nicht aber für das effektive und für den Kunden notwendige Bearbeiten von Fehlern.

Adapteranpassungen

Die Exchange Infrastructure erlaubt individuelle Erweiterungen außerhalb des Standards. Diese können einfach in die XI-Prozesslogik integriert werden, vergleichbar mit den "Userexits" in R/3. In diesem Projekt war die MQ-Series-Anbindung lediglich auf Satzstrukturebene vorhanden, so dass im JMS-Adapter diese Struktur in XML umgewandelt werden musste. Diese Transformation realisierte das Team in einem zusätzlichen Java-Programm, das im JMS-Adapter integriert wurde. Auf diese Weise konnte der Anwender die MQ-Series-Schnittstellen und deren Logik im Backend übernehmen.

Einige Schnittstellen generieren im SAP-System Idocs für Produktionsplanungsdaten für Drittsysteme. Die Dokumente umfassen bis zu 150 MB. Große Datenmengen müssen jeden Abend sicher über die Schnittstellen versendet werden, damit am nächsten Tag die Produktion nicht stillsteht. Diese Größe war auch für XI eine Herausforderung, aber mit Hilfe einiger Tuning-Tricks und genügend Speicher besonders für die J2EE-Adapter-Engine ließ sich eine vernünftige Performance und vor allem Sicherheit erzielen.

Nachrichtenarchivierung

Die von XI gebotenen Möglichkeiten, um Nachrichten zu archivieren beziehungsweise zu löschen, reichten dem Anwender nicht. Seine Anforderung bestand darin, jeweils pro Schnittstelle den Archivierungslauf starten zu können. Auch diese zusätzliche Funktion musste programmiert werden. Der Archivierungsjob des SAP-Produkts bietet diese Funktion, wenn auch gut versteckt. Sie ließ sich aber durch ein paar Eingriffe in Abap-Programme umsetzen. In allen anderen Bereichen wie zum Beispiel dem Mapping der Daten hat sich das Projekt größtenteils im Standard bewegt. (fn)