Depending on the Access type of a SAP Cloud Platform Portal Site there are several options how to configure classic UI technologies such as Web Dynpro ABAP and SAP GUI for HTML. With this blog, I want to illustrate the configuration options for classic UIs in Internal Access Point(IAP) and External Access Point(EAP) scenarios. For a detailed description of the configuration steps for classic UIs in an External Access Point(EAP) please read Murali Shanmughams excellent summary Launch Classic UIs from Cloud Portal.
Internal Access Point (IAP)
When using a portal site as an Internal Access Point the frontend code of a portal site, meaning its UI5 resources and the configuration, are hosted in the SAP Cloud Platform. The actual business data can only be accessed while the client is in the same network zone as the backends. To fulfill the Same-Origin policy, frontend and data requests are merged via a Web Dispatcher.
IAP is enabled in the system settings of a site by setting the Access Type to internal.
Classic UIs in an IAP site require that the associated destination URL must contain an internal backend or WebDispatcher.
- The destination contains the host URL of the WDA/BSP/GUI, either the backend directly or a Web Dispatcher. The parameter Usage: Backend is used to make the destination available in the Portal Service.
- IMPORTANT: The URL must contain the internal URL of the backend or Web Dispatcher. The URL is read during runtime to build the full application URL, no routing through the SAP Cloud Platform Connectivity Service occurs.
The tile configuration contains the destination name in the System Alias field and the remaining part of the classic UI URL in the field SAP Business Client URI
- These two fields, together with a few extra parameters, are then concatenated into the iFrame URL which is used during runtime to load the classic UI
Classic UI URL = <internal URL from Destination> + <Business Client URI from Tile> + FLP Parameters
External Access Point (EAP)
For an EAP, the options for working with classic UIs become more varied:
Basically, we now have the choice whether we’d like to access the classic UIs from the internet or not. Let’s go through them one by one:
“Yes, and show in launchpad”
In this scenario, the classic UIs can be accessed from anywhere, provided our users can log in and principal propagation to the relevant backends is set up. All connections to the on-premise systems are tunneled via the Cloud Connector and made available as a Destination in the Connectivity Service.
The destination in my example is actually the same as in the IAP above, since the internal and virtual host name match. To use the Connectivity Service the Proxy Type is set to OnPremise.
Note: If you want to use virtual host names in the destination, make sure they at least follow the fully qualified domain name convention, as the backend will throw an error without it.
virtualhost:80 –> Throws HTTP 500
virtualhost.sap.com:80 –> Allowed
In general, I would recommend that the virtual and internal host names match.
Classic UI URL = <Virtual Host in Destination> + <SAP Business Client URI from Tile> + FLP Parameters
Notice that the iframe src URL is now in the form of SCP-Destination-ID.dispatcher.hana.ondemand.com/<BC URI>
“No, but show in launchpad”
With this option, classic UI tiles are not routed through the Connectivity Service and can therefore only be accessed while the client is within the intranet. The configuration of the tile and destination are therefore the same as when configuring classic UIs in an Internal Access Point. Be aware that this only affects the classic UIs, UI5 Apps and their OData services are still fully available from the Internet.
The classic UIs are still shown even though users cannot open them from outside the intranet. I’d recommend using the tile subtitle to inform users that a tile is only available from the internet.
“No, do not show in launchpad”
Finally, there is the option of filtering out classic UI tiles when the client is not in the intranet. The tile configuration is still the same as with an IAP, meaning the backend destination contains the internal URL of the backend.
How does a portal site know whether it’s being called from the Intranet or internet? During the initial load of the site, it issues a ping to a single backend service via the doBEPing() method. If that ping returns a HTTP Status of either 200, 201, 304, 401 or 403 the classic UI tiles are shown, otherwise they are hidden.
By adding the parameter pingflag = 1 to a destination it is then pinged during site startup. In my case, I used the existing backend destination and added the parameters pingflag = 1 and pingTimeOut = 1234.
This will call the http://<backend>/sap/bc/ping service. If you want to call a different service, you can specify an additional pingPathName parameter. See the official documentation under Working with Backend Apps –> Set up an External Access Point Landscape for more details.
IMPORTANT: In order for the backend ping to work, the called service needs to return the header
[Access-Control-Allow-Origin: <Cloud Portal Host Name>]
See How to enable CORS in SAP Netweaver Platform in the Cross-Origin Resource Sharing (CORS) for SAP ICM wiki, for a description of how to set the Access Control headers.