1. Sap Alv Examples

Don’t get too excited about the editable SALV solution out of the box, but I think we have a solution. Recently published a blog as the 8 th anniversary of the first SALV Editable question and so far no out of the box solution. To those who hasn’t read the previous so many discussion, out of box solution means a single method to make it editable. As of ABAP 740 SP05, there isn’t any new method in SALV OM which does the same thing or at least sounds like SETEDITABLE. I developed an work around in November 2008 and got lot of criticism for that.

You can see the solution and read the comments – Based on the comments, customers should never use these type of workarounds. Obviously, SAP must not use the work around as they say Editable is not intended purpose of SALV OM.

• Jan 1, 2014 - *---code addition for ALV pushbuttons *--for placing buttons METHODS handle_toolbar_set FOR EVENT toolbar OF cl_gui_alv_grid IMPORTING e_object e_interactive. *---user command on clicking a button METHODS handle_user_command FOR EVENT user_command OF cl_gui_alv_grid IMPORTING.
• Hi experts,I am using the FM REUSE_ALV_GRID_DISPLAY to display an ALV output. I have made one column editable to the user. Now i want to validate the value entered.

But, look what I found Standard SAP (yes, standard SAP) has used the almost similar approach to make SALV editable which I used in my solution. Standard SAP Application I was replying to some query on CLSALVTREE and I did a where used on the adapter object and stumbled upon this function group FOTRFDMONI. Usually the adapter is used by only CLSALV. Classes and my test program.

Hai Gurus,I have to make an editable ALV-Grid that is user can edit the data by clicking the data in the alv grid and also i want the details of the.

But, suddenly I see a new program popping up in the where used list and that kept me thinking what is this program doing here? This standard SAP application is developed using this approach – almost same as the approach used in my solution. (Note, that I’m not calling it a workaround anymore 😉 ):. Inherit the class from the Model class.

Create a method in the inherited class to gain access to the Adapter object – E.g. Grid, Fullscreen, Tree.

Gain access of the underlying object – Grid or Tree Class definition Class Implementation Use of method to make Grid editable / non-editable Redefined Solution So, based on this design, I simplified my version of the approach. Created a custom class where I have couple of helper methods to gain access to the adapter and then the underlying object – either Grid or Tree. GETGRID would be used to get the CLGUIALVGRID object. GETTREE would be used to get the CLGUIALVTREE object Utility Class.———————————————————————-. CLASS ZCLTESTNPSALVMODEL DEFINITION.———————————————————————-.———————————————————————-.

CLASS zcltestnpsalvmodel DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. CLASS-METHODS getgrid IMPORTING!iosalvmodel TYPE REF TO clsalvmodel RETURNING value (eogrid ) TYPE REF TO clguialvgrid RAISING cxsalverror. CLASS-METHODS gettree IMPORTING!iosalvmodel TYPE REF TO clsalvmodel RETURNING value (rotree ) TYPE REF TO clguialvtree RAISING cxsalverror. PROTECTED SECTION. PRIVATE SECTION. CLASS ZCLTESTNPSALVMODEL IMPLEMENTATION.

—————————————————————————————+. Static Public Method ZCLTESTNPSALVMODEL=GETGRID. +————————————————————————————————-+. — IOSALVMODEL TYPE REF TO CLSALVMODEL. METHOD getgrid. DATA: loerror TYPE REF TO cxsalvmsg. IF iosalvmodel -model NE ifsalvcmodel = table.

RAISE EXCEPTION TYPE cxsalvmsg EXPORTING msgid = ’00’ msgno = ‘001’ msgty = ‘E’ msgv1 = ‘Incorrect SALV Type’. Eogrid = lclsalvmodellist =getgrid ( iosalvmodel ). “getgrid. —————————————————————————————+. Static Public Method ZCLTESTNPSALVMODEL=GETTREE. +————————————————————————————————-+. — IOSALVMODEL TYPE REF TO CLSALVMODEL.

METHOD gettree. DATA: loerror TYPE REF TO cxsalvmsg. IF iosalvmodel -model NE ifsalvcmodel =tree. RAISE EXCEPTION TYPE cxsalvmsg EXPORTING msgid = ’00’ msgno = ‘001’ msgty = ‘E’ msgv1 = ‘Incorrect SALV Type’.

Sap Alv Examples

Rotree = lclsalvmodellist =gettree ( iosalvmodel ). “GETTREE ENDCLASS. To get the CLGUIALVGRID.”. use this source file for the definition and implementation of.”. local helper classes, interface definitions and type.”. declarations.

CLASS lclsalvmodellist DEFINITION INHERITING FROM clsalvmodelbase. PUBLIC SECTION. CLASS-METHODS: getgrid IMPORTING iosalvmodel TYPE REF TO clsalvmodel RETURNING value (roguialvgrid ) TYPE REF TO clguialvgrid RAISING cxsalvmsg, gettree IMPORTING iosalvmodel TYPE REF TO clsalvmodel RETURNING value (rotree ) TYPE REF TO clguialvtree RAISING cxsalvmsg.

