Lesson 2 of 5
Feature and authorization control
10 min
Listen to this lesson
Not every operation should be available all the time, and not to everyone. A closed core return agreement must not be edited. Only the deposit team may change deposit rates. Only agreements in the US company code 1710 are maintained by Contoso's US team, while the Alternadores del Norte agreements for company code 1910 belong to the Monterrey team. RAP separates these concerns: feature control decides whether an operation is possible given the data; authorization control decides whether this user may do it.
Static and dynamic feature control
Some rules never change and are declared statically in the behavior definition: field ( readonly ) AgreementID; or field ( mandatory ) Customer;. Others depend on the instance or on global conditions and are declared as dynamic feature control, which you implement in the behavior pool.
| Variant | Declared as | Handler method | Contoso example |
|---|---|---|---|
| Instance feature control | features : instance on update, delete, actions, associations, Edit, or on fields | FOR INSTANCE FEATURES | Update, delete and the action closeAgreement are disabled when Status is CLOSED |
| Global feature control | features : global on create, update, delete, actions, associations | FOR GLOBAL FEATURES | Create is disabled during the month-end freeze window |
| Static field characteristics | field ( readonly ), field ( mandatory ), and combinations | None | AgreementID read-only; Customer mandatory |
Feature control variants. Static operations can only use global feature control.
The handler returns, per instance and operation, whether it is enabled, using constants such as if_abap_behv=>fc-o-enabled and fc-o-disabled in the %features component of the result. In a Fiori elements UI, a disabled operation appears greyed out. An EML consumer that tries a disabled operation gets an entry in failed. EML calls made IN LOCAL MODE from the BO's own implementation skip these checks, which is intended for internal logic and a trap if used carelessly.
Authorization control
Authorization control protects the BO from unauthorized changes. The root entity is declared as authorization master with ( global ), ( instance ) or both; currently only root entities can be authorization masters. Child entities are declared authorization dependent by _Agreement, so their modifications are checked against the master's update authorization. Individual operations can override with additions such as authorization : update or authorization : none.
Authorization methods govern modifying operations. Read access is restricted separately with CDS access control (Data Control Language), defined on the CDS views and passed on to projections. In managed BOs the framework calls the authorization methods for each operation. SAP's documentation describes special behavior in draft scenarios: for example, the authorization methods are not called for Activate, Discard and Prepare, so a rule that must block activation belongs in a validation.
Precheck
For create, update, delete and actions you can also enable a precheck. It runs before the change reaches the transactional buffer and can reject it early, for example when a new agreement would duplicate an existing one for the same customer and product. Use it for checks that must stop bad data entering the buffer at all; use validations for consistency checks at save.
- RequestA user or EML consumer asks to update agreement 100045
- Global authorizationDoes the user have the role to change agreements?
- Instance authorization and featuresMay this user change agreements in company code 1710, and is this one not closed?
- PrecheckWould the change create a duplicate or impossible state?
- Transactional bufferThe change is accepted; determinations and validations follow
What would you do?
The Monterrey team must not change US agreements in company code 1710, and the US team must not change Alternadores agreements in 1910. A developer implements this by disabling the Edit button in instance feature control based on the user's country. What should Kenji change?
- Feature control answers "can it happen?"; authorization answers "may you do it?".
- Instance and global feature control are implemented in FOR INSTANCE FEATURES and FOR GLOBAL FEATURES.
- Authorization master on the root, global and/or instance; children are authorization dependent.
- Read access uses CDS access control; prechecks stop bad requests before the buffer.
Check your understanding · not graded
Lesson check
1. A closed agreement must not be updated. Which mechanism fits best?
2. Which entities can currently be declared authorization master?
3. How is read access to agreements restricted in RAP?
4. What happens when an EML consumer calls an operation that feature control has disabled?