S4HANA : Attachment Services Ways of consumption - DMS and GOS

[former_member191063]

INTRODUCTION:

Attachment service is a re-usable UI component in S/4HANA application. Applications can make use of this component to deal with attachment related functionality. Uploading, downloading, renaming, and deleting an attachment from or to the parent application are some of the basic features supported by Attachment Services. This re-usable component is based on UploadCollection control from UI5 foundation.

Attachments are linked to business objects based on SAP Document Management System (DMS) or Generic Object Services (GOS).

The attachment content is stored on the HCP (HANA Cloud Platform) Document Service (in cloud scenario) using SAP KPRO (Knowledge Provider) and it is stored on the configured content server (in on-premise scenario).

ATTACHMENT SERVICES UI:

CUSTOMIZING:

You can customize attachment services by going to the path: SPRO-> Cross Application Components-> Document Management-> Additional Settings - Simplification

• Attachment Service- Storage Repository Activation

• Attachment Service- Object Type Mapping

CONSUMPTION STRATEGY:

HOW TO CONSUME ATTACHMENT SERVICE BASED ON DMS:

As a pre-requisite, a document type, an object type, and their linkage has to be configured in the system.

In this case, where we are consuming attachment services based on DMS, a Document Info Record (DIR) is created in the background. The DIR is completely abstracted from the end user. It is not required for the end user to have knowledge on DIR and its functionality to deal with attachments in different applications. This makes the process simpler by treating the attachments as attachments in various applications instead of complicating with a technical business object behind the scenes.

What is happening behind the scenes when a user adds an attachment?

The attachments are added with respect to a parent object. They cannot be made independent, a context is always required. Attachment is added corresponding to an object type and a key. This object type is the parent business object. A DIR is created in the backend and linked to this object type. On saving, the attachments added for an object type gets linked to the DIR which was created. This DIR creation process and linkage of attachments with that DIR is completely hidden from the end user. In SAP GUI, if we open the same DIR, we can see the attachments and also the object link.

Example: For material master object (object type: MARA), attachments are added in the UI. If we open the same material in SAP GUI (backend), we can see a DIR created with the same attachments that were added from the UI. (Assuming MARA is DMS scenario). The advantage is instead of creating the DIR and adding attachments to it and then creating an object link, the user will now only add attachments to the desired object type. Attachment services will create a DIR in the backend and link attachments to it.

GUI SCREEN FOR DMS SCENARIO :

Another example which explains GOS scenario is Purchase Order (Object Type: EKKO). Here, the attachments added from UI can be seen under the attachments list if we open the same material in SAPGUI.

NOTE:

Consumers can see from SAPGUI, only if there is an object link to the consuming object and consuming object has a SAP GUI screen.

.

Also, attachment services comes up with a BAdI which supports a consuming application to choose document type. They may require different document types to be mapped to a single object type. Normally, if there are more than one document type configured, the first one will be picked by default. But with this BAdI extension, the consuming application will have the flexibility to choose the document type from the customizing entries.

It is recommendation for cloud consumption to have one document type mapped to one object type. But in case of on-premise consumers there is a n:1 mapping and consumers have the flexibility to determine the document type at runtime.

HOW TO CONSUME ATTACHMENT SERVICES BASED ON GOS :

Earlier in SAP ERP applications, attachments were dealt via GOS (Generic object services). In order to support the previous applications to create or read attachments from FIORI UI to SAP GUI and vice-versa, this support is available.

Consuming applications can pass their technical object type and object key and add attachments. User can go to that object type in SAP GUI and can see the added attachments if they have a SAP GUI screen.

Rename of attachments is not possible in case of GOS attachments as it is not supported by GOS.

GUI SCREEN FOR GOS SCENARIO (Material Master Object)

Attachment service implements the concept of ‘Key Replacement’. If the attachments are added to any object which is not permanent or just created and not saved, in that case attachments will be added to the temporary key and during save when the object is permanently saved, this temporary key is replaced by the permanent key.

KEY POINTS:

1. A consuming application should not have both GOS and DMS based consumption.
2. All attachments in S/4 Cloud are stored on HANA Cloud Platform document services.
3. Attachments cannot be created without a consuming application object.
4. Attachment service supports draft handling. This means that an attachment is in a draft state unless it is explicitly saved. This helps holding of attachments without permanently saving them. So even if the application is refreshed, the attachments are still there.
5. For any attachment added, mimetype validation is done against the Customizing done in the backend. If the mimtype exists, only then attachment is allowed to be added otherwise relevant error message is thrown.