Personal Insights
4 Ways to make Simple ALV Client friendly
From the customer point of view Application list viewer is the way to summarize the data and to project the data on the output screen .
This Blog will help you understand what kind of an ALV table should be presented to the customer .
The customer might ask for a Simple ALV table but it is always a good practice to give a polished end product that will keep both the customer and business happy.
- Stick to one style of programming:
Either Procedural or Object-Oriented style (OOPs), it is always a good practise to follow one style . I personally feel OOps is good for me as it is very handy to extend the program and do changes in the ALV. - Include the inbuilt tool bar in an ALV:
Try to include the inbuilt toolbar and disable if any functionalities that are not required, like sometimes i get request from the client not to include sort buttons. - Include functioning Change layout in ALV:
Sometimes the client requires only 5 fields from a table in ALV, but in the background all the fields from the ALV can be included this will give the client to choose any fields in the future for comparison or review.
4. Make the ALV more approachable:
In order to make the ALV more approachable, include a container with summary of the program. I generally like including the program name along with summary, date, username .
These are few tips that I follow to enhance the experience of ALV from a developer as well as a customer’s perspective.
In the next Blog I will try to deep dive this with an actual example. Stay tuned 🙂
I have a sub-class of the ALV grid which I always use. It provides functionality for titles, events etc etc and provides the same look and feel for every ALV Grid that i write. Common sense really.
Probably every ABAP developer since the ALV came out in the year 2000 has their own template program so they do not have to start from scratch each time.
I think there are many people inside SAP who would be shocked to realise how many new ALV reports are getting created every day. They think we have all moved away from the SAP GUI, which is why they will not make CL_SALV_TABLE editable, or officially enable the push channel functionality for the SAP GUI ( which is where one ALV report can publish an event, and any subscribed ALV reports , even for different users, can auto-refresh in response).
I agree that SAP seems to have forgotten the thousands of users using the SAP GUI.
I have not heard of the "push channel functionality" and find that interesting...
The idea of the messaging channels is that if I have an application which is run at head office and it lists all the quality inspections that have to be done country wide, and the person at head office adds a new entry relating to a specific plant, then an application running by a user at that plant can subscribe and get automatically refreshed.
That works fine, but officially only for web based applications. It also works for GUI applications but that is a "prototype" and not to be used by us customers for productive applications. SAP have also promised to remove this functionality at some point in the future (for the GUI) but it is still there as of release 7.52
Ah, interesting. I will do some digging into the subject.
While I completely agree that "it is always a good practice to give a polished end product" the suggestions mentioned are about offering basic ALV functionality, it doesn't seem to qualify as "polishing".
I'd disagree with some of the points.
4. How exactly does this make the program "approachable"? Such headers IMHO are a legacy from the mainframe printout times and add no value. Program name should be in the title line where it belongs. Do the users not know what day today is or what their name is? There can be some merit in adding a header but it needs to offer something helpful to the users. And not every ALV report benefits from it (majority don't).
If you choose to post more on this subject please consider including more information to support your statements. E.g. in what business context what specific value/advantage is gained.
Of course, it's possible to write an engaging and informative blog based solely on common sense and widely available knowledge but then something needs to be added from the author. This blog, unfortunately, is just very plain. E.g. you could've added at least the SALV demo program names that illustrate your points. Anything.
There are some posts on SCN on how to write a better blog (this is just one good example), you might want to take a look at them before continuing this journey.
Different eyeballs, different vision. In my workday reality we must stick to a certain style of programming for "new" coding, but if we want to "fix" someone's old bad stuff we would have to do it "quietly" and it better not break something. The effect is a mix of procedural and oo-type programming. Personally for me the actual coding is not the point whether one uses procedural syntax or OO-Syntax. E.g. I think of ABAP/HR as object oriented even though the code itself is more often than not procedural.
ALV headers at customers where I have worked seem to be wanted by the end-users and often are specified in the requirements. Just because something was used during the mainframe time does not make it bad. Heck, SAP itself is just an old mainframe applications and an older one at that, similar to CICS, SHADOW, TSO and other messy transaction type systems. E.g. the old CMS/VM mainframe system was "lifted" pretty much verbatim to create VMware. All of course legal, because even back in 1967 there was "open source" required then by the U.S. government since they helped finance Unix and VM.