Attachment Service provides consumers to add their own business functionality to the existing functionality.
The following BAdI extensions can be efficiently consumed to achieve multiple functionalities:
1) BAdI: BADI_CV_ODATA_ATTACH_DRAFT_HDL:
Method: DRAFT_DELETE_AVOID
As already explained about the ‘Draft’ scenario in Attachment Service, where the attachments are in draft state until an explicit save is done. With this scenario, a situation can occur where there are multiple draft attachments which have not been saved since long time. As we know that ‘On Cloud, Space is equal to Money’, so these attachments should be deleted as they are unnecessarily consuming space. Deletion of draft attachments is an optional administrative activity. Hence, a report program is available for administrators to delete all the draft attachments which have been introduced with an intention to efficiently utilize the cloud space. This means that long pending draft attachments which are not saved can be deleted so that the space occupied by those attachments is removed. This BAdI will be called from the report DELETE_DRAFT_ATTACHMENTS, which is used by Admin to delete the draft contents. In order to avoid an attachment getting deleted, the parent application can write an implementation to avoid deletion.
2) BAdI: BADI_CV_ODATA_ATTACH_DRAFT_HDL
Method: DETERMINE_DOCUMENT_TYPE
Sometimes it is possible that a consuming application needs more than one document type to be mapped to an object type. Currently, there is a Customizing available for mapping the document type to an object type in DC10. In this Customizing, it is possible to maintain the mapping of one object to different document types. But if there are more than one document types configured, the first one will be picked. Now with this BAdI solution, the consuming application will have the flexibility to choose the document type from the customizing entries. This BAdI has an importing parameter which receives the table containing the list of object types and document types from table TDWO as per the customizing in DC10. This table contains entries of all document types allowed for an object type and hence passed to change to valid document type. The BAdI implementation can set a document type to the appropriate object type if only it is available in the DC10 customizing. If any other document type is set, the save process will fail. After receiving the table of entries, the users can determine which document type they want to pick for the corresponding object type. The changing parameter is of row type of Draft table for attachments, that is the complete information of attachments is received and can be changed. The consuming application can create an implementation which can depend upon various attributes like mimetype, WSapplication type, filesize, and so on to determine the document type. Only DOCUMENTTYPE field is compared and change is accepted.
NOTE: Recommendation for cloud consumption is to have one document type mapped to one object type (1:1 mapping). 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.
3) BAdI: BADI_CV_ODATA_ATTACHMENTS_AUTH
Method: CHECK_AUTHORIZATION
This BAdI method is capable of supporting multiple features:
a) Assume a situation where you want the users to have authority to only read all the attachments but not to rename or delete them. How can you restrict them?
This BAdI provides solution to this problem.
Previously before this solution, providing object type and object key would suffice to load attachments corresponding to that object key. With this newly introduced BAdI method, first the authorization check is done against the operation being performed on attachments i.e READ (display list of attachments), CREATE (adding attachment), and DELETE (delete Attachment). This is a filter-based BAdI having filters for OBJECT_TYPE and OBJECT_TYPE_LONG. So there can be multiple active implementations and it will be specific for each object type. If Implementation exists for an object type, only then users will be able to perform any action on attachments related to that object type and key. Also, in the implementation based on activity type, it is possible to restrict or allow any activity.
b) This BAdI method is also capable enough to restrict uploading of attachment or getting list of attachment based on check on any of the attachment properties. It can restrict based on mimetype, file extension of attachment, created by, created at date of the attachment, or even file size of the attachment. If you have any condition that file size greater than 10 MB should not be displayed or attachments will extension .txt should not be loaded or any similar scenario, this BAdI method addresses such requirements. A changing parameter having list of all attachments is passed to the BAdI. In the implementation, based on mimetype or file extension of the attachments, users can restrict CREATE and READ operation.
4) BAdI : BADI_CV_ODATA_ATTACHMENTS_AUTH
Method : CHECK_USER_AUTHORIZATION
For the same scenario as mentioned above, where you want users to only to be able to read the attachments and not perform any action on them. Then using this BAdI you can control the visibility of rename, delete, and add action available for attachments. So now if a particular user is unauthorized to perform any particular action, then the user won’t see the corresponding button on the UI.
Before restricting delete and rename actions based on User , UI appears as :
After restricting delete and rename actions , UI appears as :
- SAP Managed Tags:
