Funktionsbausteinaufruf oder doch OData-Service ist die Frage. Wie rufe ich aus einer RAP-Anwendung aus Steampunk heraus Backend-Logik auf? Eine Suchhilfe? Validierungen? Oder ganze Objektanlagen und und und… eigentlich eine ganz normale Frage bzw. ein ganz normaler Use Case will man doch moderne Anwendungen entwickeln und die Clean Core Strategie befolgen. So einfach ist es aber nicht. Oder anders gesagt, wird es einem nicht gerade einfach gemacht.
Betrachten wir einmal die Entwicklersicht. Die Handstände die man gegebenenfalls machen muss um sein Backend-System an die BTP anzubinden mal größtenteils außen vor gelassen. Hat man es aber mal geschafft eine Destination in der BTP anzulegen wo der Connectioncheck auch “grün” ist meint man es geschafft zu haben. Dem ist aber nicht so. Bedenkt man doch, dass die meisten SAP-Beispiele mit z.B. “Basic Authentication” oder einem ins Web publizierten OData-Service nicht wirklich Businesstauglich sind. Hier fehlen die wirklichen Business Use-Cases. Zum Beispiel: Wie binde ich ein klassisches 7.50 On-Premise System an und das mit einem kleinen bisschen Security z.B. Principal Propagation.
Ein einfacher Use Case war das Aufrufen einer Suchhilfe aus dem Backend. Beides in einer Rap Anwendung über eine Custom Entity. Zwei Wege habe ich ausprobiert. Einmal das lesen über einen RFC-Baustein. Der zweite Weg, der mir etwas zukunftsfähiger erschien war der Aufruf eines OData-Services, welcher aus einer neu angelegten CDS-View für ebendiese Suchhilfe erstellt wurde.
Den Aufruf eines RFC-Bausteins hat man noch hinbekommen nachdem man sich lange mit Trial und Error durch die Cloud-Kommuikationsverwaltung oder das Identity- und Zugriffsmanagement gewühlt hat. Auch die verschiedenen Einstellungen über die Fiori-Oberfläche im ABAP-Enviroment (Communication-Scenarios, Communication-Users, Communcation-Arrangements, ...) sind nicht selbsterklärend. SAP Help? Hilft nicht wirklich außer ein wenig Hintergrundinformationen zu liefern.
Der Aufruf eines OData-Service war im Gegensatz zu einem RFC-Baustein schier unmöglich. Zumindest über die vorgedachten Wege über die Kommunikationsverwaltung. Hier funktionierte nur: Klassischer Weg über eine HTTP Destination (create_by_http_destination) mit Authentifizierung über einen extra angelegten Service-User der nur Berechtigungen für diesen OData-Service hat.
Auch da gibt es wiederum viele Stolpersteine. Beispiel: Möchte man den Aufruf seines OData-Service einfach mal über den ADT Classruner testen hat aber eine Destination mit Principal Propagation geht das nicht. Gibt es einen kleinen versteckten Hinweis in einer Doku. D.h. die OData-Aufrufe muss man ggf. in seiner schwergewichtigeren RAP-Anwendung testen.
Man will doch einfach nur einen simplen OData-Service aus dem Backend aufrufen. Braucht Cloud Connector, Destination, Kommunikationsverwaltung, Zugriffsmanagement, Coding und was weiß ich nicht alles… und vielleicht geht es… irgendwie.
“Keep the Core clean” ist schön und gut aber so einfache Use-Cases. Das muss einfacher gehen, besser dokumentiert sein und vor allem transparenter in der Fehlersuche!
Natürlich liegen viele Probleme im Business gerade im Bereich Security aber damit muss man doch rechnen und Lösungen haben und vor allem die Leute abholen!
Was wäre eine Lösung?
Einfache Business Use-Cases die End-to-End beschrieben sind. Beispiel “Ich will einen OData Service aus einem 7.50-System aufrufen”, “Ich willein Feld validieren und brauche dafür Logik aus dem Backend” diese Szenarien müssen End to End beschrieben sein. Von Cloud-Connector bis… Beispielcode in der RAP-Anwendung in Steampunk. So kann man doch wenigstens mal grobe Business-Szenarien einfach nachvollziehen und muss sich nur noch um die entsprechenden Eigenheiten bei Kunden und Partnern kümmern beispielsweise in Abstimmung mit Basis oder Security.
Sei der Erste der einen Kommentar abgibt