Introduction

SAP application documents such as Invoice, Purchase Order, Sales Order and so on use common functions such as create attachments, list attachments, show links to an internet address and display associated workflows. The Generic Object Services toolbox provides these functions. These functions are invoked and used in the same way across all SAP applications.

Figure 1: GOS in SAP

Example: Creating an attachment and displaying using the generic object service toolbox. We can navigate to create attachment service after clicking the GOS icon as shown in the following figure.

Figure 2: Adding an attachment using GOS

The attached list of documents can be viewed  by using the Attachment list service.

Figure 3: Displaying an attachment using GOS

List of services in GOS Toolbox:

The following figure shows possible object services. Only active objects can be used.

  Figure 4: All possible services in GOS

The Driving Table : SGOSATTR

The SGOSATTR table contains GOS attributes. This table can be maintained using SM30.

Figure 5: Table SGOSATTR

Figure 6:  entry in table SGOSATTR

Table Fields

NAME (Technical name): A unique technical name for the service and the primary key of the table.

CLSNAME (Class for Gen. Services): Driver class available in the GOS toolbar when the object service is selected from the menu. It has to be a subclass of CL_GOS_SERVICE, which is an abstract class. When we select a service it executes the EXECUTE method of the class.

Figure 7:  Driver class

TYPE (Service Type): Different types of services are available in the GOS toolbox. The Service type is used to determine how a service should be displayed in the toolbox.

Following are the possible values of this field:

1.        A ‘single service’ is displayed as a pushbutton. 

2.        A ‘service list with default’ can be created as a pushbutton with a drop-down menu.

3.        A ‘service list’ summarises one or several single services as a menu key but cannot be executed itself.

4.        A ‘service with sub-functions and default’ is created by using a drop-down menu. Here, the menu is also provided by the service itself, which must support the IF_GOS_SERVICE_MULTIPLE interface.

5.        A ‘service with sub-functions’ is displayed as a menu key. However, the menu is provided by the service itself. This requires that the implementing class supports the IF_GOS_SERVICE_MULTIPLE interface.

ICON: Icon for the service such as ICON_CREATE. The following figure shows the table ICON which contains the list of icons:

Figure 8:  Table ICON

NEXTSRV (Next Service): Indicates the name of next service and it is used to determine the order of the object services in the context help and in the toolbox. The object service which is entered in this field is kept on the right side of the object service that is mentioned in the field NAME.

Figure 9: Arrangement of Services in GOS toolbox

SUBSRV (Sub service): Used to determine the hierarchy of the object services in the menu and in the toolbox. The name of the service in this field is ordered under the service, which is in the field NAME.

ISCONTROL (Service Executable as control): If it has a value ‘X’ then an output is generated in a Control Container.

SRVCMIT (Commit Work): Its value is ‘X’ if the service has an update and needs a commit work for data backups.

To add a new service to the existing toolbox care must be taken to maintain the field values in the table. It depends on the position where the new service will be added. If it is added at the beginning, then the service should not be the NEXT for any of the existing services and the NEXT service for this new service should be the one which is currently at the beginning.

Figure 10: Positioning of Services in GOS toolbox

Proper discipline must be followed while maintaining the SGOSATTR table. Else, it will reflect incorrect GOS services in the applications. .

Suppose if there is more than one service which is not a Next service for other services, then it takes the one which comes first in the ascending order (for example, there are two services VIEW_ATT and SHOW_ATT which do not occur as NEXT_SERV for any other service, then SHOW_ATT will be taken into consideration). Once it identifies the first service then it follows the chain till it meets the service which does not have a NEXT_SERV. This is true even when there is a sub service. The rows which are skipped in this way are not considered in the toolbox services. So we should be prudent in maintaining the table clean always.

Publishing Generic Object Services:

The Class CL_GOS_MANAGER is used for publishing GOS. Alternately the Function Module SWU_OBJECT_PUBLISH can also be used. When we use the class, an instance of the class must be generated by calling the constructor method. Also, a variable of type BORIDENT must be created for the application business object, to which the object and object key is assigned.

data : lr_gos_manager type ref to cl_gos_manager,

is_borident type borident.

s_borident-objtype = ‘BUS2081’. ls_borident-objkey = ‘12345678902011’.

create object lr_gos_manager

exporting

is_object = ls_borident

ip_no_commit = ‘ ‘

exceptions

object_invalid = 1.

This will publish the GOS with the supplied BO instance if it is used in an executable program.

CL_GOS_MANAGER constructor parameters

Following are the constructor parameters:

IP_NO_COMMIT: A value of ‘X’ by default implies that there will be no commit in the service that is published. But if it is empty, it will be committed (for example, for service Create attachment).

IO_CONTAINER: Passes the custom container. The services that enable this are maintained in the SGOSATTR table field ISCONTROL.

IP_MODE: Value that determines whether the services are available in display mode only or also in change mode. In display mode, some services are omitted entirely. Possible values are ‘W’ for display and change mode, ‘R’ for display mode only

IP_NO_INSTANCE: The value is ‘X’ when the BO key is not yet known when creating an object. However, many services require the key, so you must subsequently hand it in. This procedure enables users to publish the object that is not yet created and transfers the object key according to which the object was created on the database.

IP_START_DIRECT: To start the toolbox directly.

IT_SERVICE_SELECTION: It excludes the services except the ones mentioned in it.

IS_BC_OBJECT : It is the parameter using which the persistent object references for business classes can also be published .

IO_CALLBACK : In case of a dynamically determined object this can be used to avoid several publication calls.

IS_OBJECT : The Business object.

GOS Service Execute and Check Status

The class we maintain in the SGOSATTR table is a subclass of the CL_GOS_SERVICE class. It inherits (among other things) the instance method EXECUTE and CHECK_STATUS.

To add our own service, users must create the subclass and maintain it in the SGOSATTR table. Redefine the EXECUTE method in your class according to the expected service.

To restrict the GOS toolbar service to a particular transaction, we need to redefine the CHECK_STATUS method. EP_STATUS is set to make it either active or invisible.

Figure 11: Method Check_Status

Where the Attachment is Stored

·        Notes, PC attachments, and URLs are treated as SAP office documents

·        They result in corresponding entries in the SOOD and SOFM tables

·        Contents of the attachments are stored in the SOC3 table (Notes and URLs)

·        Contents of the PC attachments are written to the SOFFCONT1 table

·        See Note 530792 for more information

·        See Note 389366 if you need to move documents from the database to an external content server