Viele SAP-Anwender verwenden den "SAP Business Connector (BC)" für die Abwicklung von Geschäftsprozessen. Er gestattet einen Datenaustausch zwischen Systemen über proprietäre SAP-Datenformate sowie über XML. Beispielsweise nimmt der BC Anwendungsdaten als Idoc entgegen und konvertiert sie nach XML. Regeln entscheiden darüber, an welchen Empfänger das Dokument zu übertragen ist.

Nahezu alle SAP-Nutzer verwenden den BC zur Übermittlung von Lohnsteuerbescheinigungen und Lohnsteueranmeldungen an Finanzbehörden. Dazu lieferte SAP vor zwei Jahren ein Standardpaket aus ("Elster für SAP BC"), das auf dem BC installiert wurde und im Wesentlichen ein bereits am Backend erstelltes XML-Datenformat entgegennimmt, dieses komprimiert und über einen http-Adapter an den jeweiligen Empfänger weiterleitet.

Häufig wird der BC auch für elektronische Bestellungen sowie zum Austausch von Stammdaten genutzt. Hier sind neben Umsetzungen von SAP-Datenformaten (zum Beispiel Idocs) zu allgemeinen Standards wie EDI oder XML sehr umfangreiche Umsetzungsregeln und Konvertierungen implementiert worden. Diese Konfigurationen lassen sich in "Netweaver Exchange Infrastructure" übernehmen. Hierzu ist eine Migration erforderlich.

Keine Migration auf Knopfdruck

Während der BC weitgehend proprietäre Definitionen für Verteilregeln, Konvertierungen und Adaptern verwendet, stützt sich XI auf J2EE-Standards wie JCA (Java Connector Architecture) für Adapter und Xpath zur Definition von Verteilregeln. Wegen ihrer Verschiedenheit gibt es keinen Automatismus und keine Standardwerkzeuge, um die einzelnen Elemente einer BC-Implementierung in XI zu überführen. Zunächst müssen Anwender herausfinden, wie die Integrationsprozesse im BC umgesetzt wurden.

Manuelles Übertragen

