Implementing Dynamic Feature Control

Objectives

After completing this lesson, you will be able to:
  • Explain dynamic action, operation, and field control in RAP.
  • Implement dynamic feature control.

Operation Control and Field Control

Types of feature control

Every business object specifies which data a consumer can change and how. This is called Feature Control.

If the possibilities are hard coded in the behavior definition, we speak of Static Feature Control. In the case of Dynamic Feature Control, the decision is made at runtime by specific implementations in the local handler classes.

If the dynamic calculations have the same result for all instances of the same BO entity, this is called Global Dynamic Feature Control, if the result depends on the specific instance, we speak of Instance-based Dynamic Feature Control.

Two aspects of dynamic feature control in RAP, i.e. operational control and field control

Dynamic feature control in RAP covers the following aspects:

Operation Control
With operation control you enable or disable modifying operations. For example, you disable changes to flight travels that lie completely in the past. Modifying operations are standard operations create, update, and delete, but also non-standard operations like actions.
Field Control
With dynamic field control you set the properties of fields For example, you disable editing for the start date of a flight travel if this start date already lies in the past. Currently dynamic feature control allows you to switch two field properties: readonly/changeable and mandatory/optional.

Feature Control Definition

Global dynamic feature control

Global Dynamic Feature Control is enabled by adding ( features: global ) to the respective statement in the behavior definition body. The option is available for statements that define operations, that is, create, update, delete, and all variants of action.

Note

Global feature control is not supported for all fields.
Instance-based dynamic feature control

Instance-based Dynamic Feature Control is enabled by adding ( features: instance ) to the respective statement in the behavior definition body. The option is available for statements update, delete, action, and field.

Note

Instance feature control is not supported for the create operation, because there is no instance information available yet before you create a new instance. We see later that in composite BOs, instance feature control is supported for the creation of child entities (create-by-association).

Feature Handler Methods

Ways to create the feature handler method using quick fix

If the local handler class for an entity already exists when you add the first (features: global) or ( features: instance ) addition, you can use a quick fix to add one or both missing methods to the local handler class. Use the usual techniques to invoke the quick fixes.

Implementation the feature handler method

The logic of dynamic feature control is implemented in the local handler class for the respective entity.

The method for global feature control is defined with the FOR GLOBAL FEATURES addition, whereas the method, for instance, based feature control is defined with the FOR INSTANCE FEATURES addition.

Both methods have an exporting parameter named result which is used to return the feature control values to the framework, but the type of this parameter is different in the two methods. While it is just a structure in the method for global feature control, it is a table-like parameter in the method for instance-based feature control, including the primary key fields of the entity.

The keys parameter is only there in the case of instance-based feature control. It is table-like and contains the key values of the instances for which feature control values are requested.

Caution

In instance-based feature control, it is important that you add a row to result for each row of keys. If you fail to do so, it leads to a runtime error.

Both methods have an importing parameter requested_features which is a structure of boolean-like components that reflect which elements (standard operations, actions, fields) of the entity are requested for dynamic feature control by the consumer. You can improve the performance of the handler methods by evaluating this parameter and only executing the logic that is needed for the requested elements.

Although not visible in the method definition, both feature handler methods also have a reported response parameter. The failed response parameter is only there in the method for instance-based feature control.

The RESULT Parameter

The result parameter of the global feature control method

The result parameter of the global feature control method is a structure. It contains one component for each standard operation that is enabled for global feature control. If any actions are enabled for global feature control, the structure contains also the %action component, which is a structure with components named after the action(s).

The %create, %update, %delete components and the subcomponents of %action have the same type. Possible values are the components of thefc-o constant in the IF_ABAP_BEHV interface, where fc stands for feature control and o for operation.

The RESULT parameter of the instance-based feature control method

The RESULT parameter of the instance-based feature control method is an internal table. The first columns are the key fields of the entity, accessible directly or via the %tky field group.

Like in the RESULT parameter for global feature handler method, the %update, %delete, and %action columns only exist if the related operation is enabled for instance-based feature control. The allowed values are the same as in global feature control.

The %field column only exists if at least one field is enabled for feature control. The components of %field are named after the fields, which are enabled for feature control. Possible values are the components of thefc-f constant in the IF_ABAP_BEHV interface, where fc stands for feature control and f for field.

Feature Control Implementation

Example of global operation control

The implementation of global operation control, fills the various components of the result parameter with the values of if_abap_behv=>fc-o-disabledif_abap_behv=>fc-o-enabledto disable/enable the respective operation globally. The decision can be based on all kinds of information. Typical examples are values from the system configuration, also known as customizing.

Note

The value of if_abap_behv=>fc-o-enabledequals the initial value of the components. This means that if you do not explicitly assign a value, the operation is enabled by default.

An example of instance-based dynamic operation control

A typical implementation of dynamic operation control starts with retrieving the data of all affected entity instances. For each instance in turn, an entry with the same key is added to the result parameter.

Note

It is recommended to use field group %tky to copy the values of the key.

Based on the data, a decision is made about whether to allow certain operations for this instance or not.

To disable the operation, the related component of the result parameter is filled with the value of the constant if_abap_behv=>fc-o-disabled before adding the new entry.

Note

If you keep the initial value for the component, the operation stays enabled.

Example of dynamic field control

The implementation of dynamic field control fills the component of substructure %field that has the same name as the affected field. In the example, themy_field field is set to read-only if a certain condition is met for an entity instance. Other values for the field behavior are mandatory, unrestricted, and all. With unrestricted, the field is not read-only or mandatory, with all the field is read-only and mandatory at the same time.

Note

If you keep the initial value, the related field remains unrestricted.