Multi-Version availability of SAPUI5
Dear users of SAPUI5,
as of today (July 30th 2015) applications will have the opportunity to refer to specific versions of SAPUI5 from SAP HANA Cloud Platform (HCP). With this feature applications can now control themselves to switch to a different version of SAPUI5 based on their release and upgrade schedule.
The following snippet shows the current way of referring to UI5 on HCP:
This will refer to the latest available version of UI5 on HCP. This version is controlled by the SAPUI5 team and will be normally updated in bi-weekly cycles with each HCP delivery. As this is a dynamic version it is not recommended to use this for applications. For testing purposes and for e.g. JSBin code snippets it is helpful because you can validate fixes later on once the update is available with that dynamic version.
If you want to use a specific version of UI5 you will be able to add the version as segment into the path of the bootstrap script tag:
This will load the specific version from HCP. This version is static and will not be changed anymore.
The difference in the URLs is a version segment between the host part and the resources segment:
- dynamic – always the latest version
- static – specific version – here: 1.28.9
In addition cache control is different for dynamic and static resources. Whereas dynamic resources have a max-age of one week static resources have a max-age of 10 years. In both cases CORS (https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) headers will be set so that you will be able to consume resources from the central location without any proxy in between.
Another important aspect for SAPUI5 on HCP is the usage of Akamai (available since March 17th) to distribute static resources as close as possible to you. Static versions will automatically benefit of Akamai. More details about the Akamai enablement can be found here: http://scn.sap.com/community/developer-center/front-end/blog/2015/04/01/sapui5-is-now-delivered-via-akamai-cdn.
If you are interested in the available versions of SAPUI5 on HCP you can have a look into the version overview. It lists the available versions and their maintenance status:
- Version Overview: https://sapui5.hana.ondemand.com/versionoverview.html (which is available as of July 30)
- SAPUI5 maintenance strategy: https://sapui5.hana.ondemand.com/docs/maintenancestrategy.pdf
Enjoy and best regards,
Peter Muessig on behalf of the SAPUI5 team
QUESTION: I am getting a the error: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”
ANSWER: Do not attach custom headers (X-…) to all requests via e.g. jQuery.ajaxSetup. In case of CORS requests this leads to unwanted CORS preflight checks, which will harm the performance of your application and also is not supported by our AKAMAI CDN setup to prevent this issue.
This is a great addition!
Unfortunately, I have a problem when bootstrapping a static version. Fetching the german message properties of several libraries fails (404). The request targets messagebundle_de_DE.properties first which cannot be found. Afterwards it will get messagebundle_de.properties which exists:
As seen above such a fallback to _de instead of _de_DE is not in place for the ca message properties.
The behavior could be spotted in Chrome, FF and IE. The tested version was 1.28.10.
I'm sorry if this is not the right spot to report but maybe other users experience similar issues.
A quick workaround would be to set the language to 'de' right after the bootstrap.
When the language is set to de_DE, there shall be an attempt to get the resource bundle for de_DE. In this case, it is not present, then there is another follow up attempt to get the resource bundle for de.
It is just like how many programming languages work. Such as Java, where there is a fallback mechanism to fetch to high level resource bundle for missing resource bundle at lower locale level.
Can you shed some lights on the issue(s)?
I get that. But I'm wondering because when executing the the bootstrap without a specific version it works without a 404. When running 1.24.7 it works. But for the versions 1.26.3 upwards the errors occur.
You can try it here
Please create a new Discussion for your question. You will get more eyes on your issue that way.
Regards, Mike (Moderator)
SAP Technology RIG
sorry for my late reply. In case of using UI5 without the version in the URL we are using a Java handler to deal with the language fallback. For the versioned access we just delegate to a static deployment and there is no Java handler in between which handles those fallbacks. An option would be to specify a concrete language like "de" or "en" which are provided by UI5.
I will take this point here and look for a solution...
Now also available for OpenUI5: OpenUI5 Blog - Use a specific version of OpenUI5 - from our CDN
This includes preview versions of upcoming releases, see https://openui5.hana.ondemand.com/versionoverview.html
So you can easily do compatibility tests with upcoming (Open)UI5 versions.
A UI5 CDN with version support .... dreams come true .... finally!
This is awesome news, and news that I have waited a long time for.
Now... when I first requested this functionality, I was informed that there were no SLAs in place for the uptime of the UI5 libs.
If I use these versioned libs in my HCP applications, can I depend on them having the same uptime guarantees as the HCP platform? Since a third party CDN is being used does SAP have an SLA with them as to the uptime?
Obviously if I'm building an HCP app - I can use the HCP uptime SLA as part of my calculations on what my app uptime SLA I can provide to customer will be. If I'm to use the CDN to provide the access to SAPUI5 code, I need to understand what uptime SLA it will have so I can use that in my calculations rather than relying on a cloned library stored in my app.
Happy to take the discussion offline if it needs to for commercial reasons!
just to clarify: are you looking just for numbers to do calculations, or are you looking for an official SLA with monetary compensation in case of excessive downtime?
In case of the former: I'm not yet sure how much of the Akamai SLAs I can disclose, but as making files available is their main purpose, you can expect their guaranteed availability to be very, very good and to not affect the overall reliability negatively.
Not looking for monetary gain clauses, pretty sure we don't get them on HCP anyway, more a statement of historical and planned up time. Pretty sure Akamai are very good at keeping files available, but wondering if they have planned outages for example and/or any notification of these.
I'm pretty sure that HCP historical downtime is greater, but hopefully you see what I'm trying to get at.
Akamai has no planned downtimes. We've indeed measured 100% uptime since we've deployed SAPUI5 head version on Akamai few months back. This was done from several locations around the globe.
So, what we can state for sure is we guarantee at least HCP uptime SLA. We will check in addition if we can disclose Akamai SLA.
it looks like the answer for the time being is that you can expect "HCP uptime or better and no planned downtimes". Normally I would say "better than HCP", but for files not cached by Akamai yet, HCP will always define the lower boundary, so it's pointless to discuss how much better it might be.
We have set up an availability tracker where you can check actual availability.
Is this enough for your needs?
Thanks for sharing and looking forward for multi version support.
Works like a charm for me - both SAPUI5 & OpenUI5!!! Thanks!
Is there any plan to publish/deploy nightly builds as well?
Maybe at least for OpenUI5?
Is there a "config" way planned to be able to change the version ?
For e.g. we would release all apps with 1.28 and once we have done our tests, would like to now release it for 1.30. Unfortunately this would imply changing the static URL for "src" in all apps.
Released Apps: src="https://sapui5.hana.ondemand.com/1.28.9/resources/sap-ui-core.js"
After Testing and incorporating new features: src="https://sapui5.hana.ondemand.com/1.30.0/resources/sap-ui-core.js"
You can use maven and maintain the version configuration in POM.XML.
If we use as per your suggestion, for example we have SAPUI5 v1.32 in our GW and we thought that we point our applications to 1.28, but we have custom theme.
When we upgraded our theme, we did a rebuild and theme fixed and running fine for v1.32 but it is not working properly and broken for v1.28, so should not we use multiversion capability of SAPUI5 and only we need to point our applications to higher version that is available in the GW?
Did you get anything on this? We have a very similar problem.
Hi folks, similar problem here. SAPUI5 Theme designer is always running on the latest UI5 version whereas my apps are on the stable release.. (as of now theme= 1.40.11 my apps= 1.38.7)... themes of course are broken. Would love to be able to use the Theme Designer with 1.38
I have the same problem. Have you ever solved it?
It is possible to select the SAPUI5 version in SAP UI Theme Designer by adding the URL parameter:
more info at: https://launchpad.support.sap.com/#/notes/2306045/E
i have a problem regarding sapui5 version 1.38.4 regarding Negative cache for viz library, becasue of that i am getting Syntax error for loading of library.js for viz.
In my testing this method is saving me about 2s on a first load (empty cache), which is great. I've noticed that the cache buster mechanism is still working even though I had to remove the previous reference to cache busting in the index.html:
How come this still works when loading the libraries from SCP? Is the relevant logic in the bootstrap there?
Perhaps the documentation should be updated to make this clear?
Cache Buster for SAPUI5
the Cache Buster is only needed if you consume UI5 without a concrete version in the URL. When you consume UI5 with the concrete version in the URL this is not needed, as the content served by that unique URLs will never change and can be cached forever.
The bootstrapping from CDN is explained in the demokit here:
But the explanation about the necessity of the cache buster mechanism for the versioned URLs is indeed missing and should be added here. Thanks for the hint!
Can we use multiple sap ui5 versions from sap gateway systems not from HCP.
Like old apps should be in sap ui5 - 1.28
new apps in some higher version.