URL Rewrite Modes

For destinations, the rewrite mode defines how the mobile services handles request and response messages.

Rewriting is mainly relevant for OData content, which often contains entity and other references as absolute URLs. Since the incoming URL that is used by the mobile application is different from the URL of the OData service, the content must be rewritten. The rewriting usually applies to request and response messages.

This functionality can also be useful for other content (for example HTML). If content rewriting is not desired, please choose No Rewriting.

The Destinations defined for an application are usually addressed by name, as you can also see in the APIs tab of the application.

Naming follows the pattern:

http://<server>/<destination name>

Note

This naming URL pattern does not apply to the Rewrite in Backend rewrite mode. Please see the specific section below for details.

For mobile services on Cloud Foundry, the server name is unique for each mobile application and no further information is required.

In contrast, for mobile services on Neo, all mobile applications use the same host name, and the configured application must be specified in the HTTP request by any of these means:

• X-SMP-APPCID cookie as retrieved during the application onboarding (this is mainly done by mobile applications based upon the SMP 3.x SDKs).
• X-SMP-APPID header with a value that corresponds to the application ID.
• X-SMP-APPID URL parameter with a value that corresponds to the application ID (this is mainly used by web-applications or for testing reasons).

Mobile applications that are built upon any of the supported SDKs already take care of this.

Rewrite URL

This is the default URL rewrite mode and usually the safest choice for OData content. This mode replaces the mobile services URL (including the destination name) with the value defined as the back-end URL in all request and response messages. It also rewrites the Location header of the response accordingly.

The rewrite URL format for Web-type applications is https://<host>/<applicationID>.

In case there is an additional system in between mobile services and the back end, the standard URL Rewrite might not be sufficient, since all three systems are using different host names, and mobile services services does not have knowledge about the host name of the final destination. In this case you must use Custom Rewrite URL.

Rewrite URL and Performance

You can use Rewrite URL with the Mobile Connectivity and Mobile Offline components. Mobile Connectivity is recommended for OData content and Mobile Offline is recommended for offline requests, since the no_url_rewrite option provides better download performance.

When handled through the Mobile Connectivity component, an Offline download request can trigger several to dozens more back-end requests, each of which could involve heavy computing work because of URL rewriting. The Mobile Offline component handles URL rewriting much more efficiently, by parsing OData and only finding/replacing the OData elements that contain URLs, while the Mobile Connectivity component does not parse the payload format and ends up finding/replacing the entire payload.

Mobile Connectivity destinations have four URL Rewrite options:

1. Rewrite URL

2. Rewrite URL on Back End

3. Custom Rewrite URL

4. No Rewrite

The Offline no_url_rewrite option is used to perform URL rewriting if the Mobile Connectivity destination is configured with option #1 and the request comes from Offline. If a request comes directly from a device app (online request) to the Mobile Connectivity component, the Mobile Connectivity component performs the URL rewrite as configured. Offline cannot perform a proper URL rewrite if Mobile Connectivity is configured with option #3, and does not derive any performance benefit if Mobile Connectivity is configured with options #2 or #4.

Note

If you enable URL Rewrite in the Mobile Offline component, you must also configure these settings for the Mobile Connectivity destination:

* Set the "Rewrite Mode" attribute to "Rewrite URL".

* Ensure that the "Relative Rewrite Paths" attribute is empty.

