Anbei eine kleine Linksammlung zum Thema „IDocs an SAP ABAP Systeme über HTTP schicken“:
Wie man IDocs als XML direkt per HTTP (ohne weitere Middleware) an ein ABAP System schickt, zeigt folgender Artikel:
Post IDoc to SAP ERP over HTTP from any application
Erstellen eines WebServices in ABAP zum Empfang von XML IDocs:
CONNECTING A THIRD PARTY TO SAP ECC USING HTTP XML FORMAT.PDF
Ersetzen des SOAP Adapters durch den HTTP Adapter (SAP PI):
SAP PI: SOAP Adapter durch HTTP Adapter ersetzen
Es gibt mittlerweile eine Vielzahl an Libraries, die es Applikationen in verschiedenen Programmiersprachen erlauben, auf eine Ressource (z.B. Datenbanken, WebServices etc.) zuzugreifen – beispielsweise gibt es für C++ die ODBC Library oder für Java die JDBC Library. In den Datenbanken, Dateien, oder sonstigen Informationsquellen liegen die Daten bzw. die Daten-Schicht, oder allgemeiner, die Ressourcen.
Aus Sicht der Applikation ist die Daten-Schicht (Data API) und damit auch die Ressource transparent, also herstellerunabhängig. Das ist dem Umstand zu verdanken, dass sich gewisse Standards, wie z.B. JDBC oder ODBC für Datenbanken oder XML für Textdateien etabliert haben.
OData ist das Equivalent für Web-Applikation, d.h. OData ist die Daten API, die beispielsweise über Web-Services den Zugriff auf Ressourcen erlaubt. Anstelle von ODBC, JDBC oder XML, werden die Standards HTML, REST und AtomPub verwendet. Die Data API wird nicht direkt in die Applikation gelinkt, sondern über REST (Representational State Transfer) Webservices mit er Anwendung verbunden. Der Zugriff auf die Ressourcen (Datenbanken, Dateien etc.) erfolgt, wie vorher, über Standards wie ODBC, JDBC etc.
Genau genommen, kommt also zum „konventionellen“ Modell noch eine weitere Abstraktionsschicht hinzu, ich will Sie den „Web-Layer“ nennen. Diese weitere Schicht bietet theoretisch den Vorteil, von „überall“ her, Ressourcen an die eigene Applikation anzubinden – natürlich nur, wenn die Ressourcen mit dem Web verbunden sind und einen entsprechenden Web-Service zur Verfügung stellen. Dieser Web-Service wird im Jargon als OData-Publisher bezeichnet.
Des weiteren wird, aus meiner Sicht, die Applikation von den Ressourcen stärker getrennt. Es wäre beispielsweise denkbar auf die Ressourcen einer „fremden“ Firma zuzugreifen, ohne sie selbst programmieren zu müssen, so wie es bereits Google (Maps etc.) oder andere Hersteller realisiert haben. Es ist dann nicht notwendig, das entsprechende Know-How firmenintern aufzubauen, mit dem Nachteil, dass evtl. Kosten für die Nutzung der Ressourcen erhoben werden.
Der Zugriff auf die OData-Ressourcen erfolgt aus Sicht der Applikation über CRUD-Operationen, also über Create-, Read-, Update-, Delete-Befehle. Diese werden über die HTTP-Operationen GET, POST, PUT und DELETE abgebildet. Parameter werden in der URL abgebildet. Will man beispielsweise in einer fiktiven Datenbank über SQL alle Anwälte ermitteln, die in Aschaffenburg ansässig sind und sich auf Mietrecht spezialisiert haben, dann würde man das in etwa so realisieren:
SELECT * from lawyers where city='Aschaffenburg' and area='rent';
Analog würde man im OData Modell einen REST-Service, z.B. getLawyers über HTTP-GET aufrufen:
http://<url>/Lawyers?city='Aschaffenburg'&area='rent'
Weitere Informationen zum Aufbau der OData URI sind hier zu finden.
Die Rückgabe kann in AtomPub (Atom Publishing Protocol), JSON (JavaScript Object Notation) oder XML (Extensible Markup Langugage) erfolgen.
Eine Auswahl an SDKs für OData-Client und -Server steht direkt bei OData.org als Link zur Verfügung.
Wie sieht es mit Security im Zusammenhang mit REST aus? Eine Möglichkeit bietet das Open-Source Protokoll OAuth. Alternativ kann man HTTP-Authentifizierungsmechanismen, OpenID, HMAC etc. verwenden.
Links:
Das Secure Sockets Layer (SSL) Protokoll dient zum Sichern von Verbindungen auf der Transportschicht (Transport Layer Security, TLS). Das Protokoll TLS ist die Nachfolgebezeichnung des Protokolls SSL (Wikipedia: Seit Version 3.0 wird das SSL-Protokoll unter dem neuen Namen TLS weiterentwickelt und standardisiert, wobei Version 1.0 von TLS der Version 3.1 von SSL entspricht)
(Abbildung entnommen aus Wikipedia)
Die Verwendung der Transport Layer Security (TLS) bietet folgenden Schutz:
SAP betreibt den Applikationsserver Netweaver in drei Variationen:
Schlüssel und Zertifikate werden für den AS ABAP und den AS Java an unterschiedlichen Orten abgelegt:
Folgende Informationen umfaßt die PSE bzw. Keystore-Sicht:
Je nachdem, ob der AS ABAP bzw. AS JAVA als Client oder Server einer SSL-Verbindung arbeitet, sind unterschiedliche PSEn/Keystore-Sichten zu verwenden:
Bevor Sie SSL auf einem SAP Netweaver Applikationsserver verwenden können, müssen Sie diesen zunächst dafür konfigurieren (siehe: AS ABAP für SSL-Unterstützung konfigurieren bzw. Transport Layer Security on the AS Java).
Als Verschlüsselungstechnik wird die Public-Key-Technologie verwendet (siehe auch: Vertrauensbeziehung aufbauen). In diesem Fall wird jeder Komponente ein Schlüsselpaar ausgestellt, das aus privatem und öffentlichem Schlüssel besteht. Der private Schlüssel wird sicher auf dem Server abgelegt und der öffentliche Schlüssel wird in Form eines Public-Key-Zertifikats an die Kommunikationspartner verteilt. Die Vertrauensbeziehung wird durch Überprüfen des öffentlichen Schlüssels des Kommunikationspartners, der mit dem Public-Key-Zertifikat geliefert wird, eingerichtet.
Für die serverseitige Authentifizierung wird also für den Server eine Schlüsselpaar erzeugt, der Server erhält den privaten Schlüssel und der Client den öffentlichen Schlüssel. Bei clientseitiger Authentifizierung erhält der Client den privaten Schlüssel und der Server den öffentlichen Schlüssel.
Ein Zertifikat kann man selbst erstellen (selbstsignierte Zertifikate) oder von einer vertrauenwürdigen CA (z.B. Verisign etc.) ausstellen lassen. Der Vorteil von selbst signierten Zertifikaten gegenüber gekauften ist ganz einfach, sie kosten NICHTS!
Es besteht die Möglichkeit eine freie Lösung, wie z.B. OpenSSL zu verwenden (siehe: Howto selbstsigniertes SSL Zertifikat erstellen) oder mit SAP Hilfsmitteln zu arbeiten (siehe: PSE für den Server mit SAPGENPSE anlegen).
Für die Verwendung von SAP Hilfsmitteln ist es wichtig, daß folgende Voraussetzungen erfüllt sind:
Um selbstsignierte Zertifikate unter Verwendung von SAP Hilfsmitteln zu erzeugen, gehen Sie wie folgt vor. Generieren Sie mit dem Befehl get_pse die PSE des Servers, die das Public-Key-Schlüsselpaar und ein Publik-Key-Zertifikat enthält. Wenn Sie eine vertrauenswürdige CA verwenden, können Sie auch den Befehl get_pse verwenden, um eine Zertifikatsanforderung zu generieren. Standardmäßig wird alles erzeugt, allerdings können Sie mit den Optionen -noreq oder -onlyreq die Zertifikatsanforderung explizit auslassen (= selbstsignierte Zertifikate) oder erzeugen. Der Befehl sapgenpse ist unter Linux im Verzeichnis /sapmnt/<SYSID>/exe/ zu finden.
Beispiel: PSE und selbstsigniertes Zertifikat für den Anwendungsserver erzeugen
Mit der folgenden Befehlszeile erzeugen Sie eine PSE für den Anwendungsserver (<SID>= ABC), die ein selbstsigniertes Zertifikat enthält. Eine Zertifikatsanforderung ist nicht erforderlich. Die PSE befindet sich in D:usrsapABCDVEBMGS28secABC.pse. Die PIN, die die PSE schützt, lautet abcpin. Der Distinguished Name des Servers lautet CN=ABC, OU=Test, O=MyCompany, C=DE.
sapgenpse get_pse -p D:usrsapABCDVEBMGS28secABC.pse
-noreq -x abcpin "CN=ABC, OU=Test, O=MyCompany, C=DE"
Hinweis: Setzen der Umgebungsvariablen ist eventuell notwendig:
export LD_LIBRARY_PATH=/sapmnt/NWA/exeexport SECUDIR=/usr/sap/NWA/DVEBMGS00/sec
Die Syntax zum Befehl sapgenpse ist unter PSE für den Server mit SAPGENPSE anlegen zu finden.
RedEyeWatching 