Read Role Name in BADI DPR_ATTRIBUTES~CHECK

[daniel_humberg]

I have create a BADI implmentation for the BADI DPR_ATTRIBUTES (cpro 4.5. in my case).

There, I would like to do some custom-made checks on the name of a role (object type = 'MTG').

Unfortunately, the role name is not available in the list of attributes (IS_ATTRIBUTES_OLD/NEW) (most probably, because it is language-dependent). Therefore, I tried to read the current role name with ir_common->get_description( ).

However, after a change of the role name by the user, get_description() returns only the OLD role name, not the NEW one.

Is there a way to get the NEW role name in DPR_ATTRIBUTES~CHECK( ) ?

[former_member201206 · Accepted solution]

Hi Humberg,

it is not easy to find a quick solution for this case.

One posibity is to do an enhancement of the method

METHOD SET_DESCRIPTION CL_DPR_ENTITY_SERVICES========CP

Kind regards

Zhenbo

[daniel_humberg · Accepted solution]

Thx for the hint.

I was thinking about using the BADI DPR_EVENTS (if_dpr_common_CHANGED), which is called after a role is changed, and from which I can also read the new role name.

However, I cannot do real checks there (at least, I cannot easily prevent the saving in case that the data is invalid).

[former_member187668 · Accepted solution]

Hi Daniel,

You can throw an error message in DPR_EVENTS. You can use the following code:

      MESSAGE ID  '00' TYPE 'E' NUMBER '011' INTO lv_msg.
      cl_dpr_common_services=>log_message( ir_common = ir_sender ).

IR_SENDER is available in the interface of ON_EVENT method.

Regards,

Ravikanth

[daniel_humberg · Accepted solution]

Hi Ravikanth,

yes, I can throw an error, but this will not prevent the save, right?

If my validation fails, (i.e. role name is not valid according to my check), I do not want the system to save that.

By just showing the message, the system would still do the save, right?

Regards,

Daniel

[former_member187668 · Accepted solution]

Yes Daniel, it doesn't prevent the save.

On a bit of research, we can enhance the Event Handler ONACTIONSAVE_CLICK (WDA

DPR_MAINFRAME, VIEW VI_MAINTOOLS) to include this additional check. DPR_EVENTS will set a

flag (EXPORT/IMPORT or a new custom field in standard structure) and in ONACTIONSAVE_CLICK

enhancement check for this flag and prevent the save.

Regards,

Ravikanth

[daniel_humberg · Accepted solution]

That would work but I don't like it too much.

It would be very UI-focused.

One of the nice things of the CHECK BADI is that is is called not only when you save via UI, but also when you do changes via BAPIs or via any other way. Also, the BADI implementation will still work after each upgrade, while the approach described above might not work if the UI logic is changed with an upgrade.

[daniel_humberg · Accepted solution]

I have decided to do this way:

1. Create a subsystem, and use the methods PREPARE_TO_SAVE and INITIALIZE_AFTER_SAVE to store a flag called "SAVE_IN_PROGRESS". In the CHECK BADI, i am doing something like

IF lo_subsystem->is_save_in_progress( ) = abap_true.
  lv_role_name = ir_common->get_description( ). "will return the right role name when save is in progress
  me->check_role_name( ... ).
ENDIF.

Luckily, the CHECK method is called twice. Once after changing the role, and once before saving. In the second case, the GET_DESCRIPTION( ) method will return the right role name.

[former_member187668 · Accepted solution]

Yeah, this should like a better approach than the standard UI enhancements.

Regards,

Ravikanth

[daniel_humberg · Accepted solution]

One more addition.

PREPARE_TO_SAVE and INIT_AFTER_SAVE is not enough, because INIT_AFTER_SAVE will not be called when the input validation fails somethere. So, I had to subscribe to an SAVE_FAILED event in the transaction manager class additionally to get this running.