Exploring Behavior Implementation Options

Objectives

After completing this lesson, you will be able to:

Describe the data flow in the Business Object Runtime.
Describe the behavior implementation options.

Interaction Phase and Save Sequence

The business object runtime showing the interaction phase and the save sequence

The business object runtime distinguishes the following two phases:

Interaction Phase: In the interaction phase, a consumer calls business object operations to change data and to read instances with or without the transactional changes. Typical operations during the interaction phase are the modifying standard operations (Create, Update, Delete), the Read operation, and the non standard operations, for example actions. During the interaction phase, the business object keeps the changes in its transactional buffer, which represents the current state of the business data.
Save Sequence: At the end of the interaction phase, when all changes are performed, the data in the transactional buffer need to be finalized, checked and written to the database. This takes place in the save sequence. The save sequence is usually triggered by a commit entities request.

Handler Classes and Saver Class

In general, the behavior implementation of a RAP business object consists of code that is executed during the interaction phase and of code that is executed during the save sequence. To increase readability and to ensure a clear separation of concern, the code in the behavior pool is placed in different local classes. The local handler classes contain the code that is executed during the interaction phase, the local saver class (naming prefix lsc_) contains the code that is executed during the save sequence.

In a composite business objects, that is, in a business object that consists or more than one entity, there can be several handler classes, one handler class for each entity. By default, the name of the local handler class begins with a lhc_ prefix, followed by the name of the entity. If the behavior definition defines an entity alias name, this alias name is used.

The saver class always belongs to the business object as a whole. This means, there is always just one saver class, no matter how many entities the business object consists of. It is also reflected in the default name. The default name of the local saver class begins with a lsc_ prefix, followed by the name of the business object.

Note

The name of a business object is identical to the global name of its root entity. The alias name of the root entity does not apply for the business object name.

Implementation Options

The process of managed implementation with managed save

Up to now, we implemented a managed business object with a managed save. In this implementation scenario, the business object runtime provides an application buffer and takes care of the entire save sequence, including the write access to the database tables specified in the behavior definition. It also handles the modifying standard operations Create, Update, Delete, and the non modifying standard operation Read. Only the non standard operations like actions are implemented in the local handler class of the related business object entity.

Note

A prerequisite for this scenario is a one-to-one relation between BO entities and database tables, that is, the data of one BO entity is stored in exactly one persistent table.

In the unmanaged implementation scenario, the business object runtime relays most of the external requests to the behavior implementation. In this scenario, the behavior implementation provides the logic for all data operations, including the standard operations Create, Read, Update, Delete (CRUD). It is also responsible for storing the current state of the business object instances in an application buffer. And to write the content of the application buffer to the database when the save sequence is triggered.

This implementation type is best suited for integrating existing application logic that already works with an application buffer. Therefore, the behavior implementation often serves as a link between the BO runtime and the existing logic around the application buffer.

The process of managed implementation with unmanaged save

In the managed implementation scenario with unmanaged save, the business object runtime provides the application buffer and handles the standard operations like in all managed scenarios. It also processes most of the save sequence logic - except for the actual write access to the database. In this scenario, the business object runtime forwards the modified content of the application buffer to the save_modified method of the saver class, from where it is then saved on the database.

This implementation type is best suited for integrating existing code that does not use an application buffer and therefore does not distinguish between an interaction phase and the write access to the database.

Note

The managed implementation scenario with unmanaged save is also helpful when there is no one-to-one relation between database tables and BO entities.

The process of managed implementation with additional save

The managed implementation scenario with additional save is similar to the scenario with unmanaged save. The main difference is that the logic in the save_modified method is executed in addition to the managed write access and not instead of it.

Note

We see later that the managed implementation scenario with additional save is particularly helpful when extending an existing managed business object.

Implementation Options - Summary

	Managed			Unmanaged
	with managed save	with unmanaged save	with additional save
Write Access to Database	BO Runtime	Implementation	BO Runtime and Implementation	Implementation
Application Buffer	BO Runtime
Standard Operations	BO Runtime
Pessimistic Locks	BO Runtime (implementation optional)
Non-Standard Operations	Implementation
Determination Validations	Implementation			Implementation (only with draft)
Daft Handling	BO Runtime

The table summarizes the different behavior implementation options. Note that besides the differences we discussed, the following aspects are common ground for all four scenarios:

Non-standard operations like actions are implemented in the local handler classes.
Determinations and validations are implemented in the local handler classes.
Note
In the unmanaged implementation type, validations and determinations are only supported if the business object is draft enabled.
Draft-handling is always done by the business object runtime. This includes the implementation of the draft actions, the access to the draft tables, and the optimistic concurrency control for draft instances (total ETag handling).

How to Define an Unmanaged Business Object

Define a business object for booking class data. Choose the unmanaged implementation type and use a quick fix to generate the behavior pool with the local handler class for the root entity and the local saver class for the business object.

Steps

Create a copy of CDS view entity /LRN/437_R_Class. Place it in your package (ZS4D437_00) and name it Z00_R_Class.
1. If not done already, add package /LRN/S4D437_DEMO to the list of favorite packages.
2. Expand /LRN/S4D437_DEMO→/LRN/S4D437D_UNMANAGED→Core Data Services→Data Definitions.
3. Right-click /LRN/437_R_CLASS and choose Duplicate.
4. Enter ZS4D437_00 as Package and Z00_R_Class as Name.
5. Choose Next.
6. Confirm the transport request and choose Finish.
7. Analyze the data definition. Highlight the definition of the AllElements view element which concatenates all view elements except for the key field. Explain that this concatenated field will be used as an etag field because there is no time stamp field in the existing data model.
Create a behavior definition for the CDS view entity Z00_R_Class and choose the unmanaged implementation type.
1. In the Project Exporter, right-click the new CDS Data definition Z00_R_CLASS and choose New Behavior Definition.
2. Open the value selection for Implementation Type and choose Unmanaged.
3. Choose Finish.
Adjust the generated behavior definition. Define an alias for the root entity (Class). Specify the key field ClassID as readonly : update. Specify the AllElements element as an etag field.
1. Edit the behavior definition. Remove the // characters before alias and replace the <alias_name> placeholder with Class.
2. Before the closing curly bracket, insert the following code:
  Code Snippet
```
123

  field ( readonly : update ) ClassID;
```
3. Remove the // characters before etag and replace the <field_name> placeholder with AllElements.
Activate the behavior definition.
1. Press Ctrl + F3.
Use a quick fix to generate the behavior implementation class (ZBP_00_R_CLASS) and analyze the definitions of the generated local classes.
1. Choose the warning icon with a light bulb left from the first code row to invoke the quick fix.
2. Choose Create behavior implementation classzbp_00_r_class.
3. Confirm the values for Package and Description and choose Finish.
4. Analyze the code on the Local Types tab of the generated ABAP class. Highlight that there are two local classes: A handler class for the root entity (lhc_class) and a saver class for the business object as a whole (lsc_z00_r_class). Explain that the handler class uses the entity alias, but that the saver class uses the global name because there is no alias for the business object name.
5. Analyze the definition of the handler class (lhc_class). Explain that in the unmanaged implementation scenario, the standard operations (create, update, delete, read), and the lock operation have to be implemented in the handler class.
6. Analyze the definition of the saver class (lsc_z00_r_class). Explain that the write access to the database during the save phase has to be implemented in the saver class.

Next lesson