Die Deutsche Wirtschaft läuft auf ABAP – so heißt es. Müssen sich Java-Entwickler im Umfeld seriöser Geschäftsanwendungen deshalb gleich mit dieser seltsamen Sprache auskennen? Den modernen Java Enterprise Technologien hat der verstaubte ABAP-Stack doch wohl nichts entgegen zu setzen!

Wer so denkt, der irrt natürlich. SAP NetWeaver Entwicklungsprojekte verlangen häufig genug nicht die Entscheidung für ABAP oder Java, sondern die Verbindung beider Technologien. Damit sind auch die Anforderungen an passende Projektteilnehmer definiert.

ABAP ist tot. Java auch.

Die Sprache ABAP hat Ihre Ursprünge noch in SAP R/2 und soll die Abkürzung für Allgemeiner Berichtsaufbereitungsprozessor gewesen sein. Seit über 10 Jahren ist sie unter der Bezeichnung ABAP OO auch objektorientiert verwendbar. Die wichtigsten SAP Lösungen sind in ABAP geschrieben, allen voran die Business Suite mit ERP, CRM, SRM usw. Insofern kam an ABAP lange Zeit niemand vorbei.

Java kam im Jahr 2002 ins Spiel, als SAP einen Application Server namens InQMy kaufte und ihn zwei Jahre später als WebApplication Server 6.20 im ersten Release von SAP NetWeaver unterbrachte. Die Euphorie war groß und im Überschwang der Internet-Economy wurde ABAP ein baldiges Ende vorausgesagt: SAP wolle mittelfristig vollständig auf Java umstellen, so hieß es. Tatsächlich hat der Java-Server auch eine respektable Entwicklung genommen. Die aktuelle Engine ist Java EE 5 zertifiziert und wichtige  Teile aus dem SAP NetWeaver Portfolio basieren auf Java: Portal, Process Integration (PI), Business Process Management (BPM), Composition Environment (CE). Die Entwicklung geht weiter: Die Sybase Unwired Platform läuft auf Java, PI und CE sollen zusammen auf einen reinen Java-Stack umziehen. Im Web sind schicke Anwendungen mit AJAX schon Standard, langsam bewegt sich auch die UI-Strategie der SAP in diese Richtung und es wird schon mal die Verwendung von HTML 5 für die Zukunft angekündigt.

Vom Untergang von ABAP war in den letzten Jahren allerdings weit und breit nichts zu sehen und inzwischen hat sich der Wind sogar gedreht. Die Übernahme von SUN durch SAP’s Lieblingsfeind Oracle brachte die Diskussion ins Rollen. Die Schlüsseltechnologie Java war jetzt vermeintlich in der Hand des ärgsten Konkurrenten. Es folgte die Ankündigung, SAP werde Web Dynpro Java nicht mehr weiterentwickeln.  Es dauerte nicht lange, bis ABAP’s Sieg über Java in der öffentlichen Diskussion propagiert wurde.

Grau ist alle Theorie

In der Praxis ist dann alles Für-und-Wider akademisch. Es ist nun einmal Realität, dass beide Technologien nebeneinander existieren, jede ihr Einsatzgebiet hat und sichdiese Tatsache auch nicht so schnell ändern wird. Die Entscheidung für die eine oder andere Technologie als Entwicklungsplattform darf nicht aufgrund persönlicher Vorlieben getroffen werden, sondern muss sich an objektiven Kriterien entscheiden und das Szenario und das Lösungsumfeld berücksichtigen.

Ein erfahrener ABAP-Entwickler mag mit seiner Sprache auskommen, solange er sich in seinem angestammten ERP-Modul bewegt. Für seinen Kollegen vom Java-Team gibt es aber keine Alternative: Früher oder später kommt er in seinen Entwicklungsprojekten mit der ABAP-Welt in Berührung, denn in praktisch jedem Projekt gibt es ein Backendsystem aus der Business Suite. Dann sollte er RFC-Schnittstellen verstehen können, Datenbanktabellen lesen, sich im Customizing zurecht finden und vor allem die ABAP-Allzweckwaffe bedienen können: Den Debugger. Darüber hinaus wäre es auch von Vorteil, den einen oder anderen generierten ABAP Proxy mit Leben füllen zu können.

In den folgenden Teilen dieser Artikelserie werden die Kernelemente von ABAP-Programmiersprache und Laufzeitumgebung aus der Sicht eines Java-Entwicklers betrachtet und Parallelen zu der ihm bekannten Welt gezogen. Ein Einstieg in die ABAP-Welt sollte auf diese Weise ausreichend verlockend werden.

Alle Java-Entwickler können sich ausnahmsweise Lothar Matthäus zum Vorbild nehmen: Der kann auch rechts wie links.

ABAP scheint auf den ersten Blick meilenweit entfernt zu sein von Java. Den Einstieg für Java-Entwickler erleichtert es, sich die Gemeinsamkeiten vor Augen zu führen – zum Beispiel anhand der Definition eines Objektes.

Zunächst einmal: Auch ABAP ist objektorientiert. Die alte Java-Maxime “Everything is an object” gilt zwar nicht (“Some ABAP-things are an object” müsste es wohl heißen. Oder “Most new ABAP things are an object”). Trotzdem: ABAP Objects hat seit dem Release 4.6 Einzug gehalten und ist seit Langem etabliert. Allerding muss man sich darauf einstellen, dass in der Praxis die klassische prozedurale Variante durchaus noch eine Rolle spielt.

ABAP kennt also Klassen analog zu Java. Die Syntax ist anders und etwas gewöhnungsbedürftig. Man muss sich aber nur die Analogien vor Augen führen, dann wird das Wichtigste schnell klar.  Als Beispiel hier eine Java Klasse mit Konstruktor, Attributen, Methoden, Sichtbarkeit und ein paar Statements, wie man sie kennt:

(Zum Sinn und Zweck dieser Klasse siehe hier: 99 Bottles of Beer)

Im Vergleich dazu eine ähnliche Klasse in ABAP. Zunächst fällt auf, dass Deklaration und Implementierung getrennt sind.

Die Deklaration umfasst eine öffentliche und eine private Liste von Methoden. Die wiederum beinhalten die Methodendefinition mit Eingabe- und Rückgabeparametern. Es fällt auf, dass viel häufiger mit sprechenden Schlüsselworten gearbeitet wird, als mit einfachen Trennzeichen. Die Implementierung:

Wenn auch nicht zwingend erforderlich, ist es doch eine weit verbreitete Konvention die Datendeklaration gesammelt an den Anfang von Programmen und Methoden zu stellen. In Java wird dies zwar auch teilweise als guter Stil empfohlen, ist aber bei weitem nicht so üblich wie in ABAP.  Diese TYPES- und DATA-Blöcke können durchaus etwas länger werden. Damit man nicht den Überblick verliert haben sich auch Konventionen in der Benennung der Variablen eingebürgert. Diese sind zwar nicht immer ganz einheitlich gehandhabt, werden aber oft nach folgendem Schema konstruiert:

{Prefix1}{Prefix2}_{name}

Das erste Prefix zeigt den Verwendungszweck an, das zweite den Typ:

In unserem Beispiel wird daraus dann lv_text als lokale Variable und ev_text als einfacher Exportparameter.  Die inflationäre Verwendung von Schlüsselworten ist auffällig. Nicht nur FOR, ELSE und NEXT sind in ABAP reserviert, sondern auch RADIOBUTTON, NO-DISPLAY, DISTANCE und DEPARTMENT. Über 700 reservierten Worte in ABAP stehen nur etwa 50 in Java gegenüber. In der Regel hilft da nur die Onlinehilfe, die aber zum Glück sehr umfangreich ist: Ein Druck auf F1 liefert zum Schlüsselwort DISTANCE die Erklärung:

Also die Sprache selbst dürfte keinen Java-Entwickler vom ABAP-Kodieren abhalten. Man darf sich nur nicht verwirren lassen!

Beim nächsten mal werfen wir mal einen Blick auf die Vorzüge der ABAP Entwicklungsumgebung!

Ganz lustig zum Vergleich von Programmiersprachen ist diese Seite:
http://99-bottles-of-beer.net

Hier finden sich Beispiele für das immer gleiche Programm in aktuell 1440 Varianten.

ABAP OO: http://99-bottles-of-beer.net/language-abap-55.html
Java einfach: http://99-bottles-of-beer.net/language-java-4.html
Java etwas komplizierter: http://99-bottles-of-beer.net/language-java-3.html

Und dann noch ein alter Bekannter aus grauer Vorzeit: EUMEL / ELAN:

http://99-bottles-of-beer.net/language-elan-232.html
http://de.wikipedia.org/wiki/L2_(Betriebssystem)

Macht Spaß!