See [Editing the Application Configuration File](../../../features/offline/admin/config.md#editing-the-application-configuration-file) for information about **URL Rewrite in Offline Service**.

Rewrite URL on Back End

The back end rewrites the URLs. The mobile services forwards the host name and port to the back end as an HTTP header, and the back end creates the URL to retrieve back-end resources. mobile services does not alter the content, except for the Location header in the response.

This requires mobile services to not alter the path of the URL in any way and for this reason a destination that is configured for Rewrite URL in Back End can be called by the mobile application not by the destination name but by the path of the back end. For example:

• Back-end URL – https://ldcigm3.wdf.sap.corp:50057/sap/opu/odata/sap/FINCUSTFACTSHEET/

• URL exposed to clients – https://<host>:<port>/sap/opu/odata/sap/FINCUSTFACTSHEET/

To expose the full URL to clients, the mobile services passes the request path completely:

• Back-end URL – http://ldcigm3.wdf.sap.corp:50057/sap/opu/odata/sap/FINCUSTFACTSHEET/

• URL exposed to clients – http://<smphost>:<port>/sap/opu/odata/sap/FINCUSTFACTSHEET/

• URL format for Web applications – https://<host>/<back-end path>?X-SMP-APPID=<applicationID>, for example:

https://mobiletest-xxxx.new.ondemand.com/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?X-SMP-APPID=xxxxxBE

To expose the full URL to clients, the mobile services passes the request path completely:

• Back-end URL – http://ldcigm3.wdf.sap.corp:50057/sap/opu/odata/sap/FINCUSTFACTSHEET/

• URL exposed to clients – http://<host>:<port>/sap/opu/odata/sap/FINCUSTFACTSHEET/

• URL format for Web applications – https://<host>/<back-end path>, for example: https://mobiletest-xxxx.new.ondemand.com/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html

Considerations

• The base path of the URL must correspond to the path of the back-end URL. For other rewrite modes, the base path must contain the destination name (as in the example above).

• If you change the value to or from Rewrite URL on Back End, inform the application developer, who must update the application base URL accordingly, for both online and offline mobile application scenarios.

• If you change the rewrite value, you must also reconfigure the mobile application.

Rewrite via Cloud Platform App

To enable requests to fetch data from HTML5 applications that are hosted on SAP Business Technology Platform, select Rewrite via Cloud Platform App. This sends the host information in the X-FORWARDED-FOR header, and HTML5 applications send it to back-end systems in the Host header.

• If selected, the host name is sent to the back end in the X-FORWARDED-FOR HTTP header.

• If not selected, the host name is sent to the back end in the Host HTTP header.

No Rewriting

Request and response messages are not modified; they are sent directly between clients and the back end.

Note

The mobile services does not provide the functionality to use No Rewriting mode to support external back ends for offline usage.

Custom Rewrite URL

For request and response messages, you can define a search string and a replacement string, which need not be URLs. Clients initiate incoming messages, which pass through the mobile services and terminate in the back-end system. Outgoing messages travel in the opposite direction.

If you select Custom Rewrite URL, click Next. In the Create Destination dialog, click the Add icon . On two separate screens, define the Inbound Rewrite Rules, and then the Outbound Rewrite Rules:

• Search For – string to find. To facilitate searching, you can use placeholder variables, for example, to find the current application, enter ${SMP_APPID}.

• Replace With – replacement string. For example, you can convert an absolute URL to a relative URL by replacing <http://host> with an empty string.

• Match Case – whether the case of the search string must match exactly.

• Regular Expression – allow regular expressions in the strings.

To define another rewrite pair, click the Add icon , and define the properties listed above. If you define more than one, you can sort them to change the order. The system works through the definitions, from top to bottom, searching for a Search For string that matches the input string from the client. For example, assume you define two rewrite pairs, in this order:

For this example, the system receives the input string <https://host/SAP> from the client, which matches the Search For string in the first definition, so it replaces the input string with <https://host/X>. The system then looks at the next rewrite definition, compares <https://host/X> with the Search For string, finds a match, and replaces this string with <https://host/Y>; this is the output string.

If the definitions are in the reverse order, and the system receives the input string <https://host/SAP>, the output string would be <https://host/X>; moving top to bottom, the matching definition is the last one.

To test a Custom Rewrite URL configuration for either inbound or outbound rules:

1. Select the configuration, and click Test.
2. In the Test Rewrite Rules dialog, enter the Input string.
3. Click Rewrite. The replacement string appears under Output.

To edit or delete a configuration, select it, and click the appropriate icon.

---

Last update: January 14, 2023