When developing navigation, there are several ways to pass startup parameters to the target application.
The easiest way to pass startup parameters to the target application is to add them to the URL hash. The maximum length of URLs is limited by web browsers. If you have a large number of parameters and / or parameters with long values, this limitation may lead to a truncation of the URL. To overcome such limitations, it is a best practice to store a set of parameters with a key, and pass only the key in the URL.
Do not put any security-critical information in the URL.
The following table gives an overview of the different possibilities:
Method |
Recommendation |
Roundtrip Required? |
URL Works |
Longevity |
Cleanup |
Security |
Comment |
---|---|---|---|---|---|---|---|
URL |
For non-security critical data |
No |
Always and for everybody |
Eternal |
Yes |
Persisted on the client (browser history) |
|
Shortened URL |
For non-security critical data |
Yes |
For everybody |
As long as key data is retained |
Via aging, cleanup via batch report |
Persisted on the server. Anybody guessing or obtaining the key can access the data. |
Only for SAP Fiori apps running in the same launchpad |
Browser local storage, pass hashtag |
OK, if URL stability is not required |
No |
For me - in the same browser session |
Session only |
No cleanup, the space may be exhausted by other apps |
Persisted on the client |
Data in storage session is limited; some browsers do not support this in private mode |
Read/write to dedicated app-specific back-end service; pass hashtag in URL |
Optimal for large amounts of data |
Yes |
Yes - for a given time and for everybody; can be configured, to be defined by the app |
For longer time, controlled by the app |
Via aging, cleanup via batch, and so on |
Extra roundtrips; all parameters can be configured by app (lifetime) per user / per role; data amount unlimited |
The following variants are not recommended:
For navigation between SAP Fiori apps running in the same launchpad, automatic transparent URL shortening allows applications to overcome the limitation regarding URL length.
Currently, this mechanism only works for SAPUI5-based Fiori apps that run within the same launchpad on the same front-end server.
Automatic URL shortening allows apps to pass large-size parameter bags to other apps as startup parameters. When the URL hash exceeds size limits, the parameters are automatically replaced by a key and persisted on the front-end server. This mechanism is transparent to the application. This allows application developers to pass any number of parameters, with any name/value length, and not have to be concerned about exceptional cases when the URL becomes too long. The SAP Fiori launchpad decides which parameters are compressed and which ones remain readable/changeable in the URL. This depends on the length of the key of the compressed data in the URL as well as on internal considerations.
When URL shortening occurs, parts of the URL are stored on the server, in a storage that is accessible across users. If you would like to avoid this, make sure to work with hashes well below 500 characters.
A report is available for cleaning up data that was written to the server for URL shortening. For more information, seeCleanup of Expired Application State.
Do not put any security-critical information into the URL. If your input parameters contain any security-critical information, pass a neutral key instead, and store the data in an application-specific service in the back-end system as described below.
We recommend that the length of the URL hash on the client side has is less than 500 characters. If the amount of data exceeds this limit and cannot be reduced, the information has to be stored in a different location, and a corresponding key should be used for the URL.
To generate the key, you can develop an application service. You can then decide how you protect the data, especially if it can be accessed across users.
The following aspects have to be considered:
If the amount of data does not fit the URL, is it possible to reduce the size of the information, or can it be safely stored locally?
If the same user opens the link of the called application again in the same session, for example using the browser's back button or in a different browser window or session, what will happen? Do you want the selection still to be available? Where and how long do you want the information to be persisted? How unique is the storage key?
For this, the following options exist: