Kontakt

Ansicht
Dokumentation

CL_WB_ABSTRACT_TOOL - Abstrakte Workbench-Toolklasse

CL_WB_ABSTRACT_TOOL - Abstrakte Workbench-Toolklasse

rdisp/max_wprun_time - Maximum work process run time   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Die Klasse CL_WB_ABSTRACT_TOOL ist die zentrale Komponente des Tool-Frameworks der ABAP Workbench. (Das Tool-Framework unterstützt die Entwicklung und Integration neuer Editor-Tools; Editor-Tools dienen der Bearbeitung von Objekten eines gegebenen Objekttyps.)

CL_WB_ABSTRACT_TOOL bzw. die von ihr erbenden Subklassen haben die Funktion eines "Controllers", der zwischen Persistenz, User Interface, Workbench Framework (Klasse CL_WB_MANAGER) und Workbench-Infrastruktur (z.B. Aktiv-/Inaktiv-Verwaltung, Sperrverwaltung, Anschluss ans Transportwesen, Objektlisten) vermittelt.

Beziehungen

Ein mit Hilfe des Tool-Frameworks entwickeltes Tool besteht im Wesentlichen aus fünf Komponenten:

  • "Objektdaten"-Klasse: implementiert Interface IF_WB_OBJECT_DATA_MODEL
  • "Tooldaten"-Klasse: implementiert Interface IF_WB_TOOL_DATA_MODEL
  • User-Interface-Klasse: implementiert Interface IF_WB_TOOL_UI
  • Persistenz-Klasse: implementiert Interface IF_WB_OBJECT_PERSIST
  • "Tool-Klasse" ("Controller"): erbt von Klasse CL_WB_ABSTRACT_TOOL, siehe oben

Beispiel

Example implementations (which may be used as templates, and can be copied) are given in package SWB_TOOL_TEMPLATES.

Hinweise

Die Kurzbeschreibung mancher Methoden in CL_WB_ABSTRACT_TOOL beginnt mit dem Kürzel ENHS:.Bei solchen Methoden handelt es sich um vorgedachte "Enhancement Spots", in denen (durch Redefinition) spezielle Eigenschaften eines Tools implementiert werden können. (Selbstverständlich können zu diesem Zweck auch alle anderen in der Subklasse sichtbaren Methoden von CL_WB_ABSTRACT_TOOL redefiniert werden.)

Sprachenbehandlung

CL_WB_ABSTRACT_TOOL is the parent class for design-time editor tools. Such an editor tool is to process repository objects of a given type. If objects of the given type may contain language-dependent data (e.g., short texts which are translated into several languages), then you should set attribute CL_WB_ABSTRACT_TOOL->LANGUAGE_IS_RELEVANT to #true#. You should also account for parameter P_LANGUAGE in method IF_WB_OBJECT_PERSIST~GET: then the Repository Browser will present the short text of the object in logon language. Furthermore, the tool framework will assist in the following situation: If the user#s logon language is different from the object#s original language, and if the user requests to edit the object in the tool, then the abstract tool framework will conduct a dialogue and ask whether the user wants to edit the object in original language or whether he wants to change the original language of the object.

You might also account for parameter P_DATA_SELECTION in methods IF_WB_OBJECT_PERSIST~GET and IF_WB_OBJECT_PERSIST~SAVE, and for parameter P_LANGUAGE in IF_WB_OBJECT_PERSIST~SAVE, so that the abstract tool framework will account for all language-dependent object data especially in the case of #copy# or #rename# operations.

Anlegen neuer Objekte ('Create Object')

The Abstract Tool is deliberately designed so that a newly created object is automatically saved. (For Usability reasons, this should be the common behavior of any tool in the Development Environment.)
You (the tool developer) can prescribe the initial content of the object with your implementation of method IF_WB_OBJECT_DATA_MODEL~GENERATE_FROM_KEY.

If this is not sufficient, then it#s time to consider the benefits of active/inactive handling (which is comfortably supported by the Abstract Tool Framework). The framework will save new objects in an inactive state; when the user tries to #activate# an object, the framework will first check whether all checks (which are to be implemented by you, the tool developer) are successfully passed.

Aktiv-/Inaktiv-Verwaltung

Die den Objekten eines Repository-Objekttyps zugrunde liegenden Daten werden üblicherweise in Datenbank-Tabellen persistiert. Der Anschluss dieser Datenbank-Tabellen ans Transportwesen erfolgt im Normalfall durch die Definition eines logischen Transportobjekts in Transaktion SOBJ.

Wenn sowohl aktive als auch inaktive Versionen der Objektdaten persistiert werden, dann sollten die Datenbank-Tabellen im ersten Feld den Objektnamen, im zweiten Feld die Versionsbezeichnung ('A' oder 'I') enthalten. In Transaktion SOBJ wird dann in der Stückliste des logischen Transportobjekts als Objektschlüssel das 'Kommando' /&A eingetragen, so dass beim Transport nur die aktive Version des jeweiligen Objekts berücksichtigt wird.

Die Aktiv-/Inaktiv-Verwaltung im Workbench-Editor-Tool muss durch Implementieren der Methoden IF_WB_OBJECT_DATA~SET_VERSION und IF_WB_OBJECT_DATA~GET_VERSION unterstützt werden. Außerdem muss bei der Implementierung der Methoden von If_WB_OBJECT_PERSIST der Parameter P_VERSION berücksichtigt werden.

Weiterführende Informationen






TXBHW - Original Tax Base Amount in Local Currency   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 5390 Date: 20240425 Time: 120146     sap01-206 ( 113 ms )