Christoph Lordieck
21. Dezember 2013

Schnelle Bearbeitung von UWL Items durch das Einbinden einer Web Dynpro Applikation

Wenn ein Anwender über die Universal Worklist (UWL) einen Eintrag bearbeiten möchte, kann er diesen normalerweise über einen Absprung in die Browseranwendung des zugrunde liegenden Systems oder direkt in der UWL bearbeiten. Dies ist in der Regel für aus dem SAP stammende Aufgaben möglich. Dennoch können Konstellationen auftreten, in denen diese beiden Möglichkeiten nicht zur Verfügung stehen - eine andere Lösung muss her. Für diesen Fall bietet die UWL die Möglichkeit, eine Web Dynpro Anwendung einzubinden, in der die Aufgaben bearbeitet werden können. Wie das Einbinden funktioniert und was dabei zu beachten ist, wird im folgenden Artikel erläutert. 

Unser E-Book zum Thema SAP Entwicklung

E-Book: SAP Entwicklung

Wir erklären Ihnen im E-Book die 3 wichtigsten Frameworks und zeigen Ihnen weitere Erfolgsbooster, die wir selbst einsetzen.

Die UWL im SAP Portal bietet standardmäßig die Möglichkeit, Aufgaben aus mehreren anderen Systemen in einer zentralen Liste zu sehen und direkt in die Bearbeitung einzusteigen. Diese können aus der UWL heraus aufgerufen werden, sofern der Single Sign On (SSO) zuvor konfiguriert wurde und das Backend eine entsprechende Oberfläche zur Bearbeitung bereitstellt. Doch wie sieht es mit Items aus, bei denen

  1. keine Bearbeitungsoberfläche gestellt wird oder
  2. ein SSO nicht möglich ist oder
  3. die aus einem Nicht-SAP-System stammen?

Für diesen Fall kann eine eigene Benutzeroberfläche zwischengeschaltet werden, die genau die individuell erforderlichen Bearbeitungsschritte ermöglicht. Sie fragen sich, wie Sie Items aus ihren Nicht-SAP-Systemen in die UWL einspeisen können? Mit unserer Lösung: Non-SAP-UWL-Connector bringen wir ihre Drittsystem-Aufgaben in die UWL. Nachfolgend wird das Einbinden beispielhaft anhand einer Web Dynpro Java Applikation (WDJA) vorgestellt.

Voraussetzungen

Um eine eigene WDJA so einzubinden, dass Items aus der UWL darin strukturiert angezeigt werden, ist als erster Schritt die entsprechende WDJA notwendig. Diese wird wie gewohnt im SAP NetWeaver Developer Studio erstellt. Damit die Items in dieser dargestellt werden können, sind passende Kontext-Attribute notwendig, in die die Daten des angezeigten Items geladen werden können. Welche Daten genau angezeigt werden, kann ganz individuell für die WDJA festgelegt werden.

Doch woher kommen die Daten? Diese Überlegung steht am Anfang der Implementierung, denn auf ihr baut die gesamte Controllerlogik auf. Eine WDJA wird – auch bei Aufruf aus der UWL – über eine URL angesprochen. Daher bietet es sich an, an diese URL einen Parameter anzuhängen, der es der WDJA ermöglicht, über die UWL-API das passende Item mit seinen Attributen auszulesen und in das WD zu übertragen. Um Zugriff auf alle Informationen zu erhalten, die auch die UWL im Zugriff hat, kann die “InternalId” übergeben werden. Diese ist für alle Items, die in der UWL angezeigt werden, eindeutig und kann über den Itemmanager auf dem UWLService aus der UWL-API dazu verwendet werden, das passende Item auszulesen. Eine entsprechende Implementierung zum Auslesen des Items (nach Auslesen des Parameters aus der UWL) kann wie folgt aussehen:

Codebeispiel 1: Auslesen eines Items aus der UWL

Codebeispiel 1: Auslesen eines Items aus der UWL

Ausgehend von diesem Item kann nun der Kontext mit den gewünschten Attributen gefüllt werden. Durch das hinterlegte Kontext-Mapping zum View und das Data-Binding der Kontext-Attribute auf die Elemente des Views ist die Grundlage zur Anzeige des Items gelegt. Es ist auch möglich, das Item selbst an den Kontext zu binden, um eine spätere Aktionsverarbeitung zu vereinfachen.

Konfigurieren der UWL für den Aufruf der WDJA

