Suche
  • Ihr Partner für IT-Aufgaben
  • info@korkisch.eu • +49 (0) 7151 944 54 90
Suche Menü

NWBC Cockpit anlegen

Möchte man beim Aufruf des NWBC (HTML Version) eine zentrale Aufruf-URL verwenden, die sowohl die ESS als auch die MSS-Rolle beinhaltet, kann dies mit einem NWBC Cockpit realisiert werden. Dabei wird die Rolle MSS nur den Usern im NWBC angezeigt die auch die Rolle entsprechend im Backend zugeordnet haben.

Zunächst legt man in der Transaktion SICF einen neuen Service unterhalb des NWBC-Knotens an (/sap/bc/nwbc/).

SICF - SICF Knoten anlegen

SICF – SICF Knoten anlegen

SICF - Neuen Knoten anlegen

SICF – Neuen Knoten anlegen

In unserem Beispiel soll das Cockpit später ZHR_ESS heißen, darum legen wir einen SICF-Service mit genau diesem Namen an.

SICF - Knoten benennen

SICF – Knoten benennen

Wichtig ist, dass der neue Service im Tabreiter „Handler-Liste“ den Eintrag mit dem Handler CL_NWBC_HTTP erhält. Nachdem alle nötigen Daten eingetragen wurden, speichern wir den Service und aktivieren ihn.

SICF - Handler angeben

SICF – Handler angeben

 

SICF - Knoten aktivieren

SICF – Knoten aktivieren

Nachdem wir den SICF-Knoten angelegt haben, passen wir die entsprechenden Rollen über die Transaktion PFCG an. In unserem Beispiel soll sowohl die ESS als auch eine MSS Rolle dem Cockpit zugeordnet werden.

Über den Button „Menüoptionen“ haben wir nun im Popupdialog die Möglichkeit einen Cockpitfilter anzugeben. Als Cockpitname müssen wir hier den selben Namen angeben unter dem wir den SICF-Knoten angelegt haben.

PFCG - Cockpit Zuordnung pflegen

PFCG – Cockpit Zuordnung pflegen

PFCG - Cockpit Daten pflegen

PFCG – Cockpit Daten pflegen

Diese Aktion wiederholen wir nun für alle Rollen die Teil des Cockpits sein sollen. Die Voraussetzung, dass ein Benutzer auch die Inhalte einer Rolle angezeigt bekommt ist eine entsprechende Rollenzuordnung. Das heißt aber auch im Umkehrschluss folgendes für unser ESS Cockpit. Ruft ein Mitarbeiter mit ESS-Rollenzuordnung das Cockpit ZHR_ESS auf, erhält dieser auch nur die ESS-Inhalte gemäß der ESS-Rolle. Erfolgt der Aufruf des Cockpits durch eine Führungskraft mit zusätzlicher MSS-Rollenzuordnung erhält dieser auch die MSS-Inhalte angeboten.

Die Cockpit-Url würde dann so aussehen: http://sapXXXX.<subdomain>.<domain>.<tld>:8001/sap/bc/nwbc/ZHR_ESS/?sap-client=<clnt>&sap-language=DE

 

 

 

 

 

 

 

 

Shared Objects Memory als Datenpuffer (Teil 2)

Um das Shared Objects Memory (SOM) zu nutzen benötigen wir zunächst eine Wurzelklasse. Diese Wurzelklasse beschreibt die Instanzobjekte, welche später im SOM abegelegt werden. Die Wurzelklasse muss Shared-Memory-fähig sein. Dazu muss in den Eigenschaften der Klasse das entsprechende Häkchen gesetzt werden. Diese Klasse kann weitere Referenzen auf andere Objekte halten, welche widerrum Shared-Memory-fähig sein muss.

Die Verwaltung der im SOM abgelegten Daten erfolgt über sogenannte Gebiete. Jedes Gebiet ist mit einer Wurzelklasse verknüpft. Gebiete werden über die Transaktion SHMA angelegt bzw. bearbeitet. Über das Gebiet werden verschiedene Einstellungen unter anderem zum Laufzeitverhalten des SOM Gebiets definiert. Beim Anlegen eines Gebiets wird automatisch eine Klasse mit dem Namen des Gebiets generiert, die sogenannte Gebietsklasse. Diese Klasse erbt von Klasse CL_SHM_AREA.