Im SAP NetWeaver Portal lassen sich Web-Anwendungen mit einem sogenannten URL-iView einbinden. Die Konfiguration ist einfach: Man gibt die URL an, die im iView-Fenster angezeigt werden soll – fertig.

Leider hat das Standard-URL-iView einen entscheidenden Nachteil: Es ist nicht mit einem System aus der Portal-Systemlandschaft verbunden. Aus diesem Grund kann es nicht ohne Weiteres durch eine mehrstufige Entwicklungslandschaft transportiert werden, wie es für andere Systemtypen Standard ist.

In der Regel gibt es für jeden Applikationsserver in einer IT-Landschaft mehrere Instanzen, also zum Beispiel:

Trägt man in diesem Beispiel im E-Portal den E-Link in ein URL-iView ein und transportiert es auf das T-Portal, so wird der Link nicht automatisch auf das T-System verweisen. Dieses Problem wird normalerweise mit den System-Objekten in der Portal-Systemlandschaft gelöst. Das Standard URL-iView unterstütz die Verwendung von System-Aliasen nicht.

Die komplizierte Lösung ist nicht mehr zu finden

Zur Lösung finden sich verschiedene Anleitungen unter anderem auch im SCN. Dafür soll aber ein Tool aus dem SAP Service Marktplatz heruntergeladen und im System deployed werden
(com.sap.portal.howtos.webapp.par, inkl. Anleitung HowToUseAppIntegrator_en.pdf).

Dieses Archiv ist inzwischen nicht mehr verfügbar, aber es geht sowieso auch ohne zusätzliche Deployments:

Schritt 1: System anlegen

Zuerst ein System anlegen:

Systemadministration > Systemlandschaft > neu > System

Als Typ am besten “Dedizierter Anwendungsserver für SAP-System” wählen.

Das System wie gewohnt benennen und im Bereich Web Application Server die Informationen eintragen, die für die Zusammensetzung des Links auf der Entwicklungsstufe erforderlich sind. Einen System-Alias eintragen, zum Beispiel MSWEBAPP .

Schritt 2: iView anlegen

Für SAP NetWeaver Portal 7.3:
Contant Administration > Portal-Content-Verwaltung > Portal-Content

Unter Portalanwendungen > com.sap.portal.appintegrator.sap > Generic suchen und Kopieren wählen.

In einem geeigneten Ordner im PCD dann Als PCD Objekt einfügen, benennen und die Eigenschaften der Kategorie Content – Generischer Launcher bearbeiten.

URL-Vorlage:
<System.wap.WAS.protocol>://<System.wap.WAS.hostname>/important_web_app/start.html

System:
MSWEBAPP

Weitere Einstellungen zu Applikationsparametern, Authentifizierung usw. sind ebenfalls möglich.

Schritt 3: Wie gewohnt transportieren

Wenn dieses iView gerufen wird, wird aus Systemdefinition und URL-Vorlage der richtige Link gebildet. Man kann es nun ins T-System und weiter ins P-System transportieren. Dort werden jeweils die zur Stufe passenden Systemdefinitionen mit dem Alias MSWEBAPP anlegelegt.

Und schon … funktioniert’s.

ABAP Entwicklungsumgebung

Die ABAP Entwicklungsumgebung ist für den Java Entwickler meist zunächst ein Kulturschock. Gewohnt ist man eine IDE im Eclipse Stil und die ABAP Workbench passt nicht so recht in die gelernten Sehgewohnheiten.

Zum Glück sind die Zeiten des sogenannten klassischen ABAP Editors mit begrenzter Zeilenlänge aber vorbei.

Klassischer ABAP Editor

Rund um die ABAP Workbench steht eine Vielzahl von Hilfsmitteln und Tools bereit. Einige sind für Java Entwickler durchaus überraschend -was in der Regel daran liegt, dass sie überhaupt nur in der ABAP Welt sinnvoll sind und im Java Umfeld schwer denkbar sind. Grund ist die Tatsache, dass das gesamte Coding eine ABAP-Stacks auf dem Server abgelegt ist, dort editiert wird und eine gemeinsame große Laufzeitumgebung bildet.

Das gilt interessanterweise sowohl für die von SAP ausgelieferten Teile wie auch für die selbsterstellten Anwendungen. Insofern ist SAP NetWeaver quasi quelloffen – obwohl natürlich nicht Open Source im eigentlichen Sinne.

Die Transaktion SE80 wird in der Regel zum Einstieg in die Entwicklungsumgebung verwendet. Hier greift man per Name auf die verschiedenen Objekttypen zu, z.B. Klassen, Funktionsbausteine oder Programme.

Da alles in der Datenbank liegt, ist auch die Sicht auf die verschiedenen Elemente nicht wie gewohnt Datei-orientiert, sondern in integriert in die IDE in Tabellen, Tab-Reitern und Feldern organisiert. Der eigentliche Quellcode ist beispielsweise nur ein Teil einer Klassenansicht.

ABAP Klasse in der ABAP-Workbench

Ähnlich Java packages sind alle Objekte in einer Hierachie von Paketen organisiert.

Paketübersicht in der ABAP Workbench

Jeder Entwickler hat noch ein spezielles Paket für sich, für sogenannte lokale Objekte. Dieses Paket verwendet man für eigene Tests und Spielereien, die nicht weiter verwendet werden sollen. Denn Entwicklungen außerhalb der lokalen Objekte dürfen nicht beliebig neu angelegt werden, sondern brauchen immer eine Referenz auf einen Transportauftrag. Man kann sich als schon mal darauf vorbereiten, dass mit dem ersten neuen Objekt eine entsprechende Abfrage erscheint und dann sollte man sich einen Transportauftrag bereits besorgt haben – oder die Berechtigung einen anlegen zu dürfen.

Transportauftrag auswählen

Die schon erwähnte Eigenschaft, dass alle Entwicklungsobjekte in einem großen Repository auf dem Server liegen, ermöglicht der Entwicklungsumgebung einige schöne Features.

Ungeahnte Möglichkeiten ergeben sich durch die Vorwärtsnavigation, die auf nahezu allen Objekten möglich ist. In Java kennt man dies für die Klassen und Methoden des eigenen aktuellen Entwicklungsprojektes. Der ABAP Editor erlaubt einen viele größeren Navigationsbereich: Ein Klick auf einen Tabelle in einem SQL-Statement springt zur Tabellendefinition. Von dort geht es weiter zum Datentyp einer Tabellenspalte und weiter zu deren Domäne. Kaum angekommen navigiert es sich einfach zum Paket, in dem die Domäne definiert ist und schon weiß man nicht mehr, von wo man gekommen war.

Die Navigation ist auch deshalb so stark, weil sie eben über eigene und SAP-Objekte , über Datentypdefinitionen, Datenbanktabelle, Interfaces und Klassen usw. usw. ohne Hindernisse hindurch funktioniert.

Auch der rückwärtige Weg ist möglich: Der Verwendungsnachweis zeigt, wo überall in der gesamten Laufzeitumgebung ein Typ, eine Klasse oder eine Methode verwendet wird. Vorsicht übrigens: Die Suche kann tatsächlich “über alles” laufen und daher auch zum Teil ein wenig dauern.

Verwendungsnachweis

Alles ist auf dem Server – aus diesem Grund gibt es nach dem Kompilieren auch keinen Buld-Prozess und kein Deployment. Stattdessen kennt jeder ABAP Entwickler die drei Schritte “Sichern – prüfen – aktivieren”. Damit wird geänderter Quellcode auf den Server gespeichert und die Syntaxprüfung aufgerufen. Nur wenn diese erfolgreich ist, kann aktiviert werden, das bedeutet die aktuell aktive Version eines Stück Software in der Laufzeitumgebung wird durch die neue Version ersetzt. Dies ist quasi das Äquivalent zum Deployment, wenn auch auf sehr kleinteiligem Niveau möglich.

Ein weiteres Beispiel für nützliche Helfer ist die Unterstützung beim schnellen Testen und Ausprobieren. Für Klassen wird via Testbefehl eine Instanz erzeugt, eine Eingabemaske für die gewünschte Methode generiert und dann mit abgefragten Parametern abgeschickt.

Testen einer Klasse

Weitere größere und kleinere Hilfsmittel und Werkzeuge wie zum Beispiel die integrierte Dokumentation und das Handling von Mehrsprachigkeit und sprengen hier natürlich den Rahmen. Aber es lohnt sich damit einmal zu beschäftigen.

Werkzeuge der ABAP Workbench

Im nächsten Teil geht es dann um den Debugger – der braucht sich ebenfalls nicht zu verstecken.

Die Suchfunktion im Portal Content Directory (PCD) des SAP NetWeaver Portals ist oft nicht besonders hilfreich. Zwar kann man zum Beispiel nach iViews mit einem bestimmten Titel suchen, aber bei komplexeren Abfragen stößt man schnell an Grenzen.

