Berechtigungen: Orgebenen für SAP EWM

Es sieht so aus, als hätten die Entwickler von SAP bei der Definition des Rollenkonzepts zwei Orgwerte vergessen. Ich empfehle, die folgenden beiden Berechtigungswerte im SAP EWM zu Orgebenen zu machen:

/SCWM/ORG und APO_LOC

Das geht über den Report PFCG_ORGFIELD_CREATE

Als Resultat sind in allen abhängigen Rollen die Werte über die Orgfelder in den Rollen pflegbar und eine Ableitung wird möglich.

Auswirkungen von SAP Hinweis 2399477

Mit dem SAP Hinweis 2399477 und den verwandten Hinweisen bringt die SAP Änderungen am ITS handler CL_HTTP_EXT_ITS in Umlauf. Diese Änderungen bewirken aber auch eine Korrelation des Parameters sap-theme am URI mit dem ~theme Parameter, den man aus der ITS Welt kennt. Wenn man nun aber ein IAC Service im Portal integriert oder aber auch einen direkten Link zur IAC im Format /…/IAC?sap-theme=xxx verwendet, dann wird der gute alte ~theme Wert für die IAC von dem XXX übersteuert. Wenn man also kein Thema XXX in der IAC hat, dann bekommt man einen RABAX, ganz egal, ob man z.B. ~theme=99 in der Konfiguration des IAC Service hinterlegt hat.

Mein Workaround: ~sap-theme einfach nicht mehr verwenden im Aufruf, auch wenn es kleinere Auswirkungen in der Formatierung beim Aufruf aus dem Portal hat.

Das Biest bezwingen – Performance aus dem Z-GPRS3 von Seneca rausholen

Das Z-GPRS3, ausgeliefert von der italienischen Firma Seneca, ist ein technisch aktuelles Anzeige- und Kontrollgerät für Messwerte aller Art. Es besitzt die Möglichkeit, die Werte über ein GPRS Interface zu übertragen und in Reports anzuzeigen. Dieses Reporting basiert auf moderner Technologie und kann daher das Berichtsfenster aktualisieren, ohne dass die gesamte Webseite im Browser neu aufgebaut werden müsste. Die Technologie dahinter wird in einer Bibliothek namens jQuery gekapselt.

Wenn man sich nun die Berichte über das Internet ansieht, sieht man eine sehr lange initiale Ladezeit. Wir reden hier von bis zu drei Minuten. Nach dieser Zeit werden die Berichte ganz normal und ohne weiteres Warten dargestellt.

Aus diesen Beobachtungen heraus haben wir einen Mitschnitt der Browserkommunikation mittels der Entwicklerwerkzeuge durchgeführt. Wie man am Screenshot deutlich sehen kann werden drei große Dateien geladen bevor die einzelnen Messwerte in kleinen Datenpaketen nachgeladen werden. Diese drei Dateien verzögern also die gesamte Antwortzeit des Systems.

Im ersten Versuch einer Optimierung sind wir an der „same origin policy“ gescheitert, welche besagt, dass die Anfragen immer zum gleichen Server zurück gehen müssen, von welchem auch jQuery geladen wurde.

Was sollten wir nun machen? Eine Option wäre, die Verbindung des Seneca Geräts über LTE abzuwickeln. Durch die zusätzlich benötigte Hardware ist dies aber für die aktuelle Installation in einem solarbetriebenen, autonomen Umfeld eher ungeeignet.

Die andere Art, die Aufgabenstellung zu lösen ist es, das Seneca Gerät über einen Zwischenserver zu verbinden, welcher das Laden von verschiedenen Quellen überwachen kann. Wir haben uns in diesem Zusammenhang für den Apache Webserver entschieden, welchen wir im „reverse proxy“ Modus betreiben. In diesem Modus werden alle Anfragen von den Clients über diesen Webserver an das Seneca Gerät weitergeleitet. Bis zu diesem Teil hat sich die bisherige Funktionsweise und auch die Architektur kaum geändert. Durch den zwischengeschalteten Server wird es aber möglich, für Zugriffe auf spezifische Adressen das Ladeverhalten zu beeinflussen.

Wir haben also die zuvor ermittelten Dateien in ein öffentlich zugreifbares Verzeichnis auf dem gleichen (wichtig!) Server kopiert. Dann haben wir den Apache Webserver so konfiguriert, dass bei Zugriffen auf diese Dateien eine Umleitung auf das Verzeichnis am Webserver (und nicht auf dem Seneca Gerät) erfolgt.

Wenn man das so macht, gehen die Zugriffe auf diese großen Dateien nicht bis auf das Seneca Gerät zurück, aber die Anfragen für die einzelnen Messwerte werden sehr wohl bis auf das GPRS Gerät umgeleitet.

Fröhliches Messen!

Know How: SAP Manager Self Service and Launchpad

Problem

Managerial reports in SAP Manager Self Service can only be properly displayed within the Manager Self Service Launchpad. Calling the reports directly does not provide a feasible solution as the manager can then see all the employees in the value help while he or she should just see the subordinates. Preferable would be a design like in Employee Self Service, where you can use the SAP Homepage Framework.

Solution

In a PoC, I have used the homepage framework to launch several instances of the Launchpad, grouped by Homepage Framework Areas. Even though SAP says you can have only one launchpad there are ways to achieve multiple instances. So the new flow is: Enter MSS though Homepage Framework (same customizing as in SAP ESS), provide some areas with links to portal pages carrying different launchpads (pass different „scenario“ keys within the iViews) and start the reports from there.
For the solution, there is no modification necessary, just a domain append to the MSS scenario datatype. Give it a try, MSS will be much prettier that way. And still SAP standard.