Project master data not updating WBS elements after custom CDS view extension in SAP S/4HANA 1909

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

After extending the standard CDS view for project master data (I_ProjectWBSElement) with custom fields, our Fiori app displays the new fields but updates don’t persist to the WBS elements. The OData service shows the fields in metadata but write operations fail silently.

We added three custom fields to store external reference data:

extend view I_ProjectWBSElement with Z_ProjectExtension {
  WBSElement.zz_ext_ref1,
  WBSElement.zz_ext_ref2,
  WBSElement.zz_priority
}

The CDS extension activates without errors in Eclipse. Fields appear in the Fiori app UI correctly. But when users update these fields and save, the data doesn’t write back to the database tables. Standard fields update fine. The OData metadata includes our extensions but something’s missing in the update path. Is there additional configuration needed for CDS view extension write-back, or do we need to implement a custom OData update operation?

2

The issue is you’re extending a consumption view, not the root CDS entity. For write operations, you need to extend the transactional interface view and its behavior definition. Find the RAP business object that I_ProjectWBSElement consumes from - that’s where your extension needs to happen. Then you’ll need to implement the save method in the behavior implementation class to handle your custom fields. Just extending the projection view won’t enable write-back.

3

Did you extend the corresponding behavior definition? CDS views need behavior definitions for write operations. Look for the behavior definition associated with I_ProjectWBSElement (probably something like I_ProjectWBSElementTP if it’s transactional). You need to extend that and map your custom fields to the update logic. Without behavior definition extension, the fields are read-only regardless of what the metadata shows.

4

CDS view extensions are read-only by default. You need to implement the write logic separately through either a BAPI wrapper or custom OData implementation. The metadata shows your fields because the view exposes them, but there’s no automatic write-back mechanism. Check if there’s a standard BAPI for WBS element updates that includes your custom fields.

5

Let me clarify the complete approach covering all three critical aspects.

For CDS view extension, your current approach is partially correct but incomplete. I_ProjectWBSElement is a consumption view. You need to extend at the interface level (C_ProjectWBSElementTP) and the root level (I_ProjectWBSElementTP). Create a second extension:

extend view I_ProjectWBSElementTP with Z_ProjectTP_Ext {
  @EndUserText.label: 'External Ref 1'
  WBSElement.zz_ext_ref1
}

For OData metadata refresh, this is crucial but often missed. After extending CDS views and behavior definitions, the OData service metadata is cached. You must clear the cache and regenerate. In transaction /IWFND/MAINT_SERVICE, find your project service, click ‘SAP Gateway Client’, and execute an $metadata request. Then go to transaction /IWFND/GW_CLIENT and clear the model cache. Finally, in your Fiori launchpad designer, republish the app catalog. Without this sequence, the OData layer won’t recognize write capabilities even if backend is configured correctly.

For Fiori app republish, after metadata refresh, you need to update the app descriptor. Open your Fiori project in Web IDE or Business Application Studio. In manifest.json, verify that the model configuration includes the extended fields in the entity type definition. Then increment the app version and redeploy. Clear browser cache on client side - this is often forgotten and causes stale metadata issues.

Now for the write-back implementation: extend the behavior definition C_ProjectWBSElementTP:


extend behavior definition C_ProjectWBSElementTP {
  field ( readonly:update ) zz_ext_ref1;
  field ( readonly:update ) zz_ext_ref2;
}

Create behavior implementation class ZCL_BP_PROJECTWBS_EXT implementing interface IF_ABAP_BEHAVIOR_HANDLER. Implement method MODIFY to handle the custom field updates. Inside modify method, read the changed fields from the modify structure and update the database table using UPDATE statement or through standard BAPI BAPI_BUS2054_CHANGE_MULTI.

Alternatively, if your S/4HANA version supports it, use the embedded extensibility approach: transaction AET_EXT_UI to define the fields at business context level. This auto-generates all required CDS extensions, behavior modifications, and OData bindings. Much cleaner than manual coding.

After implementation, test the complete flow: update a field in Fiori app, check browser network tab to verify the PATCH request includes your fields, then query the database table directly to confirm persistence. If PATCH request doesn’t include the fields, the issue is in Fiori app binding. If PATCH succeeds but data doesn’t persist, the issue is in behavior implementation.

6

I found the behavior definition C_ProjectWBSElementTP. Do I need to create an extension for this as well? And if so, what specific methods need implementation? We’re new to RAP development and most documentation focuses on creating new business objects, not extending existing ones.

7

Yes, behavior definition extension is required. But there’s a simpler approach if your fields are just storing reference data. Instead of full RAP extension, use the field extensibility framework with key user tools. Navigate to Custom Fields app in Fiori launchpad, add your fields to the WBS element business context, then publish. This automatically handles both read and write operations without coding.