Behavior Definition: CRUD, Fields and Features

Explanation

The behavior definition is the heart of RAP transactional logic. It declares whether the entity supports create, update and delete. It can define readonly fields, mandatory fields, numbering, actions, determinations, validations, locks and authorization. The behavior definition is like a contract between the RAP runtime and your business object. If an operation is not declared, the consumer cannot use it. This is one reason RAP is safer and cleaner than ad hoc CRUD code.

Code example

managed implementation in class zbp_i_purchase_req unique;strict ( 2 ); define behavior for ZI_PurchaseReq alias PurchaseReqpersistent table zpur_reqlock masterauthorization master ( instance ){ create; update; delete;  field ( readonly ) RequestId, CreatedBy, CreatedAt; field ( mandatory ) CompanyCode, RequestReason;  determination setDefaults on modify { create; } validation validateCompanyCode on save { create; update; }} * Behavior definition declares the transactional contract.* Fields can be readonly or mandatory.* Determinations and validations are attached to lifecycle events.

Real project scenario

A purchase request app allowed users to create and update requests, but request number and created-by fields were readonly. The behavior definition enforced these rules consistently in the OData service.

Common mistakes

- Forgetting mandatory fields. - Allowing update on fields that should be readonly. - Declaring delete when business process should not allow it. - Putting business rules only in UI instead of behavior.

Best practices

- Declare only required operations. - Use readonly for generated/system fields. - Use mandatory for required business fields. - Keep business rules in behavior, not only in UI.

Interview angle

A good answer should explain behavior definition as the transactional contract of a RAP entity.