What?
Inspired by alessandro.spadoni's useful post explaining the "Fiddler" proxy, I want to explain how a UI5 app can be easily run with a different UI5 version, without changing any code or installing and configuring additional tools.
Why?
There are several use-cases, e.g.:
- Testing an existing application against a new version of UI5: can I safely upgrade UI5? Does the app still run? Any design changes I don't like?
- Testing a local fix within UI5 code against an existing application - useful to verify that a change does actually solve the customer's issue, even before committing the change, and a long time before the customer gets the change.
- Finding the exact patch version when a regression or other change in behavior appeared
- Debugging a tricky bug against a copy of UI5 with additional logging/tracing statements
To repeat the great thing about it: the actual productive app can be used for testing, without affecting regular users working with the app in parallel.
How?
Since UI5 version 1.30, the UI5 support popups (the Ctrl-Alt-Shift-S one as well as the small Ctrl-Alt-Shift-P one) offer configuring a different UI5 URL to reboot from.
Let's assume we are maintaining the "Worklist" demo app, and it is using UI5 version 1.30 (we use the URL with hardcoded version), which looks like this (I've opened the support window to verify that UI5 version 1.30 is being used):
Since this week OpenUI5 stable version 1.32 is available, so we are curious whether we could use this new version in our Worklist app. To do so, just expand the "Debugging" section in the support popup and find the section titled "Boot application with different UI5 version on next reload". It features a dropdown box to select a preconfigured UI5 version to use, a textfield to enter other UI5 URLs (the URL of sap-ui-core.js, that is), and a button to activate the usage of the selected UI5 version.
The list currently offers the public OpenUI5 and SAPUI5 servers, the OpenUI5 beta server, and the option to enter any URL to the sap-ui-core.js file. (Soon, some known versioned URLs will be added to the dropdown, but they can be already be entered manually, so this will just add more convenience).
So let's select "Public OpenUI5 server" from the list and press "Activate Reboot URL".
In the application window a popup opens to confirm and explain what's happening now: the browser has remembered that a different UI5 version should be used on next startup. So just reload the app!
Note: this configuration only applies to YOUR browser, so you can't affect any other users. And it only affects the next reload of the app. If you need to reload the app again, you have to re-do the configuration. (This is to prevent the situation where the app cannot be loaded, and you cannot switch back to the normal UI5 version because the app is broken or the given UI5 URL is wrong.)
And this is what you see after reloading the app:
The app warns the user that something special is happening. This is meant as additional safeguard to make sure nobody can trick an unsuspecting user into running an app with a modified UI5 version. (Security is also the reason why we can't just offer a URL parameter.)
After accepting, the application starts and opening another Ctrl-Alt-Shift-S window proves that the app is now using UI5 version 1.32 even though the URL still points to the 1.30 version of the app! And it still works, yay! 🙂
If you compare this screenshot closely to the very first one in this post, you notice a visual change that apparently happened between UI5 versions 1.30 and 1.32: the "letter" icon in the footer button looks different. During startup you might also have noticed the new BusyIndicator design (blue bubbles).
You could now do all kinds of tests with this app to verify upgrading to the new UI5 version is safe. Done!
Reloading the app again will revert to the original version and design.
What else?
As indicated in the beginning, you could also use a localhost UI5 URL to make a customer app run against your local copy of UI5. You just need to make sure that the server from which UI5 is loaded allows cross-domain requests (or use the --disable-web-security flag in Chrome).
Any Caveats?
Well, while this works well for "normal" simple UI5 apps, I have not really checked what happens for SAP Fiori apps with their custom bootstrap and control libraries beyond the normal (SAP)UI5 delivery or other special cases. A first test (loading https://fiorilaunchpad.sap.com/, which uses 1.30.8, with an older 1.30 patch) looked good, but going to a local 1.32 version of SAPUI5 didn't.
In general, all the used control libraries present in the original UI5 installation also need to be in the substitute installation. E.g. running a SAPUI5 app with an OpenUI5 runtime fails when a library like sap.viz is used in the app, which is not part of OpenUI5.
Of course the Fiddler approach is more powerful, as youcan configure different substitution rules for different URLs, so you can change where data is loaded from, or where parts of the application code are loaded from, so the above does not cover all possible Fiddler use-cases, but it's probably still useful because it is so simple, requires no setup, and addresses the important topic of testing before upgrading the UI5 version.
Anything else I should know?
UI5 URLs you entered are remembered and kept in the list as soon as they were successfully used. To get rid of custom UI5 URLs in the dropdown, just delete the local storage entry:
Hope this feature turns out to be useful!
Andreas
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 14 | |
| 11 | |
| 10 | |
| 10 | |
| 9 | |
| 8 | |
| 7 | |
| 7 | |
| 7 | |
| 7 |
