Datenkommunikation zwischen SharePoint und SAP

SharePoint mit SAP über den BCS Connector verbinden

Für die richtige Wahl der Mittel sollte erst eine grundsätzliche Frage beantwortet werden, die oben kurz angesprochen wurde: Muss die Lösung programmiert werden, oder soll es sich um eine No-Code-Lösung handeln? SharePoint selbst ist mehr als ein Baukasten anzusehen, in dem vor allem Architekten, die eben nicht programmieren können oder sollen, einen Business Case modellieren. Das ist auch ein großer Vorteil dieser Lösung, wie schon oben angesprochen. Trotzdem ist es möglich, durch eigengeschriebenen Code Erweiterungen vorzunehmen und auf SAP-Daten zuzugreifen. Aber lassen Sie uns im ersten Beispiel gleich eine Lösung anschauen, die ohne jegliche Codierung auskommt.

Auf SharePoint-Seite kann dazu von den Business Connectivity Services (BCS) Gebrauch gemacht werden. Dabei handelt sich um eine Technologie, die es erlaubt, sogenannte externe Inhaltstypen mit einer Entität in einem externen System zu koppeln. Konkret übersetzt auf den Fall von SAP als externes System könnte diese Entität ein Lieferant, ein Auftrag oder eine Lagerbuchung sein. Der Zugriff auf den externen Inhaltstyp erfolgt durch eine externe SharePoint-Liste. Die Daten liegen aber tatsächlich im SAP, und sämtliche Datenänderungen reflektieren sich auch unmittelbar in der jeweiligen Liste. Abbildung 1 zeigt eine entsprechende simple Liste von SAP-Debitoren. Wie man am Kontextmenü sehen kann, ist die Liste auch beschreibbar gestaltet. Änderungen an einzelnen Einträgen werden also ins SAP-System zurückgeschrieben. Ansonsten handelt es sich um eine Standard-Liste, die als Grundlage für darauf aufbauende Applikationen dienen kann, zum Beispiel Formulare oder Workflows.

Das Design des externen Inhaltstyps erfolgt durch den BCS Connector - ein Stand-alone-Tool, das lokal auf dem Desktop des Architekten installiert wird - analog dem SharePoint-Designer. Datengrundlage bildet in diesem Beispiel die Tabelle KNA1 aus SAP, die Kundenstammdaten enthält. Abbildung 2 zeigt den BCS Connector mit dem externen Inhaltstyp zum Designzeitpunkt. Das im Designer entworfene Modell kann eine oder mehrere Entitäten enthalten, jede Entität wiederum mehrere Attribute. Jede Entität führt beim Deployment zu genau einem externen Inhaltstyp, jedes Attribut zu einer Spalte desselben.
Obgleich die Datenbeschaffung direkt aus der SAP-Tabelle erfolgt, muss das Rückschreiben natürlich andere Mechanismen nutzen. Auf SAP-Seite ist im Allgemeinen die Anlage und Änderung von Entitäten an ein großes Gebilde von Business-Regeln gekoppelt. Dabei spielt es keine Rolle, ob beispielsweise ein Debitor direkt in der SAP-Oberfläche oder durch externen Zugriff geändert wird. Die Regeln dürfen nicht ausgehebelt oder umgangen werden. Um dies sicherzustellen, erfolgt das Rückschreiben mithilfe eines Funktionsbausteins. Im BCS Connector werden im unteren Bereich die Operationen definiert, die auf Listeneinträge angewendet werden können. Für das Rückschreiben in eine bestehende Entity heißt die Operation beispielsweise "Update Table Record". Hinter diese Operation wird dann der Verbuchungsbaustein gemappt. Auch für die Datenbeschaffung kann natürlich ein Funktionsbaustein genutzt werden für den Fall, dass sich die gewünschte Entität nicht einfach durch einen Tabellenzugriff herstellen lässt.

Externe Listen sind in vielen Situationen ein pragmatischer, einfacher Weg, SAP-Daten in SharePoint zu bringen. Werden die Anwendungsfälle aber etwas komplexer, ist die Grenze des Machbaren sehr schnell erreicht. Insbesondere zusammenhängende Entitäten lassen sich nur schwer darstellen. Ein Beispiel dazu wäre ein Kundenauftrag mit einem Kopfsatz, aber mehreren Positionen.