Verteilregeln werden im BC über proprietäre Definitionen festgelegt. Die grundlegenden Informationen sind die logischen Empfängernamen (zum Beispiel Lieferant A), die technischen Netzwerkadressen (etwa http:// 191.101.238.50:0080) und die Regeln (beispielsweise: wenn Nachrichtenschnittstelle = Bestellung dann logischer Empfänger = Lieferant A).

Definitionen muss das Projektteam in das "Intergation Directory" von XI manuell übertragen. Jeder Empfänger und jeder Sender ist als System mit einem logischen Empfängernamen und mit der Zuordnung der technischen Netzwerkadresse im "System Landscape Directory" zu pflegen (zum Beispiel logischer Empfängername = Lieferant A). Diese Migration erfolgt über das Kopieren und Einfügen der physikalischen Netzwerkadressen von Sender und Empfänger - eine Tätigkeit, die einige Konzentration erfordert, um keinen Übertragungsfehler zu verursachen.

Für jeden dieser Empfänger sind der Eingangs- und Ausgangkanal als Adapter und als Schnittstellenobjekt in XI anzulegen. Im Falle eines R/3 4.6c muss der Systemspezialist für das Senden der Daten an XI einen Idoc-Adapter konfigurieren. Dieser nimmt die Daten (Idoc-Format) entgegen und konvertiert sie in "Idoc-XML". Das XML-Dokument wird als Nachricht mit den Senderinformationen (Name des R/3 Systems, Zeitstempel etc.) in die Warteschlange von XI eingestellt. Eine anzulegende Nachrichtenschnittstelle verarbeitet die XML-Botschaft.

Attribute beschreiben die Datenstruktur der Nachrichtenschnittstelle. Deren Beschreibungen werden in XI hinter- legt. Geht es dabei um Eigenschaften eines SAP-Funktionsbausteins (BAPI oder Idoc), so lassen sie sich aus dem Sendersystem auslesen und automatisch anlegen.

Für eigene Datenformate muss der Anwender hingegen eine XSD-Datei (XSD = XML Schema Definition) importieren. Mitunter kann dies aufwändig werden, wenn viele eigene Datenstrukturen zu bearbeiten sind.

Verteilregeln formulieren

Ein HTTP-Adapter sorgt für die Weiterleitung der Daten. Er benötigt daher die HTTP-Adresse des Empfängers. Verteilregeln können Anwender entweder als einfache Empfängerermittlungen (beispielsweise "wenn Nachrichtenschnittstelle=Bestellung dann logischer Empfänger= Lieferant A") oder auch inhaltsabhängig formulieren (etwa: "wenn Nachrichtenschnittstelle = Bestellung und Feld MATNR = 4711 dann logischer Empfänger= Lieferant B ELSE Empfänger = Lieferant A"). Unter Umständen lässt sich die Anzahl der Verteilregeln dabei reduzieren.

Daten-Mappings

Wenn keine Mapping-Regeln zwischen dem Sender und Empfänger notwendig sind, ist die Migration abgeschlossen, und die funktionale Prüfung sowie die Performance-Tests können beginnen. Doch nur in wenigen Fällen handelt es sich bei BC-Implementierungen lediglich um eine automatische XML-Konvertierung. In der Regel richten Anwender Mappings zur Konvertierung von Idoc-Formaten in ein beliebiges XML-Format und umgekehrt ein. Der Business Connector verfügt für diesen Zweck über die Verfahren "Flow Logic Services", "XSLT Services" und "Java Services".

Die Flow Logic Services sind proprietär und lassen sich nicht in XI wiederverwenden. Der beste Weg zur Migration ist daher, eine möglichst genaue Beschreibung der Umsetzung beziehungsweise Feldzuordnungen zu erstellen. Dies kann in Form einer Tabelle oder mittels Screenshots (Ansicht als HTML) geschehen. Der Anwender legt Eingangs- und Ausgangsformate als Nachrichten-Schnittstelle an. Anschließend können die Feldzuordnungen mit dem grafischen Mapping-Designer von XI umgesetzt werden.

Konzeption braucht Zeit

Der zeitliche Aufwand für die eigentliche Umsetzung ist meist deutlich geringer als die Erstellung der Mapping-Beschreibung. Die Konzeption kann schon mal Tage in Anspruch nehmen, wenn die Dokumentation unzureichend, veraltet oder gar nicht vorhanden ist. Ein Mapping lässt sich innerhalb eines Tages implementieren, da die XI-Werkzeuge den Anwender gut unter die Arme greifen.

Während bei Flow Logic ein Re-Design in XI vorzunehmen ist, lassen sich XSLT- (XML Style Sheet Transformation) und Java-Services-Mappings übernehmen. Damit der XI-Import von Java Services klappt, müssen die Java-Archive Bedingungen erfüllen:

• Der Java Service darf keine Datenbankaufrufe enthalten (diese kann der Anwender nachträglich mit XI-Mitteln implementieren);

• es dürfen keine class loader in den Java Klassen verwendet werden;

• die Java-Klassen müssen stateless sein, also keine Zustandsinformationen intern speichern;

• die Funktionen Java.lang.System.exit und Java.lang.System. setProperty dürfen nicht vorkommen.

Kaum Aufwand bei XSLT

Ist dies doch der Fall, dann sollten alle Java Class Files aus dem betreffendem Java Service in ein Archiv (JAR oder ZIP) verpackt werden. Zum Einlesen der Archive in XI erzeugt der Benutzer ein neues Objekt im Menübaum "Imported Archives" und legt den Pfad zum JAR- oder ZIP-File an. Alle Objekte des Archives werden so in XI-Repository geladen und dort als Objekt in der Datenbank abgelegt. Die Programme stehen als Mapping-Klasse zur Verfügung und sind sofort verwendbar. Änderungen an diesen Klassen kann der Anwender nur mit externen Tools wie "NetWeaver Developer Studio" vornehmen.

Am geringsten ist der Migrationsaufwand für XSLT Services. Zwar müssen auch hier die Nachrichtenschnittstellen angelegt, importiert oder manuell gepflegt werden, jedoch sind die eigentlichen Umsetzungsregeln sowohl beim BC als in XI standardisiert: In beiden Umgebungen basieren die Regeln auf XSLT-Definitionen. Systemspezialisten exportieren eine XSLT-Datei aus dem BC und importieren sie in XI.

Die Projekterfahrung gezeigt, das die Umsetzung von BC nach XI selbst nicht komplex ist. Schwierigkeiten bereiten eher schlecht dokumentierte Services, so dass ein großer Teil des Vorhabens auf die Vorbereitung entfällt. Ein in der Praxis bewährtes Schema hilft, eine Migration des Business Connector BC zu XI strukturiert abzuwickeln. (fn)