Ändert sich zum Beispiel die URL einer Web-Applikation, dann benötigt man die Antwort auf die Frage: Welche URL-iViews zeigen auf die URL http://www.mindsquare.de?

Dabei hilft die Suche im PCD-Inspektor, genauer gesagt die JNDI-Suche. Unter Systemadministration > Support > PCD-Werkzeuge > PCD-Inspektor findet man dieses Hilfsmittel.

Man stimmt zu, dass man weiß was man tut (natürlich wissen wir das) und findet sich in der Root-Ansicht des JNDI-Directories wieder.  Über “Blättern in” geht es in den Portal Content bis zu dem Level, ab dem man suchen möchte.

PCD Inspektor

Das kleine graue Fernglas führt in die Suchmaske, die man am besten links liegen lässt und gleich zu “JNDI Suchmaske verwenden” weitergeht. Hier kann man sich jetzt die Suchanfragen nach Belieben definieren.

JNDI Suche im PCD

Die hier verwendete Syntax für JNDI-Filter sieht grundsätzlich so aus: (&(Eigenschaft=Wert)(Eigenschaft2=Wert2))
Details dazu sind hier zu finden: http://docs.oracle.com/javase/jndi/tutorial/basics/directory/filter.html

Hier einige der mögliche Eigenschaften:

Welche Eigenschaften es gibt und wie diese heißen, das findet man leicht im PCD selbst. Am PCD-Objekt die Eigenschaften aufrufen und “Attribute anzeigen” wählen. Die angezeigte Eigenschafts-ID kann in der JNDI Suche verwendet werden, wie zum Beispiel hier com.sap.portal.pcd.unit.LastChangedBy für “Geändert von”.

Objekteigenschaften im PCDObjekteigenschaften im PCD

Die Suchanfrage “Welche URL-iViews zeigen auf mindsquare.de?” sieht also so aus:

(&(url=*www.mindsquare.de*)(com.sap.portal.pcd.gl.ObjectClass=com.sapportals.portal.iview))

Der PCD-Inspektor ist im SAP NetWeaver Portal 7.0 bis 7.3 verfügbar.

Die Webseite SAP Design Guild ist zu unrecht eher unbekannt.

www.sapdesignguild.org

Es handelt sich um eine offizielle Seite der SAP, genauer gesagt des “SAP User Experience Team”.

SAP Design Guild

Das erklärte Ziel des Teams ist es, das UI-Design der SAP Software “auf das nächste Level zu heben”. Zumindest bietet die Seite ein riesige Menge an Resourcen zum Thema Benutzeroberflächen und den verschiedenen Technologien der SAP. Man findet die unterschiedlichsten Materialien von UI Guidelines für iPad bis zum historischen Abriss über SAP UI-Technologien.

Ein Besuch lohnt sich!

Wie heißt dieser Web Dynpro Fortschritts-Anzeiger eigentlich? Donut? Web-Dynpro-Sonne? Runde Sanduhr? Die SAP nennt es jedenfalls Wartebild. In jedem Fall ist ein Wartbild, das sich unendlich dreht ein Symptom bei folgendem Problem:

Die Oberfläche im SAP NetWeaver Portal friert scheinbar ein, das Web Dynpro Wartebild dreht sich und keine weitere Aktion ist möglich. Dies passiert bei verschiedenen Web Dynpro Applikationen, zum Beispiel im Portal Content Studio und im Usermanagement. In der Regel muss der Browser komplett beendet werden.

Das beschriebene Problem tritt in der Kombination SAP NetWeaver Portal 7.2 / 7.3 und dem Internet Explorer 10 auf.

Grundsätzlich wird der IE 10 am SAP NetWeaver 7.3 SP08 unterstützt. Ein Fehler in der AJAX Runtime, die das Wartebild anzeigt, führt aber auch in Versionen ab SP08 zu einem Java Script Fehler “Unable to get property toUpperCase”.

Leider verhindert die Standardeinstellung des IE 10, dass der Java Script Fehler angezeigt wird. Das kommentarlose Einfrieren des Browsers macht die Fehlersuche dann etwas schwierig.

Gehen Sie deshalb wie folgt vor: Stellen Sie zunächst fest, ob der beschriebene Fehler vorliegt. Wenn Sie keinen Java Script Fehler angezeigt bekommen, dann ändern Sie die Internetoptionen so, dass Debugging und Fehleranzeige aktiviert sind.

Jetzt sollten sie im SAP Portal den Skriptfehler “Unable to get property toUpperCase” erhalten.

Aktualisieren Sie in diesem Fall mindestens die Komponente AJAX-RUNTIME auf die neueste Version ihres NetWeaver SP. Dazu können Sie über den Maintenance Optimizer (MOPZ) ein komplettes Update generieren lassen oder gezielt diese Komponente herunterladen: Im SAP Software Download Center unter Support Packages > A- Z > SAP NetWeaver > [Ihre Version] > Entry by Component > Application Server ABAP > AJAX RUNTIME > OS independent

Dort finden Sie für die verschiedene Service Packs (SP) den jeweils letzten Patch, um das genannte Problem zu beheben.
Übrigens: SAP NetWeaver unterstützt grundsätzlich keine 64 bit Versionen des Internet Explorers. Diese Aussage hat für den IE 10 aber keine besondere Relevanz mehr. Denn hier gibt es gar keine getrennten 32 bit und 64 bit Versionen mehr. Standardmäßig laufen die einzelnen Tabs immer im 32 bit Modus.

Verweise:

• SAP Note 1824806: http://service.sap.com/sap/support/notes/1824806
• Product Availability Matrix (PAM): http://service.sap.com/pam
• SAP Software Download Center: http://service.sap.com/swdc
• IE Blog zu 32 bit / 64 bit: http://blogs.msdn.com/b/ie/archive/2012/03/14/enhanced-protected-mode.aspx

Hintergrund

Bei meinem aktuellen Kunden befindet sich ein SAP NetWeaver Portal 7.3 im Einsatz. Dies wird vor allem als Single Point of Entry und damit zur Integration verschiedenster Anwendungen aus angeschlossenen SAP R/3 Systemen und anderen Fremdsystemen verwendet. Es wird viel Arbeit, Geld und Zeit in die Wartung, Weiterentwicklung und Pflege dieses Systems investiert Kunde aber niemand hat einen Überblick darüber ob dieses System auch wirklich intensiv genutzt wird.

• Wie oft werden die integrierten Anwendungen aufgerufen?
• Welche Anwendungen werden am häufigsten aufgerufen?
• Wie viele Benutzer benutzen überhaupt das SAP NetWeaver Portal?

Dies sind nur einige der Fragen mit denen mein Kunde auf mich zukam. Die Antwort auf diese Fragen lautet: Portal Activity Reports!

Ein Portal Activity Report ist ein SAP Portal iView, welches statistische Daten über die Benutzung von iViews und Seiten aggregiert und darstellt. Hierbei lassen sich diese Aktivitätsdaten unter unterschiedlichen Gesichtspunkten und Zeiträumen betrachten. Also genau das richtige für mich Problem!

Konfiguration des Berichtes

Damit wir relevante Daten über Benutzerverhalten und Aufrufe erhalten können muss das eingesetzte Portal Activity Report iView erst noch konfiguriert werden. Zwei Fragen müssen dabei vorab geklärt werden:

• Über was soll eigentlich berichtet werden?
• Über welchen Zeitraum bzw. über welche Berichtsperiode sollen die Daten gesammelt werden?

Auswahl und Konfiguration der Berichtsart

Das WAS bestimmen wir über die Berichtsart. In der Konfiguration des Portal Activity Reports lässt sich die Berichtsart festlegen. Hier lassen sich die beispielsweise die Anzahl der angemeldeten Benutzer oder Daten über Seiten/iView Aktivitäten auswählen.

Abbildung 1 Berichtsarten eines Portal Activity Reports

Ich habe mich für die Daten über Seiten/iView Aktivitäten entschieden, da ich wissen will, welche Applikationen WANN wie oft aufgerufen werden. Dazu richtete ich die Einschränkung ein, dass nur Seiten und iViews in dem Bericht berücksichtigt werden sollen, welche innerhalb des Berichtzeitraumes öfter als 99 mal aufgerufen wurden.

Auswahl und Konfiguration der Berichtsperiode

Das WANN, der Zeitraum der Datenerfassung, wird über die Berichtsperiode konfiguriert.

Abbildung 2 Auswahl der Berichtsperiode eines Portal Activity Reports

Folgende Optionen stehen zur Auswahl:

• Aktivitäten am aktuellen Tag: hierbei werden sämtlich Aktivitäten des aktuellen Tages zu den angegebenen Uhrzeiten ausgewertet.
• Letzte Aktivität: Hier besteht die Möglichkeit einen Zeitraum in der Vergangenheit ab dem aktuellen Tag festzulegen. Die Aktivitäten, welche in diesem Zeitraum stattgefunden haben werden ausgewertet (z.B. sämtliche Aktivitäten der letzten 3 Wochen ab heute).
• Fester Zeitraum: Aktivitäten eines fest definierten Zeitraumes werden in die Auswertung mit einbezogen.

Ich habe mich dazu entschieden die Aktivitäten der letzten 4 Wochen auszuwerten und dies ab jetzt einmal im Monat zu tun. Somit bin ich in der Lage zu beobachten, wie sich Änderung im Portal (z.B. Release neuer Anwendungen) auf das Nutzerverhalten auswirken.

Weitere Auswertung und Aufarbeitung des Berichtes

Das Bericht Flat-File

Nachdem der Bericht nun fertig konfiguriert wurde lässt er sich auch schon ausführen. Wie auf zu sehen ist befinden werden bereits Aktivitätsdaten angezeigt, mit denen ich schon die gestellten Fragen beantworten kann.

Abbildung 3 Ausführung eines Portal Activity Reports

Nun wirkt dieser Report sehr trocken und ist wenig für Präsentationen und Vorstellungen geeignet. Ein Import der Daten in ein BW oder Excel wäre sehr gut geeignet, um die Daten präsentationsgerecht aufzubereiten. Zum Glück ist es möglich die Aktivitätsdaten des Reports direkt per Flat File herunterzuladen. Dieses Flat File enthält alle Spalten (mit Tabulatoren getrennt) und Zeilen, welche auch in dem Report angezeigt werden und wird im *.txt Format ausgegeben.

Damit lassen sich nun im Prinzip die aufgetretenen Fragen beantworten.

Eigentlich ist die Version 7.0 der SAP NetWeaver Portal eine Erfolgsstory. Noch immer gibt es zahlreiche produktive Installationen, obwohl inzwischen mehrere Nachfolgeversion auf den Markt gekommen sind.

Die neuen Features des aktuellen Portals in der Version 7.3.1 und vor allem die allgemeine Landschaftspflege veranlassen aber früher oder später jeden Portalbesitzer eine Migration zu planen.

In kürzlich abgeschlossenen Migrationsprojekten haben sich einige Aspekte herauskristallisiert, die man dabei unbedingt berücksichtigen sollte.

Der wichtigste Punkt ist die Entscheidung für das grundsätzliche Vorgehen beim Upgrade.

Upgrade auf dem bestehenden System

Beim klassischen Upgrade eines Servers werden einfach gesprochen die neuen NetWeaver 7.3 Softwarepakete auf dem bestehenden System eingespielt. Dazu werden die SAP Upgrade Leitfäden und Tools genutzt und jede der Systemstufen von der Entwicklung bis zur Produktion nacheinander aktualisiert.

Prinzipiell geht man wir folgt vor:

1. Vorbereitung nach SAP Upgrade Guides
2. Klärung der Voraussetzungen
3. Entwicklungsstopp auf dem E-System
4. Upgrade E-System mit genauer Dokumentation
   • Abschalten
   • Sicherung
   • Upgrade mit dem SAP Java Upgrade Tool
   • Nacharbeiten
   • Tests
5. Upgrade weiterer Systeme nach gleichem Schema
6. Upgrade P-System

Der Upgrade Prozess muss gewissenhaft nach den dokumentierten Voraussetzungen und Schritten durchgeführt werden, damit es bei der Durchführung keine Probleme gibt. Es liegt auf der Hand, dass das Risiko hier wächst, je größer die Unterschiede zwischen E- und P-System sind. Nach jahrelangem Betrieb sammeln sich in der Regel so einige Dinge an, die mal ausprobiert wurden und es nicht in die Produktion geschafft haben.

Von praktischer Bedeutung ist die Tatsache, dass kein Parallelbetrieb zwischen alter und neuer Systemlinie möglich ist. Damit besteht in der Zwischenphase nicht die vollständige Wartbarkeit, wenn für ein 7.0 Produktivsystem nur ein 7.3 Entwicklungssystem zur Verfügung steht. Eine Downtime der Produktion ist mit dieser Strategie ebenso verbunden wie eine Fallbackstrategie, die auf einem System-Restore der Produktion basiert.

Parallele Neuinstallation

In vielen Szenarien ist ein alternatives Vorgehen möglich: Eine Neuinstallation auf einer komplett neuen Systemlinie. Man gewinnt die Möglichkeit ein neues, sauberes System ohne Altlasten zu erhalten und bei der Gelegenheit auch die Serverplattform zu wechseln und zum Beispiel LINUX als Basis zu wählen.

Das Vorgehen im Überblick:

1. Neue Systemlinie installieren
2. Content Export: PCD, UME, Theme
   • Export aus dem alten P- oder E-System denkbar
3. Content Import in das neue E-System
   • Test
4. Transport in der neuen Systemlinie mit den korrekten Transportmechnismen
5. Test aller weiteren Systemstufen
6. Go Live durch Schwenken des alten auf das neue P-System
7. Abschalten der alten Systemlinie

Alle individuellen Einstellungen und Entwicklungen werden über definierte Transportwege aus der Entwicklung in die Produktion transportiert und garantieren einen neuen konsistenten Stand über die ganze Systemlinie.

Größter Nachteil ist der Aufwand, der durch den manuellen Umzug des Portalcontents entsteht. Sorgfältig ist zwischen produktiven Rollen, iViews usw. und Altlasten zu entscheiden. “Kann das weg?” ist in dieser Phase die entscheidene Frage.

Entspannt ist die Übergangsphase dann durch den Parallelbetrieb von alter und neuer Systemlinie. Ein intensiver Test des neuen P-System vor dem Go Live ist möglich und der Go Live bringt so konkret ein vergleichsweise geringeres Risiko mit sich.

Es wird einfach ohne Ausfallzeit vom alten auf das neue System umgeschwenkt, durch Umstellung im Netzwerk oder einfach durch Weiterleitung der Einstiegs-URL. Ein Fallback ist sofort durch einen Rückschwenk möglich.

Wofür man sich entscheidet ist wie immer situationsabhängig. Wenn die Rahmenbedingungen stimmen, kann die Variante einer neuen Systemlinie durchaus stressfreier und zukunftsorientierter sein.

Für die Darstellung von SAP Web Applikationen im eigenen Corporate Design werden sogenannte Themes eingesetzt. Mit ein und demselben Theme lassen sich Portaloberflächen, Web Dynpro Java und Web Dynpro ABAP Anwendungen individualisieren. “Unified Rendering” lautet das Stichwort. Für aktuelle Versionen zeigt sich aber ein Problem: Eine offizielle Unterstützung durch SAP gibt es nicht.

Für Intranet-Seiten auf Basis des SAP NetWeaver Portals gehört es schon fast zum guten Ton: Das Portallayout wird an das Firmendesign angepasst. In der Regel reichen schon die Änderung der Grundfarben und das Ersetzen der Logos und Grafiken, um dem Portal einen individuellen Anstrich zu geben.

Wenn Portalapplikation oder Web Dynpro Anwendungen im Portal eingebunden sind, dann wird standardmäßig bereits das Portal-Theme für die Darstellung gezogen. Das Theme muss dazu allerdings schon deutlich detaillierter ausgeprägt werden. Für alle verwendeten UI-Elemente wie Buttons, Tabellen usw. lassen sich individuelle Einstellungen vornehmen.

Das eigene Theme erstellen

Der Theme Editor befindet sich im Portal im Bereich Content Administration / Portalanzeige und ist mit der Rolle Content Admin erreichbar. Als Ausgangspunkt für ein neues Theme dient immer eines der von der SAP mitgelieferten Standardmotive, das dann individuell angepasst wird.

Abbildung 1: Portal-Motiveditor

Ist allerdings gar kein Portal verfügbar und soll nur um die Darstellung von Web Dynpro ABAP Anwendungen gehen, dann hält die SAP einen alternativen Editor bereit. Der Java-Eclipse-UR-Editor ist ein Plugin für die Eclipse Entwicklungsumgebung. Allerdings wurde er nur unter einer Evaluierungslizenz angeboten und wird nicht supported. Die Klarstellung dazu findet sich in der SAP Note 1613933. Für die Motive der Version 7.3 funktioniert der Editor definitiv nicht korrekt.

Im Grunde erzeugen beide Editoren das gleiche Ergebnis: Ein Paket aus CSS-Stylesheets, Grafiken und Konfigurationsdateien, die zusammen ein Unified Rendering Theme bilden. Wenn die Möglichkeiten der Theme Editoren nicht ausreichen, kann man auch direkt in den Konfigurationsdateien weitere Anpassungen vornehmen. Hier ist allerdings Vorsicht geboten. Nicht selten kommt es vor, dass eine Einstellung an der einen Stelle unvorhergesehene Auswirkungen an der andern Stelle hat.

