Mysap findet den Host über Umwege

29.06.2006
Von Torsten Fink 
Nach wie vor ist es schwierig, Mainframes mit SAP-Software zu verbinden. Es gibt verschiedene Methoden, doch alle haben Nebenwirkungen.
Verarbeitung einer Nachricht in der Exchange Infrastructure.
Verarbeitung einer Nachricht in der Exchange Infrastructure.
Über Messaging-Systeme gekoppelte Sender und Emfpänger arbeiten in unterschiedlichen Transaktionen.
Über Messaging-Systeme gekoppelte Sender und Emfpänger arbeiten in unterschiedlichen Transaktionen.

Viele Mainframe-Anwender stehen vor der Aufgabe, die Rechnerboliden mit betriebswirtschaftlicher Standardsoftware wie etwa SAP R/3 zu verbinden. Die einfachste Form der Integration besteht darin, Host-Daten manuell in das SAP-System einzubuchen. Noch heute nutzen zum Beispiel Banken und Versicherungen Altanwendungen auf dem Host und SAP-Lösungen parallel und ohne wirkliche Integration. Doch es ist wenig effektiv, ausgebildete Mitarbeiter mit der Datenerfassung zu betrauen. Zudem können sich durch Eingabefehler Inkonsistenzen zwischen ERP- und Host-System ergeben.

Fazit

Für die Integration zwischen Host- und SAP-Anwendungen gibt es ausgereifte Lösungen. Die Vergangenheit hat gezeigt, dass die Wartbarkeit eines Gesamtsystems schnell gefährdet ist, wenn beide Softwarewelten an vielen Stellen direkt koppelt sind.

Mit SAPs Exchange Infrastructure steht ein modernes System zur Verfügung, um die Komplexität gekoppelter Subsysteme wieder unter Kontrolle zu bringen. Es ist allerdings eine Überlegung wert, ob man aus strategischen Erwägungen statt SAP XI nicht alternative SOA-Produkte einsetzen sollte.

Insbesondere die Kosten der Anbindung externer Geschäftspartner sollten hier genauer betrachtet werden.

Integrationsmethoden im Vergleich

Terminalemulation:

Einfach zu installieren.

Eingabefehler, Gefahr von Inkonsistenzen.

Direkte Host-SAP-Kopplung:

Idoc-Dateien

Einfach, Standard der SAP.

Geschäftliche Daten in Dateien lesbar;

Fehlerbehandlung schwierig.

Java Connector

SAP-Standard.

Nicht J2EE-konform;

zusätzliche Module erforderlich, falls die Host-Applikationen nicht auf Java basieren.

Business Connector

Wenig Hardwareaufwand.

Support läuft aus (Entwicklung seit 2003 eingestellt).

Integration über Nachrichtensysteme:

Lose Kopplung verschiedener Systeme;

flexibel.

Fehlerbehandlung bei Bugs in der Programmlogik schwierig;

Sender und Empfänger arbeiten in getrennten Transaktionen.

Kopplung über die Exchange Infrastructure:

Keine "Spaghetti-Integration";

zentrales System;

unterstützt Standards wie Soap.

Hoher Hardwareaufwand;

intensive Schulung erforderlich.

Glossar

Corba: Common Object Request Broker Architecture ist eine 1995 von der Object Management Group herausgegebene Spezifikation für ein Objektmodell für verteilte Systeme.

ESB: Ein Enterprise Service Bus ist die zentrale Schaltstelle in einer SOA. Er vermittelt zwischen einzelnen Web-Services.

Java Connector (JCO): Ein Wrapper für die binäre RFC-Bibliothek von SAP. Auf diese Weise können Java-Anwendungen RFCs für die Kommunikation mit SAP-Systemen verwenden.

J2EE: Die Java 2 Enterprise Edition definiert ein Server-seitiges Komponentenmodell mit Programmierschnittstellen und dient dazu, Unternehmensapplikationen zu entwickeln und zu betreiben. J2EE steht in Wettbewerb mit Microsofts .NET.