“lclsalvmodellist DEFINITION. CLASS lclsalvmodellist IMPLEMENTATION.

METHOD getgrid. DATA: logridadap TYPE REF TO clsalvgridadapter, lofsadap TYPE REF TO clsalvfullscreenadapter, loroot TYPE REF TO cxroot. Logridadap?= iosalvmodel -rcontroller -radapter. CATCH cxroot INTO loroot. “could be fullscreen adaptper TRY.

Lofsadap?= iosalvmodel -rcontroller -radapter. CATCH cxroot INTO loroot.

RAISE EXCEPTION TYPE cxsalvmsg EXPORTING previous = loroot msgid = ’00’ msgno = ‘001’ msgty = ‘E’ msgv1 = ‘Check PREVIOUS exception’. IF logridadap IS NOT INITIAL. Roguialvgrid = logridadap -getgrid ( ). ELSEIF lofsadap IS NOT INITIAL. Roguialvgrid = lofsadap -getgrid ( ). RAISE EXCEPTION TYPE cxsalvmsg EXPORTING msgid = ’00’ msgno = ‘001’ msgty = ‘W’ msgv1 = ‘Adapter is not bound yet’. “getgrid METHOD gettree.

DATA: lotreeadap TYPE REF TO clsalvtreeadapter, loroot TYPE REF TO cxroot. Lotreeadap?= iosalvmodel -rcontroller -radapter. CATCH cxroot INTO loroot. RAISE EXCEPTION TYPE cxsalvmsg EXPORTING previous = loroot msgid = ’00’ msgno = ‘001’ msgty = ‘E’ msgv1 = ‘Check PREVIOUS exception’. IF lotreeadap IS NOT BOUND. RAISE EXCEPTION TYPE cxsalvmsg EXPORTING msgid = ’00’ msgno = ‘001’ msgty = ‘W’ msgv1 = ‘Adapter is not bound yet’. Rotree = lotreeadap -rtree.

“gettree ENDCLASS. “lclsalvmodellist IMPLEMENTATION To get the CLGUIALVTREE. METHOD onusercommand. DATA: logrid TYPE REF TO clguialvgrid. DATA: lslayout TYPE lvcslayo. CASE esalvfunction.

Make ALV as Editable ALV WHEN ‘MYFUNCTION’. Logrid = zcltestnpsalvmodel =getgrid ( loreport -osalv ). CATCH cxsalvmsg.setfrontendlayout EXPORTING islayout = lslayout. refresh the table CALL METHOD logrid -refreshtabledisplay. “onusercommand Questions are These also raises to these questions:. Is SAP not planning to have SETEDITABLE method in OM as they have started using this approach?. Would SAP now provide support if customer uses the same approach and run into issues?.

If no, than how come SAP approved this design to exist it in customer’s system?. If yes, As you can see, the application was created in somewhere 2011 by SAP. So, the developer must be aware of the existence of my solution. Shouldn’t I get at least a some credit?

Not that I want, but would be good to have, 😉 Please share your thoughts updated on 23-Jun-15 at 8:30 AM CST to add the missing local class. I didn’t see your original blog at the time, but I’ve read it now, and I disagree with the nay-sayers. The fact is that if you’re using this or your other solution (not workaround!), I find it very hard to see how you could break anything standard. And since SAP don’t support anything custom you write anyway – what’s the problem? In the real world, we’re using and reusing SAP classes all over the place. If they were never designed to work in the way that we’re using them then perhaps that’s design issue – not customer misbehaviour! If you don’t intend us to use your classes in a particular way, then you should have written them so we couldn’t.

Decently written classes are extendable safely (pathalogical use notwithstanding). I can imagine the Java or C communities’ response to a complaint that you’re not using their libraries the way you want them to! Agree that they shouldn’t allow us – customers or even the internal SAP developers – if the class library is not supposed to be used by “others”. Certainly that’s not the case with this library.

SAP doesn’t support the custom development but they have to at least entertain the customers query when customer is using the so called “released” function modules / classes. For few giant customers, they have to respond to the customer message even customer uses “unreleased” approach. I guess, they want to avoid the load of tickets created by this type of solutions by giving early (false) warnings – “this is not intended use”, “we will not support”, etc. Glad you get a chance to read through the original blog. Regards, Naimesh Patel.

Two points: 1. Good oo-design should minimise the chance of class misuse (which is the main thrust of my argument and not applicable to directly updating database tables). If you choose to use classes for purposes not designed, unreleased function modules or update tables directly, SAP do not have to support you. (This is counter to the argument presented by the SAP dev team, who said that people will come running to them when it doesn’t work). Unless you’re updating SAP tables (using SAP classes, FM or directly), you’re unlikely to screw anything up that you can’t fix yourself. It occurs to me that SAP programmers are “real” people also. They experiment with things, they read the blogs on the SCN and no doubt use some of the things they read there as indeed I do.

