International Editable SALV Day 2015
http://scn.sap.com/thread/733872
Dear Programmers,
On the 8th of February 2008 James Hawthorne started the discussion (link above) as to why SAP does not give the CL SALV TABLE the option to be editable, as CL GUI ALV GRID is.
Today is the 7th anniversary of that blog, and hence is “International Editable SALV Day”.
I started a little discussion on this here on SCN last June:-
http://scn.sap.com/thread/3567633
Back in the year 2003 I went to SAPPHIRE in Brisbane and the speakers from SAP made much of the convergence of reports and transactions.
To put that another way – people did not just want a list of blocked sales documents where the system could not determine the price. They wanted a list of such documents on a screen where you could actually change the price yourself to fix the problem, and then release the document there and then.
The obvious answer is an editable grid, rather like the table controls in classical DYNPRO.
In CL_GUI_ALV_GRID this was a piece of cake. You could set whatever cells you like to be editable, and programmatically add extra custom commands at the top of the screen e.g. a custom “release” button.
The CL_SALV_TABLE was supposed to be the successor of CL_GUI_ALV_GRID and SAP pushed us to use that instead. Whilst far better in many ways, CL_SALV_TABLE has some surprising drawbacks, making it actually have less functionality than its predecessors.
· You cannot edit the data
· You cannot programmatically add commands in the full screen mode
· You cannot add separator lines between icons
All of this was available in CL_GUI_ALV_GRID. The really strange thing is that at the heart of a CL_SALV_TABLE instance is a a CL_GUI_ALV_GRID instance, so obviously all of the above functionality could be added if it was so desired.
You will see from the prior blogs that the history of this is as follows:-
· Every single ABAP developer desires this extra functionality in CL_SALV_TABLE
· Many workarounds have been proposed on assorted SCN blogs
· SAP development looks for those workarounds, and changes the CL_SALV_TABLE to block them
· People tried to do the right thing, and put a proposal on “idea place” to make the SALV editable, a proposal which got a lot of votes
· A senior SAP person from the development department got very upset indeed, said the SALV was never meant to be editable, and closed off the idea.
To quote from “V for Vendetta” however you cannot kill an idea…….
So eight years on and workarounds are still springing up. SAP development can close off certain avenues but with the enhancement framework it is possiblefor developers to get around virtually any barriers placed in their way.
Wouldn’t it be easier if this was not a fight between the central team at SAP who develop the ABAP language and the users of that language?
Someone once said that if there was a law, and virtually everybody broke that law on a day to day basis, would it not be worth looking at the law to see if it actually made sense?
I don’t mind admitting I have created several SALV reports in my company where the users can edit data and I imagine I am not alone. I am also sure SAP development would be horrified by this fact. They hate people doing workarounds, cannot fathom my anyone would do such a rule-breaking dangerous risky thing, just to keep the business users happy.
As I said at the end of my last posting on this subject might I humbly suggest to the red nosed SAP ALV development team that the easiest way to stop people doing workarounds is to remove the need for a workaround in the first place, by having the functionality as standard.
So the question is – in 12 months’ time will I be posting another blog to celebrate the 9th anniversary of International Editable SALV Day?
Cheersy Cheers
Paul
Hi,
i agree 100%. It was high time a blog like this was published.
Thanks for daring and showing so openly your opinion.
Best regards.
Of course, if you were to describe it as an issue with a particular reporting component of Business Suite on HANA, you might get somewhere...
In the meantime, run simple or run like mad (and get back to work on that book) 🙂
The book is done, coming out shortly!
Strangely enough, I have a chapter on the SALV, and at one stage talk about this very subject..... 😏
Hi,
Lets start with something simple like:
Multiple heading in ALV....
regards.
Hi, Paul!
That's exact reason why I stopped using CL SALV TABLE once I tried it. I don't want to rewrite the screen logic of the report when users ask for "just one editable column".
If also ALV input history is to be ever done (there was a note saying the opposite) I'll go on the booze the same day 🙂
>So the question is – in 12 months’ time will I be posting another blog to celebrate the 9th anniversary of International Editable SALV Day?
If I calculate correctly it will be only the 8th 🙂
Anyway, I like this blog. Reminds me to the new ABAP editor story with Thomas Jung, where in the end they did the downport to older releases.
At least we still have CL_GUI_ALV_GRID and it was not flagged for obsolete, but I totally agree, that having this in CL SALV TABLE would make developers life easier.
Peter
Leaving my inability to count aside, the greatest ever success in this area was SAP caving in in regard to Business Workflow.
For almost ten years they put the workflow that runs inside of the ERP system into "maintenance mode" i.e. no new features, and kept the 3.0 ABAP editor inside transaction SWO1.
This was to boil us customer frogs, hoping we would all stop using the free version of workflow and instead pay vast amounts of money for new "better" workflow systems with fancier names which we could then integrate back to our ERP systems.
That did not work as well as SAP hoped, so in the end they caved in to the American SAP User Group Workflow pressure group and implemented about ten of fifteen fixes / enhancements and main one being the new ABAP editor in SWO1.
I never understood why they had that old editor in SWO1. It looked really inconsistent to me.
BTW we also like the SAP standard Workflow engine so much, that we decided to have an own one instead in our product 🙂
Paul, great blog indeed. You might be interested in checking out my recent CC discussion on "stuff SAP could easily fix". Well, this is probably not easily fixable (or, more importantly, perceived as a feature, not bug by SAP) but apparently one needs to get into the Customer Engagement program for things like that. And then there is, of course, prioritization, resources, etc.
We do have great demand for editable ALV in our organization and now I'll make sure not to tell anyone how we do that. Thanks for the warning!
Just do be fair, a framework built with the ABAP language is not the ABAP language. But of course I understand, that from the user's view it's all the same ... 😏
It is rather like the other day when I was in the Antique shop where the girlfiend of one of my mates works. Their computer had broken down so of course my wfe says "Oh, Paul works in IT! HE can fix it!"
Now, I might now a bit about ABAP programming but how to fix a broken PC is usually beyond me - but as you say from the end users view it is all the same.
Anyway, I sit near the help desk at work so I have picked up on the way experts deal with such problems.
So I said "switch it off and switch it on again" which worked and I breathed a huge sigh of relief.
IT Crowd - Have You Tried Turning It Off And On Again? - YouTube
And so the legend of "IT guy" who can fix any device, write code in any programming language, install HANA server and configure intercompany process while at it will live on. You've doomed us all, Paul! 🙂
You forgot that the legends, in the darkest corner of company break rooms, whisper about the IT guy NEVER works, just sit and look at a laptop and get overpaid to do this!
I'll second....errr fifteenth this request.
Like this post and greetings to the SAP dinosaurs out there ^^
*&---------------------------------------------------------------------*
*& Report ZIPPO_EDIT_CL_SALV the present template is derived from an
*& original solution implemented by a
*& SAP specialist from China
*&
REPORT zippo_edit_cl_salv.
*----------------------------------------------------------------------*
* CLASS lcl_alv DEFINITION
*----------------------------------------------------------------------*
* cl_salv_controller_table is declared in cl_salv_table as friend
* cl_salv_controller_table is not declared as final
*
* within lcl_alv defined INHERITING FROM cl_salv_controller_table
* we can acced protected elements in cl_salv_table via friendship
*----------------------------------------------------------------------*
CLASS lcl_alv DEFINITION INHERITING FROM cl_salv_controller_table ABSTRACT.
PUBLIC SECTION.
CLASS-METHODS: get_grid
IMPORTING iref_salv TYPE REF TO cl_salv_table
RETURNING value(ret_grid) TYPE REF TO cl_gui_alv_grid.
ENDCLASS. "lcl_alv DEFINITION
*----------------------------------------------------------------------*
* CLASS lcl_alv IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_alv IMPLEMENTATION.
METHOD get_grid. " to get the ref. of the instance cl_gui_alv_grid in OO ALV
DATA: r_controller TYPE REF TO cl_salv_controller_table,
r_adapter TYPE REF TO cl_salv_fullscreen_adapter.
TRY.
r_controller ?= iref_salv->r_controller.
r_adapter ?= r_controller->r_adapter.
ret_grid = r_adapter->get_grid( ).
CATCH cx_root.
" ERROR HANDLER TO DO ( if you want )
ENDTRY.
ENDMETHOD. "get_grid
ENDCLASS. "lcl_alv IMPLEMENTATION
*----------------------------------------------------------------------*
* CLASS lcl DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl DEFINITION.
PUBLIC SECTION.
TYPES: BEGIN OF t_row,
account_a(10) TYPE p DECIMALS 2,
account_b(10) TYPE p DECIMALS 2,
END OF t_row,
t_it TYPE STANDARD TABLE OF t_row.
CLASS-DATA: itab TYPE t_it,
ls_itab TYPE t_row,
r_alv TYPE REF TO cl_salv_table,
r_functions TYPE REF TO cl_salv_functions_list,
r_cl_gui TYPE REF TO cl_gui_alv_grid.
CLASS-METHODS: srv_main RAISING cx_salv_msg,
srv_alv RAISING cx_salv_msg,
srv_added_function FOR EVENT added_function
OF cl_salv_events_table IMPORTING e_salv_function.
ENDCLASS. "lcl DEFINITION
*----------------------------------------------------------------------*
* CLASS lcl IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl IMPLEMENTATION.
METHOD srv_added_function.
DATA: ls_layo TYPE lvc_s_layo.
* MESSAGE 'added function' TYPE 'I'. "message to trace added_function event
IF r_cl_gui IS NOT BOUND.
r_cl_gui = lcl_alv=>get_grid( r_alv ).
" to get reference of cl_gui_alv_grid instance
ENDIF.
CASE e_salv_function.
WHEN '&EDIT'.
*** get front end layout ; edit = 'X' ; set front end layout
r_cl_gui->get_frontend_layout( IMPORTING es_layout = ls_layo ).
ls_layo-edit = abap_true. "'X'
r_cl_gui->set_frontend_layout( EXPORTING is_layout = ls_layo ).
***
r_cl_gui->refresh_table_display( ). "refresh grid to evaluate edit = 'X'
WHEN 'REFRESH'.
r_cl_gui->check_changed_data( ). " to get modified data
* " from front end grid to report
* " mouse double click on grid get the same
ENDCASE.
ENDMETHOD. "srv_edit
METHOD srv_main.
ls_itab-account_a = 100.
ls_itab-account_b = 450.
APPEND ls_itab TO itab.
ls_itab-account_a = 110.
ls_itab-account_b = 2750.
APPEND ls_itab TO itab.
srv_alv( ).
ENDMETHOD. "srv01
METHOD srv_alv.
DATA: r_events TYPE REF TO cl_salv_events_table.
cl_salv_table=>factory( IMPORTING r_salv_table = r_alv
CHANGING t_table = itab ).
*TRY.
r_alv->set_screen_status(
report = sy-repid
pfstatus = 'ST_ALV' " GUI Status created in the actual report
" adjusted via adjust template -> list viewer
" with '&EDIT' added function
" with 'REFRESH' added function
* set_functions = C_FUNCTIONS_NONE
).
*ENDTRY.
r_functions = r_alv->get_functions( ).
r_functions->set_all( ).
r_events = r_alv->get_event( ).
SET HANDLER srv_added_function FOR r_events.
r_alv->display( ).
ENDMETHOD. "srv_alv
ENDCLASS. "lcl IMPLEMENTATION
START-OF-SELECTION.
FIELD-SYMBOLS: <f> TYPE lcl=>t_row.
lcl=>srv_main( ).
LOOP AT lcl=>itab ASSIGNING <f>.
WRITE:/ <f>-account_a, <f>-account_b.
ENDLOOP.
Technical solutions to make the SALV editable have been around for a while. I describe something very similar to the code above in my book, for example.
Below Naimesh notes he found a solution in 2008 which still works to this day.
That is not really the point though - SALV has a CL_GUI_ALV_GRID object at it's heart so it should at the very minimum be able to do everything that CL_GUI_ALV_GRID does, but it cannot.
That is just plain insanity on the part of SAP.
As an example using CL_GUI_ALV_GRID I can bring up the report directly in editable mode. All the workarounds require a user to press a button to change the grid into editable mode.
Unless I am mistaken? Has anyone got a workaround to bring up a SALV report in editable mode from the get-go?
Hello Paul,
Yes, I think you will posting the 9th anniversary with waiting for SALV for editable function. As SAP has roadmap to go more on new UI techniques so, SALV would be left as is ...
Coincidence that I also wrote the solution to make is editable in the 1st year of "Editable SALV" - November 2008 - Power of ABAP Objects: Overcome the Restrictions of SALV Model
Whenever, I have new version of ABAP release, I would test the functionality and it works till ABAP 740 SP5 (thats latest I can manage till today).
I would be more interested to see why SALV can't be made editable. There are few comments on the blog from ALV development team, that it is not designed for editable. I think, I'm already on the not-so-well-list for ALV team 🙂 as I'm causing more trouble for them.
By not providing editable function, SALV is losing the purpose. Can you imagine the shock the end-users (and directors who approve the budget) when you say - to make existing ALV report editable, I would need to change the design and use a different (older version - not that they care)... So, I always think (and want) to use SLAV but end up using the CL_GUI_ALV_GRID.
Regards,
Naimesh Patel
Hi Patel,
I am with you. I've encapsulated CL_GUI_ALV_GRID long time ago - to hide the technicalities - and had actually forgotten about SALV. It's a bit of a non-issue.
But on the topic of the new UI technology. I've just walked out of a meeting with yet another large customer that has come to the conclusion that
- using the standard SAP transactions leads to unhappy users due to the cluttered screens
- building a UI in JavaScript takes too long and is too high maintenance in the long run
- the only sensible thing to do is to use controls like Cl_GUI_ALV_GRID and the splitters, drag/drop, etc to quickly build simple usable UIs that talk the language of the users, whilst calling standard SAP components behind the scenes to run standard business logic.
Is it true Personas is free now? Because if it is, they will simple put Personas 3 (once it is out of ramp-up, I understand V3 doesn't need silverlight any more) in front of the ABAP UI and be done with it. Scrap Fiori.
Does that strike a cord with anyone out there?
Personas is indeed free now. Many companies actually paid for it (circa 200,000 euros) and then seethed when it became free - they got a credit for the amount they had spent, which could only be used to buy more SAP products and do you know - that did not calm a lot of those companies down for some reason.
Version 3 of Personas is indeed looking good - SAP claims it fills some gaps that assorted companies have said makes the current version useless.
However I would note that apart from the drag and drop nature of Personas that you use to configure the basics, if you want to do anything out of the ordinary - and most organisations do - then you have to use the programming language.
That is not the end of the world - in fact to programmers like me that sounds great - as with a fully fledged programming language you can do pretty much anything you want.
That fully fledged programming language is however JavaScript - so does that put Personas back in the "takes too long and too high maintenance" basket?
Cheersy Cheers
Paul
Hi Paul,
Thanks.
My gut feeling is that most UI requirements can be implemented using good old ABAP dynpro and rendered through Personas without the need to resort to JavaScript. The other UI requirements will probably be around dynamically moving objects around on the screen, making things fade in and out and flip around etc... which is all nice and fancy but probably not essential for an enterprise application... Happy to be challenged on this.