Datenkommunikation zwischen SharePoint und SAP

Die hier gezeigten Handlungsoptionen sollen dabei helfen, strategisch die richtige Entscheidung beim Verbinden der Systeme SharePoint und SAP zu treffen. Um die Praxis nicht aus den Augen zu verlieren, schließt der Artikel mit einem Beispiel sowie einer ausführlichen Beschreibung der ERPConnect Services von Theobald Software ab.

Viele Entscheider stellen sich die Frage, inwiefern SharePoint erfolgreich und zukunftsorientiert mit SAP integriert werden kann. Gibt es Möglichkeiten Daten flexibel, erweiterbar und vereinheitlicht in SharePoint darzustellen? Würde es nicht Sinn machen, Daten aus unterschiedlichen Systemen in SharePoint anzuzeigen und Prozesse im Hintergrund zu starten, ohne dass der Anwender mitbekommt, dass mehrere Systeme abgefragt werden? Somit besteht das Streben vieler Hersteller wie IBM, Microsoft, SAP oder Pirobase nach einer offenen Systemwelt, die mehr Interoperabilität gewährleistet und der veränderten Marktnachfrage gerecht wird. Denn obwohl die Zeit der geschlossenen Systeme längst vorbei ist, werden in vielen Unternehmen noch heterogene Systeme verwendet, welche erst noch mit anderen Systemen integriert werden müssen.

SharePoint gewann in der jüngsten Vergangenheit immer mehr an Bedeutung. Noch vor wenigen Jahren haben sich viele Verantwortliche in Unternehmen die Frage gestellt, ob SharePoint die richtige Plattform für ihr Unternehmen ist, tatsächlich helfen kann, Kosten und Zeit zu minimieren, und damit eventuell andere Systeme ablöst. Dieser Fragestellung haben sich bereits verschiedene Business Cases gewidmet, die die Wirtschaftlichkeit von SharePoint aufzeigen. Die neuen zentralen Fragestellungen der Verantwortlichen sind: Welche Bereiche von SharePoint sollen zuerst eingeführt werden, damit Fachbereiche oder IT-Bereiche optimiert werden? Wie könnte eine sinnvolle und nahtlose Integration mit anderen Systemen aussehen? Wie können Daten systemübergreifend genutzt und angezeigt werden?

Hierbei stehen nicht nur die Systeme im Vordergrund, sondern auch die Usability, unter anderem wie die Anwender künftig mit heterogenen Systemen arbeiten sollen. Macht es überhaupt noch Sinn, dass Anwender an mehreren Systemen arbeiten beziehungsweise sich an mehreren Systemen einloggen müssen? Viele Unternehmen gehen deswegen den Weg, ein einheitliches Überportal, zum Beispiel als Intranetplattform, zu entwickeln. Diese Plattformen zeigen konsolidierte Daten aus mehreren Systemen an oder steuern Prozesse, ohne dass der Anwender mitbekommt, in welchem System der Prozess läuft. Es ist somit ein anwendungsübergreifender Zugriff auf strukturierte und unstrukturierte Unternehmensdaten möglich.

Über Absprünge, integrierte Links, gelangt man über Single-Sign-On (SSO), falls umgesetzt und gewünscht, in andere Systeme wie zum Beispiel in ein SAP-Portal. Viele sprechen dabei von Unternehmensprozessen und Unternehmensdaten ohne Systembrüche und ohne Absprünge zu den verschiedensten Plattformen. Hinter dem Begriff Portal verbergen sich einige wichtige Schlüsselpunkte: sicherer und zentraler Einstiegspunkt für alle Anwender, einheitliche und intuitive User Experience (Look and Feel), rollenbasierter Zugriff auf Geschäftsprozesse und alle relevanten Informationen, Single-Sign-On (SSO) sowie weitere Aspekte. Ein Überportal hingegen bündelt verschiedene Portale und stellt diese auf einer Webseite dar - ist sozusagen eine Sammlung verschiedener Portale.