Zudem kann ein Gebiet eine Kunstruktorklasse besitzen, diese Klasse implementiert das Interface IF_SHM_BUILD_INSTANCE und dient u.a. zum Aufbau der Gebietsinstanzen. Außerdem kann diese Klasse dazu genutzt werden beim erstmaligen Aufruf alle benötigten Daten zu ermitteln und zu berechnen. Soll dies automatisch geschehen, muss in den Einstellungen zum Gebiet die Option „Automatischer Aufbau“ gesetzt sein.

Anlegen eines Gebiets

Transaktion SHMA, als Name des Gebiets wählen wir ZCL_SFLIGHT_AREA. Der Präfix ZCL ist empfehlenswert da im Hintergrund die Gebietsklasse mit selbigen Namen generiert wird.
Transaktion SHMANach einem Klick auf „Anlegen“ müssen verschiedene Angaben zum Gebiet gemacht werden. Ein Pflichtfeld ist die Angabe der Wurzelklasse des Gebiets.

Transaktion SHMA, Eigenschaften

Anlegen der Wurzelklasse

Die Wurzelklasse kann per Vorwärtsnavigation angelegt werden. Dazu tragen wir den Namen der Klasse in das Feld Wurzelklasse im Bereich Grundeigenschaften ein.

SHMA Grundeinstellungen, WurzelklasseNach der Bestätigung unserer Eingabe mit „Enter“ werden wir gefragt, ob wir die Klasse anlegen wollen.

SHMA, Wurzeldatenklasse anlegenSHMA Wurzeldatenklasse anlegen 2

Nachdem die Klasse angelegt wurde, muss sie in den Eigenschaften als Shared-Memory-fähig markiert werden.

SOM WurzelklasseZur Veranschaulichung implementieren wir 2 Methoden und definieren eine Attribut als Tabelle, welche die gelesenen Daten hält.

Wurzelklasse WurzelklasseWurzelklasse

Methode SET_SFLIGHT

liest die Daten von der Datenbank und legt sie im Attribut OTO_SFLIGHT ab.

METHOD set_sflight.
  CLEAR oto_sflight[].
  SELECT * FROM sflight INTO CORRESPONDING FIELDS OF TABLE me->oto_sflight[].
ENDMETHOD.

Methode GET_SFLIGHT_BY_ID

liefert zur ID der Fluglinie alle Einträge aus der Tabelle OTO_SFLIGHT.

METHOD get_sflight_by_id.
  FIELD-SYMBOLS: <line> TYPE sflight.

  CLEAR et_sflight[].

  LOOP AT me->oto_sflight[] ASSIGNING <line>
    WHERE carrid EQ iv_carrid.

    APPEND <line> TO et_sflight[].

  ENDLOOP.

ENDMETHOD.

Nach dme Aktivieren der Klasse ZCL_SFLIGHT_AREA_ROOT kehren wir mit F3 zurück in die Transaktion SHMA. Dort werden wir nun aufgefordert die Konstruktorklasse anzulegen.

Anlegen der Konstruktorklasse

Dynamische EinstellungenDa wir unter Grundeigenschaften die Option „Automatischer Aufbau“ aktiviert haben, müssen wir die Konstruktorklasse benennen. Als Namen geben wir ZCL_SFLIGHT_AREA_LOAD an und bestätigen mit „Enter“. Da hier kein Anlegen per Vorwärtsnavigation möglich ist, öffnen wir einen weiteren Modus und starten die Transaktion SE24 (bzw. SE80). Dort legen wir die Klasse ZCL_SFLIGHT_AREA_LOAD an und implementieren das Interface IF_SHM_BUILD_INSTANCE.

KonstruktorklasseDie Methode BUILD muss implementiert werden.

METHOD if_shm_build_instance~build.

  DATA: lo_sflight_area TYPE REF TO zcl_sflight_area,
        lo_sflight_root TYPE REF TO zcl_sflight_area_root,
        lx_root_exception TYPE REF TO cx_root.


  TRY.
      lo_sflight_area = zcl_sflight_area=>attach_for_write( ).

      CREATE OBJECT lo_sflight_root AREA HANDLE lo_sflight_area.

      lo_sflight_area->set_root( lo_sflight_root ).

      lo_sflight_root->set_sflight( ).

      lo_sflight_area->detach_commit( ).

    CATCH cx_shm_error INTO lx_root_exception.
      RAISE EXCEPTION TYPE cx_shm_build_failed
        EXPORTING
          previous = lx_root_exception.
  ENDTRY.

ENDMETHOD.

