Where is my UI5 lib?

SAP decided once to offer UI5 on a CDN. This is like many other JavaScript libraries are offered too. Compared to hosting the library on some web server, a CDN distributes the files globally and tries to offer them closely to the end user. JQuery for instance offers all versions on their CDN, offered by stackpath. You can get jQuery starting from version 1.0.0, first published in 2006.

Another popular JavaScript library is D3js. Going back the version history and time is not a problem. Released 11 years ago, version 2.5.1 is still accessible. The library can be loaded from jsDelivr (CDN for open source projects). To get the latest version, just include this in the HTML file:

<script src="https://cdn.jsdelivr.net/npm/d3@7"></script>

Content Delivery Network

Offering a way to download a specific version of a library via CDN is common practice. It makes adoption of a library easier. When SAP decided to offer UI5 on a CDN they were dopting their UI5 offering to common practice. No need to download the UI5 SDK and extract the resource folder and make it locally available. Load the library from CDN and things get easier. As SAP is SAP, nothing is as easy as it could be and as UI5 comes in a commercial and open source version, there are two CDNs available.

• SAPUI5: https://ui5.sap.com/resources/sap-ui-core.js
• OpenUI5: https://sdk.openui5.org/resources/sap-ui-core.js

Now you only have to figure out which one you are allowed to use and load the library from the CDN. Still easy and still aligned with common practice. The CDN approach is very nice as it allows to roll out UI5 apps without having also to host the UI5 lib on your own. You only serve the app code, not the library. That is great as loading the UI5 lib means to transfer some MB over the internet. To be able to run the sample app Manage Products over 6MB is transferred. If you have a similar UI5 app, this scales up rather rapidly and very soon you’ll have to deal with several GB of traffic just for the library. That’s stuff you do not want to worry about, and CDNs allow you to focus on the app, not on the library. No wonder CDNs are popular. Another vantage is that the app can use automatically the latest released version of the lib. UI5 uses semantic versioning. Therefore, using the latest version should just work without breaking an UI5 app, even when it was written years ago using an older UI5 version. A specific version of the lib can be enforced by providing the version number in the URL, e.g. https://ui5.sap.com/1.105.0/resources/sap-ui-core.js

CDNs are great and UI5 is available on a CDN. Win-win. Yet, I am not 100% sure if SAP did offer UI5 on a CDN because they were convinced that this is the way to do it or because they simply had to. There is the famous SAP note 2943781 that states clearly that on premise UI5 apps are forbidden to make use of the UI5 CDN. You enforce this kind of restriction to:

1. Save costs. CDNs can be expensive
2. Make life easier for your support staff

Both cases are very valid and exclude the customer and end user as they are focused and tailored to the need of the vendor. That’s somehow contraire to the “lets make things easier for everyone and offer the lib on a CDN” approach.

SAP’s best practice

That’s where the announcement “Removing outdated UI5 versions from UI5 CDN” starts to play an important role. The title is about UI5 and is not differentiating between OpenUI5 and SAPUI5. And yes, SAP is removing outdated versions for both flavors. The version is outdated, not supported, and might contain security risks. Why continue to offer it? Sounds like a good idea, right? Per se, this is not a bad idea. In general, any library that steals data, comes with a backdoor, or any other malicious behavior should not be distributed. Access to a version with an identified security risk should be restricted.

Reaching EOL?

What about a library that has reached EOL? Should that one removed from the CDN?

In a perfect world: yes. UI5 uses semantic versioning, if you do not pin your app to a specific version, the app will always use the latest UI5 version available on the CDN. An UI5 app written for 1.30.0 will work with version 1.106.0 thanks to semantic versioning. The app will continue to work and automatically wins: performance, bug fixes, security, etc. No effort on the app development side.

Reality, however, is different. Apps are developed, tested, released, and then enter a maintenance period. While using the latest version available for a UI5 app is recommended, and thanks to semantic versioning should work, this is not how UI5 projects are delivered all the time at all customers. Unfortunate, in many cases, the project decides to use a given UI5 version for developing and testing. That is the version that is approved and under which the app is released. While there is a maintenance period, rarely it is used to also update the UI5 version. A common argument against this is from the functional team: than we have to test everything again. After the app is released, why bother with a technical update that brings no benefit to the end user or functional team (aka the one that pay for the app)? If you wonder if this is true: how often is your SAP system updated? How many UI5 apps do you find with a pinned UI5 version (not FLP apps)?

Using Google, it is very easy to find some UI5 apps from SAP. After a few seconds I found 4 apps, all using a specific, pinned version of UI5. 50% is using CDN, 50% a local version.