Herausforderungen bei der Integration mit SAP

SharePoint ist in sich kein geschlossenes System und bietet somit große Flexibilität bezüglich der nahtlosen Integration mit anderen Systemen. Für Unternehmen relevante Fragen sind dabei, welche Möglichkeiten die Standardbordmittel von SharePoint bieten, um SharePoint mit SAP zu verbinden. Was sind die Grenzen dieser Integration, und muss ein Tool eingekauft werden, das mehr an Funktionalitäten und Möglichkeiten bietet?
Es gibt heutzutage zahlreiche Third-Party-Tools auf dem Markt, die ein Zusammenspiel zwischen SharePoint und SAP ermöglichen. Es bleibt zu beachten, dass für das Finden der passenden Lösung vorab genau analysiert werden muss, welche Vorrausetzungen überhaupt im Unternehmen gegeben sind und welche Anforderungen an die Integration bestehen. Es ist ebenso wichtig zu erfahren, wie mit den Daten umgegangen werden soll. Das heißt: Wie soll der Datenaustausch stattfinden, und welche Daten sollen überhaupt angezeigt werden?

Viele Unternehmen haben SAP im Einsatz und lassen dort komplexe Business-Prozesse laufen, die sehr stark im System verzahnt sind. Es stellt sich dabei langfristig die Frage, ob die Verlagerung von Prozessen aus SAP nach SharePoint sinnvoll ist oder ob eher eine prozessübergreifende Lösung gefunden werden sollte. Es bleibt hierbei zu erwähnen, dass komplexe und verzahnte SAP-Prozesse nicht ohne Weiteres aus SAP herausgelöst und in SharePoint überführt werden können. Hier stößt auch SharePoint schnell an Grenzen, und der Einsatz von Third-Party-Tools kommt erneut zur Sprache. Somit bleibt strategisch und aus Kostensicht betrachtet nur ein Weg übrig, und zwar die Verknüpfung von SharePoint und SAP. Auch hinsichtlich Datenspeicherung, -management und -bearbeitung sollte gut überlegt werden, wie das neue Szenario künftig aufgebaut werden soll.

Werfen wir zunächst einen Blick auf Verbindungsmöglichkeiten ohne Third-Party-Tools, bevor wir auf diese Tools eingehen und an einem Beispiel aufzeigen, wie einfach und schnell eine Verbindung hergestellt werden kann.

SharePoint mit SAP aus Entwicklersicht verbinden

Als Entwickler hat man die Möglichkeit, mit Standardmitteln SharePoint mit SAP zu verbinden. Dabei kann auf SAP-Daten zur weiteren Verarbeitung oder einfach nur zum Anzeigen in SharePoint zugegriffen werden. Dies hat zum einen den Vorteil, dass am Anfang keine Lizenzkosten anfallen (bei einer Weiterverarbeitung der SAP-Daten können durchaus SAP-Lizenzkosten anfallen), und zum anderen den Nachteil, dass Entwicklungsaufwand betrieben werden muss, der wiederum Kosten verursacht.

Tabelle 1: SharePoint mit SAP aus Entwicklersicht verbinden

Doch auch mit diesen Bordmitteln stößt man schnell an die Grenzen und sollte sich vorab durch eine detaillierte Analyse überlegen, ob hier nicht lieber ein Third-Party-Tool zum Einsatz kommen sollte. Im nächsten Abschnitt werden die Key Player auf dem Markt näher betrachtet und ein praxisorientiertes Beispiel aufgezeigt.

Aktuelle Key Player auf dem Markt

Die Anzahl der Third-Party-Tools auf dem Markt nimmt immer mehr zu. Es gibt verschiedene Tools, die eine nahtlose Integration zwischen SharePoint und SAP ermöglichen. Der Zugriff auf SAP-Daten und SAP-Funktionalitäten lässt sich sehr schnell realisieren, der Aufwand ist vergleichbar mit dem Hinzufügen eines WebParts in einer SharePoint WebSite. Damit erhält man schnell einen Überblick über relevante Daten - egal ob es sich hierbei um einen Einkaufsprozess oder um einen Urlaubsantrag handelt. Neben der Möglichkeit zur schnellen Umsetzung eines Pilotprojektes bieten Third-Party-Tools weitere Vorteile für die Nutzung im Enterprise Umfeld:

• Schnelle Bereitstellung der Lösung

• Geringer Schulungsaufwand, da die Mitarbeiter zumeist schon mit der SharePoint-Oberfläche vertraut sind

• Möglichkeit zur Integration seitens des Fachbereichs, da keine Notwendigkeit zum Schreiben eigener Codes

• Einfache Synchronisierung der Rollen beziehungsweise Berechtigungen

• Unterstützung für SSO

In der folgenden Tabelle werden vier Tools genauer vorgestellt.

Tabelle 2: Third-Party-Tools zur Integration von SharePoint mit SAP

In den nachfolgenden Absätzen werden die ERPConnect Services von Theobald Software genauer unter die Lupe genommen und vorgestellt. Anhand eines praxisorientierten Beispiels lässt sich sehr gut zeigen, wie einfach es ist, SAP-Daten flexibel, erweiterbar und vereinheitlicht in SharePoint darzustellen.

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.

Fazit

Dieser Artikel hatte zum Ziel aufzuzeigen, vor welchen Herausforderungen und Anforderungen Unternehmen stehen, wenn es um die Verbindung von Welten geht - speziell die Verbindung von SharePoint mit SAP. Es wurde die Sichtweise eines Entwicklers aufgezeigt, der Standardbordmittel verwenden kann. Des Weiteren wurden verschiedene Third-Party-Tools besprochen, die aus meiner Sicht derzeit die Key Player auf dem Markt sind. Nichtsdestotrotz sollten, bevor die Entscheidung für ein Third-Party-Tool getroffen wird, die Anforderungen genau unter die Lupe genommen werden, da es sich um eine langfristige Entscheidung und Investition handelt. Dies könnte auch in einer Art Vorstudie oder in einem Proof of Concept durchgeführt werden.

Zum Schluss sollte durch das praxisorientierte Beispiel mit den ERPConnect Services gezeigt werden, wie schnell und einfach es ist, SharePoint mit SAP zu verbinden. Mit dem Einsatz eines Third-Party-Tools sind zwar Lizenzkosten verbunden, sie bieten jedoch einen klaren Vorteil: die Verbindung von SharePoint und SAP ohne Programmierkenntnisse. Dies ermöglicht jedem Mitarbeiter aus dem Fachbereich mit den entsprechenden Zugriffsrechten die Anzeige von Daten aus dem SAP-System, zum Beispiel in einer SharePoint-Liste.

Der Wandel geht hier immer weiter in Richtung "Arbeitsplatz der Zukunft". Im Vordergrund standen bisher mobile Endgeräte und Home-Office-Möglichkeiten durch stationäre Computer. Nun werden eher Möglichkeiten betrachtet, Daten aus verschiedenen Applikationen und Systemen in einem Überportal darzustellen. Der Vorteil liegt dabei auf der Hand: Mitarbeiter können an einer Plattform arbeiten und dabei Daten aus unterschiedlichen Systemen bearbeiten - auch Freigaben durchführen, die Suche nutzen, Workflows ansteuern etc. Auch Prozesse aus anderen Systemen können dabei angesprochen werden. Somit können Daten in Echtzeit aus SharePoint heraus genutzt werden.

Der Markt gibt sicherlich noch viel her. Bleiben wir gespannt, welche weiteren Tools uns in nächster Zeit begleiten werden. Wie am Anfang des Artikels angesprochen, gehen viele Unternehmen den Weg, heterogene Landschaften durch homogene zu ersetzen. Wie sieht es dann mit der Interoperabilität und mit der Unterstützung durch Third-Party-Tools aus? Es bleibt spannend. (bw)