Some SAP developers are also are clearly interns out on their first day with no training provided and no testing of the code they write before it goes into production, clearly the ones who wrote the original release of SAP GUI 740 fall into that category, as did the developers who did the OSS note to enable account assignment on GR for purchase orders with multiple account assignment. That OSS note code mixed up BUKRS and WERKS and put the value for one into the other, and oh dear, the end result was not too good. It would have worked in an IDES system as both BUKRS and WERKS would have both had the value 1000, but not in any “customer” system. When the code exchange was hosted on SCN SAP reserved the right to use anything put there in the standard product and indeed did so with some JSON handling classes, which surprised (and probably flattered) the original author. He was happy as the SAP developer just copied the classes wholesale using SAPLINK and did not realise the author had a dummy method in one class with just a sort of copyright message in comments saying he had written the class in the first place. Anyway, the point is that SAP developers are no doubt just as frustrated as us “customer” programmers that the SALV is not editable and seek to work around this in the same way all the companies running SAP do.

Thus I extend the comment I made recently:- “If a rule made by SAP is broken by all the companies using SAP, and internally by SAP developers i.e. The rule is broken by 100% of people, maybe it is time to look at the logic behind the rule?”. But it won’t happen. On the 9th anniversary I will be posting another blog commerating the fact of the non-event. In the interim I will be beefing up my work-around to try and use the techniques you use above.

The question I would have is this – have you found a way to open a SALV screen in editable mode? Thus far I have always had to open it in read only mode, and then have a button for the user to press to make it editable.

If I could solve that problem I would never need to use CLGUIALVGRID directly again. Cheersy Cheers Paul. SAP developers would even ask some silly questions. I would be surprised to see the question content and the SAP logo next to the name.

So, either as you suggested they are interns and don’t have any on the job training, or SAP doesn’t have any Quality Assurance. Earlier I thought SAP has rigorous check-up, performance tuning, code cleanup, before they ship the code to customers. But now I know that they don’t even follow the standards which we follow at customers. In one DSD solution, there are many SELECT.

FROM BSAD, BSID and being executed recurring time. The funny thing, is they don’t even need all 250+ fields as they only are interested in checking if there is any open item or any payment already posted for this customer. Certainly this type of code would have been only tested in IDES and SAP would have decided to include that in the next support pack / upgrade. Customer would have thought the new support pack is great (as SAP advertise) and boy oh boy, they would end up miserably using that. So, ultimately would end up ditching that or enhancing to the certain extend that there wont be a standard call anymore.

The developer of that JSON handling class would be happy as his creation is now part of standard. But he might not had been criticize to create that solution as I had been for this.

Anyways, I think only the out-of-box solution would put an end to this. Regarding making SALV directly editable, I have few ideas. Let me run them through and would let you know how it goes. Regards, Naimesh Patel. I think its more than just changing the SLAYOUT-EDIT = ‘X’ to make it editable in the method GETSLISLAYOUT.

Alongwith this, you would need to make sure toolbar appears with all the required buttons. Also, all required events are registered to handle the changes. You would need to replicate the similar enhancements for the Grid as the SLIS.

methods would only get executed for the Fullscreen ALV. For GRID, the methods would be LVC. Gaining access to the underlying object (GRID or TREE) allows you to do many other things, like add a wallpaper to the header, register extra events (NODECONTEXTMENUREQUEST and ITEMCONTEXTMENUREQUEST) for tree. I would refrain from using the implicit enhancements within the “helper” methods of the SALV OM models, as the architecture may change and enhancement wont be executed anymore. That would be also apply to this approach of gaining access — but I guess it would at least raise syntax error, if that happens. Regards, Naimesh Patel.

I think its more than just changing the SLAYOUT-EDIT = ‘X’ to make it editable in the method GETSLISLAYOUT. Alongwith this, you would need to make sure toolbar appears with all the required buttons.

Also, all required events are registered to handle the changes. Hi Naimesh, I just changed the value of this field to X in debug mode and it gives me what I want – ALV in edit mode, with SAVE, and BACK buttons enabled. Whenever I make changes, press SAVE and clicks BACK, whatever changes I did on the screen, where passed back to the program. Toolbar can be activated by calling CLSALVTABLE -GETFUNCTIONS ( )-SETALL ( ABAPTRUE ), correct? So, which event am I missing? I understand that access to underlying object gives much more capabilities.

Thanks, Juwin. Juwin Pallipat Thomas wrote: Toolbar can be activated by calling CLSALVTABLE -GETFUNCTIONS ( )-SETALL ( ABAPTRUE ), correct?

