Show TOC

 Deleting Existing Records

Procedure

Before your infotype may delete a record, it must first read the corresponding container, as described in the topic Reading Before Writing . Once the corresponding container has been read, you may pursue one of three approaches to perform the deletion.

  1. CALL METHOD a_masterdata_buffer->read

    (Interface IF_HRPA_MASTERDATA_BUFFER->DELETE )

    This approach will directly delete data from the buffer, but it will not process generic business logic – for example, retrocalculation, time constraints, and so on. Due to the nature of this approach, it is seldom applied to delete existing records.

    With this approach, your infotype will not need to handle messages.

  2. CALL METHOD a_generic_update->delete

    (Interface IF_HRPA_GENERIC_UPDATE->DELETE )

    This approach will delete the record. It will also process generic business logic – for example, retrocalculation, time constraints, and so on. To avoid endless recursion, this is the recommended approach for updating records of your own infotypes.

    With this approach, your infotype will need to handle messages.

  3. Interface IF_HRPA_MASTERDATA_BL->DELETE

    This approach will delete the record and process the complete business logic – both the generic checks and all infotype-specific checks – for the container. This is the recommended approach for deleting records of other infotypes.

    With this approach, your infotype will need to handle messages.

If you pursue the second or third approach named above, refrain from using interface IF_HRPA_MESSAGE_HANDLER , which is introduced in the topic Performing Message Handling ; it is more expedient to create your own instance (for example, of class CL_HRPA_MESSAGE_LIST ), which will allow your infotype to evaluate any messages that arose during the deletion of records.

Regardless of the approach you choose to pursue, you must always consider the appropriate response if the deletion should fail (for example, in response to retrocalculation or authorization checks). But regardless of the response you choose to implement, a failed operation will never alter the buffer. In other words, no matter what prevented the deletion from occurring, the buffer will remain in the same state as before the attempted deletion, since the system automatically rolls it back if errors occur.

Note Note

Exceptions of type CX_HRPA_VIOLATED_ASSERTION can arise with any of the three deletion approaches summarized here. Unless you have a specific reason to do so, we recommend that you disregard such exceptions.

End of the note.