Fiori resource management apps fail to load after HANA System Replication failover

ERP SAP S/4HANA
, , , , , , , ,
1

We executed a planned failover using HANA System Replication last weekend and now our Fiori resource management apps are completely broken. Users get HTTP 500 errors when trying to access resource allocation screens, and some apps just show blank pages.

The failover itself completed successfully and the HANA database is running fine on the secondary node. All backend SAP systems appear healthy. However, the Fiori front-end server seems to have lost connectivity to the Gateway.

Checking the Gateway error logs, I’m seeing:


Error: ICF service /sap/opu/odata/sap/ZRESOURCE_SRV not found
Gateway: Alias mapping failed for system PROD_100
HTTP 500 - Internal Server Error

I suspect the OData service aliases are still pointing to the old primary system. Has anyone dealt with Fiori connectivity issues after HANA System Replication failover? What’s the proper procedure to re-register the front-end server and update the Gateway alias mappings?

system 2

Here’s the complete resolution procedure for Fiori connectivity after HANA System Replication failover:

1. Update RFC Destinations (Gateway System) Go to SM59 and update all RFC destinations pointing to your backend:

  • Change hostname from old primary to current active node
  • Better solution: Use virtual hostname that floats with HSR
  • Test connection with “Connection Test” button

2. Re-register Front-End Server On Gateway system, transaction /IWFND/GW_CLIENT:


Delete: Old FES registration (points to old hostname)
Create: New registration with current HANA node details
System Alias: PROD_100
Host: <new_primary_hostname>
Port: 44300

3. Update OData Service Aliases Transaction /IWFND/MAINT_SERVICE:

  • Select your resource management services (ZRESOURCE_SRV, etc.)
  • Click “SAP Gateway” → “Edit Service”
  • Update system alias mapping to point to correct backend
  • Regenerate service metadata

4. Verify ICF Services (Backend System) Transaction SICF on new primary:

  • Navigate to /sap/opu/odata/sap/
  • Ensure all OData services are active (green light)
  • Activate if needed: Right-click → Activate Service

5. Clear Gateway Cache Transaction /IWFND/CACHE_CLEANUP:

  • Select “All Caches”
  • Execute cleanup to remove stale alias mappings

6. Test End-to-End

  • Access Fiori launchpad
  • Open resource management apps
  • Verify data loads correctly

Prevention for Future Failovers: Implement virtual hostname configuration at infrastructure level. Your Gateway and Fiori configs should reference the virtual hostname, not physical node names. This makes the entire setup HSR-aware and eliminates manual updates during failover.

The root cause is that SAP Gateway caches the physical system topology and doesn’t automatically discover the new primary after HSR failover. The alias mappings and front-end server registrations must be explicitly updated to reflect the new active node.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this exact scenario. The Gateway alias configuration doesn’t automatically update after HSR failover. You need to manually update the RFC destinations in SPRO that point to your backend system. The aliases are cached and still reference the old hostname/IP of the primary node.

4

Check transaction /IWFND/MAINT_SERVICE on your Gateway system. The service catalog might need to be refreshed after the failover. I’d also verify that the front-end server can actually reach the new primary HANA node - sometimes firewall rules or load balancer configurations don’t get updated properly during failover scenarios. Run a connection test from SM59 to confirm basic connectivity first before diving into the OData layer.

jeffrey_arch 5

Confirmed this resolves the issue — updating SM59 RFC destinations to the virtual HSR hostname eliminated recurring Fiori app failures after every HANA System Replication failover in our S/4HANA 2021 landscape.

6

This is a common HSR gotcha. Your Fiori front-end server registration in the Gateway includes the HANA system hostname which changed during failover. You need to re-register the front-end server using transaction /IWFND/GW_CLIENT. Delete the old registration entry and create a new one pointing to the current active HANA node. Also make sure your virtual hostname setup is correct if you’re using one - that should prevent this issue in future failovers.

7

Thanks for the suggestions. I checked SM59 and the RFC connections are timing out. The destination still has the old primary hostname hardcoded. Should I just update the RFC destination to point to the new active node, or is there a better way to handle this with virtual hostnames?

8

Don’t hardcode the physical hostname in your RFC destinations - that’s asking for trouble. Set up a virtual hostname that floats between your primary and secondary HANA nodes. This way, the Gateway configuration stays constant regardless of which node is active. You’ll need to configure this at the OS/network level with your infrastructure team.

9

The HTTP 500 errors indicate the entire OData request chain is breaking down. I’d check the ICF services on the backend as well - sometimes they get deactivated during system changes. Go to SICF and verify /sap/opu/odata services are active on the new primary node.