Delete later

See also: Save changes later

Event action – Abstract

Purpose: Flags an entity for deletion at the completion of the current transaction.

images/download/attachments/83165445/image2021-4-14_17-9-12-version-1-modificationdate-1633440316199-api-v2.png

The event action Delete later creates a flag for deletion for the current reference object within event handling.

When the transaction is completed, the entity in question is then deleted if it still exists.

NOTE◄ For a reference object that has never been saved, executing Delete later usually has no effect. In the context of an input form that provides a volatile input object directly after executing 'New' or 'Copy', this object cannot be 'discarded' by calling an event handling with the event action Delete later.

Definition of the reference object

In the simplest case, the current reference object is the entity determined by the event handling data context.

However, there are also event actions (e.g. Execute with or For each loop) that can temporarily override the current reference object at runtime. The configuration of the event action provides a defined block of event actions to be executed in the context of an alternative reference object. At runtime, the alternative reference object is considered the current reference object for these event actions, as can be traced via the value of the variable entity, if applicable. Within such an action block, the event action Delete later also refers exclusively to the entity temporarily defined as the reference object.

Within an event action that provides an alternative reference object, Resolvers can generally be used to define a specific reference object:

IMPORTANT◄ The Delete later event action should be executed only with independent entities as the reference object and not, for example, with attributes or items of business objects. No corresponding check takes place at runtime, and executing the event action for a related object that cannot actually be stored (interactively) on its own may lead to unexpected results when the transaction is completed.

Flag for deletion

The flag for deletion takes into account the applicable logon context (company, role, user) at the time of execution of the Delete later event action, which may be defined as temporarily different from the current session at runtime by the Run as event action.

  • If the Delete later event action is executed multiple times within the same transaction for the same reference object, the flag only takes the logon context of the last execution into account.

  • This login context is the deciding factor for checking for permissions to delete the reference object.

The fact that the deletion is not immediately triggered by executing the Delete later event action also causes the following effects:

  • If a rollback (by an Abort or a 'real' process exception) is triggered after executing Delete later for the same transaction, the 'delete later' is omitted and the entity in question is maintained.

  • The time of execution of the event action for a specific reference object within the same transaction is irrelevant. Until the transaction is completed, there is access (inside and outside the transaction) to the reference object to be deleted.

  • Repeated execution of the event action for the same reference object within the same transaction has no effect unless different logon contexts are used (see above).

Execute the deletion

The deletion flag is not taken into account until the current transaction is completed. If one of the flagged reference objects was not deleted by the transaction, an attempt is then made to delete it explicitly. If this attempt fails because an error message occurs, the transaction as a whole is considered a failure and a rollback is performed. In this regard, the following aspects must be considered:

  • The logon context applicable in the course of the flagging (see above) must have the authorization to 'delete' the reference object.

  • Executing the Delete later event action in the Try block of a Try/Catch actor does not result in catching errors that occur 'later' (when deleting).

NOTE

  • Since deleting objects is generally not supported in the context of Tests, the Delete later event action has no effect whatsoever in test mode.

  • If within the same transaction for the same reference object not only the Delete later but also Save changes later event action was executed, there are flags for saving and deleting the reference object when the transaction is closed. Saving is then completely unnecessary, even in the special case that a 'volatile' reference object is present, i.e. one that cannot be deleted because it has never been saved.

Example

When any entity is deleted, all Documents assigned to this entity should also be deleted automatically.

Configuration:

An event handling for the Triggering events 'Delete' is configured as shown on the right side:

  • As a Validating rule, a Check type is set up for the 'Entity' type, which groups all types of entities (business objects, configurations, master data, etc.) together.

  • Among the Actions on passed rule, a Search (Event action) is performed first, which returns a list of all documents related to the entity to be deleted via the assignedDocuments Variable. Details of the search are shown below.

  • A For each loop iterates through the list of Documents in the assignedDocuments variable and executes the Delete later event action to set a flag for deletion for each Document.

When all relevant documents have been flagged for deletion, the transaction is completed. Only then will the entity passed as the input value of the event handling and all assigned documents really disappear from the database.

NOTE◄ It is assumed that in the logon context for all relevant documents at least the authorization to 'read' (for the Search (Event action)) and to 'Delete' is given. If the Search (Event action) returns at least one document for which 'Read' is allowed but 'Delete' is not, an error occurs when the action is completed, which triggers a rollback of the transaction. Then the deletion is ineffective for all documents and the entity itself.

images/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/warning.svg CAUTIONimages/s/-95e2zf/9012/8yg2g7/_/images/icons/emoticons/warning.svg Since Documents also belong to the 'Entity' type, deleting a document triggers the event handling described here for this document as an entity. Because it is also possible to assign other documents to a document, this can lead to a cascade of deletions for documents, going beyond the direct context of the original entity. The principle formulated in the requirement is thus applied recursively to an optionally nested hierarchy between documents.

images/download/attachments/83165445/image2021-4-14_17-10-27-version-1-modificationdate-1633440316186-api-v2.png

The collapsed Search (Event action) shown above should only be configured as shown on the right:

  • in the Save result as parameter, the name of the variable to which the search result should be written is specified: assignedDocuments.

  • The Entity type 'Document' is selected here, since Documents are searched for.

  • The Mode 'Search value' specifies that a list with all 'matches' of the search is written into the variable.

  • The Search is executed as a Search (see Search types), so that Documents are returned as complete data items as matches.

  • Within Where, an AND conjunction connects two criteria, each of which is configured as a Field restriction. Only if both criteria are true does a document actually refer to the entity to be deleted:

    • On one hand, the object field 'Referenced entity ID' (referencedEntityId) of the document should match the 'ID' (id) of the entity to be deleted, which is present as an input object.

    • On the other hand, the value for the 'Referenced Entity' (referencedEntity) object field must also correspond to the specific type of entity to be deleted, which is automatically provided in the entityClass variable when event handling is invoked. For example, if Users are to be deleted, the variable entityClass contains the following text value at runtime: de.lobster.scm.base.security.user.User

images/download/attachments/83165445/image2021-4-14_17-11-45-version-1-modificationdate-1633440316178-api-v2.png