I didn’t try, but I don’t believe so, No, see previos comment. Since CLSALVFUNCTIONSLIST encapsulates only a subset of ALV functions and the editing functions are to the very least not among those which can be controlled using the named methods of this class. Unless CLSALVFUNCTIONSLIST-ADDFUNCTION( ) + SETFUNCTION( ) lets to set up and control editing functions as custom ones, they will have to be activated via some “funky stuff”, I feel cheers Janis.

Err, yes – real people 🙂 I still feel that on average the level of SAP’s ABAP developers, standards and procedures are above those of the custom developments I have seen And the resistance to changes has more to do with real peoples real fears to screw up things in too many to count systems, I feel. Part of the response I got to my “” bug fix proposal for simple sounding “BDT: required field check doesn’t process all (field) status changes” problem illustratates: We cannot test all the scenarios. Sorry for the negative response as we cannot provide the standard SAP note for this. I have no idea about the technical challenges involved in getting to “editable SALV”, but what I suspect is: maybe it’s not so much unwillingness to do the “right thing”, which many customers want – it’s the inability to deliver a quality solution. The fear, which of course in turn reflects negatively on the quality of code base, developers, standards and procedures cheers Janis.

Naimesh, Have you yet found a way to get the SALV to open directly in edit mode? Thus far I have only been able to bring up the grid display for a SALV in read only mode, and have some sort of button so the user can change it into editable mode. With a real CLGUIALVGRID report you can display the report directly in editable mode without the user having to do anything, just like in SM30. And users do want this sort of thing. I was sort of thinking this was impossible with a SAV as you cannot get your hands on the underlying object until after the report has been displayed. What do you think? Cheersy Cheers Paul.

The “fullscreen” and “ALV grid in a container” adapters (I assume) seem to handle setting up the toolbars differently – “grid in a container” does not show the editing functions automatically. I can show CLSALVTABLE instance in a container in editmode as simply as calling its display( ), followed by getting and doing the “funky stuff” to grid (getfrontendlayout( ) + setfrontendlayout( )), followed by CLSALVTABLE-refresh( ) in PBO. Obviously, ALV at this point is without appropriate toolbar and most likely the events to handle the functionality, but those can likely be set up by doing more “funky stuff”. There may also be a cleverer way without calling standard display( ), by instantiating and setting up the adapter and the grid in the “funky stuff” part I feel, however, that doing the “funky stuff” to switch on editiable grid alone is already depending on SALV “implementation details” too much I wish CLSALVTABLE was at least programmed to an interface, so it could be kind of “decorated” easier, if SAP didn’t want us to inherit this class. Don’t feel good about this solution; SAP should just do the “right thing” Another small comment about the old solution: unlike fullscreen, for the grid in container SETSCREENSTATUS( ) is not supported for obvious reasons (check is programmed in CLSALVMODELBASE-SETSCREENSTATUS( )). Test code fragment: data: logrid TYPE ref to clguialvgrid. Data: lslayout TYPE LVCSLAYO.

Data: ltfieldcat TYPE LVCTFCAT. FIELD-SYMBOLS: type LVCSFCAT. Lofunctions = me- moalvresulttable- getfunctions ( ). Lofunctions- setall ( IFSALVCBOOLSAP= TRUE ).

Me- moalvresulttable- display ( ). Logrid = lclsalvmodellist= getgrid ( me- moalvresulttable ).

Logrid- setreadyforinput ( 1 ). Logrid- getfrontendfieldcatalog ( IMPORTING etfieldcatalog = ltfieldcat ). Loop at ltfieldcat ASSIGNING where FIELDNAME = ‘RATETYPETEXT’. Logrid- setfrontendfieldcatalog ( ltfieldcat ). Me- moalvresulttable- refresh ( ). Hi, For one, “phylosophically” there is no real need to try to mess with “GUI status” of the whole application from within and via a “subcomponent” placed in a GUI container – application can control GUI status directly.

In addition one can also imagine an application with several grid containers on one screen; then it gets a bit dicey, I feel. Fullscreen mode with one grid does away with those concerns (the grid IS the whole of application so to speak), but honestly – I don’t yet understand the need to control application GUI status via CLSALVTABLE To accomplish what – adding a GUI function and making grid aware of it with single method call.? Cheers Janis.

Hello Jānis, Correct that the Grid and Fullscreen has different trigger time. For the Grid, you are in PBO of the your own screen so the DISPLAY method doesn’t actually bring up the ALV, the end of PBO does. For Fullscreen, ALV handles that so after DISPLAY, you don’t have control anymore.

Also the toolbar is tricky. The SALV grid has special functionality for the toolbar and it hides many of those. So, had to put those buttons back. I just published blog to cover this and make it happen using AFTERREFRESH event. Regards, Naimesh Patel.