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.
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.
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.
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
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.