Interaction Phase and Save Sequence

Interaction Phase and Save Sequence

 

The business object runtime has two parts:

• The first part is the interaction phase where a consumer calls business object operations to change data and read instances with or without the transactional changes. The business object keeps the changes in its transactional buffer, which represents the state.
• After all changes are performed, the data should be persisted. This is implemented within the save sequence.

 

In a managed implementation scenario for RAP business objects, the RAP provisioning framework defines and manages the transactional buffer. During interaction phase, it automatically fills the buffer with data from the persistent tables, handles write access to the buffer during standard operations (create, update, and delete), and takes care of writing the changed buffer content back to the persistent tables during the save sequence.

 

Unmanaged versus Managed

Comparison of Managed and Unmanaged Business Objects

 

In the unmanaged implementation type, the transactional buffer, the standard BO operations, and the database access must be implemented in the ABAP behavior pool. Unmanaged implementation is recommended for development scenarios in which business logic already exists and is intended to be reused. If your start your development from scratch, or if not much more than the persistent database tables exist, we recommend that you follow the managed approach.

 

Some additional restrictions apply for the unmanaged implementation scenario:

• Determinations and Validations are not available, unless the business object is draft enabled.
• Pessimistic concurrency control (locks) are not mandatory. If they are required, they have to be implemented manually.
• Optimistic concurrency control (ETag handling) requires the manual implementation of a READ method that provides the latest version of the entity instance.

 

Handler Class and Saver Class

The Behavior Pool of an Unmanaged RAP BO

 

If a behavior definition uses the unmanaged implementation type, it is mandatory to specify a behavior pool.

 

Like in the managed scenario, this behavior pool contains one local handler class (lhc) for each entity of the business object. The methods of the local handler classes are triggered during the interaction phase.

 

In addition to the local handler classes, the behavior pool of an unmanaged RAP BO contains a local saver class (lsc). There is not a saver class for each entity but only one saver class for the business object as a whole. The framework calls the methods of the local saver class during the save sequence.

 

The ABAP syntax check issues a warning if the saver class does not at least define a FOR SAVE method. Similarly, it issues warnings if a FOR READ method is missing in the local handler classes.

 

In the unmanaged scenario, it is optional to set the root entity as lock master. If the addition lock master is present, the corresponding handler class has to define and implement a FOR LOCK method.

 

Similarly, corresponding FOR MODIFY methods are required if the behavior definition enables the standard operations create, update, and delete.

Handler Class and Saver Class

 

If a RAP BO consumer, for example an OData service, sends a modify request to the RAP BO, the framework triggers the execution of the respective create, update, and delete methods in the handler classes.

 

The implementation of these methods validates the data changes and stores them in an application buffer. Usually, the validation logic and the application buffer are implemented somewhere outside the behavior pool, for example, in an already existing function module or global class.