My SAPUI5 Christmas Wish List
Dear Santa,
I think I have been pretty good this year. I have tried not to fight with my brothers too much. I have tried to think of others before myself. I have tried to be more tolerant of those other idiots – who are everywhere by the way. 😉
So, if it’s okay, here is my short list of some things I would like from SAP for Christmas
Downloadable SAPUI5 Runtime & SDK.
Thankyou for giving me one of last years wishes – namely the hosting the SAPUI5 and OpenUI5 libraries on a CDN so that those of us who live and work outside the SAP corporate network can get fast and reliable access to them.
But whilst I can download the OpenUI5 SDK to my development environment I can’t easily do this for the SAPUI5 library. This makes it hard to do offline development of SAPUI5 applications. It also makes development a pain when I have browser caching turned off and the library has to reload all the time.
Not being able to easily download the SAPUI5 runtime makes it more difficult for me to provision non-SAP servers, such as NGINX, for SAPUI5 apps.
Combine SAPUI5 and OpenUI5 libraries into a single package.
Why do we have two different libraries for the same thing? Is it a symptom of bureaucracy gone mad or is it something else? A single library with a single code line has got to be easier for all – and of course keep it Open Source. If SAP have proprietary IP in the SAPUI5 library then just agree to Open Source it please. If the SAPUI5 library uses non-SAP IP that is restricted just get it sorted out please.
FLP to use standard SAPUI5 library
The Fiori Launchpad (FLP) is designed to use the SAPUI5 library that is delivered with the underlying application server. This appears to be a ‘special’ third SAPUI5 library! *Note – please change previous request to combine every SAPUI5 library into one.
SAPUI5 applications that are built to run as first-class citizens of the FLP have to use the same SAPUI5 library that FLP loads. This means these apps have to be written for the SAPUI5 library that is installed on the application server and in most cases an older version than is generally available.
If FLP used the standard (unified) SAPUI5 library it would be a simple matter to point it to the latest available and allow developers to build FLP apps using the latest available technology.
SAP to actively enable rapid innovation on ABAP platform.
The change management culture of enterprise software inhibits innovation. While carefully managing change in enterprise systems we also slow down the potential rate of innovation. Changes tend to be bundled into large groups that are implemented once or twice a year scheduled months in advance.
Rapid innovation requires a different approach. One that supports lots of incremental changes. An environment where ideally the develop, test, deploy cycle can happen in minutes not months. The people building SAPUI5 applications need this now.
SAP gets this – but they are doing nothing to help enable rapid innovation on their good ole’ ABAP platform. I want tooling and strategies to support rapid innovation on all SAP platforms. How about SAP support for ABAP/Git integration for a start?
Thanks for your patience Santa. I will try to be better next year.
Your friend,
Graham Robbo
We can but ask! I'm with you on the FLP request in particular.
I see too many customers not able to manage transport requests as it is... I'd be curious to see if a ABAP/Git path would make things better or worse... because it seems to me more a people problem (governance, discipline, rigour) than a software problem ... given there are also lots of customers for whom transports are just a regular bread and butter activity.
Perhaps we need to check Santa's naughty and nice list first to see who's done their homework before they play with that particular new toy... 😏
Thanks Jocelyn,
You are 100% right that it is more than just a software problem - it is a cultural one.
But, what about a GitHub webhook, that triggers a deployment app on the ABAP dev system, that performs pre-deployment tasks (like automated testing, minification, etc.), then creates a transport, deploys into UI5 framework, and then releases the transport and imports it into the Dev (and maybe even Prod) system?
Voila!
Trivial example I know, but very do-able.
Sounds a bit like http://yelcho.github.io/sapui5-deployer/ 😉
Cheers
Graham Robbo
Patent pending?
Open Source 😎
Ooh, very nice - I wasn't aware of it. What's the license, BTW - FWICS it's not mentioned in the README or the source code?
I am the author - you can use it however you like. 😎
🙂 I'd suggest explicitly choosing a license though - without one, it's not open source (if I'd stumbled upon the repo I wouldn't have known and so would have not considered using/contributing to it).
Don't mean to sound so pedantic,but so much source on GitHub has no explicit license, which definitely makes it not open source, even though the author perhaps intended it to be ("public domain" is not a valid open source license, for example)
Pending Patient?
Now now! 😉
Yes yes and yes....
I spent 5 hours on a Plane the other day with the idea of working on a Fiori app that I'd recently scaffolded on web ide.
But the damn FLP has so many hooks into the web ide templates it's too much of a pain to disentangle.
A simple download as a zip for sapui5 would be great. Even better host it on bower (although I notice the openui5 bower repo has fallen into disrepair)...
With you on all points here.
I think the viz libraries were kept out because the quality wasnt up to scratch.
I agree though - it should just be one library.
A good list - hopefully Santa will delivery on at least some of them in the coming twelve months 😉
It is possible to download the SAPUI5 SDK and runtime, but the process is certainly not easy - I have a home-rolled script that extracts it from the Eclipse plugins (which are available from the CDN). Definitely not as straightforward as it should be and for reasons that aren't too clear, really.
Agree with you 100% about the ABAP tooling - the language itself has evolved rapidly, particularly since the advent of HANA, but the tooling hasn't kept pace. IMHO, we haven't seen any major new features since the advent of packages and the active/inactive concept, both of which were added over ten years ago. I think retrofitting a proper version control system (with proper branching and merging, etc) into the ABAP landscape would be quite tricky (particularly as database changes and source code are so intertwined), but I'm sure it's not an insurmountable problem...
I can only subscribe the need for introducing branching and merging into the version control of ABAP code.
Hi,
Can you help explaining a bit more about the need for branching? Do you have multiple development systems which are difficult to merge, or is it more a need for backup/rollback capabilities? Doing development on 5 branches at the same time would require 5 SAP systems.
You might want to try out abapGit, suggestions/questions/pull requests welcome on the github page.
One feature I would like to see is more detailed version management in ABAP, if multiple developers are working on the same objects in the same open transport request, then it is difficult to tell who changed what and when.
This could be built on top of the ABAP stack by exporting all active changed objects to git every eg. 10 minutes.
Well, one common case is an application that has version 1.00 in production and version 2.00 currently being worked on in development. Same system landscape, same list of objects for the application, etc.
Now, a fix needs to be made to the version in production (versions 1 and 2 are very different). With a proper version control tool (using Git terms here, but the same principles apply) it's easy to check out the production version of the source, create a topic branch with the fix, test and then merge the fixes. Version 1.0.1 can then be promoted to production and development on version 2.0 can continue.
Doing that in an ABAP environment is a real pain as you need to retrieve previous versions of source in development, make your changes, promote through the landscape and then retrieve the version 2.0 sources in development to continue working on that version. A very tedious set of activities for something that's easy with a different (and dare I say it, more modern) toolset. I agree that implementing something better in the ABAP world would be tricky due to the tight integration between database and source code, etc. but I'm sure something better than what we have at the moment can be delivered... I do have few ideas of how that could be implemented, but they would require quite fundamental changes to the way the ABAP subsystem and kernel work (ie it's not something that could easily be delivered by someone outside SAP).
Thanks for the link to abapGit - I've experimented with it before - excellent work!
Sometimes we're doing further developments for applications already in production over a longer period. If during this time bugs have to fixed on basis of the productive version it would help if the developments are done on a seperate branch and the master reflects the productive code.
I forgot where a read about it but I think there are some third party components like the Rich Text Editor and others that sap is not allowed to distribute to non customers and that is part of the reason SAPUI5 and open UI5 are not identical.
Regards,
Christian