Nach dem Deployment der WDJA auf dem AS Java gilt es, die Oberfläche aus der UWL heraus aufzurufen. Die Konfiguration dazu wird in der XML-Konfiguration der UWL vorgenommen (zu finden im SAP Portal unter Systemadministration -> Systemkonfiguration -> Zentraler Arbeitsvorrat – Administration -> Zentraler Arbeitsvorrat – Content-Administration). Dort wird in der XML der View, auf der der Absprung eingefügt werden soll, ein zusätzlicher Eintrag eingefügt, der mindestens folgenden Inhalt benötigt, jedoch zusätzliche Parameter zulässt:

Codebeispiel 2: XML-Konfiguration zum Absprung in die WDJA

Codebeispiel 2: XML-Konfiguration zum Absprung in die WDJA

Für WDJAName ist der Name (ohne Pfad) der WDJA einzutragen und für WDJAnamespace der Pfad, unter dem die Applikation im Portal hinterlegt ist. Diese Daten können in der Content-Administration des Portals im Ordner “Web-Dynpro-Java-Anwendung” gefunden werden. Dort werden die deployte Applikation hinterlegt und die Daten in den Eigenschaften angezeigt. Wird statt einer WDJA eine Web Dynpro ABAP Applikation verwendet, wird der Handler SAPWebDynproABAPLauncher benötigt und beim System der Systemname des ABAP-Stacks.

Damit diese Aktion aufgerufen werden kann, wird zusätzlich eine Konfiguration benötigt, die angibt, wann diese ausgeführt wird. In diesem Beispiel wurde dafür ein Button eingesetzt, der zwischen den schließenden Tags der Properties und der Aktion eingefügt wurde mittels <Descriptions default=”NameDesButtons”/>

Die angepasste XML-Datei wird anschließend wieder hochgeladen, um die Konfiguration zu aktualisieren. Sind alle Daten richtig gepflegt und die WDJA auf dem Server deployed worden, kann nun ein Item aus der Worklist in der WDJA aufgerufen werden.

Durchführen von Aktionen in der WDJA

Ein Item aus der UWL ist in der Regel mit einer Benutzerinteraktion verbunden. Der Anwender bekommt dieses zugewiesen, um einen Bearbeitungsschritt zu vollziehen. Auch dies ist über die WDJA realisierbar, sodass ein Absprung ins Backend überflüssig wird.

Abbildung 1: Beispiel einer WDJA zur Darstellung von Workitems

Abbildung 1: Beispiel einer WDJA zur Darstellung von Workitems

Sieht die View der WDJA Buttons wie im oben zu sehenden Beispiel vor, die für die Bearbeitung verwendet werden können, kann im Eventhandling entweder das Item aus dem Kontext gelesen oder dieses erneut über den oben beschriebenen Weg ausgelesen werden. Dies hängt von der jeweiligen Implementierung ab. Von diesem Item können über den Itemmanager alle möglichen Aktionen aus der UWL ausgelesen werden und die zum Event passende Aktion über einen Pushchannel ausgeführt werden. Die Variable “key” entspricht in diesem Fall dem Aktionsnamen, der zuvor ausgelesen wurde.

Codebeispiel 3: Durchführen einer Aktion auf dem Item aus der WDJA heraus

Codebeispiel 3: Durchführen einer Aktion auf dem Item aus der WDJA heraus

 

Mich interessiert Ihr Feedback – hinterlassen Sie mir gerne einen Kommentar!

Nützliche Quelle:

Christoph Lordieck

Christoph Lordieck

Als Bereichsleiter SAP Entwicklung berate ich Unternehmen rund um das Thema SAP Individualentwicklung. Einige Jahre Projekt- und Umsetzungserfahrung haben meinen Wissenshunger noch nicht gestillt und ich suche ständig nach neuen Themen und Entwicklungen im ABAP-Umfeld.

Sie haben Fragen? Kontaktieren Sie mich!



Das könnte Sie auch interessieren

Häufig ist es während der SAP Entwicklung notwendig, zu Testzwecken im Debugger Werte zu verändern. Bei "normalen" Variablen im ABAP-Umfeld ist dies recht einfach. Wenn jedoch auch Web Dynpro - […]

weiterlesen

In unterschiedlichen Projektmanagementmethoden wie PRINCE2 oder PMI ist das Risikomanagement immer ein wichtiges Thema. In diesem Artikel finden Sie eine einfache Vorlage für ein Risikoregister für Excel.

weiterlesen

Ziel der Internationalisierung einer Anwendung ist die Bereitstellung einer Grundlage, um das Programm mehrsprachig zu gestalten, ohne das Design oder den Quellcode im Nachhinein zu verändern. Sobald der Benutzer seine […]

weiterlesen

Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Kontaktieren Sie uns!
Alexander Koessner-Maier
Alexander Kössner-Maier Kundenservice