JMS: Java Messaging Services ist eine Spezifiktion für den nachrichtenbasierenden Datenaustausch zwischen Systemen und ist Teil von J2EE.

JNI: Java Native Interface erlaubt den Zugriff auf nicht in Java geschriebene Programmfunktionen und -bibliotheken.

h3270: Eine Software (http://www.h3270.org/), die einen Browser-Zugriff auf Hosts gestattet. Dies entspricht etwa den Funktionen eines Terminals.

Idoc: Intermedia Document, ein SAP-Standard für den Datenaustausch.

Mule: Ein Open-Source-ESB (http:/mule.codehouse.org) von Codehouse.

SAP RFC: Mit dem Standardprotokoll Remote Function Call lassen sich über ein SAP-System Funktionen eines entfernten SAP-Systems auf- rufen.

Soap: Ein einfaches, auf XML basierendes Kommunikationsprotokoll.

SOA: Service-orientierte Architektur.

XML: Extensible Markup Language.

Hier lesen Sie …

Mehr zum Thema

www.computerwoche.de/

577723: Migration von SAP-Software vom Mainframe auf Linux;

577318: Cobol bleibt im Gespräch;

576870: Mainframe-Software ist noch immer teuer.

Weitere Artikel zum Thema SAP finden Sie unter http://www.computerwoche. de/SAP-Tuning.

Um SAP-Anwendern den Zugriff auf Host-Applikationen zu ermöglichen, bieten sich beispielsweise Terminalemulationen an. Mit dem Tool "h3270" etwa kann der Nutzer via Web auf Mainframes zugreifen. Dies ist zwar eine schnell installierbare Zwischenlösung, sie sollte aber durch eine technische Integration abgelöst werden.

Direkte Kopplung über Idocs

Eleganter lassen sich beide Systemwelten direkt über Schnittstellen verbinden. Dabei tauscht eine Host-Anwendung direkt mit einem Softwarebaustein von SAP Daten aus. Hier gibt es mehrere Optionen. Das "Intermediate Document" (Idoc) etwa ist ein von SAP definiertes Dateiformat für den Datenaustausch. SAP-Module können Idocs sowohl einlesen als auch Daten in diesem Format exportieren.

Daten lesbar

Idocs werden als Datei zum Mainframe übertragen und mittels eines Enterprise-Application-Integration-Tools in ein Host-spezifisches Format umgesetzt. Die Leseroutine auf dem Großrechner muss der Anwender selbst bauen, es gibt jedoch Werkzeuge, die entsprechende Programme automatisch erzeugen können.

Diese Art der Integration mit dem Host vollzieht sich im einfachsten Fall über ein Verzeichnis. Alternativ lassen sich für den Transfer Protokolle wie FTP und HTTP verwenden. Am häufigsten werden Idocs jedoch über das SAP-eigene Protokoll RFC (Remote Function Call) übertragen.

Ein Problem mit diesem Ansatz besteht darin, dass potenziell kritische Geschäftsdaten in Form einer lesbaren Datei versendet werden. Unbefugte könnten sensible Informationen auslesen beziehungsweise manipulieren. Des Weiteren mangelt es an einer Fehlerbearbeitung: Sind beispielsweise die Daten im Idoc fehlerhaft, so dass der SAP-Funktionsbaustein sie nicht verarbeiten kann, wird der Erzeuger des Dokuments darüber nicht informiert. Der Anwender müsste den Funktionsbaustein mit einer Fehlerbehandlungsroutine ausstatten, was zu einer schwer wartbaren Abhängigkeit zwischen Sender und Empfänger führt.

Java Connector

Der Java Connector (JCO) ist ein Wrapper für die binäre RFC-Bibliothek von SAP. Er gestattet eine bidirektionale Integration zwischen Host und SAP-System, sofern auf dem Mainframe eine Java-Anwendung läuft.

Der JCO liegt im Binärcode vor und läuft auf z/OS, OS400, AIX, Tru64, Solaris und HP-UX.

Leider unterstützt die Programmierschnittstelle Typsicherheit: Alle Typüberprüfungen finden erst zur Laufzeit statt, was im Vorfeld umfangreiche Tests erfordert. Läuft auf dem Host keine Java-Software, muss das Unternehmen zusätzlich eine Kopplung zwischen der Host-Applikation und dem Jco-Adapter entwickeln. Dieser macht auf dem Großrechner einen zusätzlichen Prozess erforderlich. Assembler- oder Cobol-Programme lassen sich beispielsweise über das Java Native Interface (JNI) und Corba mit einem Java-Prozess verbinden, welcher über den Jco mit einer SAP-Anbindung gekoppelt ist.

Doch selbst im Falle einer J2EE-Anwendung ist die SAP-Kopplung via Java Connector problematisch: Da der JCO nicht für J2EE entwickelt wurde, muss der Anwender bei der Programmierung gegen Vorgaben der Spezifikation Enterprise Java Beans (EJBs) verstoßen. Der JCO macht zum Beispiel den Einsatz statischer Methoden notwendig und verstößt damit gegen das EJB-Konzept. Aus diesem Grund sollten Anwender für diesen Zweck besser einen J2EE-konformen Ressourcenadapter einsetzen, wie beispielsweise "Librados". Dieser arbeitet intern mit dem JCO.

J2EE-Applikationen

Es gibt für die Anbindung von Java-Software Alternativen zum JCO: SAPs "Web Application Server", auf dem ERP-Lösungen ab R/3 4.7 aufsetzen, lässt sich über die gängigen Methoden Java RMI over IIOP (Remote Methode Invocation über das Internet Inter-Orb Protocol) sowie Java Messaging Services (JMS) mit J2EE-Applikationen verbinden. Ferner kann der SAP-Server Anwendungen über Soap/http koppeln.

SAP Business Connector

Der SAP Business Connector dient zur Anbindung externer Geschäftspartner. Er eignet sich auch zur Host-Anbindung. Ein Mapping von Datenstrukturen ist mit XML (Extensible Markup Language) möglich. Neben der RFC-Schnittstelle unterstützt er SMTP, HTTP und FTP. Trotz seines mächtigen Funktionsumfangs verfügt das SAP-Produkt über eine einfache Architektur, was sich in der Praxis als Vorteil erweist. Der Ressourcenbedarf des Business Connector ist gering; er lässt sich auf einfachen PCs betreiben.

Im Markt dürften derzeit einige tausend Installationen des Business Connector zu finden sein. Allerdings hat SAP die Weiterentwicklung des Produkts eingestellt. Unternehmen müssen vorhandene Prozesse und Strukturen mittelfristig auf die Integrationslösung "Exchange Infrastructure" (XI) von SAP umstellen.

Nachrichtensysteme

Eine Integration von SAP- und Host-Anwendungen über einen Nachrichtendienst, wie beispielsweise MQ Series von IBM, ermöglicht eine lose Kopplung zwischen verteilten Systemen. Ein Programm kann eine Nachricht asynchron an ein anderes System schicken und muss nicht so lange warten, bis der Empfänger die Botschaft verarbeitet hat. Ist das Empfängersystem beispielsweise aufgrund von Wartungsarbeiten nicht verfügbar, kann der Nachrichtendienst die Message aufbewahren, bis es wieder funktioniert. Zusätzlich gestatten es Nachrichtendienste, zur Laufzeit die Route zu ändern: Ohne Eingriffe ins Sendersystem kann der Anwender eine Message auf ein anderes Empfängersystem umleiten.

Es ist jedoch ein Problem, Systeme zuverlässig über ein nachrichtenbasierendes Verfahren zu koppeln, insbesondere angesichts von Fehlern in der Programmlogik. Angenommen, beim Empfänger führt die Verarbeitung einer Nachricht zu einem internen Fehler. Wie kann dann der Sender davon in Kenntnis gesetzt werden, und was kann er tun, um wieder einen konsistenten Zustand zu erzeugen? Sender und Empfänger arbeiten in getrennten Transaktionen: Kann das System die Sendertransaktion nicht abschließen, wird die Nachricht gelöscht, ohne je wirklich verschickt worden zu sein. Das Verschicken geschieht erst beim erfolgreichen Transaktionsabschluss. Kommt es in der Empfängertransaktion zu Problemen, wird diese zurückgerollt (Rollback) und die Nachricht erneut verschickt. Dieses Zurückrollen hat aber keinen Einfluss auf die Sendertransaktion, die zu diesem Zeitpunkt schon abgeschlossen ist.

Pannen bei der Übertragung

Treten bei der Übertragung von Nachrichten Störungen auf, erhält im Allgemeinen ein Administrator eine Mitteilung und behandelt das Problem. Wird eine Nachricht aufgrund logischer Fehler vom Empfän- ger nicht bearbeitet, fällt dies möglicherweise erst sehr spät auf, beispielsweise durch eine Rückmeldung vom Kunden. Selbst wenn das Problem iden- tifiziert wurde, kann seine Be- hebung problematisch sein, wenn die Senderapplikation nicht über geeignete Funktio- nen verfügt. Ein weiteres Problem taucht beim Ausfall der beteiligten Systeme auf. Wenn sowohl Sender- und Empfangsapplikationen als auch der Nachrichtendienst versagen, kann die Wiederherstellung eines konsistenten Systemzustands (Desaster Recovery) äußerst aufwändig sein.

Trotz der Kritik sind die hier gezeigten Lösungsansätze ausgereift und nach Einarbeitung auch ohne größere Überraschungen nutzbar. Die Projekterfahrung zeigt, dass Probleme bei diesen Verfahren selten technischer, sondern meistens fachlicher Art sind. Beispielsweise verhalten sich SAP-Funktionsbausteine manchmal nicht so wie erwartet und machen eine Begutachtung des Quellcodes (Code-Review) erforderlich.

In größeren Geschäftssystemen ergibt sich allerdings bei direkter Kopplung - ganz gleich, über welches Verfahren - schnell das Problem, dass viele Einzelapplikationen mit anderen Anwendungen auf individuelle Art integriert sind. Die daraus entstehenden Abhängigkeiten führen zu erheblichen Problemen in der Wartung und in der Betriebsführung. Ändert sich ein Subsystem, sind mit ihm auch alle Kopplungen anzupassen. Stammen die Kopplungstechniken noch dazu von Drittfirmen, fehlt unter Umständen das Know-how, um Änderungen vorzunehmen. Des Weiteren ist die Wiederverwendung vorhandener Kopplungen schwierig.

Da die für den Betrieb einer Applikation Zuständigen oft nicht über Entwicklungskompetenz verfügen, können sie Abhängigkeiten zwischen Subsystemen kaum erkennen. Solche Beziehungen erschweren den reibungslosen Neustart des Geschäftssystems. Den Autoren ist ein Fall bekannt, bei dem es nach einer Totalabschaltung zwei Tage dauerte, bis alle angekoppelten Business-Applikationen wieder vollständig verfügbar waren.

Knackpunkt Monitoring

Eine weitere Aufgabe der Betriebsführung ist das Geschäftssystemzu überwachen, um lange Antwortzeiten zu erkennen und ihnen vorzubeugen (Monitoring). Hierfür sind die Schnittstellen zwischen den Systemen besonders wichtig, da die Übertragung von Daten aufwändig und nicht immer zuverlässig ist. Wenn die Kopplungen individuell entwickelt wurden, mangelt es häufig an Monitoring-Schnittstellen.

Diese Probleme sind schon seit längerem bekannt. SAP hat mit "Netweaver" und insbe- sondere mit der "Exchange Infrastructure" eine Architektur und unterstützende Werkzeuge bereitgestellt, um Systeme über eine zentrale Plattform mit ei- ner SAP-Umgebung zu verbinden.

Integration mittels XI

SAPs Integrationslösung XI überträgt und verarbeitet Nachrichten. Ein Subsystem sendet eine Nachricht über einen XI-Adapter an ein Zielsystem. Der Adapter erzeugt eine XI-konforme Soap-Nachricht, die das Integrationssystem von SAP verarbeiten kann. XI bestimmt den Nachrichtenempfänger und gestattet es, die zu verwendenden Informationen in eine für das Ziel verständliche Form zu bringen. Die so überarbeitete Nachricht wird über einen Adapter an das Zielsystem übergeben. Auf diese Weise wird die Integration unterschiedlicher Systeme zentralisiert. Abhängigkeiten zwischen einzelnen Systemen sind klar erkennbar und wartbar. XI gestattet es ferner, Geschäftsprozesse grafisch zu modellieren, die mit anderen Subsystemen über Soap-Nachrichten interagieren.

Kommt es bei der Übertragung zwischen XI und dem Host zu Fehlern, versucht der Integration Broker, die Nachricht erneut zu versenden. Messages kann der Anwender manuell editieren. Kann XI eine Nachricht nicht zustellen, erzeugt es eine Fehlernachricht. Die Quellanwendung muss dann mit speziellen Routinen auf solche Fehler reagieren. In der Praxis führt das allerdings häufig zu Problemen.

Über JMS-Adapter, die Dritthersteller entwickelt haben, können Anwender bestehende MQ- Series-Installationen an XI anbinden. Statusmeldungen erlauben ein Monitoring des Nachrichtentransfers zwischen Quellsystemen, XI, MQ Series und dem Zielsystem.

Ressourcenhunger

Zwar bietet XI eine Reihe nützlicher Funktionen, doch der Ressourcenbedarf des Produkts ist im Vergleich zum Business Connector um ein Vielfaches höher. Zudem lässt sich das SAP-Produkt nur als Unicode-System installieren. Dadurch benötigt der Anwender eine leistungsstarke Hardware sowie eine Datenbank, die mindestens 50 GB umfasst.

Ein weiteres Manko: Anders als beim Business Connector ist die Anbindung externer Partnersysteme nicht mehr kostenlos. Kunden, die einen Umstieg auf XI planen, sollten auch berücksichtigen, dass nicht unerhebliche Betriebskosten auf sie zukommen.

XI ist ein sehr komplexes System, das nach wie vor stetig weiterentwickelt wird. Dies erzwingt sowohl einen intensiven initialen Schulungsaufwand als auch eine konstante Weiterbildung.

ESA und SOA

SAP schlägt als Architektur für Geschäftssysteme die "Enter- prise Services Architecture" (ESA) vor. Die Idee besteht darin, Subsysteme mit fachlichen Operationen zu definieren, so genannte Cross Components, und diese über eine nachrichtenbasierende Soap-Schnitt- stelle verfügbar zu machen. Die Geschäftsprozesse werden grafisch als Zustandsautomaten entwickelt, die mit den Subsystemen über Nachrichten interagieren. Die Exchange Infrastructure verwaltet Nachrichten zentral.

Die ESA entspricht im Prinzip der Service Oriented Architecture (SOA). Zur Realisierung einer SOA existieren unterschiedliche Enterprise Service Busses (ESBs), welche über mit XI vergleichbare Integrationsfunktionen verfügen. Ein Beispiel ist das Open-Source-Produkt "Mule" von Codehouse. Ein Vorteil der Open-Source-Software ist, dass sich der Anwender in puncto Integration der einzelnen Subsysteme nicht an einen Hersteller bindet. (fn)