ABAP RAP

CRUD Scenarios

Scope

This slide set focuses on the standard features of the managed scenario. The following topics are covered:

  • CRUD applications
  • Behavior definitions
  • Creating, editing and deleting child entities

CRUD application

Managed vs. Unmanaged

Managed

In the managed scenario the RAP framework takes care of the CRUD operations:

  • Create
  • Read
  • Update
  • Delete

Locking is handled automatically as well. On top of the generic CRUD behaviour you can add custom business logic (actions, determinations, validations).

Unmanaged

You must implement everything yourself. This is useful if you want to reuse existing application logic. Two local classes are involved in the implementation (handler & saver).

Unmanaged - Methods to implement

Interaction Phase

CLASS lhc_ZI_TASKS_UM DEFINITION 
								 INHERITING FROM cl_abap_behavior_handler.
	PRIVATE SECTION.
		METHODS get_instance_authorizations 
							 FOR INSTANCE AUTHORIZATION IMPORTING keys 
							 REQUEST requested_authorizations 
							 FOR zi_tasks_um RESULT result.

		METHODS create FOR MODIFY
			IMPORTING entities FOR CREATE zi_tasks_um.

		METHODS update FOR MODIFY
			IMPORTING entities FOR UPDATE zi_tasks_um.

		METHODS delete FOR MODIFY
			IMPORTING keys FOR DELETE zi_tasks_um.

		METHODS read FOR READ
			IMPORTING keys FOR READ zi_tasks_um RESULT result.

		METHODS lock FOR LOCK
			IMPORTING keys FOR LOCK zi_tasks_um.
ENDCLASS.

Save Sequence

CLASS lsc_ZI_TASKS_UM DEFINITION INHERITING FROM cl_abap_behavior_saver.
	PROTECTED SECTION.

		METHODS finalize REDEFINITION.

		METHODS check_before_save REDEFINITION.

		METHODS save REDEFINITION.

		METHODS cleanup REDEFINITION.

		METHODS cleanup_finalize REDEFINITION.

ENDCLASS.

Interaction phase and save sequence

Interaction phase

Changes are only stored in the transactional buffer:

  • Modify
  • Create
  • Delete
  • Actions

Save sequence

Consistent persistence of data changes involves:

  • Finalize
  • Checks
  • Save
  • Commit

SAP documentation

Integration: SAP LUW and RAP

  • RAP follows the classic SAP LUW concept but automates many steps:
    • Distributed control remains (SAP LUW), while RAP takes care of transaction logic.
    • Consistency: RAP validates and persists data according to LUW principles.
    • Flexibility: developers implement behaviour in the Behavior Implementation (validations, authorizations, etc.).

RAP Business Object (BO)

A Business Object (BO) models a coherent business entity and typically consists of one or more entities. Technically it comprises the following components:

Data model (CDS Views)

Mapping the BO data model to database tables.

Behaviour Definition (Behavior)

  • Numbering
  • Locking
  • Actions
  • Validations
    ...

Implementation - (ABAP classes)

Implementation of the behaviour that is not covered by the generic framework (for example in managed scenarios).

The BO does not have to contain UI properties.

Business Object

Transactional RAP applications are based on a Business Object (BO) that consists of:

  • The data structure (CDS Root View Entity) — the core defining the data layout.
  • The behaviour definition (Behavior) — defines the BO behaviour.

Service Definition and Service Binding are not part of the Business Object itself.

Entities

The data model for RAP apps is built on DB tables, wrapped and linked by CDS views.

Root entities

Root entities are standalone objects (customers, orders, materials) and often contain child entities.

Child entities

Child entities are part of a root entity, cannot exist on their own and often reference the root via a part of the key or a foreign key.
Examples:

  • Line items for orders
  • Addresses for customers

Business object with a single entity

In the simplest case a BO contains exactly one entity. The CDS view is created as a ROOT view and a behaviour definition is added.

The mapping must be completed so that BO fields map to DB table fields.

managed implementation in class zbp_i_jb3_projects unique;
strict;

define behavior for zi_jb3_projects //alias <alias_name>
persistent table ZBC_PROJECTS
lock master
authorization master ( instance )
//etag master <field_name>
{
	create;
	update;
	delete;
	mapping for zbc_projects
	{
		ProjectKey = project_key;
		Name = name;
		ProjectManager = project_manager;
		ChangedBy = changed_by;
		ChangedAt = changed_at;
		CreatedBy = created_by;
	}
}

Multiple entities in a BO

The BO structure is defined with CDS views. The data structure is determined by a Root View Entity.

  • COMPOSITION — association from root to child objects of the BO (cardinality required).
  • TO PARENT — reverse association from child to root (cardinality always 1..1).

There is exactly one Behavior Definition per root object. Child entities do not have their own behavior.

Keys in a BO

You can choose between a semantic key or a GUID/UUID.

Semantic Key

The semantic key must be provided by the user; collisions with existing DB entries are possible.

GUIDs

GUIDs are globally unique and work well for automatic numbering. They are unreadable for humans, however.

Behavior Behaviour Definition (Behavior)

The behavior defines:

  • Implementation type (managed or unmanaged)
  • Implementation class
  • Persistent DB tables
  • Draft behaviour
  • Transactional behaviour (locking, authorizations, numbering)
  • Actions, validations & determinations
  • Field properties
  • Field mapping

Field properties

Field properties are defined inside the behavior using the syntax:
field ( <property> [,<property2>] ) <field-list>;

List of field properties

  • numbering:managed — automatic UUID assignment
  • readonly — not input-ready
  • readonly:update — input allowed on create only, then locked
  • mandatory — UI shows a required indicator (framework does not necessarily validate)
  • mandatory:create — mandatory on create; enforced by the framework

Field mapping

Map BO fields to DB table fields:

	mapping for zbc_tasks
	{
		TaskKey = task_key;
		Summary = summary;
		Status  = status;
		Project = project;
	}

With corresponding equal names are mapped automatically:

	mapping for zbc_tasks corresponding
	{
		TaskKey = task_key;
	}

Locking

RAP provides multiple approaches to prevent concurrent modifications.

Pessimistic lock

Short-lived exclusive lock while the BO is changed on the server. Set before change and released afterwards. Avoids conflicts but is not suitable for Fiori apps.

Optimistic lock

No real lock: on write we check whether the version changed since editing started. This uses an ETag field (typical candidate: last changed timestamp).

Locks with Draft handling

With Draft handling the draft row (including timestamp and user) in the draft table acts as an exclusive lock for Fiori apps. The lock may expire after some time; optimistic locking can still prevent lost updates.

Numbering

  • Manual numbering by user input and validation at save.
  • Automatic numbering with UUIDs — no implementation required.
  • Custom numbering strategies:
    • EARLY NUMBERING — assign number early, before the UI shows the new instance.
    • LATE NUMBERING — assign number late, just before commit (useful for gapless sequences).

Automatic numbering

If UUIDs are used as primary keys, numbering can be fully automatic (managed).

The behaviour definition must include the numbering settings. Example header:

define behavior for <My_CDS_View>
early numbering
...
{
		field ( numbering : managed ) <FieldName>;
}