Paul Modderman, author of our book SAPUI5: The Comprehensive Guide, sat down last week to answer reader questions about the programming language on our LinkedIn page. Here's a recap of what was asked, and what Paul had to say.
Q: Why should I use SAPUI5 and not some other web technology to write apps?
If you’re doing web development with SAP as your backend, SAPUI5 is a powerful choice. It’s designed to work smoothly with OData, which SAP Gateway and SAP HANA output natively. It flows right into the SAP Fiori launchpad, and works quite well as single apps which are part of a larger experience of unified enterprise applications. If you’re doing web development and SAP is not your backend, SAPUI5 is probably not your first choice, and probably shouldn’t be. But I do not see that as a downside for SAPUI5!
Q: I have read SAPUI5: The Comprehensive Guide, 1st edition, and I found it a little confusing. First, you describe all four viewtypes and finally say SAP's preferred viewtype is XML. If that is the case, why not concentrate on XML from the very beginning, and not confuse readers by explaining one view first, then asking to replace it with XML at the end? By the time I got to XML, I was lost.
You are right. There are several options for creating views in SAPUI5, and XML is the preferred type. Two things I think you should keep in mind:
- This book is intended to be comprehensive (or as comprehensive as can fit into one volume), so explaining all view types is a necessary undertaking.
- Even if you always start with XML views, there are occasionally times when you will have to resort to understanding the notion of JavaScript view styling if you need to be more dynamic than the XML allows. Knowing all the types definitely informs each.
By the way, calling all authors: there is room in the world for another book in this series, much shorter, called "SAPUI5: The Quick Start Guide".
Q: I have done extensive coding in ABAP; however, I'm not that familiar with JavaScript or XML or HTML5. I have tried to learn them separately on other websites, but that knowledge will not help us in UI5, as SAP has its own kind of wrapper, and it is not "true" JavaScript or HTML5 coding. When a system creates controller, model, etc. files automatically in SAP Cloud Platform, it is not easy to follow the code that is automatically generated. What do you recommend that we should do to understand it better?
Don’t despair! Our book attempts to put together the understanding that goes behind the scenes of automatically generated code tools. I suggest two things to make understanding easier:
- Walk through and take the time to play with the small examples at the beginning. The examples move from code-all-in-one-place to splitting up into controller/view files.
- Browse the sample controls at https://sapui5.hana.ondemand.com/#/ and flip back and forth between the live screens and the code behind them. I have learned so much just by laser-focusing on one control and watching its various options come to life in the samples. By the way, SAPUI5 is true JavaScript and true HTML5! But you are certainly correct that SAPUI5 has its own flavor of accomplishing single page applications, distinct from other frameworks, just as those frameworks are distinct from one another.
Q: It seems development in UI5 takes a very long time. Do you agree? We used to create screens in SE51 and code in a very short period of time. Now it takes weeks to develop in UI5, especially by the time you understand OData and code. What do you recommend to make the development faster?
To make development faster, I recommend a few things:
Make yourself faster. Get accustomed to source control so it’s easy to try something new without fear of destroying your old work. Always be writing code just to try something. My project files are littered with little apps that are intended only to teach me one new thing. That one new thing always comes in handy either right now or later on.
Make your team faster. Some folks have a better grasp of OData and others might lean toward front end work. For those who work on the front end, learn how to use mockserver.js so you can avoid having to wait for an OData service.
Give yourself permission to understand that this does take a little longer. SAPUI5 is geared toward making a better experience for the end user. Even if it’s easy to smash out an ALV report or something similar in ABAP, by using SAPUI5 you’re making a commitment to improving the work lives of many many people.
Q: Why does deploying to SAP Cloud Foundry take so long?
There is some good discussion in this SAP Blog post. A few points:
- Could partial deploys work for you?
- One commenter was experiencing long deployments because of long upload times. Is that part of your issue?
- I am no stranger to builds that seem to take longer than they should, and this happens in a lot of cloud environments (e.g. Google Cloud, with App Engine Flexible, can take similar amounts of time to deploy). I think part of the issue is that flexible provisioning of resources to do the deployment can be time-consuming.
Q: Is there a way to improve web IDE auto code completion?
You can do a couple things:
- Update es-lint rules to help with annoying warnings you don’t want, or warnings that you do want. Check out this SAP Blog post.
- SAP has a beta version of TypeScript enablement in SAPUI5. This one is coming in the future, and I can’t personally make any guarantees about availability/usage, but getting TypeScript involved in JavaScript projects makes it so that many editors can do better content assistance.
Q: The project I'm currently working for is planning to switch the SAPUI5 major version (from 1.52 to 1.71). Do you have any tips for updating the SAPUI5 major version? In this specific situation (update from 1.52 to 1.71) should we expect major compatibility issues within custom developed apps?
You should not expect major compatibility issues. As a general statement, SAPUI5 is very good about maintaining compatibility across minor versions. (Using SAP’s terminology as shown here, 1.52 to 1.71 is a “minor” version upgrade.) If you stick with the public APIs and don’t use sap.ui.extend very much, you will almost certainly be safe. You should, of course, absolutely test your apps when you switch to the new version. If you can get buy-in from your project, use it as an opportunity to automate some of your testing!
Q: For the SAP Fiori desktop app should we use the sap.m controls or the sap.uxap?
They're both well-enough supported and powerful that your choice should really depend on the experience you're planning to make for your users. If the Object Page layout is the best choice for your app, then move toward those uxap controls. But there's no reason you can't mix and match. The sections of the Object Page can certainly contain sap.m controls.
Q: The sap.ui.cor.util.Export control is deprecated. Is there a replacement?
Not a quick and easy one I've seen. Looking for some examples in my old code, I will reply again if I find a nice slick example.
Q: What do you think about wrapping all SAPUI5 CRUD calls in JS Promises? Is it worth it (considering the overuse of Promises increases CPU usage)?
I don't know about all of them. I think the current CRUD style with the success and error callbacks works pretty well. But I have seen some cool things where you go "I want these 6 requests to happen, and then I want to do something after they're all done" that Promises helped with. It was a little more elegant than $batch handling.
Q: What is the status of the new Business Application Studio IDE?
It's generally available for Cloud Foundry customers.
Q: SAP Cloud Platform Site for Cloud Foundry is so limited compare to site for NEO, should we continue to use NEO?
Cloud Foundry is where innovations happen; I would go to Neo wherever I can.
Q: Apart from your book, openSAP website, and SAP's SAPUI5 site, what other websites or resources do you recommend so we can learn more?
Here are a few resources I recommend:
- Use https://glitch.com to prototype and share quickly.
- Use an XML format checking site for quick troubleshooting XML view issues, like https://www.xmlvalidation.com/.
- Review the SAP Fiori design guidelines. They will make you a better developer.
- JavaScript: The Good Parts
- Get really good at the debugger in your browser. The number of bugs I can fix by prototyping in the debugger is just insane.
- A quick tool I love for inspecting JSON results of OData calls: https://jsonformatter.org/
This post was originally published 4/2020.
Comments