Das Rosettanet Business Framework ist ein ganzheitlicher Ansatz für eine standardisierte und integrierte Geschäftsprozessabwicklung. Es setzt sich aus den Ebenen Kommunikation, Syntax, Enveloping, Semantik, Dateninhalte und Geschäftsprozess zusammen. Die einzelnen Ebenen lassen sich am besten in einem Vergleich zum Datenaustausch in Hightech-Betrieben via Edifact-Datenformat über X.400-Netzwerke beschreiben.

Im Rosettanet Business Framework ist die Vorgabe XML als Datenformat und HTTP/S als Kommunikationsebene zu nutzen. Da es sich bei HTTP/S im Gegensatz zum klassischen X.400 um eine Internet-basierende Kommunikation handelt, sind hier diverse Verschlüsselungs- und Authentifizierungsverfahren anzuwenden. Die inhaltliche Definition der Nachrichten (Bestellung oder Rechnung) ist Bestandteil der "Rosettanet Partner Interface Processes". Das Pendant im klassischen Datenaustausch sind die "Edifact Message Descriptions". Das Enveloping, also das Verpacken und Adressieren der Nachricht, erfolgt nach den Vorgaben des Rosettanet Implementation Framework (klassisch: Edifact Service Segmente).

Vorgaben statt Vereinbarungen

Sind beim klassischen Datenaustausch die exakten Geschäftsprozessabläufe und Dateninhalte zwischen den Handelspartnern noch bilateral zu definieren, geben bei Rosettanet die Partner Interface Processes und Business Dictionaries Geschäftsprozessabfolgen und Dateninhalte exakt vor. Dies stellt eine signifikante Weiterentwicklung zum klassischen Datenaustausch dar.

Die Partner Interface Processes (PIP) definieren nicht nur die einzelnen Geschäftsprozesse beziehungsweise deren Abfolgen. Neben der strukturellen und inhaltlichen Beschreibung umfasst ein PIP vielmehr auch exakte Angaben über Prozesslaufzeiten, Reaktionen des Partners und Eskalationsmechanismen. PIPs sind in Cluster eingeteilt: Neben den zentralen Clustern für Lagerbestands-Management, Produktinformationen, Auftrags- und Bestellabwicklung sowie Produktentwicklung und Marketing, existieren zusätzliche für die Bereiche Herstellung, Service und Support sowie für die Service- und Setup-Prozesse von Rosettanet. Das Cluster Bestellabwicklung besteht wiederum aus den vier Segmenten:

- "3A" für Anfragen und Auftragseingang,

- "3B" für Transport und Distribution,

- "3C" für Retouren und Zahlungsverkehr sowie

- "3D" für Produktkonfiguration.

Charakteristisch für einen PIP ist die Bestätigung oder Ablehnung der ausgehenden Nachricht durch den Empfänger. In der Bestätigung (receipt) wird die inhaltliche und strukturelle Korrektheit der Nachricht sowie die richtige Übergabe der Daten an die betriebswirtschaftliche Standardsoftware quittiert beziehungsweise im Fehlerfall unter der Angabe des Fehlers an den Sender zurückgesandt. Für jeden PIP existieren exakte Beschreibungen über die Aufgaben, Reaktionen und Mechanismen der Handelspartner.

Der Datentransfer zwischen Geschäftspartnern wird im Rosettanet Implementation Framework (RNIF) definiert. RNIF spezifiziert den XML-Datenaustausch für die Ebenen Nachrichtentransport, Routing und Packaging sowie Integration von Sicherheitskonzepten. Die Kommunikation zwischen den Partnern erfolgt auf Basis des HTTP/S-Protokolls und läuft wie folgt ab:

- Beantragen eines Server- und Client-Zertifikats - dabei ist der Client der Sender, der Server der Receiver. Beim Aufbau der Kommunikation muss jeweils das Zertifikat der Zertifizierungsstelle Server-seitig vorhanden sein. Bevor ein HTTP/S-Verbindungsaufbau realisiert werden kann, muss zuvor ein Handshake zwischen Server und Client erfolgen. Hierzu senden Client und/oder Server je Sitzung eine String-Abfolge unter anderem mit Session-ID sowie zu dem bei der Übertragung verwendeten symmetrischen Verschlüsselungsalgorithmus.

- Austausch der Server- und Client-Zertifikate nach dem Public-/Private-Key-Verfahren - sobald die Authentifizierung abgeschlossen ist, erfolgt der HTTP/S-Verbindungsaufbau. Die Mime-Datei wird dabei symmetrisch verschlüsselt.

