Deletion of delivered objects in Customer Specific solutions

Overview

Currently, PDI solutions do not have any restrictions on the number of objects that can be created within a solution. Also, due to maintenance mode, deletion of few delivered (already assembled) content is restricted. This tends to increase the size of a PDI solution and thus many customers end up having large PDI solutions. Due to the increase in size, the time taken for the Lifecycle Management processes like Activate, Assembly and Deployment on these solutions tend to increase. Also, due to guardrail features like limit of extension fields, it is required by the end user to delete such obsolete extension fields. To overcome this constraint and support deletion, the feature of allowing deletion of delivered objects (DODO) is introduced.

Deletion Patch

To allow Deletion of delivered objects, a new patch variant is introduced in SDK named as Deletion Patch. A deletion patch allows deletion of delivered content even in maintenance mode. This patch follows similar lifecycle of a regular patch, i.e. it would have the same patch namespace, versioning and would follow a similar assembly and deployment lifecycle management process.

Pre-requisites:

In order to create a deletion patch, the following pre-requisites should be met:

• Deletion of delivered objects Authorization: Work center view needs to be assigned to the user.
• Solution should be of type – Customer Specific solution.
• Solution should be “Assembled” in 1902 and one regular patch should have been created, that means DODO patch cannot be the first patch.

Once the above pre-requisites are met, the user can see a new create Deletion patch button on the SDK like the one shown below:

After the patch creation button is clicked, a disclaimer pop-up is shown to the developer stating that deletion of objects in this patch would also delete the data corresponding to these objects in the dev tenant as well as on the tenants where this patch is deployed.

• Once the user Clicks on OK in the above dialog box, the solution status changes to – “In Development – Deletion Patch”.
• User can now delete extension fields in an XBO. Once the XBO is activated, these extension fields should be adjusted in other content types to make the solution consistent. In order to understand which content types need to be adjusted, a solution level consistency check should be run and the adjustments should be made accordingly. The next step would be  to assemble and download the deletion patch and then deploy it to the target tenants.

Features of Deletion patch:

• Import of solution template into a deletion patch is restricted.
• Download a copy as new solution in a deletion patch is restricted.
• GDPR content (like PDD and PSD or content referring to the same) cannot be deleted in a deletion patch.
• User is allowed to create only 3 consequential Deletion patches.
• Deployment of a normal patch is restricted to target tenant if the previous DODO patch is not present. For e.g. if a user created normal patch 4 and Deletion patch 5 and then a normal patch 6 on the source. Deployment of version 6 to target(already running on version 4) will not be allowed until Deletion patch 5 is deployed.

Current Scope (as of 1911):

• The feature is GA.
• A deletion patch can only be created on a 1902 assembled patch namespace solution.
• One-off solutions support Deletion patch.
• Only deletion of extension fields is supported as part of Deletion patch.
• Any other change in BO definition like adding a new field, changing field, adding annotation etc is not supported in Deletion patch. So a word of caution, do not remove a field and activate Deletion patch if you are planning to revert the change.
• In case extension fields are being used in custom artifacts like ABSL, reports, form templates etc, a consistency check error will be thrown on Solution level check after the field is deleted. So, other content types would need to be adjusted if an extension field is deleted.
• In case an extension field is used to extend a standard entity (such as screens, web services, data sources, reports etc.), deletion of the extension field will remove the reference from all these entities automatically. Only in the case of standard forms, in case the partner has manually added the extension field to a form template from the UI, then, the partner would need to remove this reference manually from the Administrator->Business Flexibility->Form Template Maintenance Work screen (The same way the partner added the field to the form).
• Where Used Wizard can be used in 1911 which will give reference of the extension field that you wish to delete. So now with 1911 you can already find out where an extension field is used so that a conscious decision can be made for deletion of fields.
• Extension fields used in content types created outside of the SDK lifecycle (like key user analytics, oData services etc.) would need to be adjusted manually by the developer before removing extension fields in the XBO.
• If any of the below content types have only one extension field and that field is deleted, then a deadlock situation might occur as the deletion of these content types is still not allowed in maintenance mode. In such cases SAP would support in deletion of these content types.
  • Custom Query
  • Custom data source
  • Custom forms.

Note : A deletion patch should be created only if necessary because if a deletion patch is created and assembled in the source tenant, a mandatory deployment of this version would be required in the target tenants (prod/test). Also, if extension fields are deleted in a deletion patch and activated then there is no way to retrieve it or the previous solution version.

This feature is only supported for C4C tenants.