Internal numbering can either be managed or unmanaged. In Managed Numbering, the unique key is drawn automatically during the CREATE request by the RAP managed runtime. This is opposed to Unmanaged Numbering, where the key values are provided in a dedicated handler method, implemented by the application developer.

 

Early vs Late

Unmanaged internal numbering can be either early or late. In Early Numbering, the final key value is available in the transactional buffer instantly after the MODIFY request for CREATE. This is opposed to Late Numbering, where the final number is only assigned just before the instance is saved on the database. Late numbering is used for scenarios that need gap-free numbers. As the final value is only set just before the SAVE, everything is checked before the number is assigned.

 

The following restrictions apply:

• Managed Numbering is only possible for key fields with ABAP type raw(16) (UUID) of BOs with implementation type managed.
• Optional External Numbering is only possible in combination with managed numbering
• Unmanaged Numbering is currently only possible in unmanaged BOs.

   

Example: External Numbering

 

In External Numbering, the consumer hands over the primary key values for the CREATE operation, just like any other values for non-key fields.

 

To ensure that the consumer can edit the primary key during create operations, but not during update operations, the primary key fields should be listed in the entity behavior body after the keyword readonly: update).

 

In addition, validations and pessimistic concurrency control should be used to avoid duplicate key errors during the save phase.

 

Managed Numbering

 

To enable managed internal numbering, you have to list the key field after the keyword field (numbering: managed) in the entity behavior body. The field in question is automatically assigned values on creation of a new entity instance. No implementation in the ABAP behavior pool is required.

 

The following restrictions apply:

• Only for primary key fields with ABAP type raw(16) (UUID).
• Only in managed implementation scenario

   

Determination Definition

Determinations in RAP

 

A determination is an optional part of the business object behavior that modifies instances of business objects based on trigger conditions. Determinations, like actions and validations, are defined in the behavior definition of the RAP BO and implemented in the behavior pool through a dedicated method of the local handler class.

 

A determination is implicitly invoked by the business objects framework if the trigger condition of the determination is fulfilled. Trigger conditions can be modify operations (create, update, delete) and modified fields. The trigger condition is evaluated at the trigger time, a predefined point during the BO runtime. Two types of determinations are distinguished, depending on the stage of the program flow the determination is executed: on modify determinations and on save determinations.

 

An invoked determination can compute data, modify entity instances according to the computation result and return messages to the consumer by passing them to the corresponding table in the REPORTED structure.

 

Example: Determination Definition

 

Determinations are defined in the entity behavior definition with the following statement: determination { }.

 

For determinations, the following trigger times are available:

on modify

The determination is executed immediately after data changes take place in the transactional buffer so that the result is available during the transaction.

 

on save

The determination is executed during the save sequence at the end of an transaction, when changes from the transactional buffer are persistent on the database.