Floorplan Manager (ABAP): Unterschied zwischen den Versionen

Aus MattWiki
(Die Seite wurde neu angelegt: „== Relevante Klassen == Alle Feeder-Interfaces beinhalten das Interface IF_FPM_GUIBB, das die beiden Methoden INITIALIZE und GET_PARAMETER_LIST umfasst. Beide…“)
 
 
(32 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
Dieser Artikel behandelt grundlegende Informationen über Floorplan Manager Anwendungen.
Codebeispiele für die Implementierungen der notwendigen Klassen und Methoden finden sich hier: [[Floorplan_Manager_Codebeispiele_(ABAP)]]
== Relevante Klassen ==
== Relevante Klassen ==


Zeile 5: Zeile 9:
=== Übersicht Feeder-Klassen ===
=== Übersicht Feeder-Klassen ===


Methoden mit lediglich unterschiedlicher Signatur:
Feeder-Klassen bilden die Schnittstelle zwischen der Anwendungslogik und den GUIBB zur Darstellung derUI-Informationen innerhalb der Floorplan-Manager-Anwendung.
 
Jeder GUIBB benötigt für die Bereitschellung von Daten eine Feeder-Klasse.
 
Alle Feeder-Interfaces beinhalten das Interface IF_FPM_GUIBB, das die beiden Methoden GET_PARAMETER_LIST und INITIALIZE umfasst. Beide Methoden werden nur während der Initialisierungsphase des GUIBBs aufgerufen.
 
  GET_PARAMETER_LIST: Eigene Konfigurationsparameter verarbeiten ( z.B. read only )
 
  INITIALIZE: Wird nach GET_PARAMETER_LIST aufgerufen. Nutzung z.B. zum Laden von Anwendungsobjekten (von der DB) / Sperren setzen etc.
 
 
Methoden mit lediglich unterschiedlicher Signatur:
 
  CHECK_CONFIG
  CHECK_CONFIG
     i.d.R. irrelevant
     i.d.R. irrelevant
Zeile 11: Zeile 27:
     i.d.R. irrelevant
     i.d.R. irrelevant
  GET_DEFINITION
  GET_DEFINITION
    Wird nach INITIALIZE aufgerufen
     Bestimmt Aufbau Baustein (z.B. welche Eingabefelder hat das Form )  
     Bestimmt Aufbau Baustein (z.B. welche Eingabefelder hat das Form )  
  GET_DATA
  GET_DATA
     Bestimmt Inhalt der Oberfläche ( z.B. Text in Textfeld eines Forms )
     Bestimmt Inhalt der Oberfläche ( z.B. Text in Textfeld eines Forms )
PROCESS_EVENT
    Verarbeitung von Benutzereingabe (z.B. Suchknopf wurde gedrückt)
    ( evtl. auch Ereignisse von anderen FPM Komponenten z.B. Refresh)
FLUSH
    Benutzereingaben von der Oberfläche in die Anwendung                    übernehmen
Standard-Interface IF_FPM_GUIBB
=== Feederklassen Programmstart ===
# GET_PARAMETER_LIST: Eigene Konfigurationsparameter verarbeiten ( z.B. read only )
# INITIALIZE: Wird nach GET_PARAMETER_LIST aufgerufen. Nutzung z.B. zum Laden von Anwendungsobjekten (von der DB) / Sperren setzen etc.
=== Feederklassen Programmablauf / Event-Loop ===
# FLUSH -> Daten von Oberfläche an Anwendung übertragen
# PROCESS_EVENT -> Besondere Ereignisse ( z.B. Knopfdruck ) verarbeiten
# GET_DATA -> Oberfläche mit aktuellen Daten aus Anwendung versorgen; Entspricht PROCESS_BEFORE_OUTPUT
=== Event-Loop mit mehreren GUIBBs und EV_RESULT = FAILED ===
Wenn ein Floorplan allerdings drei GUIBBs enthält, dann wird jeder der drei Schritte oben für jeden der drei Events nacheinander durchgelaufen, also folgendermaßen:
# FLUSH GUIBB 1
# FLUSH GUIBB 2
# FLUSH GUIBB 3
# PROCESS_EVENT GUIBB 1
# PROCESS_EVENT GUIBB 2
# PROCESS_EVENT GUIBB 3
# GET_DATA GUIBB 1
# GET_DATA GUIBB 2
# GET_DATA GUIBB 3
Nun sollte man wissen, dass wenn man z.B. den PROCESS_EVENT von GUIBB 1 (in der o.g. Auflistung in 4. Zeile) abbricht mit EV_RESULT = FAILED, dass dann die PROCESS-EVENTs für GUIBB 2 und GUIBB 3 (Zeilen 5 und 6) nicht mehr durchlaufen werden.
Kann man wollen, aber evtl. will man es auch nicht.
Unabhängig, ob PROCESS_EVENT abgebrochen wurde, oder nicht, wird GET_DATA für alle GUIBBs wieder durchlaufen.
== Anwendungsdaten in Model-Klasse ==
Empfehlung: Singleton (andere möglich, aber meist umständlich).
== UIBB / User Interface Building Blocks ==
=== GUIBB / Generische UI Building Blocks ===
GUIBB-Komponenten inkl. zugehöriger Feeder-Interfaces
* FPM_FORM_UIBB --> IF_FPM_GUIBB_FORM
* FPM_LIST_UIBB --> IF_FPM_GUIBB_LIST
* FPM_SEARCH_UIBB --> IF_FPM_GUIBB_SEARCH
Nur in den seltensten Fällen muss eine eigene Komponente angelegt werden.
== Übersetzungen ==
=== Texte übersetzen ===
Nachrichtenklassen und Texte in Klassen werden direkt an den Stellen übersetzt, wo sie eingegeben werden.
Texte für FPM Konfigurationen können für die Anmeldesprache direkt in den UIBBs / Komponenten hinterlegt werden.
Für die Übersetzungen solcher Texte muss aus dem zugehörigen Objekt der Objektkatalogeintrag (FPM-Konfigurationen sowie FPM-Komponenten) rausgesucht werden. Danach:
* '''SE63''' → Übersetzung → ABAP-Objekte → Transportobjekt → Dort das Transportobjekt aus dem Objektkatalogeintrag eintragen.
'''Wichtig:''' Bei Übersetzungen von FPM-Konfigurationen mit Vorwärtsnavigation / Doppelklick in die einzelnen Konfigurationskomponenten rein gehen.
'''Wichtig 2:''' Falls nach Übersetzung der Floorplan-Konfiguration mit SE63 die Übersetzungen noch nicht korrekt angezeigt werden, nochmal die Konfiguration des Floorplan öffnen, und diese im Konfigurator erneut speichern (Es muss nichts geändert werden).
=== Transportauftrag für Texte erstellen ===
Transaktion: '''SLXT''':
# Exportmodus auswählen: Einzelne Sprache + Sprachtransport erzeugen
# Entweder Haken "Neuen Auftrag anlegen" anklicken (Beschreibungstext für Transportauftrag eingeben) oder bestehenden (Nixht-SLXT-Auftrag) auswählen
# Als Filter verwenden: Bearbeitungsdatum und Objektbearbeiter
== WebServices pflegen und aktivieren ==
WebServices können mit der Transaktion <code>SICF</code> gepflegt und auch dort aktiviert werden.
Für ein WebDynpro / FPM kann über die SE80 die FPM-/WebDynpro-Anwendung geöffnet werden und dann über Springen -> HTTP-Service-Pflege in die SICF bis zum richtigen Service springen.
=== Aktivieren per Funktionsbaustein ===
Falls keine Zugriffsrechte vorliegen, kann ein Webservice vielleicht mit einem RFC-fähigen Funktionsbaustein auf dem Zielsystem aktiviert werden, indem der verwendete User auf dem Zielsystem ausreichend Zugriffsrechte hat.
{| class="wikitable"
| Funktionsgruppe || HTTPTREE
|-
| Funktionsbaustein || HTTP_ACTIVATE_NODE
|}
Als RFC-Zielsystem das Zielsystem auswählen unter Berücksichtigung des Users mit ausreichenden Rechten.
Bedeutung der Parameter des Funktionsbausteins:
{| class="wikitable"
| '''Parameter''' || '''Inhalt / Bedeutung'''
|-
| RFC-Zielsystem || z.B. BIPCLNT010
|-
| URL || Service-Pfad aus SICF verwenden (siehe oben)
Beispiel: /SAP/BC/WEBDYNPRO/ZMYFPMAPP
|-
| HOSTNAME || DEFAULT_HOST (aus SICF verwenden)
|-
| EXPAND || X
|}
== FPM Anwendungen Customizen ==
Es gibt einen Customizing-Modus. Wenn eine FPM-Anwendung in diesem Modus gestartet wird, werden alle Customizing-Einstellungen nicht im User-Profil des angemeldeten Users gespeichert, sondern im Customizing Layer.
Der Customizing-Modus kann folgendermaßen gestartet werden:
* Anwendung mit folgendem URL-Parameter starten: sap-config-mode=x
* Die Anwendungskonfiguration öffnen und "Ausführen im Administrations Modus" auswählen
Weitere Hinweise: https://help.sap.com/viewer/9c91640bf34c49d8bad6bc560bedd707/1809.000/en-US/ae80f9f5f6c241aa95042a344fc8e89d.html
== Fehlerbehandlung ==
=== Protokolle ===
Standard-Protokolle von SAP nutzen:
{| class="wikitable"
! Transaktion !! Beschreibung !! Anmerkungen
|-
| ST22 || Laufzeitfehler ||
|-
| SM21 || Systemlog ||
|-
| SLG1 || Anwendungslog || Für Floorplan Manager filtern nach:
Objekt = <code>FLOORPLAN_MANAGER</code>
Unterobjekt = <code>Runtime</code>
|-
| ST11 || Fehlerprotokolldatei ||
|}
== Pakete ==
{| class="wikitable"
| '''Paket''' || '''APB_FPM'''
|-
| Kurzbeschr. || Floorplan Manager
|-
| Anwendungskomponente || BC-WD-CMP-FPM Floorplanmanager Web Dynpro ABAP
|-
| Oberpaket || SWDP
|-
| Softwarekomp. || SAP_UI Release 740, SP 20
|}
Unterpakete mit Test-Daten und Demo-Applikationen:
* APB_FPM_TEST
* APB_FPM_DEMO
Die den FPM-Anwendungen zugehörigen Webservices (Vgl. Feld URL in der WDP-Anwendung) müssen ggf. erst mit Transaktion SICF aktiviert werden.
== Quellen und Tutorials ==
https://blogs.sap.com/2017/05/04/getting-started-with-the-floorplan-manager/
https://blogs.sap.com/2012/12/02/a-step-by-step-guide-to-create-a-simple-fpm-application-using-feeder-class-for-form-guibb/
https://blogs.sap.com/2017/11/14/the-fpm-event-phase-model-easy-going-or-already-lost/
Developer Guides: https://archive.sap.com/documents/docs/DOC-61783
Floorplan Manager for Web Dynpro ABAP: https://help.sap.com/viewer/7bd8201a728810148a4b1a83b0e91070/7.5.9/en-US/9f95467bbefc4a808fffeba4c5177258.html
Floorplan Manager for WebDynpro ABAP 7.4 SP08 https://archive.sap.com/documents/docs/DOC-59244
Floorplan mit Search-UIBB und Listen-UIBB:
* https://archive.sap.com/documents/docs/DOC-71083
* http://www.teamabap.com/2014/05/search-guibb.html
* https://blogs.sap.com/2017/05/04/getting-started-with-the-floorplan-manager/
Datenübertragung zwischen UIBBs mit Wiring: http://www.teamabap.com/2014/05/data-transfer-between-uibb-using-wiring.html
[[Category:ABAP]]

Aktuelle Version vom 15. November 2019, 14:28 Uhr

Dieser Artikel behandelt grundlegende Informationen über Floorplan Manager Anwendungen.

Codebeispiele für die Implementierungen der notwendigen Klassen und Methoden finden sich hier: Floorplan_Manager_Codebeispiele_(ABAP)

Relevante Klassen

Alle Feeder-Interfaces beinhalten das Interface IF_FPM_GUIBB, das die beiden Methoden INITIALIZE und GET_PARAMETER_LIST umfasst. Beide Methoden werden nur während der Initialisierungsphase des GUIBBs aufgerufen.

Übersicht Feeder-Klassen

Feeder-Klassen bilden die Schnittstelle zwischen der Anwendungslogik und den GUIBB zur Darstellung derUI-Informationen innerhalb der Floorplan-Manager-Anwendung.

Jeder GUIBB benötigt für die Bereitschellung von Daten eine Feeder-Klasse.

Alle Feeder-Interfaces beinhalten das Interface IF_FPM_GUIBB, das die beiden Methoden GET_PARAMETER_LIST und INITIALIZE umfasst. Beide Methoden werden nur während der Initialisierungsphase des GUIBBs aufgerufen. 

 GET_PARAMETER_LIST: Eigene Konfigurationsparameter verarbeiten ( z.B. read only )

 INITIALIZE: Wird nach GET_PARAMETER_LIST aufgerufen. Nutzung z.B. zum Laden von Anwendungsobjekten (von der DB) / Sperren setzen etc.


Methoden mit lediglich unterschiedlicher Signatur: 

CHECK_CONFIG
   i.d.R. irrelevant
GET_DEFAULT_CONFIG
   i.d.R. irrelevant
GET_DEFINITION
   Wird nach INITIALIZE aufgerufen
   Bestimmt Aufbau Baustein (z.B. welche Eingabefelder hat das Form ) 
GET_DATA
   Bestimmt Inhalt der Oberfläche ( z.B. Text in Textfeld eines Forms )

PROCESS_EVENT
   Verarbeitung von Benutzereingabe (z.B. Suchknopf wurde gedrückt)
   ( evtl. auch Ereignisse von anderen FPM Komponenten z.B. Refresh)
FLUSH
   Benutzereingaben von der Oberfläche in die Anwendung                    übernehmen

Standard-Interface IF_FPM_GUIBB

Feederklassen Programmstart

  1. GET_PARAMETER_LIST: Eigene Konfigurationsparameter verarbeiten ( z.B. read only )
  2. INITIALIZE: Wird nach GET_PARAMETER_LIST aufgerufen. Nutzung z.B. zum Laden von Anwendungsobjekten (von der DB) / Sperren setzen etc.

Feederklassen Programmablauf / Event-Loop

  1. FLUSH -> Daten von Oberfläche an Anwendung übertragen
  2. PROCESS_EVENT -> Besondere Ereignisse ( z.B. Knopfdruck ) verarbeiten
  3. GET_DATA -> Oberfläche mit aktuellen Daten aus Anwendung versorgen; Entspricht PROCESS_BEFORE_OUTPUT

Event-Loop mit mehreren GUIBBs und EV_RESULT = FAILED

Wenn ein Floorplan allerdings drei GUIBBs enthält, dann wird jeder der drei Schritte oben für jeden der drei Events nacheinander durchgelaufen, also folgendermaßen:

  1. FLUSH GUIBB 1
  2. FLUSH GUIBB 2
  3. FLUSH GUIBB 3
  4. PROCESS_EVENT GUIBB 1
  5. PROCESS_EVENT GUIBB 2
  6. PROCESS_EVENT GUIBB 3
  7. GET_DATA GUIBB 1
  8. GET_DATA GUIBB 2
  9. GET_DATA GUIBB 3

Nun sollte man wissen, dass wenn man z.B. den PROCESS_EVENT von GUIBB 1 (in der o.g. Auflistung in 4. Zeile) abbricht mit EV_RESULT = FAILED, dass dann die PROCESS-EVENTs für GUIBB 2 und GUIBB 3 (Zeilen 5 und 6) nicht mehr durchlaufen werden.

Kann man wollen, aber evtl. will man es auch nicht.

Unabhängig, ob PROCESS_EVENT abgebrochen wurde, oder nicht, wird GET_DATA für alle GUIBBs wieder durchlaufen.

Anwendungsdaten in Model-Klasse

Empfehlung: Singleton (andere möglich, aber meist umständlich).

UIBB / User Interface Building Blocks

GUIBB / Generische UI Building Blocks

GUIBB-Komponenten inkl. zugehöriger Feeder-Interfaces

  • FPM_FORM_UIBB --> IF_FPM_GUIBB_FORM
  • FPM_LIST_UIBB --> IF_FPM_GUIBB_LIST
  • FPM_SEARCH_UIBB --> IF_FPM_GUIBB_SEARCH

Nur in den seltensten Fällen muss eine eigene Komponente angelegt werden.

Übersetzungen

Texte übersetzen

Nachrichtenklassen und Texte in Klassen werden direkt an den Stellen übersetzt, wo sie eingegeben werden.

Texte für FPM Konfigurationen können für die Anmeldesprache direkt in den UIBBs / Komponenten hinterlegt werden.

Für die Übersetzungen solcher Texte muss aus dem zugehörigen Objekt der Objektkatalogeintrag (FPM-Konfigurationen sowie FPM-Komponenten) rausgesucht werden. Danach:

  • SE63 → Übersetzung → ABAP-Objekte → Transportobjekt → Dort das Transportobjekt aus dem Objektkatalogeintrag eintragen.

Wichtig: Bei Übersetzungen von FPM-Konfigurationen mit Vorwärtsnavigation / Doppelklick in die einzelnen Konfigurationskomponenten rein gehen.

Wichtig 2: Falls nach Übersetzung der Floorplan-Konfiguration mit SE63 die Übersetzungen noch nicht korrekt angezeigt werden, nochmal die Konfiguration des Floorplan öffnen, und diese im Konfigurator erneut speichern (Es muss nichts geändert werden).

Transportauftrag für Texte erstellen

Transaktion: SLXT:

  1. Exportmodus auswählen: Einzelne Sprache + Sprachtransport erzeugen
  2. Entweder Haken "Neuen Auftrag anlegen" anklicken (Beschreibungstext für Transportauftrag eingeben) oder bestehenden (Nixht-SLXT-Auftrag) auswählen
  3. Als Filter verwenden: Bearbeitungsdatum und Objektbearbeiter

WebServices pflegen und aktivieren

WebServices können mit der Transaktion SICF gepflegt und auch dort aktiviert werden.

Für ein WebDynpro / FPM kann über die SE80 die FPM-/WebDynpro-Anwendung geöffnet werden und dann über Springen -> HTTP-Service-Pflege in die SICF bis zum richtigen Service springen.

Aktivieren per Funktionsbaustein

Falls keine Zugriffsrechte vorliegen, kann ein Webservice vielleicht mit einem RFC-fähigen Funktionsbaustein auf dem Zielsystem aktiviert werden, indem der verwendete User auf dem Zielsystem ausreichend Zugriffsrechte hat.

Funktionsgruppe HTTPTREE
Funktionsbaustein HTTP_ACTIVATE_NODE

Als RFC-Zielsystem das Zielsystem auswählen unter Berücksichtigung des Users mit ausreichenden Rechten.

Bedeutung der Parameter des Funktionsbausteins:

Parameter Inhalt / Bedeutung
RFC-Zielsystem z.B. BIPCLNT010
URL Service-Pfad aus SICF verwenden (siehe oben)

Beispiel: /SAP/BC/WEBDYNPRO/ZMYFPMAPP

HOSTNAME DEFAULT_HOST (aus SICF verwenden)
EXPAND X

FPM Anwendungen Customizen

Es gibt einen Customizing-Modus. Wenn eine FPM-Anwendung in diesem Modus gestartet wird, werden alle Customizing-Einstellungen nicht im User-Profil des angemeldeten Users gespeichert, sondern im Customizing Layer.

Der Customizing-Modus kann folgendermaßen gestartet werden:

  • Anwendung mit folgendem URL-Parameter starten: sap-config-mode=x
  • Die Anwendungskonfiguration öffnen und "Ausführen im Administrations Modus" auswählen

Weitere Hinweise: https://help.sap.com/viewer/9c91640bf34c49d8bad6bc560bedd707/1809.000/en-US/ae80f9f5f6c241aa95042a344fc8e89d.html

Fehlerbehandlung

Protokolle

Standard-Protokolle von SAP nutzen:

Transaktion Beschreibung Anmerkungen
ST22 Laufzeitfehler
SM21 Systemlog
SLG1 Anwendungslog Für Floorplan Manager filtern nach:

Objekt = FLOORPLAN_MANAGER

Unterobjekt = Runtime

ST11 Fehlerprotokolldatei

Pakete

Paket APB_FPM
Kurzbeschr. Floorplan Manager
Anwendungskomponente BC-WD-CMP-FPM Floorplanmanager Web Dynpro ABAP
Oberpaket SWDP
Softwarekomp. SAP_UI Release 740, SP 20

Unterpakete mit Test-Daten und Demo-Applikationen:

  • APB_FPM_TEST
  • APB_FPM_DEMO

Die den FPM-Anwendungen zugehörigen Webservices (Vgl. Feld URL in der WDP-Anwendung) müssen ggf. erst mit Transaktion SICF aktiviert werden.

Quellen und Tutorials

https://blogs.sap.com/2017/05/04/getting-started-with-the-floorplan-manager/

https://blogs.sap.com/2012/12/02/a-step-by-step-guide-to-create-a-simple-fpm-application-using-feeder-class-for-form-guibb/

https://blogs.sap.com/2017/11/14/the-fpm-event-phase-model-easy-going-or-already-lost/

Developer Guides: https://archive.sap.com/documents/docs/DOC-61783

Floorplan Manager for Web Dynpro ABAP: https://help.sap.com/viewer/7bd8201a728810148a4b1a83b0e91070/7.5.9/en-US/9f95467bbefc4a808fffeba4c5177258.html

Floorplan Manager for WebDynpro ABAP 7.4 SP08 https://archive.sap.com/documents/docs/DOC-59244

Floorplan mit Search-UIBB und Listen-UIBB:

Datenübertragung zwischen UIBBs mit Wiring: http://www.teamabap.com/2014/05/data-transfer-between-uibb-using-wiring.html

Abgerufen von „https://otremba.net/w/index.php?title=Floorplan_Manager_(ABAP)&oldid=2147“