We extended a standard CDS view (I_SALESQUOTEITEM) to include three custom fields from the VBAP extension table for our quote management analytics. The CDS extension compiles without errors and we’ve added the proper annotations for OData exposure:
The fields appear in the backend when we test the OData service in Gateway Client, but they don’t show up in the Fiori Elements analytical app that consumes this view. We’ve tried refreshing the OData metadata cache and clearing browser cache, but the Fiori UI still only displays standard fields. The custom fields are critical for our quarterly risk analysis reports. Has anyone successfully propagated CDS extensions through to Fiori Elements analytics apps? What are we missing in the metadata refresh or UI configuration?
Thanks for the quick response. I checked the manifest.json and it’s using dynamic annotations from the service. The analytical query was created before we added the extension though - could that be the issue? We’re running on 1809 which I know has some limitations with dynamic CDS extensions in analytical scenarios.
The standard cache clear isn’t enough - you need the runtime regeneration step which rebuilds the OData metadata from the CDS definitions.
3. Fiori Elements UI Update (Root Cause #3)
The analytical query definition is static on 1809. You have two options:
Option A (Recommended): Regenerate the existing query
Go to transaction RSRT
Find your analytical query (typically starts with 2C prefix)
Select “Regenerate” from the menu
This preserves your query name and existing app configuration
Option B: Create new query
Use transaction RSDS to create a new analytical query based on your extended CDS view
Update the Fiori app’s manifest.json to point to the new query name
This is cleaner but requires app reconfiguration
Additional Step for 1809: Update the Fiori app’s selection variant if your custom fields should be filterable. Edit the variant in transaction SFP and add the new fields to the selection screen definition.
Verification Steps:
Test OData service in /IWFND/GW_CLIENT - verify custom fields appear in metadata ($metadata endpoint)
Check analytical query in RSRT - verify extended fields are in the field catalog
Clear browser cache completely (Ctrl+Shift+Delete, all time)
Open Fiori app in incognito mode to avoid any local caching
After following these steps, your custom fields should appear in both the Fiori table view and be available for filtering and aggregation. The key issue on 1809 is that analytical queries don’t auto-refresh when underlying CDS views are extended - this was improved in later releases but requires manual intervention on your version.
The cache cleanup helped but fields still weren’t showing. Turns out it was the analytical query issue cds_expert_2k mentioned combined with missing UI annotations.
We had a similar problem last year and discovered that the SAP Gateway cache has three layers that need clearing: the model cache, the metadata cache, and the data cache. Use transaction /IWFND/CACHE_CLEANUP and select all three options. After that, restart the ICM using SMICM transaction. This forces a complete metadata refresh across the entire OData stack.
I’ve seen this exact behavior before. The OData metadata is probably cached at multiple layers. Did you regenerate the analytical query definition in the backend? Sometimes the Fiori app’s manifest.json also needs updating if it has hardcoded field references. Check if your app is using a static annotation file that might be overriding the extended metadata.
Adding to what cds_expert_2k mentioned - in our implementation we had to explicitly add UI annotations to the extension as well. The Fiori Elements framework generates the UI based on annotations, and if your custom fields lack @UI.lineItem or @UI.identification annotations, they won’t appear in the default view even if they’re in the OData metadata. Check your annotation file or add them directly to the CDS extension.