Die Definition und Programmierung einer Schnittstelle zwischen ERPSystemen und anderen Softwarelösungen treiben regelmäßig alle Beteiligten zur Verzweiflung: Der Projektleiter sieht das Budget und den Zeitplan in Gefahr. Der Berater scheut die langen Abstimmungsrunden mit anderen Software-Anbietern und die Programmierer befürchten eine unbefriedigende iterative Programm-Erstellung mit mehreren Optimierungsläufen. Der Kunde sieht sich schon mit nicht besprochenen Konventionen und undokumentierten Funktionalitäten konfrontiert.

Eine Ursache für diese Probleme liegt im stets gleichen, traditionellen Schnittstellen-Ansatz: Noch viel zu oft wird auf simple Datentransfers als Technologiebasis zurückgegriffen. Dieser häufig kleinste gemeinsame Nenner zwischen zwei Softwarelösungen ist sehr zeitintensiv und aufwendig: Neben den üblichen Kommunikationsproblemen zwischen den Programmierern und den - weniger softwaretechnisch versierten - Anwendern, fallen weitere Aufgaben an.

Dazu zählen beispielsweise die Abstimmung der technischen Details (Dateiformate, Dateitypen) oder die zu programmierende Geschäftslogik, die sich auf Basis eines Datei- Austauschs nicht transferieren lässt. Fast immer notwendig ist eine Datenkonvertierung, um die Feldformate und -längen der unterschiedlichen Systeme anzupassen.

Ebenso muss der Programmierer Methoden entwickeln, um die Transaktionssicherheit des Datenaustauschs zu gewährleisten und Maßnahmen für ein erneutes Verarbeiten der Daten bei einer fehlerhaften Übertragung bereitstellen - inklusive der Benachrichtigung des Administrators bei Übertragungsfehlern. Zudem müssen Parameter wie Dateiname und Verzeichnis- Strukturen flexibel konfigurierbar sein.

Trotzdem, die traditionell erstellten Schnittstellen sind eher statisch und nicht einfach erweiterbar: Neue Parameter und Datenfelder erfordern in der Regel eine erneute Programmierung der Schnittstelle. Ziel muss es sein, die für eine Problemstellung beste Lösung zu finden, die mit dem geringsten Aufwand zu implementieren ist und dennoch größtmögliche Flexibilität gewährleistet. Solche Kopplungstechnologien sind beispielsweise:

• Webservices,
• Message-Queue-Systeme,
• und Enterprise Service Bus.

Webservices - wenn es synchron sein soll

Webservices erleichtern das Zusammenspiel verschiedener Anwendungen, indem sie bestimmte Funktionen einer Anwendung als definierte und standardisierte Schnittstellen anderen Anwendungen zur Verfügung stellen. Webservices sind durch das W3C (WWW-Consortium) standardisiert und werden von vielen Programmierumgebungen unterstützt. Aus der Standardisierung resultiert eine weitgehend einheitliche Fehlerbehandlung beim Aufruf der Webservices. Maßnahmen gegen inhaltliche Fehler (zum Beispiel fehlende Stammdaten) sind weiterhin zu programmieren.

Eine besondere Stärke von Kopplungen via Webservices liegt in der losen Anbindung der Anwendungen: Es bestehen keine direkten Abhängigkeiten zwischen den Systemen, so dass ein Update eines Systems keine Auswirkungen auf das andere System hat. Bei Bedarf lassen sich die Systeme dennoch synchron koppeln: Durch den Aufruf einer Funktion (Webservice) in einer anderen Anwendung kann die aufrufende Applikation auf deren Rückmeldung warten und die Rückgabe- Daten weiter verarbeiten.

Dieses Feature zeigt, wo der Einsatz- Schwerpunkt von Webservices liegt - im synchronen Datenaustausch zwischen zwei Systemen. Weniger sinnvoll ist es, Massen-Daten wie einen Bestandsabgleich mit dem Lagerverwaltungssystem (LVS) darüber durchzuführen.

