Skip to Content

By on-boarding a couple of systems to the SAP Fiori Cloud Edition (FCE) using the HCP OData provisiong as a Gateway, we discovered a few obstacles at the installation and configuration process. This document should help you to avoid these traps and give you some hints in case of troubles.

Additional useful documentation

 

In addition to the product documenation you find configuration steps in the Fiori apps RDS

https://fioriapps-rds.dispatcher.hana.ondemand.com/ -> Fiori apps RDS -> Solution Scope -> Fiori Cloud Edition

 

Fiori Apps Reference Library & Maintenance Planner

 

Currently the software provisioning service by using the Fiori Apps Reference Library together with Maintenance Planner requires the configuration of an on-premise Gateway system. Also UI components will be installed. By using Fiori Cloud Edition togehter with HCP OData provisioning service you will not need this installation. Therefore use the standard Maintenance Planner for your installation Maintenance Planner | SAP Support Portal and install only the Fiori backend components.


Post installation tasks

 

After the installation of the Fiori backend components call transaction SU25 and run the postprocesses 2A, 2B, 2C – this may be necessary to update exisisting user roles.

/wp-content/uploads/2016/09/su25_1031115.png

 

 

  • For testing create a new user, e.g. FIORIUSER
  • Add the roles of the Fiori apps to this user – use transaction PFCG (not SU01)
  • if you already using SAP GUI for the functionality of the Fiori app – test your user first here and check if he has all the necessary roles and data configurations. You may have to add additional Authorization templates.


Registration of oData service is not possible in HCP OData Provisioning

 

If you can’t see any services by trying to register an oData service in HCP OData provisioning service, check the following:

  •   SAP Cloud Connector log – you may see a similar log entry:

          sap.core.connectivity.protocol.http.handlers.HttpProtocolOutboundHandler#tunnelclient-5-1#0xd2e3010e#Access denied to / for virtual host

This gives you an hint that something is wrong with your authorization.

  • Check in transaction SICF that sap/iwbep is activated
  • For accessing the IW_BEP component in HCP OData provisioning service the user needs the /IWBEP/RT_MGW_ADM authorization template. Check if your user has the appropriate authorization, If not: in transaction PFCG create a new role (e.g. Z_RT_MGW_ADM), add this authorization template and map the role to your user.
  • In the destination definition at the HCP oData provisioning service configuration check that your sap-client is set in the URL:

    /wp-content/uploads/2016/09/gaasdest1_1031393.png

 

  • When using principal propagation check in the SAP Cloud Connector that a trust to your OData provisoning service (gwaas) and IDP is established – you may have to click the synchronize button to display all services:

/wp-content/uploads/2016/09/scc_pp_1031129.png
Use basic authentication for the first setup

 

To simplify the on-boarding process it is helpful not to start with a full E2E security setup. Instead use a basic authentication setup for your development environment. So you can check first that your app is working and the backend user roles are set properly.For basic authentication you have to change the following setup steps:

  • Check in your backend (RZ10) that no icm/HTTP/redirect is set for the HTTP port
  • In SCC create a HTTP connection to your backend with no principial type
  • In the OData Provisioning setup create a destination with basic authentication. Use the credentials of your test user. Be sure that the oData service in OData Provisioning is registered by using this destination. When you later change the setup to prinicipal propagation you should delete and register the service again.

  
OData Provisioning – caching of service metadata


By default the OData provisioning service is caching the oData metadata. When you make changes in your oData service, you must refresh the metadata cache –> in the OData Provisioning menu select Metadata and clear the cache.

/wp-content/uploads/2016/09/gwaas_menue_1031130.png

/wp-content/uploads/2016/09/odata_metadata_1031131.png

Missing user roles


For some Fiori apps it is necessary to have additional roles for accessing all the data. You might get an data access error in your FCE app if the user don’t have the necessary roles/authorization objects. If you don’t know the appropriate roles, add the SAP_ALL authorization template to your user. In transaction ST01 start a trace for authorization check (set a filter for your user Id). Call the Fiori app with your user. In the trace log you should get a list of all authorization objects.  Add these objects to your user (e.g by creating a custom role in PFCG), remove the SAP_ALL and try again.

/wp-content/uploads/2016/09/system_trace_1031132.png

 

Errors in trust settings


By setting up the E2E trust with principal propagation you may face a couple of problems which could be related to errors in your security settings:

 

  • User is not able to logon to the Launchpad

possible error: wrong SAML2 assertion -> the defined role for your user in your IDP may not match the group & role settings for your HCP service: –>  use a browser tool (SAML tracer) for checking the assertion.

  • You are able to logon to the HCP Portal Launchpad, but when you call your Fiori app you get an authentication required message:AuthenticationError.png

 

This could be caused by the following errors:

    1. Wrong principal is propagated: User is not accepted in backend. Use a SAML tracer – enable SCC trace and set log level to debug. You may see a similar entry in the SCC log: #DEBUG#com.sap.scc.security#tunnelclient-5-1#0x26df8606#Generated X.509 certificate with subject CN=<wrong principal>  –> check your IDP settings
    2. Broken mutual SSL between SCC and ABAP: Analyze ICM trace on ABAP
    3. Broken trust SCC to ABAP: Analyse SCC log and SMICM trace on ABAP
To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Andrei Nicolae Plaiasu

    Hi,

    great blog and thinks for the info.

    Unfortunately the metadata cache on the HCP gateway is not refreshing even after I clear it. I went ahead and deactivated the caching but I get the same error from the backend – metadata on hub is outdated.

    Any ideas?

    Thanks,
    Andrei

    (0) 
    1. Wolfgang Scheer Post author

      Hi Andrei,

      if the refreshing seems not to work, do the following:

      • check if the metadata of your service on the oData Provisioning is the same as at your backend. (add /$metadata to your service URL) – if this is the case the problem is related to another caching problem – maybe metadata caching of the app.
      • otherwise delete the service from oData Provisioning and add it again, check the metadata, it should now be the same – otherwise check the destination if it is pointing to correct backend.

      Regards
      Wolfgang

      (1) 
  2. Jing Biscocho

    Hi Wolfgang,

    Thanks for this blog … very useful indeed. I, however, still have a lingering issue. Based on the SCC logs, it is generating the X.509 certificate properly. However, when I check the ICM trace file, it shows that the client certificate it is getting from SCC is the system certificate of SCC, not the short-living certificate.

    Any idea where I might have missed something?

    Cheers,
    Jing

    (0) 
      1. Jing Biscocho

         

        Hi Wolfgang,

        Thanks a lot for replying to my question. I eventually found the cause of the issue. I had to specify assertion based attributes.

         

        Cheers,

        Jing

        (0) 

Leave a Reply