RAP Value Help Additional Binding Not Updating Read Only Fields

[Gayathri_Vedagiri]

Hi Experts,

I am working on a RAP application where I have a value help based on a Custom Entity. The value-help data comes from an external on-premise backend system through OData.

When the user selects a value from the value help, I use additionalBinding with usage: #RESULT to populate related fields in my RAP entity.

For example:

@Consumption.valueHelpDefinition: [{
entity: {
name: 'ZMY_I_VALUEHELP',
element: 'DocumentNumber'
},
additionalBinding: [
{
localElement: 'RelatedField1',
element: 'RelatedField1',
usage: #RESULT
},
{
localElement: 'RelatedField2',
element: 'RelatedField2',
usage: #RESULT
},
{
localElement: 'RelatedField3',
element: 'RelatedField3',
usage: #RESULT
}
]
}]
DocumentNumber;

My requirement is:

1. The user selects the Document Number from the value help.
2. The related fields are populated using additionalBinding with usage: #RESULT.
3. The related values should be persisted in the RAP database.
4. The related fields should be display-only and should not be editable by the user.

The current behavior is:

When the related fields are editable, the values from additionalBinding are populated and persisted successfully.

However, when I define the related fields as readonly in the RAP behavior definition, the values are no longer updated or persisted.

For example:

field ( readonly ) RelatedField1,
RelatedField2,
RelatedField3;

I would like to make these fields non-editable in the UI while still allowing additionalBinding with usage: #RESULT to populate and persist their values.

What is the recommended approach in RAP/Fiori Elements for this scenario?

Can I make the fields UI read-only without defining them as readonly in the RAP behavior?

Any guidance or example would be greatly appreciated.

Thanks in advance!

[sandeep_rs]

Interesting issue! 🙂 I am not sure if this works,, but one idea might be to use Core.Computed instead of making it read-only - maybe then the update of the field "programmatically" is allowed but the question is if the backend ignores this due to the Core.Computed annotation (not sure of this part). Fiori elements documentation of Core.Computed can be seen at https://ui5.sap.com/#/topic/f49a0f7eaafe444daf4cd62d48120ad0.

Best Regards,

   Sandeep

[ThomasM]

Just Something to try Out maybe use features instance for These read only fields then maybe Update works AS the are dynamically read only even If you Set them Always read only in your get_instance_features Implementation 

Another was would bei to use a determination in backend and Side effects to refresh the dependent fields

[SachinArtani]

I agree with Thomas. @Gayathri_Vedagiri you should try to implement the feature control dynamically for those fields.

[SAPdeadrat]

Yes it won't work for fields defined as non-editable in the RAP BO - BDEF file.

[Gayathri_Vedagiri · Accepted solution]

Thank you all for your suggestions.

I found the solution. I kept the related fields updateable in the RAP Behavior Definition and made them read-only at the Fiori Elements UI level using Common.FieldControl.

I used the following annotation:

<Annotations Target="SAP__self/MyEntity/RelatedField1">
    <Annotation Term="Common.FieldControl">
        <If>
            <Eq>
                <Path>ConditionField</Path>
                <String>VALUE1</String>
            </Eq>
            <EnumMember>Common.FieldControlType/ReadOnly</EnumMember>
            <If>
                <Eq>
                    <Path>ConditionField</Path>
                    <String>VALUE2</String>
                </Eq>
                <EnumMember>Common.FieldControlType/Mandatory</EnumMember>
                <EnumMember>Common.FieldControlType/ReadOnly</EnumMember>
            </If>
        </If>
    </Annotation>
</Annotations>

I applied the same Common.FieldControl approach to the other related fields.

With this approach, the fields are not defined as readonly in the RAP Behavior Definition, so additionalBinding with usage: #RESULT works correctly and the values are persisted, while the fields remain non-editable in the Fiori Elements UI.

Thanks again for your suggestions!