Ein mittelständisches Unternehmen nutzt diese Eigenschaft von Webservices bei der Anbindung ihres LVS an die ERP-Lösung proAlpha, um neben dem zeitgesteuerten Austausch von Bestandsund Stammdaten mit dem ERP-System auch Daten anzufordern, die anschließend weiterverarbeitet werden.

Mit den vom Technologie-Partner Progress bereitgestellten Werkzeugen konnten diese Funktionen leicht als Webservice implementiert werden. Der Überwachungsaufwand für Systemadministratoren ist gering, da die Anwender die meisten Probleme selbstständig lösen können. Bei einer klassischen Batch-Verarbeitung von Austauschdateien wäre das nicht gegeben gewesen.

Message-Queueing: Übertragung garantiert

Bei sogenannten Message-Queue-Systemen handelt es sich um eine Middleware, die verschiedene Systeme miteinander verbindet. Der Datenaustausch erfolgt nachrichtenorientiert (häufig im XMLFormat), wobei die Middleware alle Aufgaben übernimmt, die ansonsten bei einem Austausch über ein Dateisystem programmiert werden müssen, beispielsweise:

• Pufferung von Nachrichten;
• garantierte Zustellung;
• erneute Zustellung von Nachrichten
• und Routing von Nachrichten.

Die meisten Systeme unterstützen die „Java Messaging-Services"-Spezifikation und werden daher als JMS-Systeme bezeichnet. Die besondere Stärke der Message- Queue-Systeme liegt in der garantierten Zustellung von Nachrichten. Da alle „Hilfsfunktionen" für den Datenaustausch das Message-Queue-System übernimmt, können sich Programmierer auf die Geschäftslogik konzentrieren. Zudem reduziert sich wie bei den Webservices der Überwachungsaufwand auf ein Minimum. Analog zu den Webservices besteht nur eine lose Kopplung der Systeme.

Trotz ihrer Nachteile sind „hart codierte“ Schnittstellen immer noch weit verbreitet.

© proAlpha

Sinnvoll ist der Einsatz von Message-Queue-Systemen, wenn zwei Systeme transaktionssicher und stabil miteinander kommunizieren müssen und keine Nachricht verloren gehen darf. Ein Handelsunternehmen, das proAlpha als ERP-System einsetzt, stand vor der Herausforderung, ein Lagerverwaltungssystem anzubinden.

Aufgrund des hohen Lagerumschlags (viele Lagerbewegungen) lag das Hauptaugenmerk auf einer stabilen Kopplung zwischen LVS und ERP. Um Bestandsdifferenzen zwischen den beiden Systemen zu vermeiden, war die garantierte Zustellung von Nachrichten zwingend gefordert. Trotzdem musste es möglich sein, die Systeme ohne gegenseitige Beeinflussung zu warten.

Diese Anforderungen führten dazu, die „JMS-Middleware SonicMQ" der Firma Progress einzusetzen, zumal die ERP-Software und das LVS die JMS-Spezifikation unterstützen. Die realisierte Kopplung ist flexibel und stabil: Selbst nach einem Stromausfall im Lager wird die Zustellung der angefallenen Nachrichten aus dem ERP-System garantiert. 

Abgeglichen werden die relevanten Stammdaten (Artikel, Lieferanten) und alle Lagerbewegungen aus dem Lagerverwaltungssystem. Aufgrund der Stabilität und des geringen Überwachungsaufwands hat das Unternehmen auch die Kopplung ihrer Artikel/Mediendaten-Plattform mit der ERP-Lösung auf die Middleware Sonic-MQ umgestellt. Dabei konnten die Programmierer viele Funktionen erneut verwenden.

Service-Bus sorgt für Flexibilität

Sofern mehrere ähnliche Schnittstellen zwischen verschiedenen Systemen benötigt werden, empfiehlt sich der Einsatz eines Enterprise Service Bus (ESB). Ein ESB ist eine Plattform, die einer Reihe von Services als Integrationspunkt dient. Die ESB-Services lassen sich in drei Kategorien gliedern:

• On Ramp-Dienste, um Nachrichten mit dem ESB zu empfangen;
• Off Ramp-Dienste, mit denen Nachrichten vom ESB aus gesendet werden,
• sowie Midiation-Dienste, welche die Kommunikation in den Prozessen auf dem ESB sicherstellen.