Im System einrichten

Im Portal-Kontext ist der nächste Schritt besonders einfach: Das Theme wird im Portal-Content-Directory abgelegt und dem verwendeten Portal Desktop zugeordnet. Wenn man möchte, kann man seinen Anwendern sogar mehrere Themes zur Verfügung stellen, die innerhalb der Personalisierung ausgewählt werden können.

Wie schon erwähnt, wird das Portaltheme direkt auf Anwendungen übertragen, die über iViews eingebettet sind. Die gleiche Anwendung sieht dann unterschiedlich aus, je nachdem ob sie per iView oder direkt per Link auf den ABAP Stack gerufen wird. Über die Eigenschaft “Portal-Stylesheet bereitstellen” lässt sich dieses Verhalten übrigens auch ausschalten.

Abbildung 2: iView Eigenschaft Portal Stylesheet bereitstellen

Custom Themes für Web Dynpro ABAP ohne Portal

Sofern kein Portal mitspielt, wird das Theme im Application Server ABAP eingespielt. Dazu steht in älteren NetWeaver Versionen den Report WD_THEMES zur Verfügung. Hier lassen sich Themes exportieren und importieren, so dass eine Verwendung “standalone” für Web Dynpro ABAP möglich ist.

Um das Stylesheet bei einem Aufruf zu setzen wird der URL Parameter SAP-CSSURL verwendet:

http://<host>:<port>/sap/bc/webdynpro/sap/<application>?sap-cssurl=/sap/public/<customTheme>


Die Dokumentation sagt allerdings auch für WD_THEMES, dass dies keine offiziell unterstützte Variante ist:

Important: This report is released for internal SAP use only.


Fazit

Unter dem Strich gilt: Ein einfaches Theme für Unified Rendering zu erstellen ist kein Hexenwerk. Es ist aber nicht nötig, mehrere Themes für die verschiedenen Anwendungen und Server zu erstellen. Im Standard erfolgt der Zugriff über ein Portal mit einem gemeinsamen Theme.

Für Web Dynpro ABAP gibt es zurzeit keine offiziell unterstützte standalone Lösung. Gerüchteweise ist ein neuer HTML5 basierter Motiveditor unterwegs – dazu gibt es aber noch nichts Offizielles.

Wenn Sie an weiteren Details zum Thema Unified Rendering interessiert sind, dann lassen Sie es mich über die Kommentarfunktion wissen.

Links: https://service.sap.com/sap/support/notes/1613933

Dies ist ein Gastbeitrag von Boris Kruppa, SAP Consultant bei der mindsquare GmbH.

Bei Quellcode ist es wichtig, diesen schnell verstehen zu können. Dies ist natürlich auch in der ABAP-Welt so. Wenn man als Entwickler in ein neues Projekt kommt, ist es wichtig sich schnell einzuarbeiten. Manchmal wird dies auf eine Probe gestellt, wenn in der Vergangenheit so gut wie keine Programmierrichtlinien verwendet wurden. Hier gibt es verschiedene Bereiche, wo Verständnisschwierigkeiten auftauchen könnten. Einmal können sich Schwierigkeiten aus unvorteilhaften Strukturierung der verschiedenen Pakete ergeben und es sollten für eine gute Unterscheidung der Art von DDIC-Elementen oder Variablen im Quellcode Pre-, In- oder Suffixe verwendet werden.

Hier ist es wichtig, von vornherein grundlegende Programmierrichtlinien zu benutzen. So wird der Code im Unternehmen identisch und von jedem Entwickler schnell lesbar. Die mindsquare bietet Interessierten hier eine kompetente Lösung an. Hierzu wurden die besten Erkenntnisse aus jahrelanger Projekterfahrung zusammengetragen. Jedem unserer Mitarbeiter dient dies als Grundlage, die er so auch in Projekten einsetzen kann. Dies ist aber von Projekt zu Projekt unterschiedlich. Bei einigen gibt es leicht abweichende, bei einigen auch keine Programmierrichtlinien.

In einem meiner Projekte wurde beschlossen, bei zukünftigen Projekten die Paketstruktur anzupassen und einen Großteil der Elemente umzubenennen. Bisher waren die neueren Projekte immer eine Kopie des vorherigen Projektes. Dieses Konzept sollte nun einmal aktualisiert werden und danach weiter fortgeführt werden. Hier ergeben sich dann allerdings einige Herausforderungen. Zuerst wurde alle Bestandteile des Paketes auf nicht mehr verwendete Altlasten, wie DDIC-Elemente, Programme, Klassen etc. überprüft. Nachdem diese aussortiert waren, musste ein Großteil der DDIC-Elemente umbenannt werden, während hierbei alle Abhängigkeiten untereinander beachtet werden müssen.

So eine Umstellung ist mit manuellen Mitteln und Aufwand nicht zu bewerkstelligen. SAP bietet hierfür auch keinen Standard der in vollem Umfang DDIC-Elemente, deren Abhängigkeiten und die Paketzuordnung anpasst. Hier muss selber Hand angelegt werden und mehrere Funktionsbausteine in eine logische Reihenfolge zu bringen.

Die Abhängigkeiten der DDIC-Elemente sind vielfältig. Tabellentypen enthalten Strukturen, Strukturen enthalten wiederum Strukturen und Datenelemente, welche einer Domänen zugewiesen sind. Datenelemente werden wiederum in vielen Strukturen und Datenbanktabellen benutzt. Zudem kann noch ein Umhängen der Elemente zwecks weiterer Kapselung in neue Pakete erforderlich sein. Die folgende Abbildung verdeutlicht die Komplexität bei einer bereits kleinen Menge an Elementen.

Abbildung: Verwendung vs. Verwendungsnachweis, Abhängigkeiten der einzelnen DDIC-Elementen

Ein sinnvolles Vorgehen beim Umstellen oder Erneuern eines vorhandenen Projektes, kann somit sinnvoll in folgenden Ablauf gegliedert werden:

• Altlasten aufspüren – Kontrollieren aller vorhandener Elemente des Pakets auf noch aktive Verwendung
• DDIC-Elemente in einem Excelsheet auflisten Hier hat sich folgende Strukturierung als Vorteilhaft gezeigt:
  
• Die Auflistung der unterschiedlichen DDIC-Typen sollte in folgender Reihenfolge erfolgen:
  • Datenbanktabellen
  • Tabellentypen
  • Strukturen
  • Datenelemente
  • Domänen
• Kopieren aller DDIC-Elemente mittels Report, welcher den Excelsheet einliest
• Kontrolle der Elemente. Ob eine Stichprobe oder Gesamtkontrolle durchgeführt wird, muss jeder selber entscheiden
• Kopieren der Datenbanktabelleninhalte in die neu erstellten Datenbankkopien
• DDIC-Elemente im Code und z.B. WebDynpro-Komponenten aktualisieren

Die Erkenntnis aus meinen bisherigen Projekten ist daher eindeutig. Es ist enorm wichtig für die Übersichtlichkeit, Produktivität und Erweiterbarkeit, sich direkt zu Anfang eines Projektes konkrete Gedanken über Programmierrichtlinien, einen logischen Aufbau der Pakete und eine konstante Benennung der Elemente zu machen. Hier kann lieber mehr Zeit im Vorfeld in die Modellierung investiert werden, um später weniger Problemen gegenüber stehen zu müssen. Für diejenigen, die Programmierrichtlinien bisher noch nicht realisiert haben lohnt sich aber definitiv eine Anpassung, um auch für zukünftige Anforderungen gewappnet zu sein.

Für unsere Entwicklungsprojekte verwendet die mindsquare häufig eigene Richtlinien mit Namenskonventionen. Das Dokument stellen wir Ihnen gerne zur Verfügung – melden Sie sich einfach per XING oder hier im Kommentarbereich bei uns!

Abgemeldet und doch nicht abgemeldet? Warum der Link zum Beenden des SAP NetWeaver Portals manchmal nicht funktioniert KANN.

Im SAP Portal gibt es den Link für ABMELDEN – in der Regel ist er irgendwo oben rechts angesiedelt. Wenn man hier klickt, gelangt man auf die Anmeldeseite des Portals und kann sich erneut einloggen. Einfach nochmal neu oder mit einer anderen Kennung – Letzteres kennen vor allem die Administratoren.

Manchmal verhält sich das Abmelden nicht ganz “erwartungskonform”: Wenn man eine SSO-Lösung für die Anmeldung am Portal im Einsatz hat, funktioniert das Abmelden scheinbar nicht:

Der Anwender Klick den Link, der Browser lädt neu und er befindet sich noch immer in seinem Portal.

Gut, aus technischer Sicht wurde der Benutzer sehr wohl ordnungsgemäß abgemeldet und auf die Startseite weitergeleitet. Nur wird er eben direkt wieder neu per SSO authentifiziert und steigt mit einer neuen Session wieder ins Portal ein.

