SAP-Programme lassen sich grundsätzlich als Web-Services publizieren, und umgekehrt können von der SAP-Welt aus externe Web-Services aufgerufen werden. Es gibt eine Vielzahl von Beispielen, bei denen Unternehmen ihren Partnern Anwendungen zur Verfügung stellen und sich diese damit beispielsweise einen Bestell- oder Rechnungsstatus ansehen können. Auch Preisanfragen oder Verfügbarkeitsprüfungen von gewünschten Produkten (Available to Promise) etwa für die Logistikplanung lassen sich via Web-Services vornehmen.
Bei der Entwicklung von Web-Services mit SAP-Werkzeugen lassen sich kurz- und langfristige Ansätze unterscheiden. Der kurzfristige: Ein Unternehmen hat ein SAP-System und möchte dieses mit externen Web-Service-Applikationen verbinden oder eine eigene SAP-Anwendung nach außen darstellen. Beim langfristigen Ansatz geht es darum, die komplette IT-Landschaft auf eine serviceorientierte Architektur umzustellen, mit dem Ziel, alle Appli-kationen eines Unternehmens - seien sie von SAP oder anderen Herstellern - über eine Integrationsplattform zu koppeln und zu orchestrieren.
SAP unterstützt beide Ansätze und stellt dazu Netweaver als technische Plattform bereit. Derzeit am häufigsten anzutreffen ist allerdings die erste Variante. Hier müssen Systementwickler zwei Vorgehensweisen unterscheiden: Beim jüngsten Release der Walldorfer ERP-Software R/3 Enterprise laufen bereits alle Applikationen auf dem hauseigenen "Web Application Server" (WAS). Bei Vorgängerversionen, etwa R/3 4.6 und älteren Releases, muss der WAS quasi "dazugestellt" werden.
Der WAS ist das Herzstück der Netweaver-Plattform, die zudem ein "Enterprise Portal", eine "Mobile Infrastructure", das "Business Information Warehouse", ein "Master Data Management" und die "Exchange Infrastructure" (XI) beinhaltet. Für die Entwicklung von Web-Services sind im wesentlichen XI und der WAS (zurzeit in der Version 6.20 verfügbar) von Bedeutung. Zu dessen wichtigsten Komponenten gehören der "Internet Communication Manager", der die gängigsten Kommunikationsprotokolle wie Soap, HTTP, SMTP und FTP unterstützt, sowie die Entwicklungsumgebung "Web Dynpro" für die Java- und Abap-Programmierung.
Komponenten wie der "Workflow Builder", ein "Web Dispatcher", HTTP- und SMTP-Schnittstellen, ein Alert-Manager sowie die WSDL-Unterstützung runden das Leistungsspektrum des WAS ab. Zusätzliche Adapter, die zum Teil von SAP-Partnern wie Webmethods kommen, erlauben es, auf der einen Seite Fremdsysteme und andererseits die SAP-Welt selbst ab Release 4.6 abwärts anzubinden.
Alte und neue Welt verbinden
Bei der Integration mit älteren R/3-Installationen ist insbesondere die Konvertierung von XML- und HTTP-basierenden Dokumenten in die SAP-eigenen Formate Idoc (Intermediate Document) und RFC (Remote Function Call) von Bedeutung - quasi die Übersetzung der neuen in die alte SAP-Welt.
Bei neueren SAP-Anwendungen, die auf dem WAS aufsetzen - also ab der Version R/3 Enterprise - ist die Kompatibilität zu den Web-Services-Standards eingebaut. So sind alle vorhandenen SAP-Schnittstellen-Beschreibungen (BAPIs, Idocs, RFCs, Q-APIs und FTP) im "Interface Repository" (IFR) publiziert und als XML-Schema abgelegt. Dadurch ist eine Darstellung in WSDL, der Beschreibungssprache für Web-Services, sehr komfortabel. Der Vorteil: Der Entwickler muss nicht jedes Interface händisch neu definieren, sondern dies geschieht per Knopfdruck. Da der WAS diese Technik eingebaut hat, ist also kein zusätzlicher Konnektor vorzuschalten. Der Application Server ist insofern in der Lage, native Soap-Nachrichten zu lesen und XML-Messages im Soap-Format zu versenden. Zusätzlich existiert ein Werkzeug, mit dem sich XML-Schnittstellen beschreiben lassen und mit dessen Hilfe sich alle SAP-Interfaces in XML verpacken und nach außen als WSDL darstellen lassen.
Anwender, die auf Basis von älteren SAP-Systemen ohne integrierten WAS mit Web-Services arbeiten möchten, können sich wie folgt behelfen: Sie installieren zusätzlich zu ihrer R/3-Suite den WAS auf ihrem System. Für die Kommunikation mit externen Services arbeitet der Application Server dann wie zuvor beschrieben. Er generiert die Web-Service-Schnittstellen und kommuniziert via Web-Services-Standards mit externen Anwendungen. Für die bestehenden internen R/3-Applikationen können die SAP-Schnittstellen angesprochen werden, da der WAS eine Kommunikationsbrücke zu den bekannten RFCs oder BAPIs aufbaut. Dieses Vorgehen zahlt sich auch dann aus, wenn Unternehmen mittelfristig auf R/3 Enterpise migrieren wollen. Dann kann der zuvor parallel eingesetzte WAS abgeschaltet und durch den in R/3 Enterprise integrierten Application Server ersetzt werden. Dieser erledigt die Aufgaben des Vorgängers, ohne dass Einstellungsänderungen nötig werden. So sind beispielsweise auch erweiterte RFCs, BAPIs oder selbst geschriebene Bausteine bei einem Release-Wechsel problemlos lauffähig.
Bei der Entwicklung neuer oder der Erweiterung vorhandener Applikationen und Schnittstellen stehen Programmierern grundsätzlich zwei Werkzeuge zur Verfügung. Anwender, die seit Jahren mit der Abap-Workbench vertraut sind, können diese weiterhin nutzen und auf ihre Daten und Schnittstellen zugreifen sowie Programme neu schreiben. Darüber hinaus bietet der WAS 6.20 die Möglichkeit, Programme in Java zu entwickeln und etwa mittels EJB-Schnittstellen dann als Web-Service zu publizieren.
Der WAS 6.20 unterstützt zwar alle benötige Web-Services-Protokolle, doch ist die Entwicklungsumgebung Web Dynpro noch recht rudimentär. Speziell die Hilfe durch Wizzards und automatisches Deployment können den Vergleich zu ausgereiften Entwicklungsplattformen etwa von Borland oder Microsoft nicht bestehen. Hier verspricht der WAS 6.30, der Ende des Jahres verfügbar sein soll, Besserung. Dieser soll eine Workbench umfassen, die Konfigurationen von Web-Services per Mausklick erlaubt. Die Walldorfer legen bei der Weiterentwicklung ihres Application Servers sehr viel Wert darauf, die Sicht auf das SAP-System von der auf die externe Darstellung und Kommunikation stark zu entkoppeln. Gründe dafür liegen in der Mächtigkeit einiger BAPIs sowie in der Tatsache, dass externe Systeme nicht dem Datenmodell von SAP entsprechen müssen. Hier hilft die Workbench künftig dabei, die Quell-BAPIs einfach zu modifizieren, von unnötigen Daten und Parametern zu befreien und so zu mappen, dass nur noch die benötigten Teile als Web-Services aufbereitet werden.
SAP-Plugin für Eclipse
Auch für den Fall, aus SAP-Anwendungen heraus die Web-Services anderer Applikationen aufzurufen, verspricht der WAS 6.30 Verbesserungen. Bisher ist es notwendig, die Aufrufe externer Web-Services aus Abap oder Java heraus manuell zu erledigen. Mit dem WAS 6.30 steht hierfür ein besserer Java-Support zur Verfügung, der die Codings für die Aufrufe automatisch generiert. Der Programmierer arbeitet dazu mit dem SAP-Plugin für die Entwicklungsplattform "Eclipse". Dort wird die Identifikation des aufzurufenden Web-Service eingegeben, und die Systemumgebung generiert automatisch die nötigen Aufrufe. Der Entwickler ist also nicht mehr gezwungen, selbst Soap-Messages einzugeben oder zu parsen, sondern kann sich auf die Programmierung der Logik konzentrieren. (ue)
*Heidi Neumes ist Managing Consultant und Matthias Kumm Senior Consultant Financials der Itelligence AG.
Angeklickt
Zur Entwicklung von Web-Services im R/3-Umfeld sind im Wesentlichen die SAP-Produkte "Exchange Infrastructure" (XI) und "Web Application Server" (WAS) von Bedeutung. Die Kompatibilität zu Web-Services-Standards ist hier eingebaut. So sind etwa Schnittstellen wie BAPIs, Idocs oder RFCs im "Interface Repository" als XML-Schema abgelegt. Lediglich die Entwicklungsumgebung "Web Dynpro" ist derzeit noch etwas dürftig und soll erst mit der Verfügbarkeit von WAS 6.3 zur komfortablen Workbench für die Konfiguration von Web-Services heranreifen.
Rasche Bonitätsprüfung
Die Kasolvenzia Inkasso Deutschland GmbH (KSI) bietet ein professionelles Forderungs-Management im Bereich Business-to-Business und stellt dazu eine Internet-fähige Plattform bereit, die auf Basis von Web-Services kommuniziert. Kunden von KSI sind Unternehmen, die ein gemeinsames Interesse daran haben, die Bonität ihrer Kunden zu kennen. Sie geben bonitätsrelevante Daten ihrer Klienten wie Verzugstage oder Negativmerkmale anonymisiert in einen zentralen Daten-Pool ein, den KSI zusammen mit weiteren Partnern aufgebaut hat. Auf diesen haben Systemteilnehmer Zugriff, um sich rasch über Käufer und deren finanzielle Situation informieren zu können.
Die von der Itelligence AG entwickelte Lösung besteht aus zwei Komponenten: dem zentralen Daten-Pool "CMS-Pool" und dem Softwarebaustein "CMS-Link", der auf den Systemen der KSI-Kunden installiert wird. Die Kopplung von CMS-Link zu den internen SAP-Anwendungen oder Drittsystemen der Kunden erfolgt über RPCs oder BAPIs. In CMS-Link, das als Abap-Programm auf Basis des SAP Web Application Servers 6.10 entwickelt ist, werden alle Finanzdaten über Kunden gesammelt.
Durch Business Server Pages (BSPs), Abap und HTML ist CMS-Link ohne zusätzliche Frontend-Software auch in Filialen einsetzbar. Die Verknüpfung von CMS-Link und -Pool erfolgt als Web-Service via Soap-Messages. Dadurch lassen sich sehr rasch weitere Versorgungssysteme wie Auskunfteien oder Bankauskünfte anbinden.
Abb: Von der Business-Applikation zum Web-Service
SAPs Web Application Server bietet die Möglichkeit, Java-Programme zu entwickeln und mittels EJB-Schnittstellen als Web-Service zu publizieren. Quelle: nach SAP