While selective deletion should be your last resort as part of a process chain – due to the fact that the providers are locked and can not be reported during the deletion. But – be it for data provider maintenance tasks (deletion of old data), data correction or during regular data load process when the data needs to be deleted first before the new data gets loaded – sometimes there is no better option. Not all extractors support delta loads, and overlapping request deletion will not work in every case either.
You probably know already how to delete data from a data provider manually:
- manual execution of selective deletion in transaction RSA1. Unfortunately, the selection cannot be saved and edited later on since the selection screen is generated on the fly. As soon as the selection screen is closed, a deletion report is generated and will be executed once the deletion is started.
- selective deletion can be also executed with the transaction DELETE_FACTS (report RSDRD_DELETE_FACTS). With this report deletion can be executed directly, but also the reports can be generated for the selection screen and for the deletion itself.
The generated report will stay in the system for longer, and could be used in process chains as well via the ‘ABAP program’ process type. The disadvantage of this trick is that the selection cannot be changed easily afterwards. Also, there is no possibility of defining dynamic selections ( e.g. to delete the current year/month instead of a hardcoded period).
For process chains there is no standard process type which would implement a selective deletion. This is really a pity, as this functionality is often required, and would not be a big deal for SAP to implement. Luckily, with a little bit of DIY, it is possible to create such a process type as a customer extension. In this blog post I will give you some hints on the most important steps to implement a custom process chain process type for selective deletion.
The implementation class
To create a custom process type we need to create an ABAP class that contains the logic and the ‘administrative tasks’ of the process type. The class needs to implement the following interfaces:
The most important methods to be implemented are described below.
Execution logic
The execution of the selective deletion is implemented in IF_RSPC_EXECUTE~EXECUTE. An application log instance needs to be created first to be able to write the selection criteria into the log. The process chains variant’s attributes are read from the generic variant storage tables – this includes the provider to be deleted from, and the selections. Finally the function module RSDRD_SEL_DELETION is called for the deletion itself. The messages of the deletion are written to the process chain’s log.
Logging and log display
To display the messages in the process chain monitor, we need to implement method IF_RSPC_GET_LOG~GET_LOG. We use the standard methods of the Business Application Log component to display the log.
Variant handling
When you add a process to a process chain, the system will ask for the variant of the process type that should be executed. Maintenance and selection of the variants is process type specific, and we need to implement this functionality ourselves using the following methods:
IF_RSPC_MAINTAIN~GET_VARIANT: in this method we need to implenet logic that can tell if a variant exist and return the description. For this we use the standard method CL_RSPC_VARIANT=>F4.
IF_RSPC_MAINTAIN~MAINTAIN: in this one we implement the maintenance of existing process type variants and also the possibility of creating new ones with all the necessary attributes, such as ID, description, data provider and selection criteria for deletion. The variant will be saved into the general variant attribtue storage table, and also a transport possibility is provided.
The maintenance screen – containing a table control – is implemetned as part of a custom function module.
IF_RSPC_DELETE~DELETE: deletion of process type variants is implemented in this method.
Registering the process type
In order to make the process chain editor aware of the existence of your new process type, we need to register it. This is done in the RSPC transaction by going to Setting -> Maintain Process Types.
The selection criteria entry screen
The custom process type requires a separate screen for the maintenance of the attributes of the selective deletion. This screen and the corresponding logic is implemented in a function module. The selection criteria can be entered in a table control – a search help being available to access the InfoObjects of the provider.
Entering the restrictions for the deletion this way is technically a lot easier to implement than a selection screen with individual fields for each infoobject. But also from a UX perspective it has some advantages: You can immediately get an overview of the deletion selections – the values are not ‘hidden’ in the multi-value-selection popups. Plus, you can easily copy-paste the values in and out of this screen – and enter placeholders as well (see below).
Capabilities
Our new custom process type can not just do the same thing the manual selective deletion does as part of a process chain – it can even do more…
Selection criteria
The standard selective deletion feature does not support wildcard selections (e.g. “AT*”). In the selection screen dialogs pattern selections are explicitly hidden in value list for the comparison type operator.
If nevertheless a pattern selection is entered as a selection for a numeric InfoObject, an error message is displayed. For InfoObjects with character type, the pattern selection is interpreted as value – including the literal character * – and not as pattern. As a result the selective deletion will not delete the records that were meant to be selected.
This screenshot shows the selective deletion log. The entry with “Delete criteria ID” = 929 is the log entry for the standard selective deletion executed from transaction RSA1.
Looking at the details we can see that the selection was not interpreted as a pattern selection.
With a custom process chain type patter selection suppoert can be implemented as well: the pattern selections are correctly processed during deletion, as you can see from the log entries for “Delete criteria ID” = 931.
Supported data provider types
As we are internally using the standard function module RSDRD_SEL_DELETION for deletion it is assured that all kinds of data provider types are supported:
- InfoCube: data is deleted from both compressed and uncompressed requests
- Classic DSO (ODSO): data from not activated requests is not deleted
- Advanced-DSO (ADSO)
All types of ADSO are supported (direct update, Cube like, Standard DSO like, etc.) except of write optimized aDSOs.
Since write optimized ADSOs only have inbound tables, selective deletion is not possible – neither with our custom solution nor with the standard selective deletion.
For Classic-DSO like ADSOs, data can not be selectively deleted from requests which are not yet activated. This is also a system limitation. - To delete data from Planning ADSOs, first the ADSO need to be switched into Load mode, otherwise the deletion process will break. This is something that can easily be added to the code so that the process type would automatically switch to load mode before the deletion and back to planning mode once finished. It could even notify users owning planning locks to log out, and give them a grace period to leave the system without continuing with the deletion.
Dynamic selections via placeholders
If we want to automate the selective deletion in a process chain without maintaining the selection every year / month / week, typically we need to find the way of defining selections where the specific value is evaluated at the time of the execution of the process.
I am using predefined placeholders for this purpose. E.g. by defining <CURRYEAR> as selection value, during the execution of the selective deletion, the placeholder is evaluated and replaced by the current year.
More complex selections could be also achieved by defining offsets to the placeholder values.
The logic of the placeholder evaluation is implemented in a separate method of the process type’s class and can be adapted according to customer needs – either in ABAP or via the formula editor.
Get the source code
You can purchase the selective deletion process chain implementation from Evosight as part of a one-day consulting package. See the our solutions page for details.
Cover picture by Terence Ong, source Wikimedia Commons
1 Comment