Beim Abmeldevorgang wird übrigens eine Portalkomponente namens com.sap.portal.dsm.Terminator aufgerufen, die für die systemseitigen Abmeldearbeiten zuständig ist und die man auch direkt verlinken kann, wenn man auf anderem Wege ein Logoff herbeiführen will.

Für den Anwender stellt sich das Verhalten in jedem Fall unbefriedigend dar: Das erwartete Ergebnis bleibt aus, stattdessen stellt sich ein ungutes Gefühl ein. “Kann ich jetzt den Browser einfach so zu machen?” Da ist es auch egal, dass aus Sicherheitsgründen Abmelden nicht erforderlich ist. Die leichte Verwirrung bleibt.

Abhilfe ist relativ einfach: Man ändert das Ziel der Abmeldung auf eine Dritt-Seite um, zum Beispiel die Startseite des Firmenintranets. Beim Abmelden wird dann unser DSM Terminator gerufen und parallel das neue Ziel im Browser angesprungen.

Dazu muss die URL nur in der UME-Konfiguration des Portalservers hinterlegt werden. Dazu ruft man das Identity Management auf (zum Beispiel über den Quick-Link /nwa/identity). Im Experten-Modus der Konfiguration findet sich der Parameter ume.logoff.redirect.url für die Zielseite:

Die SAP hat jetzt eine App für den Zugriff auf das SAP Help Portal im Apple AppStore veröffentlicht. Für iPad und iPhone soll dadurch der Zugriff auf die Inhalte erleichtert werden. Man kann sich durch die diversen Bereiche navigieren und der Content wird aus dem Web nachgeladen. Einzelne Kapitel kann man für die Offline-Verwendung markieren, dann wird ein Download als PDF ausgeführt.

SAP Help auf dem iPad

PDF als Download

Man kann sich jetzt also wo immer man ist der Lektüre der SAP Hilfe widmen: Im Entwicklerbüro, in der Kantine, im Fahrstuhl, beim Warten auf den Beginn des wichtigen Meetings, beim Warten auf das Ende des unwichtigen Meetings, während des Stromausfalls, beim Abendessen, unter der Dusche (vorausgesetzt, man hat so etwas) oder als Bettlektüre.

Aber mal im Ernst: Gibt es eine Situation, in der man die SAP Hilfe benötigt und nicht sowieso schon am Rechner sitzt? Ich bin nicht sicher, habe aber die App installiert und werde die nächsten Wochen ausprobieren, ob ich einen sinnvollen Einsatzzweck finde.

Was meinen Sie? Auf dem stillen Örtchen vielleicht?

Link zum AppStore: SAP Help Portal Reader

Bei der Planung einer SAP NetWeaver Portal Migration denkt man zunächst vor allem an den Upgrade des Applikationsservers. Geht es zum Beispiel von der weit verbreiteten NetWeaver Version 7.0 auf ein aktuelles Release 7.3 oder 7.4, dann gibt es dafür verschiedene Varianten, wie hier schon einmal erläutert:

SAP NetWeaver Portal 7.3 Migration – Lessons Learned Teil 1

Aber Vorsicht – nicht die eigenen Applikationen vergessen! Die selbstgeschriebenen Web Dynpro Java Anwendungen, Visual Composer und Java EE Entwicklungen laufen nicht einfach so weiter und müssen in das Migrationsprojekt mit einbezogen werden.

Die Entwicklungsumgebung

Natürlich kommt für die Java Entwicklung das SAP NetWeaver Developer Studio (NWDS) zum Einsatz. Es empfiehlt sich, hier stets die Version einzusetzen, die zum Laufzeitumgebung passt. Also für den Application Server 7.3 SP09 Patch 11 auch das NWDS 7.3 SP09 Patch 11. Bei den Hotfixes innerhalb eines Patches kann man ohne Probleme abweichen.

Das NWDS 7.3 basiert auf Eclipse 3.5 und es wird in Java 6 entwickelt. Nicht mehr ganz der neueste Schrei – aber zur Version 7.0 immerhin ein Fortschritt.

Alle Versionen zum Download findet man hier auf der Update-Site (S-User erforderlich): SAP NWDS-Update-Site

Die Migration der SAP NetWeaver Development Infrastructure (NWDI) kann man getrost als eigenes Projekt angehen und getrennt von der Portalmigration durchführen. Für den Server zur Verwaltung der Entwicklungsprojekte und Sourcen gilt die Regel der Versionsgleichheit nämlich nicht: Eine NWDI 7.0 kann Entwicklungen für alle möglichen Laufzeitumgebungen aufnehmen.

Der Grundsatz: Laufzeitkompatibilität

Für die meisten der selbstentwickelten Applikationen gilt: Die Archive aus der Version 7.0 sind weiter lauffähig. Es kommt also auf einen Versuch an, sie auf den neuen Server zu deployen und zu testen. Für die Zukunft bringt dieser Ansatz einen aber nicht wirklich weiter. Für Fehlerbehebung und Wartung und vor allem natürlich für die Weiterentwicklung müssen Sourcecode und Entwicklungsprojekte migriert werden.

Web Dynpro Java

In der internen Architektur von Web Dynpro Java Anwendungen hat sich in den Nachfolgeversionen von NetWeaver 7.0 Verschiedenes geändert. APIs wurden umstrukturiert und benutzte Softwarekomponenten geändert. Besonders eine strukturelle Änderung fällt auf: Der Interface Controller der Komponenten macht seinem Namen jetzt endlich alle Ehre. Er ist fungiert als Interfacedefinition und trägt keinen eigenen Code mehr.

Um das Entwicklungsprojekt einer Web Dynpro Anwendung aus Version 7.0 nach 7.x zu migrieren, geht man wie folgt vor:

1. Das Projekt per Filesystem oder besser über die ganze Development Configuration über die NWDI in das neue Developer Studio importieren
2. Der Import erfolgt in jedem Fall als DC-Projekt, als im SAP Komponentenmodell
3. Es wird automatisch ein Migrationsassistent gestartet, der die zwingend erforderlichen Schritte durchführt
4. Im Anschluss können kleinere manuelle Nacharbeiten erforderlich sein, wie zum Beispiel das Schlüsselwort ENUM zu ersetzen (das erst seit Java 6 eben ein Schlüsselwort ist).
5. Es kann passieren, dass die Used-DC Definitionen des neuen Projektes noch auf neue SAP Bibliotheken angepasst werden müssen, bevor das neue Projekt zum ersten Mal erfolgreich kompiliert. Das Wichtigste ist geschafft!
6. Wer sauber sein will, kann sich daran machen alle Verwendungen von deprecated API zu ersetzen. Diese werden durch Warnungen gekennzeichnet.

Schließlich besteht auch die Möglichkeit, wie oben erwähnt den Aufbau der Interface Controller auf die neue Struktur zu migrieren. Das kann manuell an jeder einzelnen Komponente durchgeführt werden. Allerdings liegt es in der Natur der Sache, dass hier nur begrenzt automatische Assistenten helfen können. Der Inhalt der Interfacecontroller muss in den Komponentencontroller umgezogen werden und die Programmlogik entsprechend manuell angepasst werden. Diesen Aufwand wird man in der Regel nicht ohne Not betreiben.

Java EE

Ganz ähnlich sieht es für Java EE aus. Die Laufzeitumgebung unterstützt sowohl Anwendungen nach dem dem J2EE 1.4 Standard, als auch nach Java EE 5.

Beim Import der Projekte in das NWDS tritt ein Migrationsassistent in Aktion. Im Nachgang kann man entscheiden, ob man den zweiten Schritt gehen will und alle Applikationen auf Version Java EE 5 bringt. Dabei geht es dann in der Regel darum, ob neue Features zum Einsatz in der Weiterentwicklung kommen sollen. Ein Beispiel: Der in der Version 7.0 verbreitete “Deployable Web Service Proxy” ist in NetWeaver 7.3 nicht mehr verfügbar. Stattdessen lassen sich Web Service Proxies ganz einfach durch Annotations in Enterprise Java Beans (EJB 3.0) implementieren.

Visual Composer

Beim Visual Composer liegt die Sache anders. Die unter Version 7.0 kompilierten Modelle sind zwar unter 7.3 noch lauffähig, die Entwicklungsumgebung wurde allerdings komplett überabreitet.

Gerade bei komplexen Modellen ist erhebliche manuelle Nacharbeit erforderlich, um diese nach dem Import im Visual Composer weiterentwickeln zu können. Das Verzwickte daran: Um die alten Modelle weiter warten zu können, braucht man weiterhin einen kompletten Application Server 7.0. Es gibt SAP Kunden, die eine Entwicklungsinstanz nur deshalb weiter betreiben, weil Visual Composer Modelle nicht auf die Version 7.3 migriert werden können.