• SAP HANA Cloud Capacity Unit Estimator (link): uses CDN, pinned to 1.90.0
• SAP Data Intelligence (cloud edition) – Cost Calculator (link): locally hosted?, pinned to 1.66.0
• SAP Data Warehouse Cloud Capacity Unit Calculator (link): locally hosted?, pinned to 1.91.0
• SAP Discovery Center estimator (link), uses CDN, pinned to 1.103.0

Note to SAP: please, please use custom DNS names for your services.

Every single app shares the same problem: using a specific UI5 version. The DI/DW calculator apps are using outdated, not supported UI5 versions. If the DW app would use the UI5 CDN, it would have a problem after Q3/2022, as there the support for 1.91.x ends. Meaning that SAP removes it after some time from the CDN and the app would stop working. The DI app that uses 1.66.0 would have stopped working already. The HANA estimator will stop working soon if not updated, as end of cloud provisioning for 1.90.0 is scheduled to Q1/2023. The Disco estimator needs to be updated until Q3/2023 to not stop working.

Again, this is just how reality works. Developers are pinning their UI5 apps to a specific version. SAP’s decision to remove libraries from the CDN is going to break apps. And this is because when many apps were delivered, this strategy was unknown and is not what developers and customers are used to from other libraries. The developers once responsible moved on, changed client, do not remember their old app and the customer is maybe even unaware of the announcements from SAP as they are functional only.

Is this not theoretical problem? Unfortunately, no. I am writing this post because I came across a tweet from Mr. Gregor Wolf. An UI5 app from SAP (sic) failed to work as the given UI5 version was removed. When not even the vendor is capable to ensure that their very own strategy works with their own apps, what do you think are the odds that this is going to be a major disruption at customers? While the idea to remove outdated versions is nice in theory, reality is going to make this a very tough time. Customers need to constantly check and update their apps to ensure that their pinned UI5 version is working / supported. Or move directly to the latest release. Which still means to adjust already delivered apps.

Even when the app is using a long term supported version of UI5 like 1.71, this does not mean that the app is safe. SAP states: “In addition to this also patches of versions in maintenance which are older than one year will be removed.” (link)

While 1.38 is supported until Q4/2028, the available versions are limited.

The fun really starts as SAP is not only doing this for SAPUI5, but also for OpenUI5. And there they are even faster / stricter when it comes to removal. For the same 1.38 version, everything older than 1.38.51 is already removed.

• Working: https://ui5.sap.com/1.38.48/resources/sap-ui-core.js
• Error: https://sdk.openui5.org/1.38.48/resources/sap-ui-core.js

Current status is that working apps are going to break as SAP is removing libraries. Even when the app is using a LTS or maintained version, if the app is using a patch level that is older than one year, it will break because of SAP removing the library. So far, a working app is going to break because of SAP. So far, this is a FUBAR situation. A rare picture of the meeting room when SAP made the decision:

Alternatives

Nevertheless, it is SAP software, and SAP makes the rules. If you have an UI5 app that fails to work because SAP removed the library: you won’t be alone, and even SAP software already suffered from this. This won’t help in real world, as your app is still broken and users are unable to use it, but maybe it helps emotionally. Side effect: the removal makes UI5 not any longer the best choice when it comes to a web library. The maintenance effort will go up if you continue to use a specific version. For open source projects, it also means that either always the latest release is used, or maintenance effort increases. At least for OpenUI5, SAP might consider using an open source CDN that makes all versions available.

Instead of removing libs, SAP might monitor the access and only remove a version that is without any access for at least some month. From the blog post it is clear that SAP can monitor the requests.

Removing a lib that you know is used by a customer (SAPUI5 is for customers only), maybe it is time for SAP to renegotiate their CDN contract.

All of the above are not really alternatives. What can be done or offered to ensure that apps don’t stop working? The correct HTTP code when accessing a removed UI5 lib is 410 – Gone. 404 and 410 still mean: the resource is not available under the given link and therefore, the UI5 app cannot load the lib and will fail to start. Maybe redirecting the browser to the latest UI5 release? And when a removed patch level is accessed, redirect to the latest patch level. This is not standard but will let the app continue to work. As for the removal of a patch level: think about offering version.minor. I let SAP solve the technical problems here, as they decided to let their customers solve a problem created by SAP.

SAP might also provide guidance regarding building and delivering UI5 apps. Pipelines, DevOps recommendations, tools to find out where future outdated UI5 versions are used. After all, one of the reasons this is a problem is reality and how apps are developed and delivered.

Or just let the UI5 in the CDN and do not remove them. I am not convinced that security is the real north star here. I think that story is not telling everything. I am not discarding money as the main driver. As SAP is a cloud company, they should be able to host the lib on their own CDN. Google, Azure, AWS have their own CDN service. Google hosts several libraries on their CDN. SAP, try to be a real cloud company.