Beim Aktivieren der Klasse tritt der Fehler auf, dass die Gebietsklasse noch nicht vorhanden ist. Dies liegt daran, dass wir das Gebiet und somit die Gebietsklasse in Transaktion SHMA noch nicht gespeichert haben. Entweder wir wählen beim Aktivieren die Option „Dennoch Aktivieren“ oder wir speichern das Gebiet nachdem wir die Option „Automatischer Aufbau“ herausgenommen und das Feld Konstruktorklasse gelöscht haben. Danach können wir die Konstruktorklasse aktivieren. Nach der Aktivierung müssen wir dann die Option „Automatischer Aufbau“ wieder setzen und können nun die Konstruktorklasse im entsprechendne Feld hinterlegen.

Da wir die Option „Automatischer Aufbau“ gewählt haben müssen wir im Bereich Laufzeiteinstellung die Option Gebietsaufbau entweder auf „Autostart bei Leseanfrage“ oder „Autostart bei Leseanfrage und jeder Invalidierung“ setzen. Ich empfehle die letztere Option, damit ist gewährleistet, dass auch nach einer Invalidierung der Gebietsinstanz eine automatische Erzeugung aller Instanzen und Daten ausgelöst wird.

Aufruf des Shared Objects

Der Zugriff auf das Shared Objects Memory und speziell auf das angelegte Gebiet ZCL_SFLIGHT_AREA könnte wie folgt aussehen. Dazu legen wir ein kleines Testprogramm an.

*&---------------------------------------------------------------------*
*& Report  ZTEST_SFLIGHT_AREA
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*

REPORT  ztest_sflight_area.
DATA: lo_sflight_area TYPE REF TO zcl_sflight_area,
      lt_sflight TYPE sflight_tab1,
      ls_sflight TYPE sflight.
TRY.
    lo_sflight_area = zcl_sflight_area=>attach_for_read( ).
    lo_sflight_area->root->get_sflight_by_id( EXPORTING iv_carrid = 'AA'
                                              IMPORTING et_sflight = lt_sflight ).
    lo_sflight_area->detach( ).
  CATCH cx_shm_attach_error.
* should do something
ENDTRY.

CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'
  EXPORTING
    i_structure_name = 'SFLIGHT'
  TABLES
    t_outtab         = lt_sflight
  EXCEPTIONS
    program_error    = 1
    OTHERS           = 2.
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.

 

Weitere Informationen

Im SAP Community Network findet man einige nützliche Informationen und Tutorials wie das Shared Objects Memory genutzt werden kann.

Shared Objects Memory als Datenpuffer (Teil 1)

SHM_Gebiete

In größeren Entwicklungsprojekten kommt man an eine Stelle an der die Pufferung von Daten eine Rolle spielt. Vor allem wenn es um die Bereitstellung von Stammdaten geht. Hier läßt sich mit Hilfe der Zwischenspeicherung von Daten die ein oder andere (Milli-)Sekunde an Geschwindigkeit herausholen.

In den letzten Jahren meiner Tätigkeit als Entwickler für ABAP Programme wurde ich immer wieder mit einer Aufgabenstellung konfrontiert: „Lese Daten von der Datenbank und stelle Sie für die Weiterverarbeitung und Darstellung im UI in einer bestimmten Struktur zu Verfügung“. Gerade im Bereich von Stammdaten, also Daten welche sich nur selten ändern macht sich der Gedanke nach einem performanten Zugriff breit.

Natürlich wird man immer dort ersteinmal auf Membervariablen zurückgreifen und auf statische Klassen bauen, welche die Daten einmal lesen und dann im Speicher halten. Aber dieser Ansatz ist nur dann wirklich zielführend wenn sich auch die Session über eine längere Periode des Lebenszyklus einer Anwendung hält.

Aber gerade im Bereich von Schnittstellen unterliegt man oft der Request-Response Zyklen, welche in ihrer Natur ertstmal nicht ’stateful‘ sind, also eine Session über meherer Requests nicht halten. Ähnlich verhält es sich, wenn mehere User auf gleiche Stammdaten zurückgreifen, auch hier würde man für jede Benutzersitzung immer und immer wieder gleiche Daten von der Datenbank lesen. Bei vielen Datenbankzugriffen, welche die Antwortzeiten einer Anwendung nach oben treiben. Gemeinsamer Zugriff aus unterschiedlichen Sessions auf dieselben Daten. Genau an dieser Stelle bietet sich der Einsatz des Shared Objects Memory an. Das Shared Objects Memory ist nicht gerade neu, auch nicht im SAP ABAP Umfeld. In weiteren Beiträgen möchte ich das Shared Memory und im besonderen das Shared Objects Memory an einem praktischen Beispiel vorstellen.

