Community
Technology Blog Posts by SAP
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

Field Control for Developer Extensibility Custom Fields

georg_wilhelm
Product and Topic Expert
Product and Topic Expert
‎2024 Nov 29 10:50 AM
7,261

Field Control for Developer Extensibility Custom Fields

Do you want to influence the field properties of your developer extensibility custom fields in SAP standard UIs? Do you want to configure them as mandatory or read-only or invisible, even dynamically, based on specific business data? 

Please note that there is another blog post that gives an introduction into the topic of field control for custom fields. It also guides you how to find out which detail blog you should look at in your specific scenario.
The reason we have several specific blogs is that what you must do to implement field control for custom field differs significantly for key user custom fields and developer extensibility custom fields.
When you already know that in your case, it’s about developer extensibility custom fields, then this blog is just for you.

This blog post covers the following topics for developer extensibility custom fields:

  • How you can find out whether the respective application supports developer extensibility custom fields
  • whether field control is supported in this case,
  • and if so, how to set your custom fields mandatory or read-only in a static or dynamic way

Please note that this blog doesn't only address SAP S/4HANA Cloud Public Edition, but also SAP S/4HANA Cloud Private Edition and SAP S/4HANA On-Premise.

Developer extensibility allows you to add custom fields to Fiori applications which are based on the RAP programming model. You can find detailed information in the documentation for the ABAP RESTful Application Programming Model: https://help.sap.com/docs/abap-cloud/abap-rap/develop-data-model-extensions.

Field control for developer extensibility custom fields is natively built into the ABAP RESTful Application Programming Model. As field control is part of the behavior of a RAP business object, it needs to be added to the Behavior Definition (BDEF). Therefore, the BDEF needs to be enabled and released for Extend (C0 Contract) by SAP Standard Development.

georg_wilhelm_0-1732630119995.png

See also https://help.sap.com/docs/abap-cloud/abap-rap/develop-behavior-extensions.

If these prerequisites are met, you can define access restrictions for fields in a static way so that these restrictions are valid for each instance. The following field properties for static field control are possible:

  • Read-Only (always or only via update)
  • Mandatory

If the field control should be specific for a certain Fiori application or OData service, this can be done with an extension on projection level. This is possible for the field characteristics readonly and readonly:update.

All these characteristics are also possible if the behavior of the field should be related to the business object and be active for all projections on this business object. In this case, the base behavior definition needs to be extended. The mandatory behavior is also available here. It can’t be defined specifically per projection.

Using developer extensibility, it’s also possible to define and implement dynamic field control based on certain conditions. You can define a field as

  • Read-only
  • Mandatory
  • Without restrictions

Dynamic field control needs to be added to the base behavior definition. The reason is that it requires an implementation which can only be added on the base layer in BDEF extensions using a released RAP BO interface.

If you want to learn more about feature control in RAP, have look here.

Example – Fiori App “Manage Sales Orders – Version 2” (Fiori App ID F3893)

Let’s start with an example to explain all options and necessary steps.

We have extended the RAP business object “SalesOrder” on header and item level with custom fields using the extension field wizard. The fields have also been added to the CDS projection views which are used in the Fiori app Manage Sales Orders – Version 2 (Fiori App ID F3893).

georg_wilhelm_1-1732630120002.png

It’s important that we also add the custom fields to the data model of the released RAP BO interface for the SalesOrder, because we want to use the fields in our implementation for the field control of the RAP business object.

This means that the fields need to be added to the CDS views I_SalesOrderTP (Header) or I_SalesOrderItemTP (Item) respectively.

georg_wilhelm_2-1732630120007.png

Next, we want to define the following field control for these fields:

Entity

Field

Field Control

Header


 

ZZDiscountPercentageSDH

Static Read-Only on Projection

 

ZZPostponeDeliverySDH

-
 

ZZDeliveryUpdateMailAddressSDH

Dynamic

Item

ZZClassificationSDI

Static Mandatory

 

ZZPrefQuantityPerDeliverySDI

Dynamic

1. Static Read-Only on Projection

