WebRFC-Aufrufe in Screen Personas – Fluch oder Segen?
In den vergangenen Monaten hat das Thema SAP Screen Personas im Bereich SAP UI Technology an Fahrt aufgenommen und wird seitens der SAP zunehmend vorangetrieben. Verschiedene Kunden machen Erfahrungen mit den unterschiedlichen Möglichkeiten, die der bisherige Release-Stand bereitstellt. Um die bereits vorhandenen Funktionen des mit Release 2.0 SP 02 noch sehr jungen Produktes der SAP zu beleuchten, möchte ich heute meine Einschätzung der Möglichkeiten und Grenzen von WebRFC-Aufrufen über die in SAP Screen Personas verfügbaren Skripte mit Ihnen teilen.
Sie erhalten die Komplettlösung – Ihr Projekt machen wir zu unserem Projekt. Wir sind Ihr Dienstleiter für Ihr Entwicklungsprojekt, das den Anwender in den Mittelpunkt stellt.
Gerne spreche ich mit Ihnen über Ihre Ausgangslage und zeige Lösungsmöglichkeiten auf. Auf Wunsch unterbreite ich Ihnen im Anschluss ein unverbindliches Angebot.
Kontaktieren Sie mich: Telefon 0211.9462 8572-16 oder per E-Mail info@erlebe-software.de
Technischer Hintergrund von WebRFC
Bei der Bearbeitung eines Flavors, also eines modifizierbaren Dynpro-Screens einer Transaktion, bietet SAP Screen Personas die Möglichkeit, über sogenannte Script-Buttons automatisiert auszuführende Schritte zu hinterlegen, ähnlich den aus Microsoft Office bekannten Makros. Diese Skripte werden bei Klick auf den Button immer gleich ausgeführt und bieten neben Funktionen wie “Wert aus einem Feld kopieren”, “Wert in ein Feld einfügen und Enter drücken” oder “Button betätigen” auch fortgeschrittene Möglichkeiten wie Berechnungen mittels JavaScript durchzuführen oder auf dem Backend-System einen WebRFC-Baustein aufzurufen.
WebRFC-Bausteine haben für SAP Screen Personas immer die gleiche festgelegte Schnittstelle. Als Changing-Parameter sind die Folgenden zu definieren:
Changing-Parameter des WebRFC-Bausteins
Im Reiter Tabellen (bzw. Tables) werden diese Angaben benötigt:
Tables-Parameter des WebRFC-Bausteins
Die Tabelle “QUERY_STRING” enthält die eingehende URL-Anfrage für den WebRFC-Aufruf. Diese sieht in der Regel in etwa so aus: http://<server>:<port>/sap/bc/webrfc?_FUNCTION=<Name des WebRFC-Bausteins>¶m1=value1¶m2={variablenname}&…
Wie schon zu erkennen ist, können über die URL auch gleich Parameter mitgegeben werden. Dabei gibt es zwei Möglichkeiten der Übergabe. Bei param1 wird ein hart codierter Wert mitgegeben, nämlich value1. Value1 steht in diesem Beispiel für einen String oder eine Zahl. Bei param2 hingegen steht kein Wert, sondern ein in geschweiften Klammern verpackter Variablenname. Dieser kann vorher im Skript definiert und entsprechend gefüllt worden sein. Um den Wert der Variable im Baustein auszulesen, hilft folgender Code-Schnipsel:
READ TABLE query_string WITH KEY name = ‘_Name’.
name = query_string–value.
Die Tabelle “HTML” bzw. auch die Tabelle “MIME” enthalten die Ergebnisse im JSON-Format. Eine zurückgelieferte HTML-Tabelle könnte im Funktionsbaustein mit der folgenden Anweisung gefüllt werden:
CONCATENATE ‘{“results”:[{“key”: “classname”, “value”: “‘ otext ‘”}]}’ INTO htmldoc–line.
INSERT htmldoc INTO TABLE html.
Hinter “key:” steht der Variablenname, der später im Skript wieder referenziert werden kann. Hinter “value” steht der Wert, der für diese Variable im Baustein ermittelt wurde.
Das einfache kleine Skript dazu sieht so aus:
Skript für den WebRFC-Aufruf
Es kopiert einen Wert aus einem Feld in die Variable “name”, ruft mit dieser Variable den RFC-Baustein auf und fügt den Ergebnis-Parameter “classname” anschließend in ein anderes Feld ein.
Welchen Vorteil bringt WebRFC zu normalen Skripten?
In der Regel liefern WebRFC-Aufrufe Informationen, die jederzeit auch über ein “klassisches” Screen Personas Skript ausgelesen und bereitgestellt werden können. Die Entscheidung für oder gegen einen WebRFC-Aufruf kann von verschiedenen Faktoren abhängen:
Kann dieser Baustein an verschiedenen Stellen in verschiedenen Skripten gebraucht werden?
Eine Überlegung, die einen WebRFC-Baustein interessant macht, ist die Wiederverwendbarkeit in verschiedenen Flavors. Ist es ein Baustein, der verschiedene Funktionen abdecken kann, was natürlich bei der Entwicklung so ausgelegt werden kann, wird mit einem solchen Baustein anstelle verschiedener normaler Skript-Schritte die Wartung der damit erzielten Funktionalitäten erheblich vereinfacht. Anstelle des Änderns jedes Skriptes mit eventuell fünf, zehn oder mehr Schritten reicht gegebenenfalls die Anpassung der Bausteinlogik, um das gewünschte Ergebnis zu erzielen.
Wieviele Schritte wären mit einem normalen Skript notwendig?
Wer bereits ein Skript zum Auslesen von zusätzlichen Informationen durch einen Baustein ersetzt hat, wird es bestätigen können: Bereits bei wenigen Skriptschritten ist eine Informationsbeschaffung über einen WebRFC-Baustein wesentlich performanter. Zwar werden alle Schritte eines Skriptes ohne zwischendurch durchgeführte Roundtrips auf dem IST des Applikationsservers ausgeführt. Dennoch wird ein WebRFC-Call wesentlich schneller durchlaufen. Dies ist im Einzelfall durch klassisches Ausprobieren herauszufinden, schließlich hängt die Laufzeit eines Bausteins auch von seiner abgebildeten Logik und Funktionalität ab.
Sollen Daten manipuliert werden?
Dies ist nicht zwingend eine Frage des Vorteils von WebRFC-Bausteinen, sondern der Vollständigkeit. Möchte ich Daten über ein Skript automatisiert manipulieren und abspeichern, kann dies über die Transaktion und Skript-Schritte ohne WebRFC in einem getesteten und bewährten Umfeld durchgeführt werden. Dabei werden Berechtigungsprüfungen durchgeführt und ggf. auch Sperren gesetzt bzw. gelöst, um eine saubere Verarbeitung zu gewährleisten. Wird die Manipulation über einen Baustein durchgeführt, sind all diese Prüfungen, Sperren und auch Wechselwirkungen mit von der Transaktion normalerweise im Hintergrund manipulierten Tabellen und Abhängigkeiten ebenfalls durchzuführen und umfassend zu testen.
WebRFC – Fluch oder Segen?
Grundsätzlich ist es ein Stück weit Geschmacks- und Performance-Frage, welche Funktionen über ein Skript mit oder ohne WebRFC-Aufrufe abgebildet und bereitgestellt werden. Mit zunehmender Anzahl an Skripten und WebRFC-Bausteinen steigt auch der Wartungsaufwand. Durch etwas dynamische Auslegung von Bausteinen kann hier eventuell das ein oder andere Skript vermieden und durch ein bestehendes Skript mit geänderten Variablen ersetzt werden.
Mit dem bisher Gelesenen wirkt WebRFC in Personas-Skripten wie ein toller Einfall. Doch wo liegen die Grenzen, bis wohin kann das Spiel “Zusätzliche Funktionalität” weitergetrieben werden? Kurz: Prinzipiell gibt es keine. Der Aufruf eines WebRFC-Bausteins ermöglicht etwas, das Screen Personas “eigentlich” nicht zur Verfügung stellt: Die Möglichkeit, in einer Transaktion von der eigentlichen Verarbeitungslogik völlig losgelöst Funktionen zu implementieren. Wird ein Dynpro umgestaltet, kann die eigentliche Verarbeitungslogik nicht verändert werden. Pflichtfelder können nicht ausgeblendet werden und sind Eingaben nicht vorhanden, die benötigt werden, wird ein Fehler geworfen. Auch aus einem Skript heraus kommt dann eine Meldung, dass dieses Skript nicht ausführbar sei. Rufe ich aber einen WebRFC-Baustein auf, kann ich völlig losgelöst von der eigentlichen Transaktionslogik agieren und manipulieren.
Dies bietet natürlich auf der einen Seite an verschiedenen Stellen lang ersehnte Möglichkeiten: Flexibles Nachladen von Informationen auf Wunsch, ohne mich durch verschiedene Transaktionen zu hangeln, Hinzufügen von Datenbankoperationen, ohne gleich eine Modifikation des Standards vornehmen zu müssen etc. Nichtsdestotrotz ist es wichtig, sich bei der Benutzung kritisch zu fragen: Wird das hier wirklich benötigt? Wird es eventuell über bestehende Transaktionen zuverlässiger bereitgestellt? Diese Fragen sind im Einzelfall zu klären. Dies ist kein Appell gegen die Nutzung von WebRFC-Aufrufen, sondern eine Empfehlung: WebRFC-Bausteine bieten viele schnell umzusetzende Möglichkeiten – Nutzen Sie diese mit Bedacht, um den Bezug zur eigentlichen Transaktion und damit dem eigentlichen Geschäftsvorfall nicht zu verlieren.
Sie setzen selbst bereits SAP Screen Personas ein oder denken darüber nach? Oder fragen Sie sich, wie ein Usecase mit SAP Screen Personas aussehen kann? Teilen Sie Ihre Fragen, Ideen und Anregungen mit mir. Ich freue mich über Ihr Feedback!