→ Shared Objects Memory als Datenpuffer (Teil 2)

kundenindividuelle Lösung zur Zeiterfassung am PC

Für die Harmonisierung seines Zeitwirtschaftssystems suchte unser Kunde nach einer Lösung. Dabei sollte vor allem die Erfassung der Arbeitszeiten durch die Mitarbeiter vereinheitlicht werden. Im Unternehmen waren verschiedene Zeiterfassungssysteme, vom Papierprozess bis hin zu Terminallösungen im Einsatz. Ebenfalls wurden unterschiedliche Systeme zur Zeitauswertung und Verarbeitung eingesetzt. Als weiteres Ziel sollte das Zeitwirtschaftssystem durchgängig im SAP Standard abgebildet werden.

Im ersten Schritt suchten wir zusammen mit unserem Kunden und Partnern eine Erfassungsoberfläche. Im Auswahlverfahren konnten wir eine Lösung finden die allen Ansprüchen gerecht wurde. Zur Erfassung von Zeitbuchungen sollte eine auf Windows lauffähige Anwendung geschaffen werden. Das Zeitwirtschaftssystem ist ein SAP ERP ECC 5.0 System. Eine Lösung über eine Webanwendung kommt nicht in Frage, da sich in der verfügbaren Systemversion lediglich BSP (Business Server Pages) als Webtechnologie nutzen lies. Langfristig möchte der Kunde allerdings auf einem aktuellen Release die Standard Self-Services der SAP nutzen. Aus diesem Grund wurde kein Lösungsweg mithilfe von BSP verfolgt. Die Entscheidung fiel auf eine native Windowsanwendung als Erfassungsoberfläche, welche sich rollenbasiert in der bestehenden Citrix-Umgebung verteilen lässt. Damit sollten die Punkte Performanceprobleme und Authentifizierungsschwierigkeiten keine Rolle spielen. Vielmehr noch, es war davon auszugehen, dass damit größere Schulungsmaßnahmen auf Grund der vertrauten Oberfläche entfallen.

Im zweiten Schritt musste eine Architektur gefunden werden, um die Windowsanwendung mit dem Zeitwirtschaftssystem zu verbinden. Mit unserem Kunden und Partnern entwickelten wir zusammen eine Architektur für das aktuelle Zeitwirtschaftssystems. Die Lösung sah vor, den Zugriff mittels Webservice über die bestehende SAP PI (Process Integration) Landschaft zu gewährleisten. Damit konnte auf die Funktionen des SAP HCM Systems zugegriffen werden. Im Zeitwirtschaftssystem mussten nun alle Funktionen für die Schnittstelle zur Zeiterfassung gekapselt werden. Dafür wurden auf Basis der Standardfunktionalitäten verschiedene Klassen und Funktionsbausteine erstellt. Diese Schnittstelle bedient die drei Funktionen: Anzeige der gebuchten Zeiten eines Mitarbeiters, dessen Salden und die Verarbeitung neuer Zeitbuchungen.
Mehrere Massentests bestätigte die Performance der Architektur. Im Test wurde mehrere hundert konkurrierende Zugriffe simuliert, eine merkbare Verschlechterung der Reaktionszeit bei der Datenerfassung konnte nicht festgestellt werden. Auch auf den PI Systemen waren keine kritischen Werte messbar. Selbst die Verbuchung der im Zeitwirtschaftssystem eingegangenen Testdaten lief ohne Zeitverzögerung. Damit war für alle Verantwortlichen klar, dass auch später im Produktivbetrieb mit ca. 15000 aktiven Benutzern keine Einschränkungen zu erwarten waren. Ziel war es, dass alle Mitarbeiter täglich ihre Kommen- und Gehenzeiten erfassen können.

Für die Produktivsetzung wurde auf ein stufenweises Vorgehen gesetzt. In der ersten Stufe wurde ein kleiner Anwenderkreis mit der Erfassungsanwendung im Rahmen des Pilotbetriebs ausgestattet. In weiteren Stufen wurden zeitlich versetzt weitere regionale Einheiten mit dem neuen Zeiterfassungssytem ausgestattet.

Die Lösung brachte folgende Vorteile mit sich:

• Vereinheitlichung der unternehmensweiten Zeiterfassung
• Entlastung der Zeitbeauftragten im operativen Geschäft
• Kostenoptimierung und Fehlerreduktion durch Wegfall von Papierprozessen
• Erhöhung der Transparenz für Mitarbeiter und Führungskräfte