- Es folgt der eigentliche Datenaustausch der verschlüsselten Mime-Datei. Sie enthält wiederum drei XML-Dokumente (die Präambel, den Service-Header und den Service-Content).

- Die gesendete Mime-Datei trifft HTTP-Server-seitig ein und wird auf Rosettanet-Konformität überprüft. Entspricht sie nicht den Rosettanet-Anforderungen, wird sie an den Sender zurück übermittelt. Bei Rosettanet-Konformität wird die Datei dem Konverter übergeben. Es erfolgt die eigentliche Datenkonvertierung.

- Verläuft die Konvertierung beziehungsweise Prüfung gegen die Document Type Definition (DTD) erfolgreich, wird ein "Receipt Acknowledgement" generiert und an den Absender in einem Mime-Dokument übermittelt. Tritt ein Problem auf, gibt es statt dessen ein "Receipt Acknowledgement Exception", das unter Angabe des fehlerhaften XML-Dokumententeils ebenfalls in Form eines Mime-Dokuments an den Absender geschickt wird.

Was muss beachtet werden?

Bei der Planung und Umsetzung einer Rosettanet-Lösung sind im Vergleich zu einem klassischen EDI-Projekt mehrere spezifische Schritte zu beachten. Zum einen ist dies das Aufsetzen der HTTP/S-Kommunikation auf einem dedizierten Server. Zum anderen müssen die Rosettanet-Server eingerichtet werden, also die inhaltliche Abstimmung der PIPs und die Erstellung der Acknowledgement-Messages (Statusmeldungen) erfolgen. Bei letzteren ist zu klären, unter welchen Bedingungen sie erzeugt werden (Setup) und welchen Inhalt sie haben sollen. Um die Einführungsphase auf ein erträgliches Maß zu reduzieren, empfiehlt sich ein paralleler Start des HTTP/S-Setup und der PIP-Integration. Gestaltet sich das X.400-Kommunikations-Setup bei klassischen EDI-Projekten als eine eher triviale Aufgabe, erfordert das Setup des HTTP/S-Servers, der Zertifikatsaustausch mit den Partnern sowie der Kommunikationstest einen nicht unerheblichen Zeitaufwand, zumal es hier auch auf die Erfahrung des Geschäftspartners ankommt.

Abstimmung des Contents

Durch die XML-Syntax der Geschäftsnachrichten wird eine inhaltliche Abstimmung der auszutauschenden Informationen in der Regel aufwändig. Im Vergleich zur eindeutigen Edifact-Semantik, sind die frei definierbaren XML-Elemente einer Rosettanet-Nachricht nicht allgemeingültig inhaltlich spezifiziert. Die Abstimmung der übertragenen Content-Informationen zwischen Sender und Empfänger sollte daher vor der Erstellung der Zuordnungsvorschriften ausführlich dokumentiert werden.

Sind die Zuordnungsvorschriften für die eigentlichen Geschäftsnachrichten festgelegt, müssen anschließend die entsprechenden Statusmeldungen abgesprochen werden. Acknowledgement-Messages sind nicht spezifisch und können daher nachrichtenübergreifend angewandt werden. Daran sollte sich ein intensiver Test der Übermittlung von Statusmeldungen von inhaltlich und strukturell fehlerhaften Nachrichten anschließen.

Akzeptanz zeichnet sich ab

Die bisherigen Praxiserfahrungen zeigen, dass sich Rosettanet in der Lieferkette der Hightech-Industrie als ein Standard für eine integrierte Geschäftsprozessabwicklung etablieren wird. Alle führenden Unternehmen einer Wertschöpfungsstufe setzen bereits Rosettanet-Standards ein beziehungsweise sind gerade mit der Einführung beschäftigt. Auch wenn der Aufwand für die Einführung einer Rosettanet-Lösung im Vergleich zu klassischen Integrationsprozessen mit Edifact und X.400 höher ist, eröffnen sich durch geringere Kommunikationskosten Einsparungspotentiale sowie durch Acknowledgement-Nachrichten eine schnellere und effizientere Geschäftsprozessabfolge zwischen den Partnern. (ue)

*Björn Georg ist Consultant Business Transactions bei der Retarus Network Services GmbH in Höhenkirchen-Siegertsbrunn.

Rosetta vs. Edifact

Ebene / Rosettanet Business Framework / klassische integrierte Geschäftsprozesse

Geschäftsprozess / Rosettanet PIP / bilateral

Dateninhalte / Business Dictionary/PIP / bilateral

Enveloping / RNIF 1.1 oder RNIF 2.0 / Edifact-Service-Segmente

Semantik / Rosettanet PIP / Edifact Message Description

Syntax / XML / Edifact

Kommunikation / HTTP/S / X.400/VAN