Fazit

Im Rahmen einer Migration das SAP NetWeaver Portals muss man die selbstentwickelten Anwendungen immer mit betrachten.

Man kann aber schrittweise vorgehen und parallel zum Serverupgrade die Anwendungen soweit aktualisieren, dass sie lauffähig und wartbar sind.

Die weiteren optionalen Schritte für die Weiterentwicklung lassen sich dann aber gut separat planen und durchführen, wenn das Migrationsprojekt abgeschlossen ist.

Welche Erfahrungen haben Sie bei der Migration von Anwendungen gemacht? Wo liegen aus Ihrer Sicht die Fallstricke? Ich freue mich über Kommentare.

Dies ist ein Gastbeitrag von Sandra Lehmann, SAP Consultant bei der mindsquare GmbH.

Drag & Drop als Funktion kommt bei Benutzern immer gut an – es ist einfach, intuitiv und schnell in der Anwendung. In webbasierten SAP Applikationen ist diese Technik immer noch nicht sehr verbreitet. Eigentlich zu Unrecht, denn auch die Implementierung zum Beispiel mit Web Dynpro Java ist nicht schwer. Dieser Artikel zeigt wie es geht.
Wir haben bereits ein Projekt im SAP NetWeaver Developer Studio (NWDS), eine entsprechende Applikation sowie dazugehörige Komponenten und Kontexte.
Im ersten Schritt erstellen wir uns zwei Tabellen. Die erste wird die Quelltabelle, aus der wir die Daten in die zweite, die Zieltabelle, übergeben wollen. Dazu wählen wir aus dem Kontextmenü, des entsprechenden Gruppenelements Apply Template und fügen nach und nach die Tabellen ein und binden sie an die Kontexte.

Schritt 2: Jetzt fügen wir in unsere Quelltabelle eine DragSourceInfo ein. D.h. wir wählen aus dem Kontextmenü der Quelltabelle Insert -> DragSourceInfo aus

In der Zieltabelle wählen wir aus dem Kontextmenü Insert -> DropTargetInfo aus.

In den Eigenschaften der jeweiligen DragSourceInfo bzw. DropTargetInfo müssen wir den Tag gleich setzen. In diesem Fall heißt der Tag bei beiden “Favorites”. Dies garantiert eine eindeutige Zuordnung.

Jetzt müssen wir nur noch sagen, was eigentlich gedropped werden soll, wenn man einen Eintrag in die Zieltabelle zieht. Dazu gehen wir auf die Eigenschaften unserer Zieltabelle in der View. Unter Events wählen wir die Aktion onDrop aus. Mit create können wir eine neue Funktion erstellen.

Zeit für eine kleine Zwischenspeicherung ;-)

Mit Hilfe von Go können wir nun gleich in den Code an die richtige Stelle springen. Hier fügen wir nun all das ein, was wir aus unserer Quelltabelle in der Zieltabelle haben wollen. In diesem Fall wollen wir nur die Nummer und die Beschreibung als zusammenhängenden String haben. Dazu lesen wir zunächst den entsprechenden Eintrag aus und setzen dann den neuen für die Zieltabelle.

Nach builden und deployen sieht die Anwendung in etwa so aus:

Viel Spaß beim Selberbauen! Für Anregungen und Kritik bin ich dankbar. Falls Sie Fragen haben, dann scheuen Sie sich nicht, mir ebenfalls einen Kommentar zu hinterlassen.

Einer von vielen Blog-Artikel hat es in der SAP Community zu einiger Berühmtheit gebracht und stand am Anfang einer Diskussion, die bis zum heutigen Tag anhält: Kiss of Death for Web Dynpro Java. Auf der TechEd 2010 hatte SAP bekannt gegeben Web Dynpro Java werde nicht mehr weiterentwickelt und befände sich bis 2018 im „Maintenance Mode“.

Der Ausdruck “Panik” ist wahrscheinlich etwas übertrieben – aber die Unsicherheit über die Zukunft der eigenen Investitionen in der SAP Gemeinde war groß. Auch drei Jahre nach der offiziellen Bekanntgabe treibt das Thema immer noch die Kunden um. Erst kürzlich hörte ich in einem DSAG-Arbeitskreistreffen einen Vortrag zur neuen SAP User Experience Strategie und die erste Frage aus dem Auditorium lautete: „Wie sieht es denn mit der Zukunft von Web Dynpro Java aus?“

Über die Vorteile von Web Dynpro Java wird mit langen und detaillierten Featurelisten und Pro / Contra Vergleichen diskutiert. Viele versuchen zu zeigen, warum Web Dynpro Java immer noch eine wichtige Technologie ist und unbedingt erhalten bleiben muss. Diese Diskussion geht so aber am eigentlichen Kern vorbei und ist wahrscheinlich emotional begründet.

Ich bin überzeugt, es ist schon lange an der Zeit diese Frage einfach zu den Akten zu legen. Es gibt keinen erkennbaren Grund, jetzt bestehende Anwendungen auf der Web Dynpro Java Plattform nicht weiter zu betreiben, laufende Projekte gar zu stoppen oder bei Weiterentwicklungen aufwändige Migrationspfade einzuschlagen. Der Application Server Java ist weit davon entfernt abgekündigt zu werden, zentrale Lösungen wie das NetWeaver Portal, Process Integration und Business Process Management werden auf dieser Plattform voran getrieben. Für alles was „in der Welt ist“ gibt es kein Problem.

In fünf Jahren WOLLEN wir nicht mehr in Web Dynpro Java investieren.

Bei Entscheidungen über die langfristige Strategie, die über die nächsten fünf Jahre hinausgeht, sind das aber nicht die wichtigen Kriterien. Bei architektonischen Richtungsentscheidungen, die aktuell und auch in den nächsten Jahren getroffen werden, lässt man sich nicht vom Status Quo einer bestimmten Technik leiten, sondern von der zukünftigen Entwicklung der Anforderungen.

Mein These: In fünf Jahren WOLLEN wir gar nicht mehr im großen Stil in Web Dynpro Java investieren. Dieser Zeitpunkt wird früher kommen, als das Ende des technischen Supports und hat nichts mit Funktionsumfang oder Perspektive von Web Dynpro Java selbst zu tun. Vielmehr sind es die Alternativen, die zukünftig attraktiver und sinnvoller sind.

Schon jetzt zeigt sich der Trend: Web Dynpro ABAP für systemnahe transaktionale Applikationen, HTML5-basierte Lösungen für die client-unabhängige Zielgruppe, die iPad-Jünger, die Consumer und Manager dieser Welt.

Ob sich HTML5 im Businessbereich durchsetzen wird, ob wir jemals wieder etwas von Flash, Silverlight hören werden, wird sich zeigen. Eins ist aber sicher: Die Innovationsgeschwindigkeit am Frontend ist unheimlich hoch und wird noch schneller. Bis zum endgültigen Ende von Web Dynpro Java werden wir noch einige heiße Trends im Bereich SAP User Experience kommen und wieder gehen sehen. Die Web Dynpro Java Anwendungen laufen dann immer noch, vermutlich macht man sich aber niemand Gedanken mehr darüber. Und wenn in ferner Zukunft die letzte abgeschaltet wird, werden wir es nicht mal merken. Irgendwann geht jede selbstentwickelte Applikation diesen Weg – das Ende des Lebenszyklus kommt bestimmt und ist bei jedem Projekt auch mit eingeplant. Zum einem “Verlust von Investitionen” in Web Dynpro Java wird es aber nicht kommen, denn das würde bedeutetn Entwicklungen früher als ursprünglich geplant abschalten zu müssen.

In der UI-Strategie geht es heute um andere Fragen: Was sind heute die Anforderungen der Kunden und Anwender? Welche Endgeräte und welche Ansprüche müssen bedient werden? Wann muss man in die Entwicklung einsteigen, sich Erfahrungen in neuen Technologien verschaffen und wann sind sie reif für die ganz großen Projekte?

Am Schluss interessiert mich Ihre Meining: Wie handhaben Sie die Weiterentwicklung Ihrer Web Dynpro Java Anwendungen? Wo sehen Sie heute die Stärken und wo fällt die Technologie nach Ihrer Meinung hinter die aktuellen Alternativen zurück?

The post Wann ist Web Dynpro Java denn jetzt endlich tot? appeared first on Erlebe Software - Das SAP UX Blog.

BOPF ist ein modernes Framework mit dem Anwendungen auf dem ABAP-Stack entwickelt werden können. Ich habe es hier schon vorgestellt.

