SAP ALV Grid : Trigger DATA_CHANGED event manually on any custom function code 'ZSAVE' or 'SAVE'

[Surendra_Karma]

As we know, when we change any entry in the ALV grid from CL_GUI_ALV_GRID, event DATA_CHANGED will be triggered, and we can do some custom validation checks there.

However, you may have faced this situation, after you change the ALV and push on some user command, like 'ZSAVE' or 'SAVE', the DATA_CHANGED event will not be triggered again, because no cell is changed in ALV grid. And actually, you want to trigger it and do same check or other validations.

This blog will show you how to do it with real-time example.

1. Let's create a class for our Z-program  as below.

2. To call the ALV grid,  method SET_TABLE_FOR_FIRST_DISPLAY has been called and ENTER event has been registered.

3. The VALIDATION_CHECK is a method that we have linked to ENTER event for event handling.

4. Now, the real-catch is when we call a custom function code e.g. ZSAVE, we take any column of ALV grid and put all ALV table entries for that column as a a DELTA modification cell.
Thereafter, if we call CHECK_CHANGED_DATA method, our VALIDATION_CHECK method will get triggered.

I have gone through multiple similar blogs, but those were not helpful. Somewhere calling CHECK_CHANGED_DATA is written or somewhere forcefully setting 'GridModified' = '1' with SET_PROP has been used or somewhere something else. But unfortunately, inside VALIDATION_CHECK, changed data entries are not reflecting in GOOD_CELLS or MOD_CELLS to validate.

So, I thought to share this knowledge to our community. This is tried and tested method, which seems to be more aligned with ALV modification protocols.

Happy learning!

[VXLozano]

SAP discourages the use of editable ALVs in GUI because they are not capable of making its update events to work properly (or reliabily). They will tell you to use SALV_TABLE instead, and to make magic to workaround the lack of editability (I do it via hotspots, buttons, calling popups and so).

Or to use a browser (much better if you pay them a RISE).

Anyways, all those things aside: why do you pass a full column in your last piece of code? Why do you not just fake-edit a single cell? Fake-edit a non-editable cell, and put a control in your event work the whole table if the field is non editable.

[Surendra_Karma]

@VXLozano  I did pass full-column intentionally as I want to fetch ROW_IDs and have validation on all rows. If it is required, you can use WHERE clause in FOR for putting restriction on row ids. Doing a single cell, will just trigger the event but will not put them in GOOD_CELLS or MOD_CELLS to validate further. The validation logic is applied on GOOD_CELLS or MOD_CELLS.

[Yasin]

Nice Code. also agree with @VXLozano that SAP discourages the edit ALVs

[AleAPassarelli]

Nice trick, thanks for sharing! Routing the save check through DATA_CHANGED is a clean way to reuse the same validation and keep the error protocol (ADD_PROTOCOL_ENTRY, cell highlighting) on save.

One thing to watch out for: since every row of the chosen column goes in as a delta cell, MOD_CELLS ends up with the whole table. On large grids, the handler then validates every row and can't tell which ones the user actually edited. Two variations that could help:

- Collect the row IDs of the cells changed in earlier DATA_CHANGED calls in a class attribute, and on ZSAVE inject only those rows as delta cells.

- If you only need the check itself and not the in-grid protocol, call the validation method directly against the output table on ZSAVE and skip the delta injection.

Curious whether you've measured how it performs with a few thousand rows?

[VXLozano]

If anyone asks for an editable ALV for "few thousand rows", that person is asking for trouble, and not just the performance kind of trouble, but the human error one.

I'm not talking SAP here, it's just something I've learn with time, and I learned it before my SAP era. Even with zebra rows, any "thousand line sheet-like thing" will lead to human error sooner or later.

But hey, they know better than us, don't they?

[AleAPassarelli]

@VXLozano Fully agree. At that size the real problem is the user reviewing thousands of editable cells, not the event. The delta-rows idea only helps when the grid is big for display but small in actual edits.