Eine mögliche Lösung dafür bietet der WebService Designer, wie in Abbildung 3 dargestellt. Er erlaubt es, komplexe Zusammenspiele zwischen mehreren SAP-Funktionsbausteinen und/oder komplexen Datentypen grafisch zu modellieren. Der Ablauf wird gekapselt und bekommt nach außen eine Signatur, die einfach zu verstehen und einzubinden ist. Nach dem Designvorgang wird der modellierte Webservice nach SharePoint deployed und steht dort als Endpunkt zur Verfügung, um in weiteren Anwendungen genutzt zu werden.
Das Beispiel zeigt die Anlage von BANFen in SAP. Kern ist der Standard-Baustein BAPI_REQUISITION_CREATE. Neben den typischen Werten wie Lieferant, Materialnummer und Menge werden an dieser Stelle auch gleich Kontierungsanweisungen gesetzt. Der Baustein kann beliebig viele Meldungen zurückgeben. Der Prozessablauf ist so gestaltet, dass ein endgültiges Commit an SAP nur dann gesendet wird, wenn keine Fehler oder Warnungen von SAP zurückgegeben werden. Ansonsten wird die Aktion zurückgerollt und die Fehlermeldung an den Aufrufer des Webservices übermittelt.

Nachdem der WebService nach SharePoint deployed wurde, lässt er sich beliebig einbinden. Im vorliegenden Beispiel ist er in einen Nintex-Workflow eingebunden, der zunächst Details zur anzulegenden BANF prüft und vom Vorgesetzten eine Genehmigung abfragt, um dann diesen WebService zu starten. Sollte SAP die Anlage verweigern, weil zum Beispiel das Material im Auslauf begriffen ist und nicht mehr beschafft werden darf, wandert diese Information an den ursprünglichen Initiator des Workflows zurück.
Es sei an dieser Stelle nochmal explizit darauf hingewiesen, dass dieser relativ komplexe Prozessablauf komplett ohne eine einzige Zeile Code auskommt. Der WebService Designer erlaubt zwar einen Export des Modells nach Visual Studio, um dort eigenen Code einzubringen, ist aber eigentlich ein Tool für Architekten und eben nicht für Entwickler.

Letztes Beispiel in der Sammlung soll nun aber doch auch die Entwicklerseite ansprechen. Die klassische Umgebung ist natürlich Visual Studio. Dort lässt sich alles bauen, was unter .NET zu Hause ist. Ein entsprechender Designer unterstützt den Entwickler dabei tatkräftig. Im Zuge von HTML5 und SharePoint-Apps, die heute schon darauf ausgelegt sein sollten, in einer Cloud-Umgebung zu laufen, ist aber der Zugriff von JavaScript aus die spannende Frage, auf die es adäquate Antworten zu finden gilt.

Selbstverständlich wäre es auch möglich, die oben beschriebenen WebServices von JavaScript zu nutzen, zumal es auch eine einfach zu implementierende OData Variante des Service gibt. Jedoch wollen wir uns im folgenden Beispiel einmal die rein generische Variante anschauen, also direkt in JavaScript einen SAP-Funktionsbaustein aufrufen und das Ergebnis sofort weiterverarbeiten. Der entsprechende Endpunkt in SharePoint _vti_bin/ERPConnectServiceRest.svc/CreateFunction liefert auf Anfrage den JSon-serialisierten Aufruf des Funktionsbausteins SD_RFC_CUSTOMER_GET.
Der eigentliche Aufruf des im unten stehenden Bild programmierten Bausteins erfolgt dann gegen den Endpunkt ExecuteFunction und gibt zumindest einen Teil der Rückgabetabelle aus. Zweifellos ist das kein Beispiel aus dem wahren Leben, aber zumindest eines, das den Aufruf von Funktionsbausteinen aus JavaScript heraus eindrucksvoll zeigt.

Abschließend kann festgehalten werden, dass SAP-SharePoint Connectivity keinesfalls immer so komplex sein muss, wie es oft dargestellt wird. Die vorangegangenen Beispiele zeigen dies eindrucksvoll. Allerdings gilt es zu beachten, dass SAP generell immer ein gewisses Grundwissen über Funktionsbausteine und das Zusammenspiel der Prozesse erfordert. Hier hat noch kein Hersteller von Schnittstellensoftware den Heiligen Gral gefunden. Gesunde Skepsis gegenüber vollmundigen Werbeversprechen ist mehr als angebracht. Ohne SAP-Wissen geht es nicht, und daran wird sich auf absehbare Zeit auch nichts ändern. Nur die technischen Mittel können so gewählt werden, dass zumindest auf der Seite der Infrastruktur der Architekt und Entwickler so gut wie irgend möglich unterstützt wird.