This is a test message to test the length of the message box.
Login
ABAP RAP Simple Object
Created by Software-Heroes

RAP - Simple Object

813

In this article we build a simple business object and show you how the framework works.

We create a simple object with all components and show you how to get a simple UI with it. We will introduce most of the components, but also omit some parts, such as UI annotations, which we will explain in more detail in later articles.

 

Data model

For our data model we use the components from the Core Data Service blogs and use the tables as a basis for this series. Via the link you will find the data model explained in detail again, here is a list of the tables and associated data:

 

Today's simple application therefore based on the partner and only includes this one entity.

 

Business Object 

The modeling begins with the creation of the core data service above the table as an interface view. This determines the set of fields that will be available in the data model. Here you also have the option of normalizing the fields for the entire data model (CamelCase). The behavior definition that determines the behavior of the BO can then be created. The business object is then fully modeled with table, behavior definition and CDS view and can be used.

 

Interface View

With a right-click on the table you can create a new data definition (CDS View) using the "Root View Entity" as template. This view always forms the basis of the object and there can only ever be one root node.

 

Accordingly, after importing the fields, we adjust the field names.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'RAP interface for Partner'
define root view entity ZBS_I_RAPPartner
  as select from zbs_dmo_partner
{
  key partner          as PartnerNumber,
      name             as PartnerName,
      street           as Street,
      city             as City,
      country          as Country,
      payment_currency as PaymentCurrency
}

 

Behavior definition

With another right-click on the new Core Data Service, you can create the behavior definition via the context menu. The fields are preassigned so far, the name corresponds to the name of the CDS View and we leave the type on "Managed".

 

Appropriate implementations are suggested, which we now adapt according to our needs. The finished version now looks like this:

managed implementation in class zbp_bs_demo_rappartner unique;
strict;

define behavior for ZBS_I_RAPPartner alias Partner
persistent table zbs_dmo_partner
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  mapping for zbs_dmo_partner
  {
    PartnerNumber = partner;
    PartnerName = name;
    Street = street;
    City = city;
    Country = country;
    PaymentCurrency = payment_currency;
  }
}

 

At this point, the following information about the behavior definition that controls the behavior and the functions of the business object:

  • Behavior Class - There is a global class where the behavior of the object is implemented. The global part of the class is empty, you can find the implementation in the "Local Types" tab. You can create the class with CTRL + 1.
  • Alias ​​- An alias can be specified after the name of the entity. This can make life easier, especially when using the BO, if the name of the CDS view does not always have to be specified.
  • Table - The table is also linked to the BO in order to store and load the data in it. In the managed approach, the system reads and writes the table.
  • Operations - The CRUD operations must first be enabled for the object to allow them, and READ does not have to be specified separately.
  • Mapping - The mapping of the fields of the CDS view to the table fields is absolutely necessary, otherwise the saving and loading of the data will not work. The system does not recognize the assignment of the fields to the database from the aliases in the interface view.

 

Publication

With the last steps you have already received a working business object and can use it within the system. Of course we want to do something more and directly make a Fiori application out of it.

 

Service Definition

To do this, you can create a new "Service Definition" by right-clicking on the Core Data Service. This service definition corresponds to a project in SEGW and combines various entities into a service.

@EndUserText.label: 'Simple Partner Service'
define service ZBS_SIMPLE_PARTNER {
  expose ZBS_I_RAPPartner as Partner;
}

 

We release the CDS View under the new entity "Partner" in this service to the outside world.

 

Service Bindung

Again with a right-click on the service definition you can now create the "Service Binding". This determines the bound protocol for the service, whether you want an API, a UI, or O2/O4.

 

After the object has been created, it still has to be activated and can then be published.

 

The service is released for testing via the "Publish" button and you receive the end point in the system under which you can call it up.

 

Preview

With a double-click on the entity, a right-click and the context menu or via marking and the "Preview" button you can then display an automatic Fiori Elements preview of how the app would be generated.

 

Looks a bit empty in the first step and does not show any data yet. With the standard functionality, however, we can quickly have the app ready for use. To do this, you can use "Adapt Filters" to activate various fields of the entity for filtering. You can determine the output fields in the list via the "cog wheel". If you then press the "Go" button again, you already have a good result.

 

Git

For this series we are again creating a Git repository so that you can access the complete sources. You can also look at the changes in the repository via the Git repository and the commits. The components are developed using the ABAP environment, so we always use the most up-to-date components.

 

Conclusion

The start is always halfway easy. Today a small and simple business object, where some functions are still missing (detail screen, delete, create, automatic fields). In the next blog we will then show you how to create the detail and further UI annotations and design the app accordingly. Furthermore, we will implement the projection in a later version, which is completely missing here.


Included topics:
RAPBTPSimple ObjectBusiness Object
Comments (0)



And further ...

Are you satisfied with the content of the article? We post new content in the ABAP area every Friday and irregularly in all other areas. Take a look at our tools and apps, we provide them free of charge.


RAP - Deep Action in OData v4

Category - ABAP

In this article we will look at actions with deep structures, how we can create them and pass data to an API endpoint.

05/24/2024

BTP - Connect On-Premise (Consumption Model v2)

Category - ABAP

In this article we want to provide another update on the connection of on-premise systems and how this is done with a communication arrangement.

12/15/2023

RAP - Show app count (Tile)

Category - ABAP

This example is about displaying a counter on the tile of a Fiori Elements application and how such a thing can be implemented.

10/06/2023

RAP - Generator (Fiori)

Category - ABAP

In this article we will look at the more complex RAP generator as a Fiori Elements application and what advantages you have with it.

09/15/2023

RAP - Generator (ADT)

Category - ABAP

Today, let's take a look at the RAP Generator, which is already integrated into ABAP Development Tools, and how you can use it to easily build new RAP apps.

09/08/2023