The Generic Object Services (GOS) comprise the definition of Object Types as well as services based and related on these object definitions, like Key Conversion and "Add to Favorites" functionality. Like the Service Provider Infrastructure they belong to the software component SAP_BS_FND.
Please note that the name Generic Object Services (GOS) is also used in the context of SAPGUI applications for functions like adding an attachment to the application object, showing linked objects to this one, or starting a workflow from this object.
Those functions belong to application component BC-SRV-GBT and are not described by this chapter.
GOS is DMZ Enabled
All GOS service methods are DMZ enabled i.e. the system switch is executed automatically – if necessary. Therefore these methods can be executed also directly in the frontend.
Object Type Definition
The definition of GOS Object Types allows using generic services that are provided in the context of this object type. A GOS object type is normally to be understood in a "broader" context, meaning it is not application specific. E.g. the master data "Material" or "Document" is defined as GOS object type. Ideally the GOS object type is defined in the software layer where the master data / objects are situated. The benefit from this is that higher software layers can reuse these definitions and double-definitions are avoided.
A GOS object type is defined via the view /PLMB/V_GOS_OTYP:
Name / ID of the object type
Description of the object type
Class name for external key conversion
Class name for internal key conversion
Conversion rule for external key conversion: in a DMZ scenario this flag defines whether the conversion of an object ID to the external format is done in DMZ system or in the backend system. The default is that the conversion is done in the DMZ system, since the external key format normally is a simple concatenation the ID fields. However as soon as an own conversion class for the external conversion is used it is very likely that the conversion has to be done in the backend system. For details refer to the key conversion chapter.
DDIC name of the ID structure of the readable key
DDIC name of the ID table type of the readable key; note: this can be a sorted table as well
Generic Service relevance of this object type: this flag allows excluding the object type from being relevant for the Generic Services "Recently Changed" and "Last Accessed"]. The default is that the object type is relevant for these services. If the flag is set and the Generic Services are called for these objects, the call is internally ignored and the object ID(s) are not written to the GOS database. This flag is e.g. helpful if an application handles several object types and does not want to – or is not able to – distinguish between the different object types upon calling GOS.
Icon to be used for this GOS Object Type. (Generic) applications that are based on GOS Object Types can use this information to display an icon for the shown objects. This – combined with the GOS key conversion – allows a heterogeneous representation of an object.
GOS Definition Specialties
The definition of GOS object types is client independent.
The underlying database table is of delivery class 'E' with 'Y*' and 'Z*' being reserved as customer namespace
The GOS key conversion is a service that allows converting object keys from one format into another. Three key formats are distinguished in GOS by following terms:
The readable key of the object is represented by a DDIC structure with one or several fields containing the keys of the object. In case of a material the structure would contain only the material as key field, while other objects like a material BOM might have several key fields (material, plant, usage...). Note: this key format must not contain "internal" components, like a GUID. The name of this structure and the corresponding table type need to be maintained in the GOS object type view.
External representation of an object key for display purposes, in general this is a concatenation of the readable key for display in e.g. heterogeneous object list. The concatenation is done with '/' as separator. Note: this concatenation cannot be reversed automatically since the separator is not a protected character.
This key is an internal generic format (CHAR90, data element /PLMB/GOS_INTERNAL_KEY) of an object key. In many cases this CHAR90 field does also contain a concatenation of key fields. However there are three important differences to the external key format:
- This key can be split again since for concatenation a protected character is used that cannot be entered via keyboard
- This key is not intended for display purposes
- The content of the key is defined by the application, i.e. which fields are used for concatenation is decided by the application and a different set of fields can be chosen that is used for the readable key. In many cases the internal key will use the same DDIC structure as is used for the readable key. However the application has the freedom to use e.g. the "real" internal key(s) of the object for this format, like a GUID.
Service Class for key conversion
GOS provides a service class (/PLMB/CL_GOS_CNV_TOOLS) for conversion of one key format into another, no application specific coding is required if an object does not need specific conversion logic. If e.g. the object uses for the internal key the same DDIC structure as for the readable key the standard methods can be used. If the object requires for the conversion own logic because e.g. the internal key consists of (concatenated) components of a different DDIC structure than the readable key, GOS can no longer convert one key format into another. In that case a conversion interface has to be implemented for the object and the implementing class needs to be maintained in the GOS object type definition. Two different conversion interfaces exist: one for conversion routines that involve the internal key format and a second that involves the external key format. The latter is normally only required if the external key e.g. should use less key fields of the readable key or maybe a different sequence for concatenation. Details concerning these interfaces are given in the respective section.
Available Conversion Methods:
Following methods handle the various conversion possibilities (the object type is always a mandatory parameter):
Key Component Concatenation
For concatenation a protected character that cannot be entered via keyboard is used, therefore later splitting is safely possible
Never Access Specific Conversion Classes Directly
The conversion class checks internally if for an object type an object type specific conversion is implemented and dispatches the call to the implementing class accordingly, i.e. there is no need to access an object type specific conversion class directly
Additional Service Methods:
The GOS Conversion Class offers several service methods than can be used when e.g. implementing an object type specific conversion:
Concatenates a given DDIC structure into the internal key format
Concatenates a given DDIC structure into an string
Splits an internal key into a given DDIC structure
Splits an internal key into a string
Usage Possible Independent of Object Type
These methods are independent from any object type definition, therefore any DDIC structure can be used along with them
Interfaces for Object Type Specific Conversion
In some cases the standard conversion routines of GOS might not be usable for an object type, e.g. when the external key should concatenate the key fields in a different sequence than they are contained in the (readable) key or if for the internal key format a "real" internal key (like a GUID) is used. For such cases GOS offers two interfaces that handle internal (/PLMB/IF_GOS_CNV_INT) and external (/PLMB/IF_GOS_CNV_EXT) conversion respectively. An object type needs to implement only the interface it requires, if both interfaces need to be implemented different classes or the same class can be used. In the object type definition the class name(s) need to be maintained.
Service Routines Available
Via GOS it is possible to define Generic Services per GOS object type. A service basically allows storing user-specific object IDs along with the service identifier. An example would be the service "Add to Favorites", which is already defined in SAP_BS_FND and therefore available for all user of SPI/GOS.
The trigger for writing a service is up to the application, in some cases explicit user interaction (e.g. button click) triggers the writing, in other cases an application might automatically write the service (e.g. "Last Accessed" when reading object data).
Services are defined via view /PLMB/V_GOS_SDEF, which is located in the IMG under "Cross-Application Components->Processes and Tools for Enterprise Applications->Settings for BO Framework and Navigation->Navigation, Parameter Mapping, and Services->Define Generic Services". It is also possible to define Service groups (view /PLMB/V_GOS_SGDF, "Cross-Application Components->Processes and Tools for Enterprise Applications->Settings for BO Framework and Navigation->Navigation, Parameter Mapping, and Services->Define Service Groups") and to assign services to service groups (view /PLMB/V_GOS_SGRP, "Cross-Application Components->Processes and Tools for Enterprise Applications->Settings for BO Framework and Navigation->Navigation, Parameter Mapping, and Services->Assign Services to Service Groups").
Writing and deleting of services data is triggered via methods PERS_AREA_SET and PERS_AREA_DELETE of class /PLMB/CL_SPI_APPL_ACCESS_UTILS, which is described in the services and tools section.
The full blown service functionality (reading, writing...) can be accessed via interface /PLMB/IF_GOS_PERS_AREA which is returned by method GET_INSTANCE of class /PLMB/CL_GOS_PERS_AREA, which offers the following methods:
Read service data
Write service data
Delete service data
Refresh service data for a given object type
Get complete (object type independent) service data
GOS Related Constants – /PLMB/IF_GOS_C
The interface /PLMB/IF_GOS_C defines constants that are related to the area of Generic Object Services. Following constants can be relevant for application programming:
Default number of records for 'Last Accessed' and 'Recently Changed'
Time zone 'UTC'
Availability of a service e.g. only for change and display mode of an object
Name of personal work areas, e.g. "Last Accessed" and "Recently Changed"
Name of generic services