Jeder Service übernimmt definierte und abgegrenzte Aufgabe mit spezifizierten Schnittstellen, die auf dem ESB zu Prozessen miteinander verbunden werden. Die Kommunikation zwischen den verschiedenen Services erfolgt in Form von Nachrichten im XML-Format. Der ESBGedanke ist eng verknüpft mit den Ideen zum Aufbau serviceorientierter Architekturen (SOA).

Verschiedene Services lassen sich auf dem „Enterprise Service Bus“ zu Prozessen verbinden.

© proAlpha

Die besondere Stärke eines Enterprise Services Bus liegt in den umfangreichen Diensten, welche die Middleware zur Verfügung stellt: Der ESB steuert den Nachrichtenfluss und stellt verschiedenste Dienste bereit, beispielsweise für die Übertragung von Nachrichten über den Bus, per http, ftp, pop3, JMS oder auch über ein Dateisystem. Darüber hinaus gibt es die Möglichkeit, eingehende Nachrichten über einfache Transformationen zu konvertieren und somit für ein Zielsystem lesbar zu machen.

Bei diesen Konvertierungen kommt häufig die Programmiersprache XSLT in Verbindung mit grafischen „Mapping-Tools" zum Einsatz, so dass die Programmierung aufwendiger Konvertiervorschriften entfällt. Weiterhin erlauben Dienste wie „Content Based Routings", Nachrichten anhand ihrer Inhalte an andere Dienste auf dem ESB zu senden. Da der Enterprise Service Bus den Nachrichtenfluss kontrolliert, ist für sichere Zustellung der Nachrichten und aktive Benachrichtigung im Fehlerfall gesorgt. Der Einsatz eines Enterprise Service Bus kann für jede Art von Schnittstelle sinnvoll sein. Die Investition in den Aufbau einer solchen Umgebung lohnt sich aber erst, wenn mehrere, idealerweise ähnliche Schnittstellen abgebildet werden.

Bei der Einführung von proAlpha bei einem Armaturen-Hersteller in Luxemburg war eine wichtige Voraussetzung, dass Aufträge aus dem ERP-System der Konzern-Zentrale ohne Anpassungen übernommen werden können. Nach Analyse der Aufgabenstellung und vorhandenen technischen Möglichkeiten des Konzern- ERPs fiel die Entscheidung auf den Enterprise Service Bus SonicESB. Für die Anbindung des Konzern-ERPs wurde auf dessen EDI-Schnittstelle (Electronic Data Interchange) zurückgegriffen, um die Aufträge zu versenden. Der ESB empfängt diese Nachrichten und führt eine XSLT-Transformation in ein für das ERP verständliches Format durch.

Die Nachricht wird anschließend an einen von pro- Alpha implementierten Service zum Aufruf des Applikationsservers weitergegeben. Letzterer verarbeitet die Nachrichten und legt im Ziel-ERP die entsprechenden Aufträge an. Neben der hohen Stabilität der Schnittstelle ist vor allem die einfache Erweiterbarkeit ein großer Vorteil. Die Flexibilität hat sich gezeigt, als neben den Aufträgen die Angebote ausgetauscht werden sollten. Dies wurde durch eine Erweiterung der XSLT-Transformation realisiert. Bei der Auswahl der richtigen Kopplungstechnologie sollte immer der Geschäftsprozess im Vordergrund stehen.

Aus dessen Analyse ergeben sich die Anforderungen an eine zu implementierende Schnittstelle. Generell sind dabei Kriterien zu berücksichtigen, die für eine möglichst flexible und zukunftssichere Schnittstelle sorgen.

Im Einzelnen sind dies:

• Stabilität,
• Transaktionssicherheit,
• Wiederverwendbarkeit für ähnliche Anwendungsfälle
• sowie lose Kopplung.

Die in die Evaluierung investierte Zeit erhält man später bei Implementierung und Betrieb der Schnittstelle vielfach zurück.

Autor: Johannes Benedikt Imhoff ist Consultant bei der proAlpha AG in Solingen.