Serviceorientierte Architekturen (SOAs) gelten als der nächste große Evolutionsschritt der Unternehmens-IT. Mit ihnen lassen sich Geschäftsprozesse flexibler gestalten und anpassen. Dies kommt den Anwendern sehr gelegen. Denn obgleich viele Unternehmen ihre grundlegenden Prozesse bereits mit Lösungen aus der SAP Business Suite abdecken, besteht für manche individuellen Abläufe Optimierungspotenzial über den Standard hinaus. So muss beim Wartungsprozess eines Versorgungsunternehmens beispielsweise ein bestimmter Schaltschrank nicht nur im Verzeichnisdienst gefunden, sondern auch geografisch geortet werden.
Bei einer SOA sind Software-Komponenten, die für einen bestimmten Geschäftsprozess benötigt werden, als Services gekapselt und über einen Servicebus miteinander verbunden. Diese Kapselung erfolgt mit einem betriebswirtschaftlichen Fokus. Daher können Anwender die Services ohne großes technisches Know-how zusammenfügen und beispielsweise über das Standardprotokoll SOAP (Simple Object Access Protocol) aufrufen. Darüber hinaus lassen sie sich problemlos konfigurieren und in anderen Zusammenhängen wieder verwenden. Viele Unternehmen wollen diese Option schon in ihrer bestehenden IT-Architektur nutzen.
Hier sind allerdings häufig Szenarien an der Tagesordnung, die Standardlösungen und Individualentwicklung kombinieren – mit der Folge immanenter Systembrüche und fehlender Durchgängigkeit. Doch auch solche Architekturen können in eine SOA-Fähigkeit hineinwachsen. Verbesserte Integrationswerkzeuge und Technologiestandards wie Web-Services helfen, die Schnittstellen-Problematik zu überwinden und alle Prozesse auf Basis einer serviceorientierten Infrastruktur zu unterstützen.
Das technische Rüstzeug für SOAs sind EAI-Komponenten – im SAP-Umfeld vor allem die SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI). Lücken, die bei einer serviceorientierten Kopplung von SAP-Lösungen mit Drittanwendungen entstehen können, weil die jeweiligen Applikationen SOAP oder andere Standardschnittstellen nicht adäquat unterstützen, lassen sich mit Open-Source-Werkzeugen schließen. So wäre es im Einzelfall beispielsweise möglich, einen Open-Source-Web-Server wie Apache TomCat zu nutzen, um eine Web-Service-Schnittstelle anzubieten.

Von EAI zur Serviceorientierung

Wie sich eine im Grunde klassische EAI-Aufgabe auf direktem Wege zum Eintritt in eine serviceorientierte Systemkonzeption nutzen lässt, zeigt ein Projekt der Lynx-Consulting AG bei einem Versorgungsunternehmen. Die Berater realisierten dabei den Geschäftsprozess “Störfallmanagement”, indem sie geografisch orientierte Informationen in betriebswirtschaftliche Abläufe integrierten.
Versorgungsunternehmen setzen in der Regel außer Lösungen zum Enterprise Resource Planning (ERP) auch Geografische Informationssysteme (GIS) ein. Damit lassen sich geografische Daten und die zugehörigen Sachinformationen zu Geräten – wie ein Hausanschluss oder eine Trafostation mit ihren verschiedenen Normierungen und Lasten – sowie deren Sachumgebung – etwa der Verteiler bei einem Hausanschluss – erfassen. Diese Informationen helfen, Netze vollständig zu dokumentieren und schneller zu planen.
Daten zur Verwaltung der genutzten Geräte und Geräteplätze werden typischerweise auch in der Komponente Instandhaltung (Plant Maintenance, PM) von SAP R/3 benötigt. Daher betreffen Veränderungen an diesen technischen Objekten in der Regel sowohl die ERP-Lösung als auch das GIS. Bei fehlender Integration müssen Änderungen jeweils manuell durchgeführt werden – was wenig effizient und äußerst fehleranfällig ist. Das Interesse an einer durchgängigen Prozessgestaltung und -synchronisation ist entsprechend hoch.

Dreh- und Angelpunkt: SAP NetWeaver XI

Daher harmonisierte das Lynx-Team die Integration der Komponente PM aus SAP R/3 4.6c und der GIS-Anwendung GE Smallworld. Hierfür wählte es eine Konfiguration des SOA-Prinzips auf Basis von EAI-Techniken. Dabei stellt SAP NetWeaver XI als EAI-Plattform die benötigten PM-Funktionalitäten als Dienste zur Verfügung und übernimmt außerdem die Aufgabe des Servicebus.
Um das GIS servicefähig zu machen, realisierte das Team einen SOAP-Adapter für GE Smallworld. Der Adapter wird über einen Web Application Server – in diesem Fall das Open-Source-Produkt Apache Tomcat – angesprochen. Darüber hinaus werden auf beiden Seiten, im GIS und in SAP NetWeaver XI, Verzeichnisse (Repositories) mit Meta-Informationen geführt, wie Interface-Beschreibungen und Datenschemata zu den realisierten Services. Damit lassen sich die Dienste in weiteren Szenarien wiederverwenden.
Die Dienste sind hierarchisch aufgebaut. Auf der niedrigsten Stufe befinden sich Basis-Services, die direkt auf GIS-Funktionalitäten, wie das Lesen oder Schreiben von Daten, zugreifen. Darauf aufsetzend sind Enterprise-Services definiert. Der Enterprise-Service “read_HA_Kasten”, der die Attribute eines Hausanschlusskastens ausliest, ist beispielsweise auf der Grundlage des Basis-Service “genRead” erstellt. Eine XML-Struktur (Extensible Markup Language) spezifiziert genau, welche GIS-Funktionalität über den Enterprise-Service zur Verfügung gestellt werden soll. Aus der XML-Struktur lässt sich automatisch ein Service einschließlich seiner Beschreibung als WSDL-Datei (Web Services Definition Language) erzeugen. Diese Datei wird in SAP NetWeaver XI als externe Datendefinition importiert. Dort stellt sie eine Nachrichtentypbeschreibung für den Aufbau einer Schnittstelle zur Verfügung, die den Zugriff auf den Service aus SAP NetWeaver XI ermöglicht.
Im Integration Builder von SAP NetWeaver XI stehen wiederum alle erforderlichen Werkzeuge für das Design und die Konfiguration des Prozessflusses bereit, beispielsweise die Integration Process Engine. Zudem lassen sich im Integration Builder die Beschreibungen von Intermediate Document Interfaces (IDocs), Business Application Programming Interfaces (BAPI) oder eigenen Funktionsbausteinen aus PM, etwa ein RFC-Baustein zum Auslesen von Informationen aus dem GIS, einpflegen. Dort werden außerdem die Servicebeschreibungen eingelesen sowie anschließend die entsprechenden Routing-Regeln und Kommunikationskanäle konfiguriert.
Ruft ein Anwender aus PM einen GIS-Service auf, etwa für den Austausch von Transformatoren, geht eine Meldung mit allen relevanten Daten und einer WSDL-Beschreibung des Dienstes an SAP NetWeaver XI. Die Plattform wertet die Nachricht aus und stößt einen Prozess an, der die Services via SOAP aufruft und ihnen die nötigen Informationen zur Durchführung bereitstellt. Der Aufruf eines PM-Services aus GE Smallworld funktioniert ähnlich. Dabei gibt das GIS die Anfrage an den SOAP-Adapter weiter, der den Aufruf an die SAP NetWeaver XI sendet. Dort wird die SOAP-Nachricht ausgewertet, um die gewünschte Funktionalität aus PM als Service zu nutzen. Das Ergebnis der Service-Durchführung, beispielsweise ob das Anlegen der Information erfolgreich war, wird zum Schluss wieder über den SOAP-Adapter an das GIS übergeben.
Derzeit gibt es für den Prozess “Störfallmanagement” fünf Basisdienste: die Netzverfolgung, das Ändern von Objekten, das Anlegen von Objekten, das Löschen von Objekten und das Lesen von Objektdaten.

Jederzeit offen für neue Services

Der auf Basis des SOA-Konzepts realisierte Adapter erleichtert es, zusätzliche Services einzubinden. Im Einzelfall ließen sich einzelne Funktionen dieses Adapters auch durch den Aufbau einer weiteren individuellen Schnittstelle realisieren, die keine Middleware wie SAP NetWeaver XI benötigt. Allerdings sind solche Schnittstellen wesentlich stärker abhängig von den Releases der entsprechenden Systeme und erfordern mehr Aufwand bei der Weiterentwicklung sowie Betreuung. Außerdem lassen sie sich nicht bei anderen Kunden mit dort jeweils eigenen Strukturen ohne entsprechende Tools wiederverwenden. Dagegen erlaubt es die im Projekt realisierte Lösung, außer SAP NetWeaver auch andere SOA-Middleware-Systeme einzubinden, da auf jeder Anwendungsseite ein Repository geführt wird. Zudem ist es möglich, die Service-Informationen in ein zentrales Repository zu überführen oder den SAP Web Application Server (SAP Web AS) zu verwenden.
Open-Source-Programme – in diesem Fall insbesondere der Web Application Server Apache Tomcat und Web-Service-Werkzeuge wie Axis oder Xfire, ermöglichen den Aufbau einer SOA für Anwendungen, die normalerweise keine Serviceorientierung unterstützen. Sie ergänzen nicht nur Integrationsplattformen wie SAP NetWeaver um zusätzlichen “Einbindungskitt”, sondern unterstützen auch den schnellen Einstieg in neue Aufgabenfelder, ohne dass Überlegungen bezüglich Lizenzfragen oder Verfügbarkeiten notwendig sind. So sind Unternehmen in der Lage, mit vertretbarem Aufwand und überschaubaren Abhängigkeiten auch in anderen Bereichen, etwa im Metadatenmanagement und Product Lifecycle Management (PLM), erste Schritte in die SOA-Welt zu machen.