My Journey to UI5 – Part 2
Continued from My Journey to UI5 – Part 1
Sorry for the long waiting, avid readers, but summer is here, kids requires their kite-builder and work is always huge!
This part, thanks to Christopher Solomon who suggested to blog about, will focus on the ABAP weight in a UI5 application.
Yes, we have a pretty and nice and userfriendly interface but… this could be a boomerang for the developers!
Now that we gave to users something that looks like a “common” app, that they can use on any device like their app, embrace many design concepts from their other app, the users obviously want the same response time and reactivity like many other apps!
As ABAPer I’m aware that main difficult developing in SAP it’s not the syntax (pretty easy and verbose) but the amount of data to retrieve and processes and flows as well: SAP is really complex!
Switching from the common SAPGUI to UI5 helps us a bit because forces to think smaller, splitting the features in different apps.
And splitting features means also that we have to manage less data.
Yes and no.
Because if we develop a fast SAP report, this doesn’t mean we also have a fast Internet application.
I’m over-semplifying the concept, I know, but we are talking of Internet, where what is fast now, it’s already slow and past in two days.
We have to refine our ABAP skills, taking them to the limit, polish the milliseconds when performing an action on the backend.
We are developing “apps” and users’ expectations are pretty high or we’ll pass from “ugly SAP report layout” to “useless and slow SAP App”.
So small amount of data surely means less data to read and transfer (quick!) but we have to identify the sensible data we need, following as much close as possible the development guidelines (here a book https://www.sap-press.com/official-abap-programming-guidelines_2093/ from Horst Keller and I suggest to follow him and his post on ABAP space too) .
Still, beware: you’ll have slow application from time to time.
In my experience I’ve to perform an HU related good movements and I followed all the hints I know, all the one I found on ABAP workspace plus a couple of new suggestions from former colleguees.
And still, since I rely on standard BAPI, I faced a slow down when I commit the changes (aka execute the good movement) because… the BAdI implementation was a mess!
I took the chance to enforce the development guidelines for our consultants who never had or followed one (oh yes, they use ABAP OO… with 583 rows long methods -sigh-) and do some cleanup of the existing code.
Pure bliss with tears of joy to halve the code length, organizing in smaller cluster (Forms or methods) and deleting rows over rows of comments so full of meaning (date-developer name -start …. Date-developer name-end)!
The lesson is easy: you still have to focus on your ABAP skills, refine them, polish them and keep them up to date as much as possible (for me, no ABAP 740, working in 731 for example).
And I do not think I’m the only one thinking this since the next SapTechEd are full of topics around the dreaming world of ABAP (with candies and cookies for everyone).
For an old ABAP developer (or even for someone who started to develop when PC’s memory was measured in KB and not in GB) the resource bottleneck is a sensible topic that the increasing hardware performances put apart more and more.
The “app-izing” world took is dusting off these issues and force everyone to be carefull about it.
ABAP is dead! Long life ABAP!