Navigation: Passing Large Amounts of Data to Another App

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.

Note

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:

Storing data in a window local JavaScript variable: This may no longer work if, in future, every application in the SAP Fiori launchpad is launched in a new window.

Automatic URL Shortening for SAP Fiori Apps

For navigation between SAP Fiori apps running in the same launchpad, automatic transparent URL shortening allows applications to overcome the limitation regarding URL length.

Note

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.

Caution

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.

Considerations for an Application-Specific Back-End Service

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:
- You can generate a unique hashtag for a new set every time.
- You can use a fixed key or a limited set of fixed keys.
How is persisted data cleaned up?