Embed Size (px)
DESCRIPTION
Attachments Development Guideline
Citation preview
SAP
Attachments
Development Guideline S/4HANA
Poovananathan, Sunder; Mandot, Utkarsh
2015-07-31
Table of Contents
1. Attachment Services Overview.............................................................................................................1
2. UI Consumption Details........................................................................................................................ 2
2.1 Embedding Attachment Service component in Parent Application..............................................2
2.2 Operations Supported by Attachment Service...................................................................................6
3. Backend Consumption Details..............................................................................................................7
3.1 Backend API Details.......................................................................................................................... 8
3.2 Object Existence Check................................................................................................................... 11
4. Gateway Service Consumptions Details.............................................................................................12
5. Pre-requisite Customizing Settings.....................................................................................................12
5.1 For consuming applications which uses GOS..................................................................................12
5.2 For consuming application using Document Objects.......................................................................13
5.2.1 How to define Object Types and link them to Document Info Record:.......................................13
6. Enable Deletion of Draft Attachments.................................................................................................14
7. Test Application.................................................................................................................................. 14
1. Attachment Services OverviewThe objective is to give the Simplified Suite users the capability in a cloud scenario to handle
attachments. This includes the capability in the user interface of the business object to upload and download attachments, to assign those attachments to a business object and to store the attachment content inside the cloud or content server. This is a re-usable solution with which different applications / business objects of simplified suite can easily integrate and consume the attachment service. Going forward, this solution would be the only way of using attachments in the simplified suite world. The attachment service (as part of the first release) is planned to support uploading, downloading, renaming, deleting an attachment from/to the parent application.
The Attachment Service supports the concept of Draft for the scenario of adding a new attachment, changing the attachment name and deletion of attachment. The changes are persisted only when the explicit save is done by the user.
Attachment Service is based on SAP Document Management System (DMS) or Generic Object Services (GOS) for the storage of the attachments. The actual attachment content is stored using the HCP Document Service using SAP KPRO interface.
The interface of the attachment service works with two mandatory parameters i.e. the Object Key and the Object Type. Both parameters are passed by the consuming application. There is a technical restriction on the maximum length of the Object Key (i.e. maximum length restriction of Char50). Object Type is a maintained in the customizing and is described in section 5.
The Generic Object Services provides different functions such as adding an attachment, displaying all the attachments etc. It is available in various SAP applications. GOS Object support maximum length
of the Object Type ID Char 32 (referred to as Object Type in the below sections of the document) and Attachment service API’s, backend ODATA service and UI supports maximum length of Object Type ID of char 10. Hence consuming application based on GOS need to maintain Object Type ID mapping between GOS and Attachment Service as detailed out in section 5.1. If this customizing is not maintained in section 5.1 attachment services stores the attachment based on SAP Document Management System.
Note: - Attachment Service only supports Attachment scenario of GOS. GOS Scenario’s like Note, Business Document and External Document (URL) are not supported in Attachment Service.
2. UI Consumption Details The UI Component can be consumed by any one of two approaches depending on consumption scenario:
1. Embedding the Attachment Service component in Parent Application3.4. The steps to consume embedded scenario approach are mentioned below:
4.1 Embedding Attachment Service component in Parent Application
Step 1: Register Attachment component in application
A. Steps for FIORI 2.0 Only (parent pom version should be 1.7.0 or greater) Referencing the Reuse Library in pom.xml file
<dependency><groupId>com.sap.fiori</groupId><artifactId>se.mi.plm.lib.attachmentservice</artifactId><version>10.2.0-SNAPSHOT</version>
</dependency>
Add Dependencies in manifest.json file"dependencies": {
"minUI5Version": "${sap.ui5.dist.version}","libs": {
"sap.se.mi.plm.lib.attachmentservice": {"minVersion": 10.2.0-SNAPSHOT
}},"components": {
"sap.se.mi.plm.lib.attachmentservice.attachment": {"minVersion": 10.2.0-SNAPSHOT
}
}
Note: If you are migrating from FIORI 1.0 to FIORI 2.0 then components can embed you need to remove below code from your component.js file.
// check for BSP environment and set reuse library path(function() { var sPath = jQuery.sap.getModulePath("<app module>"); if (sPath.indexOf("/<app BSP name>") !== -1) { if (sPath.lastIndexOf("/") !== sPath.length - 1) { sPath += "/"; } jQuery.sap.registerModulePath("sap.se.mi.plm.lib.attachmentservice.attachment", sPath + "../mi_plm_ath_cre/sap/se/mi/plm/lib/attachmentservice/"); }}());Here
<app module>: Consuming Application Project Name<app BSP name>: Consuming BSP Application Name
Modification in ViewUI components can embed in your views via the ComponentContainer (core library) control:
<core:ComponentContainer id="idastestcompContainer" />
Update the neo-app.json in root for testing in SAP Web IDEOpen the neo-app.json on root level (used at design time in SAP Web IDE) to see the route for the Fiori Library. If there is path with only "/src/main/webapp/resources":Old Entry:{ "path": "/src/main/webapp/resources", "target": { "type": "application", "name": "semiplmlibattachmentservice", }, "description": " Reuse Library for Attachment Control Component (River RDE)”},
Replace old entry with new entryNew Entry: { "path": "/src/main/webapp/resources/sap/se/mi/plm/lib/attachmentservice", "target": { "type": "application", "name": "semiplmlibattachmentservice", "preferLocal": true }, "description": "Reuse Library for Attachment Control Component (River RDE)" }, { "path": "/resources/sap/se/mi/plm/lib/attachmentservice", "target": { "type": "application", "name": "semiplmlibattachmentservice", "preferLocal": true }, "description": "Reuse Library for Attachment Control Component (River RDE)" }, { "path": "/src/main/webapp/resources", "target": { "type": "application", "name": "semiplmlibattachmentservice", "preferLocal": true }, "description": "Reuse Library for Attachment Control Component (River RDE)"
}
Note: -o If your application is based on new UI5 Freestyle template then /src/main/webapp should
be replaced with /webapp.o Library route should be included before the UI5 routes
Reference Links:https://wiki.wdf.sap.corp/wiki/display/fioritech/Descriptor+Migration+Guide+for+Fiori+Librarieshttps://wiki.wdf.sap.corp/wiki/display/fiorisuite/AT1+UI+Reuse+Guideline
B. Steps for FIORI 1.0 Only Referencing the Reuse Library in pom.xml file
<dependency><groupId>com.sap.fiori</groupId><artifactId>se.mi.plm.lib.attachmentservice</artifactId><version>10.1.0</version>
</dependency>
Modification in component.js (Temporary work around for FIORI 1.0)
Insert the following code into the Component.js at the top between the jQuery.sap.declare and the sap.ui.core.UIComponent.extend statements:
// check for BSP environment and set reuse library path(function() { var sPath = jQuery.sap.getModulePath("<app module>"); if (sPath.indexOf("/<app BSP name>") !== -1) { if (sPath.lastIndexOf("/") !== sPath.length - 1) { sPath += "/"; } jQuery.sap.registerModulePath("sap.se.mi.plm.lib.attachmentservice.attachment", sPath + "../mi_plm_ath_cre/sap/se/mi/plm/lib/attachmentservice/"); }}());Here
<app module>: Consuming Application Project Name<app BSP name>: Consuming BSP Application Name
The final step is adding the library name to the dependencies section of your Component.js:metadata: { dependencies: { libs: ["sap.m", "sap.se.mi.plm.lib.attachmentservice"], components: ["sap.se.mi.plm.lib.attachmentservice.attachment"] },
Modification in ViewUI components can embed in your views via the ComponentContainer (core library) control:
<core:ComponentContainer id="idastestcompContainer" />
Update the neo-app.json in root for testing in SAP Web IDEOpen the neo-app.json on root level and insert below entry:{ "path": "/src/main/webapp/resources", "target": { "type": "application", "name": "semiplmlinattachmentservice", }, "description": " Reuse Library for Attachment Control Component (River RDE)”}, { "path": "/resources", "target": { "type": "application", "name": "semiplmlinattachmentservice", }, "description": "Reuse Library for Attachment Control Component"},
Step 2: Create & initialize the Attachment Service Component instanceConsuming application need to initiate the reusable component of Attachment service. Initialization could be done on the business usage of the attachment service e.g. it could be done on the user action like Tab switch or press of a button press. Below is a sample code which would help in doing the initialization.
Sample code:oController._oComp = sap.ui.getCore().createComponent({
name: "sap.se.mi.plm.lib.attachmentservice.attachment",id : oController.createId("ASComp"),settings:{ mode: param1, objectKey: param2, objectType: param3});
Parameters: Name: “se.mi.plm.lib.attachmentservice” should be same as shown in above sample code.Id : can be created with any unique text(i.e. ASComp)
Parameter details:
Parameter Description
param1 Mode of Attachment Service component Create(I), Change(C) or Display(D)
param2 Primary key of linked SAP object e.g. MATNR for Material Master
param3 Linked SAP Object e.g. MARA for Material Master
Note:For GOS based consumption, param2 comes with a restriction of char 50 length and param3 of char 10 length.
Some of the consuming applications may have a composite key (more than one key field). In this case, the param2 must be passed by concatenating all the key fields. For example, a Document Info Record consists of 4 key fields.
Key field Name Length in characters
Document Type 3
Document Number 25
Document Part 3
Document Version 2
The Document number is most important part of Key and it could have values which the system proposes (internal number) or as entered by User (external number).
Hence sharing the scenario how we expect the Object Key should be passed when the object has a composite key.
Case1: Internal number:
Key field NameLength in characters
Example Values
Document Type 3 DRW
Document Number 25 10000044136
Document Part 3 000
Document Version 2 00
Here param2 will be passed as “DRW000000000000001000004413600000”. The leading places of the Document Number are filled with Zeroes.
Case 2: External number:
Key field NameLength in characters
Example Values
Document Type 3 PRT
Document Number 25 PDFDOC_11
Document Part 3 000
Document Version 2 00
Here param2 will be passed as “PRTPDFDOC_11 00000”. The trailing places for document number are filled with blank spaces. In this example the character positions from 13 to 28 are with blank spaces as the document number is of 9 characters.
Step 3: Create a component container, passing the component instance
Assign above attachment service created component instance (as in Step 2) to component container.
Sample Code: this.byId("idastestcompContainer").setComponent(oController._oComp);
2.2 Operations Supported by Attachment ServiceAddition of new attachment, Renaming of attachment, Deletion of attachment can be confirmed only if the user presses the Save Button of the respective application. Similarly the changes can be reverted back by the use of the Cancel button. Consuming applications can trigger Save or Cancel from backend or UI.
If Save is triggered from UI, call save() method from consuming application referring to the Attachment service component. An input parameter to save/cancel method is “isRefresh” which is of type Boolean. This indicates whether a read to get the latest content is required after a save/cancel operation.
Note: For GOS based consuming applications, rename of attachments is NOT supported from Attachment Service.
Sample Code: Var response = oController._oComp.save(true); // if a read is required after saveVar response = oController._oComp.save(false); // if a read is not required after save
If Cancel is triggered from UI, call cancel() method from consuming application referring to the Attachment service component.
Sample Code: Var response = oController._oComp.cancel(true); // if a read is required after cancelVar response = oController._oComp.cancel(false);// if a read is not required after cancel
Here: o response is object which contain three Boolean attributes
Attributes Description
isSaved Attribute will return true if Save done successful
isRefreshedAttribute will be return true if Originals are retrieved successful after save and isRefresh passed true
isCanceled Attribute will return true if cancel done successful
Refresh:With this function, consuming applications can refresh the contents of attachments view. For instance, in the consuming application, when user makes a shift from change mode of the application to read-only mode (or vice-versa), the attachment view can also be forced to react accordingly by calling the refresh () method. In read-only mode, the controls in attachment view like “Add” button, “Edit” button, “Delete” button, “Rename” button will be disabled.
Sample Code:oController._oComp.refresh(asMode, objectType, objectKey);
getApplicationState:Consuming applications can call this method getApplicationState( ) at any point in time to understand if the attachments content is dirty or not. That means, if user has made any changes to any attachment or not. This returns a Boolean value. True -> if the attachment content are changed and a save is required.False ->if there are no changes recorded to attachment services. No save is required.
Sample Code:Var applicationState = oController._oComp.getApplicationState( ); Note:
After a SAVE or CANCEL action, this value will be false (unless a change happens). Scenario: If user has renamed an attachment. Refreshes the browser without saving or
cancelling. Here the change to the attachment is already recorded and the application is dirty. After reloading the page, if getApplicationState() is called, then it returns back a value “true” indicating a save is required.
getAttachmentCount:This method will be useful when the attachment view need not be shown, but the consuming applications need a count of attachments. The attachment service component has to be initialized at this moment in order to call this method.
Sample Code:var countOfAttachments = oController._oComp.getApplicationCount();
This method returns the following:countOfAttachments : {
totalAttachmentCount : <<Integer value>>, confirmedAttachmentCount : <<Integer value>>, unconfirmedAttachmentCount : <<Integer value>>
}Parameter Definition:unconfirmedAttachmentCount :: provides the count of attachment associated to an Object which were either deleted or newly added or have their name changed since the last Save or Cancel operation of user. In summary this parameter provides the count of attachments which are in draft state.confirmedAttachmentCount :: provides the count of attachments which were added new, deleted and had their name changed and were followed by Save or Cancel operation. Additionally there are no change to the attachments.
totalAttachmentCount :: provides the total count of confirmed and unconfirmed attachments. When an existing attachment is deleted or changed and save operation is not done, such
attachment are considered as unconfirmed attachment. Since such unconfirmed attachment already exist, the totalAttachmentCount would remain the same.
5. Backend Consumption DetailsAll operations related to attachments like adding an attachment, renaming and deleting to/from a parent object type (Ex: Material, CRM Activity, SRM Shopping Cart etc.), is done in two steps. Operation has to be performed and then user has the option to SAVE or CANCEL these operations. This SAVE or CANCEL is nothing but the parent object’s SAVE or CANCEL.
On SAVE, all changes to any attachment will be moved to a permanent state. On Cancel, all changes to any attachment will be simply ignored. Contents of newly added
attachments will be deleted from the storage server.
These transactional capabilities can be achieved by the following ways:
1. From the UI (by calling the SAVE or CANCEL methods of the component – Attachment service) which in turn calls the Gateway service to accomplish the goal
2. From the backend (by calling the below mentioned methods), called by the parent object’s backend implementation
3.1 Backend API Details
Package Name ODATA_CV_COMMON
Class Name CL_ODATA_CV_ATTACHMENT_API
Instantiation Generation Type Singleton
Final X
Method name
GET_INSTANCELevel Static Final
Eventclass/Event Visibility Public Abstract
Contract
English
Short Description Get instance of this class - Singleton
Unit tested
Functionality Get the instance of class CL_ODATA_CV_ATTACHMENT_API
Preconditions
Result Object is instantiated
Parameter nameParameter Type
Data Type Ref. Def. Value
RO_ATTACHMENT_API Returning CL_ODATA_CV_ATTACHMENT_API X
Method name
IF_ODATA_CV_ATTACHMENT_API~SAVELevel
Instance
Final
Eventclass/ Visibility Public Abstract
Event
Contract
English
Short Description Saves all the draft attachments
Unit tested
Functionality
All the attachments in draft(unconfirmed) state will be linked to a Document Info Record and saved to a permanent state(committed to database)
For example, user can add an attachment to a material. Without a save, user can view the contents of the attachment, rename & delete the attachment. Upon SAVE, a Document Info Record will be created and the attachment will be linked to it. This will be a permanent state.
Note: After any operation on attachments, if user refreshes the UI application without save, the attachments will still retain their states.
Preconditions
Result Attachments are linked to a Document Info Record and persisted in database.
Parameter name Parameter Type Opt. Data TypeRef
.Def. Value
IV_OBJECTTYPE Importing DOKOB
IV_OBJECTKEY Importing OBJKY
IV_TEMP_OBJECTKEY Importing Optional OBJKY
EV_SUCCESS Exporting BOOLE_D
ET_MESSAGES Exporting BAPIRET2_T
Method name
IF_ODATA_CV_ATTACHMENT_API~CANCEL Level
Instance
Final
Eventclass/Event
Visibility PublicAbstract
Contract
English
Short Description Cancels all the draft attachments
Unit tested
Functionality
All the attachments in unconfirmed state will be cancelled permanently
For example, user can add an attachment to a material, delete an existing attachment from a material. Upon Cancel, the newly added attachment’s content will be removed permanently from the storage server and the attachment which is deleted from the Material will remain visible (Marked for deletion, but actual deletion will happen only on SAVE).
Note: After any operation on attachments, if user refreshes the UI application without save/cancel, the attachments will still retain their states.
Preconditions
Result Attachment contents are removed permanently
Parameter name Parameter Type Opt. Data TypeRef
.Def. Value
IV_OBJECTTYPE Importing DOKOB
IV_OBJECTKEY Importing OBJKY
EV_SUCCESS Exporting BOOLE_D
ET_MESSAGES ExportingBAPIRET2_T
Method name
IF_ODATA_CV_ATTACHMENT_API~MASS_UPLOAD_ATTACHMENTS Level Instan Fin
ce al
Eventclass/Event
Visibility PublicAbstract
Contract
English
Short Description Mass upload of attachments
Unit tested
Functionality
Additional info: When an Mediacontent(also referred to as File) is passed to the API, a Document Info Record(DIR) is created in the background. The File is first uploaded to the Repository (configured by Attachment Service) and then associated to the DIR. The DIR is then linked to the Object which is passed by the consuming application. A DIR can have one or more File associated to it. It’s recommended to always have one to one relationship with Object key to DIR to File. If the consuming application has the knowledge of the DIR, then the DIR could be used as an input parameter. Consumers who do not know more info on the DIR can ignore passing any value for the parameter IS_DIR_ID.Parameter info:If DIR (Document Info Record) is passed (optional), then all attachments will be linked to this DIR.
If one DIR has to be created for each attachment, then IV_MULTI_DIR_CREATE has to be passed as ABAP_TRUE. In this case, the parameter IS_DIR_ID must be initial.
IV_AUTO_COMMIT can be passed with value as “true”, if SAVE has to be called within the API implicitly. Applications can decide this commit and can call their own commit work for persisting the data.
ET_FAILED_CONTENTS will contain all the attachments which could not be uploaded successfully.ET_ATTACHMENT_URL : This contains the URL to access the Files which are stored in the repository.
Preconditions
Result Attachment contents are uploaded into the storage system and linked to the Object type and Object key.
Parameter name Parameter Type Opt. Data TypeRef
.Def. Value
IV_OBJECTTYPE Importing DOKOB
IV_OBJECTKEY Importing OBJKY
IS_DIR_ID Importing Optional BAPI_DOC_KEYS
IV_MULTI_DIR_CREATE Importing Optional BOOLE_D false
IT_MEDIA_CONTENT ImportingIF_ODATA_CV_ATTACHMENT_API~TY_T_MEDIA_RESOURCE
IV_AUTO_COMMIT Importing Optional BOOLE_D false
ET_ATTACHMENT_URL ExportingIF_ODATA_CV_ATTACHMENT_API~TY_T_ATTACHMENT_URL
ET_MESSAGES Exporting BAPIRET2_T
ET_FAILED_CONTENTS ExportingIF_ODATA_CV_ATTACHMENT_API~TY_T_ATTACH
Note: For consuming applications which uses GOS, the following 2 parameters are not applicable.
IS_DIR_ID
IV_MULTI_DIR_CREATE
Method name
IF_ODATA_CV_ATTACHMENT_API~RETRIEVE_ATTACHMENTS_CONTENT Level
Instance
Final
Eventclass/Event
VisibilityPublic
Abstract
Contract
English
Short Description Retrieve the attachment's contents
Unit teste
dFunctionality For a given Object type and Object Key, all related attachments can be retrieved.
Preconditions
Result
Parameter name Parameter Type Opt. Data TypeRef
.Def. Value
IV_OBJECTTYPE Importing DOKOB
IV_OBJECTKEY Importing OBJKY
ET_ATTACHMENT_CONTENTS
ExportingIF_ODATA_CV_ATTACHMENT_API~TY_T_ATTACHMENT_CONTENT
ET_MESSAGES Exporting BAPIRET2_T
No te:
The above methods throw an exception of type CX_ODATA_CV_BASE_EXCEPTION which is non-resumable.
Attachments can also be added in the create mode of the consuming application. In most applications, the key or the ID of the Object will be generated only at the time of SAVE. In such scenarios, the consuming applications have to mandatorily pass an object key (a temporary key could be generated & used) to the attachment service. This is required to create a link between the attachments and the consuming application.
During the save of the consuming application (after the permanent key is generated), a call can be made to the attachment services’ backend SAVE() method via class CL_ODATA_CV_ATTACHMENT_API and pass the new object key along with the old object key (temporary key). This API will replace the temporary key with the new permanent key.
3.2 Object Existence CheckNote: Object existence check is not applicable for attachments which are created for GOS based consuming application
Attachment service is heavily depending upon the Object type and the Object key as all the attachments are linked to the Object key ultimately. So it is necessary to do an Object existence check before any attachments can be made towards the Object.
In order to validate the object key, two options are available:
All consuming applications have to create a Function Module with name OBJECT_CHECK_<<OBJECT_TYPE_NAME>>. Here OBJECT_TYPE_NAME can be a maximum of 10 characters. Inside this FM, there can be a validation done to check if the object exists, any system failure during its access.
This function module must minimum contain the following parameters:
Parameter NameDescription
ObjectKey Primary key of linked SAP object e.g. MATNR for Material Master
ObjectType Linked SAP Object e.g. MARA for Material Master
Parameter name Parameter Type Opt. Data Type Ref.Def. Value
SINGLE Importing Optional SPACE
OTAB Table Parameter RMCLOBTX
Exceptions to be raised by this Function Module:FOREIGN_LOCK Record blocked by other userOBJECT_NOT_FOUNDObject is not validSYSTEM_FAILURE Blocking error
Example: There are already function modules available for various objects. In SE37, they can be searched by “OBJECT_CHECK*”. OBJECT_CHECK_MARA, OBJECT_CHECK_VBAP etc. can be used as reference for implementation.
If this function module need not be implemented, then applications have to implement the badi ‘DOCUMENT_OBJ’ with appropriate Object type as filter value which will prevent this validation call. The method OBJECT_CHECK has to be implemented with exporting parameter ‘RUN_NO_ACTION’ set to abap_true.
6. Gateway Service Consumptions Details
Service URL:
https://ldai1er3.wdf.sap.corp:44335/sap/opu/odata/sap/CV_ATTACHMENT_SRV ?$format=xml
Metadata URL:
https://ldai1er3.wdf.sap.corp:44335/sap/opu/odata/sap/CV_ATTACHMENT_SRV/$metadata
7. Pre-requisite Customizing SettingsAttachment service, as defined in the above sections, is used to manage attachments related to an Object type e.g. MARA for Material Master. Attachment Service will make use of Document Info Record (DIR) to link the attachment to the Object Type when DMS is consumed. To accomplish the linking, the Object type has to be mapped to a Document type in the backend customizing. When GOS is consumed, the relationship to document type is not required.Additional info: The attachment service team could help you out to do the below mentioned customizing
5.1 For consuming applications which uses GOSMake an entry in the customizing as follows:
IMG Path: Cross-Application Components -> Document Management -> Additional Settings – Simplification -> Attachment Service – Object Type mapping
Object Mapping customizing contain two columns: -o SAP Object: It is an object id which will be passed by consuming application as Object
Type (Max Char length 10). This will be used for linking the attachments to the parent object
o Object Type: Business Object Id for GOS object (Max char length 32).
Attachment service will use GOS scenario only if Object mapping customizing is maintained else it will use DMS as a default scenario. To define a new Object Type, Step 1 of section 5.2.1 could be used
5.2 For consuming application using Document Objects
5.2.1 How to define Object Types and link them to Document Info Record:
Step 1: Define new Object Type(required only if the object type does not exist in the sSuite system)
SPRO->Cross-Application Components->Classification System->Classes->Maintain Object
Keys
Step 2: Define and associate Document Type with Object type1. SPRO->Cross-Application Components->Document Management->Control Data->Define
Document Type.
2. Maintain the object link for a defined document type (created above) in transaction DC10.
8. Enable Deletion of Draft AttachmentsDeletion of draft attachments is an optional administrative activity. A report program DELETE_DRAFT_ATTACHMENTS is available for administrators to delete all the draft attachments. This has been introduced with an intention to efficiently utilize the cloud space. i.e, long pending draft attachments which are not saved can be deleted so that the space occupied by those attachments is removed.
BAdI Name: BADI_CV_ODATA_ATTACH_DRAFT_HDL Interface: IF_EX_CV_ODATA_ATTACH_DRAFT Method: DRAFT_DELETE_AVOID
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.
The parameter CT_ATTACHMENTS is of type “changing parameter” and the BAdI implementation should clear the respective attachment entry from this internal table to avoid getting deleted. In short, all entries in this table will be deleted permanently.
9. Test ApplicationA test application is available which consumes the attachment service UI component. This test
application exhibits all the features of the consumption. The details of the test application are as follows:
1. Here the consuming application is “Document Info Record” whose object type is defined as “DRAW”. Attachments are linked to the DRAW object.
2. Refresh button on the footer is set to showcase changing the mode of the application (Change mode to read-only mode and vice versa).
3. Link to the Test application project:
Test application project name (Project Portal): se.mi.plm.attachmenttestapp
Project Page for Test Application: https://projectportal.wdf.sap.corp/projects/se.mi.plm.attachmenttestapp
Use the source location from the above link
4. The consuming applications can download this project into eclipse to make use of the consumption pattern, code snippets, debugging etc.
5. The following link will help to test this test application:
