if_dpr_appl_plug_in_subsystem~save( ) : Setting returning parameter to 1 causes short dump

[Former Member]

Hello gentlemen,

I've implemented a custom DPR subsystem.

It work's fine, but in method if_dpr_appl_plug_in_subsystem~save( )  I coded data validation logic. If validation fails, I want to rollback changes.

So if validation fails, I set returning parameter of the method rv_rc = 1.

VALUE( RV_RC )

TYPE I

Return Value (0 = Call OK; >0 = NOK -> Cancellation by Appl)

Unfortunately, setting it to 1 causes short dumb at save of the projects, which is very frustrating.

As a workaround, I could probably move validation logic to IF_DPR_APPL_PLUG_IN_SUBSYSTEM~PREPARE_TO_SAVE , but I don't like that idea for a number of different reasons, and it also doesn't make sense for me that SAP provides returning parameter which we cannot use.

BTW, If you modify SAP delivered sample class CL_DPR_DEMO_SUBSYSTEM and set rv_rc = 1 in the method if_dpr_appl_plug_in_subsystem~save( ) , it will cause the same short dump at save. So I'm pretty sure it is not caused by custom code.

Please share you thoughts on this topic

[former_member201206 · Accepted solution]

Hi Vadim,

though the  existing logic sounds not perfect, but there is no other better solution. The backgound of this behaviour is that the abort of the time point save is already too later.  There are double digit number of sub systems, at save action, the program loop of them and  trigger the save one by one.  If a undo- of save is required, EACH sub system( include the customer sub systems) must implement a undo-save logic to make sure all saved or nothing saved behaviour.  Such undo-save logic is extremly complex and can also not be expected by customer's implementation.

As you mentioned, abort using Prepare_to_save   is the right one.

Kind regards,

Zhenbo

[Former Member · Accepted solution]

Hi Zhenbo,

Thanks for clarification.

I believe it would make sense for SAP to get rid of confusing returning parameter in this method.