To define a field as read-only for a certain projection, we need to create a behavior definition extension for this projection. Right-click on the behavior definition in the Project Explorer view in ABAP development tools for Eclipse and choose to create a new behavior definition extension. Set the correct package and name for the extension and click Finish.

Define the respective custom field as read-only in the behavior extension of the extended entity.

The BDEF syntax is field (readonly).

georg_wilhelm_3-1732630120008.png

If you want to set the field only to read-only during update operations, you could also use the syntax field (readonly:update)

2. Static Mandatory

The field characteristic “Mandatory“ can only be defined on the level of the business object. Hence, a BDEF extension for the business object R_SalesOrderTP needs to be created. Here, you also need to specify the released RAP BO interface which should be used to access the released part of the RAP business object in the BDEF extension and its implementation.

georg_wilhelm_4-1732630120011.png

Next, define the field as mandatory.

georg_wilhelm_5-1732630120020.png

A mandatory field also requires a validation which checks the mandatory field. See below for more information on how to implement a mandatory validation.

3. Dynamic Field Control

For dynamic field control, we should also extend the behavior of the RAP business object together with the RAP BO interface, as we need to provide an implementation for it, too.

georg_wilhelm_6-1732630120033.png

The implementation is done in the respective behavior pool. The method get_instance_features for each relevant entity is generated into this class. Here, we need to add the logic for our field control. On the item, we set the field ZZPrefQuantityPerDeliverySDI to read-only once the overall delivery status is completed, since otherwise, it's editable.

On the header, we set the field ZZDeliveryUpdateMailAddressSDH to mandatory if the delivery status is not yet completed and the custom field ZZPostponeDeliverySDH is set to true. The field is read-only if the delivery status is completed, since otherwise, it's editable.

georg_wilhelm_7-1732630120045.png

Mandatory Validation

Now, we have defined fields as mandatory, both static and dynamic. However, the definition of the behavior doesn't imply automatic mandatory validations. You should implement these too to make your custom field entirely mandatory.

How to implement such a validation is specific to the application which is extended. RAP Validation extensibility is not available for RAP-unmanaged applications like the sales order. However, these applications sometimes offer BAdIs which are called during the unmanaged implementation of the respective application. For our sales order example, the relevant BAdI is located in the enhancement spot ES_SD_SLS_EXTEND. It's the BAdI SD_SLS_CHECK_BEFORE_SAVE which is called during the save sequence of the sales order.

The implementation could look like this:

georg_wilhelm_8-1732630120053.png

With that, we have defined different field control characteristics for our custom fields using developer extensibility.

The result with multiple custom fields, their field control, and before save validation looks like this:

georg_wilhelm_9-1732630120067.png

Now, you are done! Congratulations!
With this you are now equipped to

  • find out whether the Fiori app based on RAP at hand supports field control for custom fields and
  • if so, you know what to do to implement the field control logic.

Please note that this blog has been elaborated by a team of experts and I want to
thank Yasmina van Rooij(YasminavanRooij), Christian Eckenweber(CE6), Karsten Schaser(Karsten_Schaser),  and Daniel Wachs(DanielWachs) for their extremely helpful contributions.

Feedback, Comments, or Questions:

You’re cordially invited to provide them in the comments section below. Please follow our profiles to get updates when we publish more posts on these topics.
Feel invited to post and answer questions here (https://answers.sap.com/tags/270c4f37-c335-46e1-bfad-a256637d5e26) and read other posts on the topic (https://blogs.sap.com/tags/270c4f37-c335-46e1-bfad-a256637d5e26/).

Other related blog posts:

  1. Custom Fields in S/4HANA: How to control field properties like mandatory, read-only, and visibility
  2. Key User Custom Fields in SAP S/4HANA SAP GUI UIs: How to control field properties (mandatory,...)
  3. Key User Custom Fields in Fiori UIs based on SEGW OData Services: How to control field properties
  4. Key User Custom Fields in Fiori UIs based on OData Services exposed with Service Binding
  5. Custom fields in S/4HANA: Key User versus Developer Extensibility
  6. SAP Screen Personas: How to position key user custom fields exactly where you want them to be

 

 

 

 

7 Comments