Es gibt verschiedene Methoden um unterschiedliche Applikationen mit SAP-Software zu verbinden. Die verschiedenen Möglichkeiten sind unterschiedlich gewachsen und werden in Zukunft auch unterschiedlich gepflegt bzw. ist die Weiterentwicklung eingestellt.
Die Folgende Übersicht soll die möglichen Schnittstellen ein wenig näher erläutern und somit eine Übersicht der Möglichkeiten ins SAP darstellen.

Manuelle Datenpflege

Als erste Möglichkeit besteht darin, die Daten händisch in das System zu pflegen. Dies ist in vielen Unternehmensbereichen nicht selten, auch wenn es wenig effektiv ist, so bringt es zumindest Arbeitsplätze ins Unternehmen. Die Fehleranfälligkeit ist ebenso groß. Schnell kommt es zu Inkonstistenzen zwischen System SAP und Applikation.

Kopplung über IDocs

Intermediate Document (IDoc): SAP-Standardformat zum elektronischen Datenaustausch zwischen Systemen
Hierbei werden vorhandene oder neue Softwarebausteine im SAP genutzt. Sie sorgen für den Austausch der Daten. Alle SAP-Module können IDocs lesen und schreiben/ exportieren.
Die Daten werden mittels IDoc an das andere System übertragen und werden dort in ein spezifisches Format geschrieben, abhängig vom Host. Die Routine zum Lesen der Daten müssen natürlich in jeder Applikation erstellt werden.
Der Austausch der Daten erfolgt im einfachsten Fall über ein vereinbartes Verzeichnis, alternativ könne Protokolle wie ftp und http eingesetzt werden. Die größte Verbreitung der IDocs erfolgt jedoch über das SAP-eigene Protokoll RFC (Remote Function Call – ist eine SAP-Schnittstellenprotokoll, das auf CPI-C (Die Common Program Interface Communication beschreibt den Datenaustausch zwischen verschiedenen Programmen. Die Dateien werden mit CPI-C „verpackt“.) beruht, Damit wird die Programmierung von Kommunikationsabläufen zwischen Systemen wesentlich vereinfacht).

Die Daten werden in einer lesbaren Datei versendet, somit besteht die Möglichkeit, dass potenziell kritische Daten manipuliert bzw. gelesen werden können. Dies ist natürlich im Unternehmen selten erwünscht. Hierbei sollte aber berücksichtigt werden, in wie weit werden die Daten an ‚Außenstehende’ weiter gegeben oder befindet sich der Datenaustausch in einem geschützten Netz.
Ein weiterer Nachteil besteht in der mangelnden Fehlerbehandlung. Fehlerhafte Übergaben oder Fehler im IDoc selbst werden nicht an den Erzeuger der Daten gegeben. Ein Monitoring ist nur durch eine eigene Fehlerbehandlung möglich, die vom Anwender erstellt wird. Diese führt zu einem schlechten Händling, denn sie muss immer angepasst werden, es entsteht eine Abhängigkeit zwischen Sender um Empfänger.

Remote Function Call (RFC)

Mit Hilfe von RFC werden Aufgaben eines bestehenden Systems an ein anderes System verlagert. Das andere System stellt die Funktion, die das bestehende System nutzen möchte zur Verfügung. Sowohl Client als auch Server können ein SAP-System sein. Es werden Funktionsbausteine innerhalb des R/3-Systems aufgerufen, wodurch der Datentransport in Fremdsysteme und SAP-Systeme möglich ist und somit die Daten in einer anderen Programmiersprache zu Verfügung zu haben. Um einen Funktionsbaustein aufrufen zu könne, muss dieser in der Funktionsbibliothek des SAP-Systems als RFC-fähig definiert sein.
Mit RFCs kann aus diversen Sprachen heraus kommuniziert werden, beispielsweise gibt es viele Anwendungen in C und VB. Ebenso ist die Verwendung von php möglich. Ermöglicht wird dies durch einen Open Source Project – SAPRFC. Es werden Klassen für php4 und php5 bereitgestellt. Zusätzlich kann ein RFC Server Programm geschrieben werden, dass dann vom R/3-System aufgerufen wird.

Business API (BAPI)

Unter BAPIs verstht man standardisierte Schnittstellen von SAP. Mit Hilfe dieser BAPIs kann man von externen Anwendungen auf das SAP-System zugreifen (siehe RFC). Ein BAPI ist ein Funktionsbaustein, der RFC-fähig ist und zusätzliche Eigenschaften mitbringt. Der Unterschied zwischen einem BAPI und einem Funktionsbaustein besteht darin, dass der Funktionsumfang fest definiert ist, das es definierte Input-/ Output-Parameter gibt, dass der Baustein in der Regel zustandslos ist, funktionsorientiert gestaltet und die Parameter sind über Versionswechsel hinweg konstant.

Java Connector

Der JCO erlaubt einen bidirektionalen Datenaustausch, insofern eine Java-Anwendung auf dem zu verbindenden System läuft.

Läuft in der anzubindenden Applikation kein Java, muss eine zusätzliche Kopplung zwischen der Applikation und dem JCO-Adapter auf SAP-Seite entwickelt werden. Ein zusätzlicher Prozess mit erheblichen Mehrkosten.
Aber selbst wenn die Applikation eine J2EE-Anwendung ist, dann gibt es Probleme. Der JCO wurde nicht explizit für J2EE entwickelt, deshalb müssen Entwickler gegen Vorgaben der Spezifikation des Enterprise Java Beans (EJBs) verstoßen. Beispielsweise erfordert der JCO statische Methoden. Alternativ könnte man einen J2EE-konformen Adapter einsetzen (z.B. Librados), welcher Intern einen JCO besitzt. (mehr Information und beispiele dazu gibt es im Artikel „Anbindung von SAP R/3 über die J2EE Connector-Architektur“)
Die Typüberprüfung findet erst zur Laufzeit statt, dadurch müssen alle Tests im Vorfeld stattfinden.

Allerdings muss man sagen, dass seit ERP-Lösung R/3 Version 4.7 eine weitere bessere Möglichkeit besteht. Ab dieser Version steht SAPs Web Application Server bereit, in der ABAP-Version. Dieser stellt eine Reihe von Diensten bereit, um das SAP-System zu koppeln. Nun können gängige Java-Methoden angewandt werden. Zum beispiel kann mit http oder SOAP gekoppelt werden.
Ab Version 6.20 des Web-AS gibt es einen JAVA-Web-AS. Auf diesem Server können Anwendungen nach J2EE-Standard laufen.

Business Connector (BC)

Gleich vorweg, der BC wird in Zukunft nicht mehr weiter entwickelt. Vorhandene Prozesse und Strukturen müssen auf die Exchange Infrastructure (XI) umstellen.

Der BC wurde entwickelt um externe Partner an das System anzubinden. Ein Mapping ist mit Hilfe von XML möglich. Neben der gängigen RFC-Schnittstelle werden htpp, ftp und smtp unterstützt. Die Architektur ist relativ einfach, wobei das Tool an sich sehr mächtig ist und dabei wenige Ressourcen benötigt. Die Anwendung ist Java-basierend und läuft als Webanwendung.

Exchange Infrastructure (XI)

Die XI ist derzeit in der Version 3 auf dem Markt und soll die zentrale Schnittstelle im SAP werden. Ziel der XI ist es, als zentrale Plattform zur Verfügung zu stehen und verschiedene Schnittstellen über eine einheitliche Technologie zu verbinden.
Die Integrationslösung XI verarbeitet und überträgt Nachrichten. Die Nachricht wird als XI-konforme SOAP-Nachricht versandt. Die XI ermöglicht es, die zu verwendeten Daten in eine Form zu konvertieren, die das Zielsystem versteht. Über einen Adapter wird diese erzeugte Nachricht über einen Adapter an das Zielsystem übergeben. Auf diese Weise wird die Integration verschiedener Applikationen zentralisiert. Die Abhängigkeiten zwischen den Systemen sind klar erkennbar und können jederzeit verändert und gewartet werden.
Außerdem ist es möglich mit Hilfe der XI Geschäftsprozesse zu modellieren, grafisch. Andere Systeme werden damit über die SOAP-Nachricht integriert.

Ein Vorteil ist das Monitoring der XI. Kommt es beispielsweise zu Fehlern bei der Übertragung, versucht der Integration Broker die Nachricht noch einmal zu versenden. Messages können durch den User manuell editiert werden.
Kann eine Nachricht nicht zugestellt werden, so wird eine Fehlernachricht erstellt mit der die Quelle reagieren kann. Im Weiteren steht mit der XI eine Technologie bereit, sie die Prozesse mit Hilfe von Standards definiert und offene Schnittstellen ermöglicht bei großer Modularität.

Die Reaktion der Quelle ist nicht unproblematisch und führt ist zu Problemen.
Der Ressourcenbedarf der XI ist relativ hoch und nicht so performant wie der Business Connnector. Da die XI relativ neu ist, ist ausschließlich ein Unicode-System verfügbar, auch dies führt zu Problemen mit älteren Hardwaresystemen. Die XI benötigt also eine leistungsstarke Hardware und eine große Datenbank.