Ein Delegated Object (DO) in BOPF ist eine elegante Möglichkeit, identische Funktionalität an mehreren Geschäftsobjekten zu haben, ohne sie redundant modellieren und entwickeln zu müssen. Der Zugriff auf den Inhalt eines DO über ABAP-Code ist allerdings nicht ganz so offensichtlich. ABAP Kurz-Dumps wie /BOBF/CX_FRW_FATAL sind die Folge, wenn man das scheinbar naheliegenste Vorgehen wählt. In diesem Beitrag möchte ich anhand eines kleinen Beispiels erläutern, wie der Zugriff von statten geht.

Exkurs: Delegation Konzept in BOPF

Bei der Delegation in BOPF werden Teile des Modells und der Funktionalität an ein separates Geschäftsobjekt, ein Delegated Object, delegiert. Dieses Geschäftsobjekt kann dann in zahlreiche andere Geschäftsobjekte eingebunden werden:

BOPF verfolgt dabei einen “Black Box”- Ansatz. Das bedeutet, dass zur Designzeit das Host-Objekt nicht die Struktur des Delegated Object kennt und entsprechend in der Modellierungsumgebung auch nicht angezeigt wird. Erst zur Laufzeit werden die Komponenten des Delegated Object in die Struktur des Host-Objekts eingegliedert und verschmelzen somit zu einem Objekt.

Mit BOPF werden direkt ein paar Delegated Objects ausgeliefert, die direkt in die eigenen Geschäftsobjekte integriert und benutzt werden können: Adresse, Textsammlung, Attachment Folder, Geschäftspartner, Change Dokument.

Vorbereitung: Das Beispiel BO

Zur Demonstration der Lösung habe ich mir ein kleines Geschäftsobjekt gebaut:

Dieses Personen-Geschäftsobjekt besteht lediglich aus einem Root-Knoten unter dem das DO Text-Collection eingebunden ist. In einer Determination auf Root-Ebene möchte ich nun ein paar Daten aus dem Delegated Object auslesen und in transiente Felder des Personen Root-Knoten schreiben.

Die Lösung: Zugriff auf das Delegated Object

Ein Delegated Object ist im Endeffekt nur ein anderes Geschäftsobjekt. Viele BOPF-Entwickler wissen, dass ein BO-übergreifender Zugriff (BO A möchte auf Daten von BO B zugreifen) nur über den Service Manager stattfinden kann. Daher ist ein häufiger erster Ansatz den Service Manager für das Delegated Object zu erzeugen. Allerdings lässt das Framework diese Instanziierung aus gutem Grund nicht zu und geht zur Laufzeit mit einem Kurz-Dump auf die Bretter.

Zur Laufzeit ist der Inhalt des Delegated Objects vollständig in die Struktur des Host-Objekts integriert und dementsprechend erfolgt der Zugriff auf den Inhalt über den Service Manager des Host-Objekts; der Zugriff über io_modify und io_read im Host-Objekt ist allerdings auch möglich. Ein Beispiel für einen solchen Zugriff ist im folgenden Code-Ausschnitt dargestellt:

Aber auch bei diesem Ansatz wird die Anwendung zur Laufzeit mit einem Kurz-Dump abbrechen. Zur Laufzeit werden auf Basis des Delegated Objects neue Knoten, Assoziationen, etc. im Host-Objekt erzeugt. Dadurch besitzen diese Elemente einen anderen technischen Schlüssel, als im Konstanten-Interface des DOs angegeben. Die Lösung für dieses Dilemma: Es muss ein Key-Mapping durchgeführt werden. Der Ablauf ist im folgenden Code-Ausschnitt dargestellt:

Zuerst holen wir uns das Konfigurations-Objekt des Host-Geschäftsobjekts. Dieses bietet eine Methode für das Content-Key-Mapping an. Dort wird eine Content-Kategorie angegeben, also ob wir den technischen Schlüssel eines Knoten, einer Assoziation oder Aktion konvertieren wollen. Des Weiteren geben wir den Schlüssel des zu konvertierenden Modellelements und den Wurzelknoten des Delegated Objects an. Zur Veranschaulichung ein Screenshot:

Wenn man diesen kleinen Schritt bedacht hat, ist es problemlos möglich, vom Hostobjekt aus auf Inhalte des Delegated Objects zuzugreifen. Arbeitet man allerdings intensiv mit Delegated Objects und greift häufig auf verschiedene Inhalte dieser zu, empfiehlt es sich, sich generische Helper-Klassen zu schreiben, die diese Konvertierung übernehmen.

Hat Ihnen dieser Beitrag beim Umgang mit Delegated Objects geholfen? Oder haben sie noch weitere Fragen zu dem Thema, die ich in diesem Beitrag nicht beantwortet habe? Ich freue mich über ihre Kommentare.

The post Zugriff auf ein Delegated Object im BOPF appeared first on Erlebe Software - Das SAP UX Blog.

Ein neues Projekt steht in den Startlöchern und die Anforderungen an die Geschäftsprozesse sind bereits weitestgehend definiert. Mit welcher der zahlreichen SAP UI Technologien diese Geschäftsprozesse dann am Ende visualisiert werden sollen ist häufig während der Konzeptionsphase noch nicht klar.

Dieses Whitepaper erklärt warum ein Prototyp im System sinnvoll ist und zeigt am Beispiel des SAP Floorplan Managers, wie ein solcher Prototyp innerhalb kürzester Zeit entwickelt werden kann damit dem internen Fachbereich das UI vorgestellt werden kann.

Download

The post Rapid Prototyping mit dem SAP Floorplan Manager appeared first on Erlebe Software - Das SAP UX Blog.

SAP Projekte mit ABAP und Web Dynpro sind Ihr tägliches Brot? Sicherlich haben Sie dann von der neuen SAP User Experience Strategie gehört.

Stellen Sie sich nun auch die Frage, was die Fokussierung auf Web Dynpro und SAP UI5 für Ihre eigene Strategie und ihre Projekte bedeutet? Oder fragen Sie sich, wie das Portal, der NetWeaver Business Client, HTML5, Fiori und alle anderen SAP UI-Technologien in Zukunft zusammenspielen werden?

Möchten Sie Strategien und Lösungen kennenlernen und über Ihre individuelle Herausforderung mit einem erfahrenen Senior Berater sprechen?

Dann lade ich Sie herzlich ein, an unserem Thementag “SAP User Experience Strategie” am 26.09.2013 in Berlin teilzunehmen. Sie können an diesem Tag eine persönliche Beraterstunde reservieren, in der ich gerne Ihre individuellen Fragestellungen mit Ihnen bespreche. Zusätzlich begrüßen mein Kollege Aiko Schmale und ich Sie zu zwei Fachvorträgen zum Thema. Die Teilnahme am Infotag und an den Beraterstunden ist kostenlos.

Sie möchten sich anmelden? Dann senden Sie mir einfach eine kurze E-Mail an biermann@erlebe-software.de. Sie möchten eine Beraterstunde buchen? Bitte lassen Sie mich wissen, welcher Termin-Slot (siehe Agenda unten) Ihnen zeitlich am besten passt.

Agenda

ab 11:00 Uhr: Meet the Expert – Beratersprechstunde mit Ingo Biermann (Slot 1-3)
11:00 – 11:45 Uhr: Slot 1
11:45 – 12:30 Uhr: Slot 2
12:30 – 13:15 Uhr: Slot 3

13:30 – 14:30 Uhr: Vortrag Ingo Biermann
„Die neue SAP User Experience Strategie – Was bedeutet sie für mein Portal, meine Applikationen, meine Projekte?“

15:00 – 16:30 Uhr: Vortrag Aiko Schmale
„Floorplanmanager Rapid Prototyping Demo Jam“

ab 14:45 Uhr : Meet the Expert – Beratersprechstunde bei Ingo Biermann (Slot 4-6)
14:45 – 15:30 Uhr: Slot 4
15:30 – 16:15 Uhr: Slot 5
16:15 – 17:00 Uhr: Slot 6

Darum geht’s in den Vorträgen:

Vortrag Ingo Biermann: „Die neue SAP User Experience Strategie – Was bedeutet sie für mein Portal, meine Applikationen, meine Projekte?“

• Was sind die Kernaussagen der SAP UX Strategie?
• Was ändert die SAP in ihren eigenen Produkten?
• Womit soll ich meine nächste Entwicklung machen?
• Ist Web Dynpro tot? Lebt SAP UI5 überhaupt schon?
• Welche Skills brauchen meine Entwickler in der Zukunft?

Vortrag Aiko Schmale: „Floorplanmanager Rapid Prototyping Demo Jam“

• Live und in Farbe: Erleben Sie, wie ein Prototyp mit dem SAP Floorplanmanager in wenigen Minuten lauffähig wird.

Ich freue mich darauf, Sie kennen zu lernen. 

Mehr zur SAP User Expperience Strategie finden Sie hier auf experience.sap.com: SAP’s UX Strategy

The post Thementag SAP User Experience Strategie: Vorträge und individuelle Beratung  appeared first on Erlebe Software - Das SAP UX Blog.