Preface – This post is part of the SAP ABAP RAP series.

Introduction

In this section, we will explain the concept of unmanaged implementation and the development tasks required for enabling transactional processing in business objects integrating existing business logic.

In an unmanaged implementation, it is required to implement all the business operations (Create, Update, Delete) in specified behavior definition before implementing it manually. In the managed scenario, on the other hand, the behavior definition is itself capable to obtain a ready-to run business objects.  We do not need to explicitly implement the CUD operations.

Architectural Overview

The underlying scenario reuses the existing business logic which manages business data.

Architectural Overview: Integration of Existing Application Logic

Development Process Overview

The development of RAP based business services by integrating the transactional behavior of existing business objects requires to perform following steps:

1. Defining CDS Data Model and Business Object Structure

The structure of a business object consists of a tree of entities where each entity is linked using associations. The root entity represents the top node of a business object and hence it is a very important part of the business object structure. The root entity is indicated in the source code of the CDS data definition using the keyword ROOT.

2. Defining and implementing transactional behavior of the business object

The operations provided by the business object is defined in the Behavior Definition.  It contains all the entities of root and their supported business operations like Create, Update, Delete, Actions with dedicated input and output.

The class pool referring to behavior definition contains the implementation of all the operations. The implementation is roughly divided into two phases: Interaction and save phase.

3. Exposing relevant application artifacts for OData service enablement

The behavior relevant to specific UI services is projected in Projection Behavior Definition. The relevant artifacts must be exposed to OData.  The projection is implemented into two artifacts: service definition and service binding.

Service definition exposes the relevant data model and behavior and service binding implements specific protocol and service to be offered to the customer.

4. Testing OData/UI services

It provides the option to PUBLISH the service. Once you publish it, it can be consumed by the OData client.  To test the application within the ABAP development environment you can use the feature PREVIEW provided by the service binding editor.