Transactional applications in ABAP Cloud provide a robust and scalable solution for managing business processes and data. The ABAP RESTful Application Programming Model (RAP) defines how transactional applications are built. The following graphic shows the big picture:
To build a transactional application, you define data models and implement business logic using a declarative approach. The data models as well as the behavior definition make up the ABAP RESTful Application Programming Model business object (RAP BO). The data model implemented with ABAP Core Data Services defines the structure of the data. The behavior definition is implemented with ABAP and the Entity Manipulation Language.
With RAP, the standard create, update, and delete operations must only be specified in the behavior definition to obtain a ready-to-run business object. In addition, the provisioning and handling of the transactional buffer is automatically done for you. The technical implementation aspects are taken over by the managed RAP BO provider. The interaction phase and the save sequence are implemented generically. For more information, see Business Object Implementation Types.
The application developer can then focus on business logic that is implemented using actions, validations, determinations, and user interaction. To define which consumers are allowed to read or change data of a business object, RAP offers an authorization concept to restrict access to the business object.
-
Actions
You can use actions to develop custom modify operations to set a specific field value, for examples. See Operations.
-
Validations
To define which consumers are allowed to read or change data of a business object. To check your data for consistency and against certain conditions based on business or process requirements, you can implement validations. A validation is implicitly invoked by the business object’s framework if a trigger condition of the validation is fulfilled. See Validations.
-
Determinations
To trigger modify operations based on trigger conditions, for example when another field is changed, you can implement determinations. A determination is implicitly invoked by the business object’s framework if the trigger condition of the determination is fulfilled. See Determinations.
You can define authorization checks for update operations like creates or custom operations like actions for a business object on global and instance level. For more information, see Authorization Control.
If your service is to be consumed by other applications, you can define a privileged mode to allow consumers to circumvent authorization checks. For this, the consumer must implement the respective checks in their authorization control implementation. For more information, see RAP – with privileged mode.
Concurrency control prevents concurrent and interfering database access of different users. This ensures that data can only be changed if data consistency is assured. In RAP, you can either implement optimistic or pessimistic concurrency control:
-
Optimistic concurrency control relies on the concept that every change on a data set is logged by a specified ETag field. Most often, the ETag field contains a timestamp, a hash value, or any other versioning that precisely identifies the version of the data set. Optimistic concurrency control is only relevant when consuming business objects via OData. SeeOptimistic Currency Control.
-
Pessimistic concurrency control is done by exclusively locking data sets. The data set that is being modified by one user cannot be changed by another user at the same time. Technically, locking is ensured by using enqueue locks and global lock table entries. See Pessimistic Concurrency Control (Locking).
UIs create an intuitive and user-friendly interface for users to interact with the business processes. In ABAP Cloud, SAP Fiori ensures a consistent user experience when developing UIs. SAP Fiori applications can be developed for OData services that are exposed as UI services. SAP Fiori applications, following the SAP Fiori design principles, can be built using a combination of SAPUI5 and SAP Fiori elements. For more information on SAP Fiori elements and SAPUI5, see Developing Apps with SAP Fiori Elements and SAPUI5.
While SAPUI5 is a development framework that allows you to build freestyle front-end applications, SAP Fiori elements is a framework that includes commonly used floor plan templates.
SAP Fiori elements applications are generated based on domain-specific annotations that define the layout, data binding, and behavior of a UI. You can define the overall layout for standard floor plans, define labels, implement value helps or define navigation on the UI to just name a few examples. The rendering of the UI is then handled by SAP Fiori elements, which interprets the annotations to create the final user interface.
Back-end features that are closely related to the UI like draft, feature control, and side effects:
-
Draft
Applications with draft capabilities let users save their changes in the system and resume their work later, even on a different device, or after an unplanned shutdown. We recommend that you use a draft for your UI use cases to improve the user experience. RAP business objects need to be draft-enabled. See Draft.
-
Feature Control
You can provide information on how data should be displayed for consumption in an SAP Fiori UI, for example, if fields are mandatory or read-only. See Feature Control.
-
Side Effects
You can make a SAP Fiori elements UI aware that data changes of defined fields require the recalculation of other data values, permissions, or messages on the UI in case of UI scenarios based on draft-enabled RAP business objects. See Side Effects.
For more information about UI development, see:
With RAP, you can implement asynchronous process integration using remote or local events. Events allow you to implement a publisher – subscriber pattern with different consumers. Reuse services offer general capabilities that are required by multiple services, applications, and business areas. You can choose from a variety of reuse services that are ready-to-run, ranging from applications jobs over logging, forms, and emails up to change documents or the workflow.
For more information, see Business Events for Process Integration.
RAP offers the possibility to develop semantically rich, upgrade-safe, and lifecycle-stable extensions for business objects. An original business object developed by an extensibility-enabler is extended with additional functionality to extend the functional scope of the original RAP business object. Using well-defined extension points enabled in the original business object, an extension provider can then extend the original data model and behavior in accordance with the business requirements or create their own business service based on an RAP business object interface.
|
Extensibility Use Case |
Extensibility Persona |
More Information |
|---|---|---|
|
Data Model Extension Build full-stack data model extensions by adding new fields and associations including corresponding behavior characteristics and authorization control. |
Extensibility-Enabler Adds annotations and extension include structures to the original RAP business object to enable data model extensions. |
|
|
Extension Provider Extends the original RAP business object with new fields or associations including field characteristics depending on the options defined by the extensibility-enabler. |
|
|
|
Behavior and Field-Related Behavior Extensions Build additional behavior like new validations, determinations, or actions including dynamic feature control and other field-related behavior. |
Extensibility-Enabler Enables data model extensibility and behavior extensibility on the original RAP business object. |
|
|
Extension Provider Extends the original RAP business object with new validations, determinations, or actions depending on the options defined by the extensibility-enabler. |
|
|
|
Node Extensibility Build additional business object nodes with own behavior and data model with node extensibility. |
Extensibility-Enabler Enables node extensibility on the original RAP business object. |
|
|
Extension Provider Extend the original business object with new nodes that have their own data model and behavior. |
For more information about how to develop node extension, see Node Extensions. |
You can use the CDS test double framework to implement unit tests for the data model of transactional Services. With the RAP business object test double framework, you can manage the dependencies in the RAP business object behavior implementation and develop unit tests for RAP business object behavior like actions or determinations.
For an example, see:
With the OData Client Proxy and the RAP business object TDF, you can implement integration tests to test use cases via EML and OData, where multiple functional units are involved. Reading or creating instances from outside, for example, makes use of the whole RAP application and involves dependent operations, such as determinations and validations. The Integration tests validate whether the interaction between the involved functional units works as expected.
For an example, see:
For more information about the OData Client Proxy, see OData Client Proxy-Consumption Types.