Skip to Content
Technical Articles

The RAP Generator


  • 19.05.2020 – added link to GitHub repo
  • 31.05.2020 – added the demo from my SAP Online Track talk [SOT114] The RAP generator
  • 05.06.2020 – changed the code of the RAP Generator so that it works again after HFC3 has been applied
  • 10.06.2020 – Published new version that offers the following
    • Object oriented design
      • BO node class
      • BO generator class
    • Support for multiple child, grandchild, … nodes
    • Unit tests
    • Exception class
  • 31.08.2020 – New version that offers the following
    • Structure of the BO can be defined in a JSON file
    • Support for CDS views as a data source
  • 11.09.2020 – Added a link to a how to a click through guide


When preparing hands-on sessions for the SAP Fiori Programming Model (in the past) and now for the ABAP RESTful Programming Model (RAP) I always faced the problem that we had to start from scratch.

That means that the participants were forced to create all objects of the stack such as table(s), Interface CDS View(s), Projection View(s), Metadata Extension View(s), Behavior Definition for interface view and projection view and Behavior Implementations, service definition and service binding.

Most of what a developer has to do here is to write boiler plate coding such the use of the insert all elements option when creating a CDS view based on a table or another CDS view.

For educational purposes it’s OK that you learn how to develop all the objects step by step. But if you want to provide a deep dive session it is not much fun if you have to create lots of boiler plate coding before having the chance to dive into the more interesting topics.

Also for a normal developer it would be nice to have the chance to speed up the development process by getting an up- and running starter business object.

So I was very pleased when I saw in an SAP internal review the new XCO framework (“Extension Components”) which allows you to generate various ABAP repository objects via ABAP API’s.

So I started to develop a class zcl_rap_bo_generator that allows you to generate nearly the complete stack of a RAP business object based on one (header) and multiple child and grandchild tables which is available on GitHub

With the 2008 release the third version is now available and can be tested on the trial systems. As of  the release 2008 the XCO framework is now also available in customer systems.

Special thanks for several discussions go to Soeren Schlegel who suggested to use an object oriented approach to get to a scalable architecture as we have it now.

While the first version was only able to generate a header item scenario the second version became much more flexible and allowed to generate more complex business object trees.

The third version now allows to define the specifics of your business object tree in a JSON file.

This way you do not have to write lots of service specific coding and you can concentrate on the structure of your BO.

I won’t explain the XCO framework as such in great detail because this will be done by my colleague Sebastian Michler who is the product owner of this library.

Click-through guide

When you just want to try it out in a trial system you find a click-through guide in my following blog

How to use the RAP Generator

What’s new with 2008

  • Structure of the BO can be conveniently entered as a JSON file
  • Support for CDS views as a data source
  • Generation of service definition and service binding
  • Generation of control structures for unmanaged scenarios

I moved the technical documentation to the file of the GitHub repository.


  • there are currently no known limitations

What does it do?

Lets have a look at the famous flight sample and take the two tables that are part of the GitHub repository


I assume that you have created a package ZRAP_DEMO and within this package you have created a class zcl_rap_generator_demo that is a clone of the class ZCL_RAP_GENERATOR that is part of this repo.

On the trial systems I have installed the generator for your convenience, so no need to download the repo from GitHub on these systems.

You now only have to create a JSON file like the following

  "implementationType": "managed_uuid",
  "namespace": "Z",
  "suffix": "_####",
  "prefix": "RAP",
  "package": "ZRAP_####",
  "datasourcetype": "table",
  "hierarchy": {
    "entityName": "Travel",
    "dataSource": "zrap_travel_demo",
    "objectId": "travel_id",    
    "children": [
        "entityName": "Booking",
        "dataSource": "zrap_book_demo",
        "objectId": "booking_id"               

Based on the two tables and the above mentioned JSON file the generator will create the following repository objects:

  • CDS interface views
  • CDS projection views
  • Metadata Extensions
  • Behavior Definition
  • Behavior implementation classes
  • Service definition
  • Service binding

as shown in the following screen shot




Please note that the generated artefacts follow the naming convention which is used for the development in SAP S/4HANA.


How does it work?

Create a package

The generator needs a package where the ABAP artefacts that are going to be generated are stored.

In the above mentioned demo I created a package ZRAP_DEMO.

Create the table(s) (for managed scenarios)

If you want to develop a managed scenario for a green field implementation you will want to create new objects. Here it is recommended to use tables with UUID based key fields since these can be changed such that they also support draft.

For a managed scenario where UUID’s are used as key fields for both, the header as well as the item table, the generator expects that the tables fulfill certain prerequisites:

The key field uuid must be a Universally Unique Identifier (UUID). This mandatory for a managed scenario where early numbering is used. That means where the ABAP framework automatically generates values for the key field when creating the data.

The last four fields of the header table

  • created_by
  • created_at
  • last_changed_by
  • last_changed_at

are also mandatory in a managed scenario for a root object. The framework expects these type of fields (with appropriate annotations in the root CDS interface view) so that it is able to check when data has been created and changed.

Download the classes from Github (only needed for non-trial systems)

The tool consists out of 5 classes and a message class that you can download from Github. The package also contains three sample tables for a managed scenario with uuid based key fields.

Call the generator using a console application

Simply duplicate the class ZCL_RAP_GENERATOR. In the above shown screen shots I created a new class called ZCL_RAP_GENERATOR_DEMO.

Copy and paste the content of a json sample file (e.g.) json_managed_uuid_table_demo.txt between the two single quotes.

Be sure to have activated the settings inADT that will wrap and escape the JSON string as I have described in this blog How to wrap long strings automatically in ADT.

Replace the placeholders #### so that they fit to the name of your package and the suffix if you want to use one for your objects.

The edited code should look like follows

When you press F9 the generator should simply tell you Finished.

What happens if I did a typo?

If you for example forget to replace the placeholders an exception will be raised.

This exception is caught by our class since it inherits from the new class cl_xco_cp_adt_simple_classrun which iis provided by the XCO framework and that shows the complete stack of the exception as you know it from ADT.



I plan to add the following features when the next release of SAP Cloud Platform ABAP Environment is available.

  • Generation of CDS views for domain fixed values
  • Objects will be generated inactive, that means you will have to activate them manually.
  • Support for on premise systems

Looking behind the scenes

If you are interested how the RAP Generator works in detail, here is a short technical overview.

The objects of the RAP Business Object tree are generated by the class zcl_rap_bo_generator.

The constructor of this class expects two parameters. The name of the package in which all the objects shall be generated and a root node of type zcl_rap_node that itself can have child nodes that also can have child nodes.

The tricky thing is now how to create the node hierarchy of node proxy classes.

When creating the root node there is the need to specify certain parameters such as the name space, the type of data source that is used (table or CDS view), the implementation type (managed or unmanaged), the type of keys (uuid or semantic and optionally a suffix and a prefix.

These root node specific parameters are inherited by the child nodes when these are added using the method add_child( ).

For each node (the root node and all child nodes) certain node specific parameters have to be set as well, such as the name of the entity and the name of the data source. Based on the data the node objects will contain data such as the names of repository objects taht shall be generated, name of key fields, etc.

Though you can create this node hierarchy programmatically yourself I came to the conclusion that it is better to provide all these parameters in a JSON file.

With the version 2008 of the ABAP stack the XCO libraries provide a powerful way to read and manage JSON files.

By developing a JSON visitor class zcl_rap_xco_json_visitor I was now able to minimize the programmatic effort for the user (the developer).

When having created an appropriate JSON file this file has only to be pasted in a class.

DATA rap_bo_visitor TYPE  REF TO zcl_rap_xco_json_visitor .
DATA(json_string) = '<enter your json string here>'.
rap_bo_visitor = NEW zcl_rap_xco_json_visitor(  ).
DATA(json_data) = xco_cp_json=>data->from_string( json_string ).
json_data->traverse( rap_bo_visitor ). 

The visitor will be used when traversing the JSON file using the class xco_cp_json. It will create the node hierarchy and will pass this data in a final call if_xco_json_tree_visitor~on_end to the class zcl_rap_bo_generator.

  METHOD if_xco_json_tree_visitor~on_end.
    LOOP AT root_node->all_childnodes INTO DATA(childnode).
      childnode->finalize(  ).
    root_node->finalize(  ).
    DATA(my_bo_generator) = NEW zcl_rap_bo_generator(
        iv_package          = root_node->package
        io_rap_bo_root_node = root_node
    DATA(lt_todos) = my_bo_generator->generate_bo(  ).

Since the class zcl_rap_generator (that you should copy beforehand) inherits from the new class cl_xco_cp_adt_simple_classrun that is provided by the XCO framework all exceptions that are thrown by the generator are conviently catched and written to the console log in the very same way as you know it from ADT.

Where can I get the source code?

The source code for RAP Generator can be found on GitHub 

What is generated?

CDS – Interface view(s)

The interface view are generated such that based on the ABAP field names aliases have been created such that the ABAP field name was converted into camelCase notation.

@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
@EndUserText.label: 'CDS View forTravel'
define root view entity ZI_RAPTRAVEL_DEMO
  as select from zrap_travel_demo
  composition [0..*] of ZI_RAPBooking_demo as _Booking
  key UUID as UUID,  
  TRAVEL_ID as TravelID,  
  AGENCY_ID as AgencyID,  
  CUSTOMER_ID as CustomerID,  
  BEGIN_DATE as BeginDate,  
  END_DATE as EndDate,  
  @Semantics.amount.currencyCode: 'CurrencyCode'
  BOOKING_FEE as BookingFee,  
  @Semantics.amount.currencyCode: 'CurrencyCode'
  TOTAL_PRICE as TotalPrice,  
  CURRENCY_CODE as CurrencyCode,  
  DESCRIPTION as Description,  
  OVERALL_STATUS as OverallStatus,  
  @Semantics.user.createdBy: true
  CREATED_BY as CreatedBy,  
  @Semantics.systemDateTime.createdAt: true
  CREATED_AT as CreatedAt,  
  @Semantics.user.lastChangedBy: true
  LAST_CHANGED_BY as LastChangedBy,  
  @Semantics.systemDateTime.lastChangedAt: true
  LAST_CHANGED_AT as LastChangedAt,  

CDS – Projection view(s)

The projection view is created with annotations added for currency code.

@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
@EndUserText.label: 'Projection View forTravel'
define root view entity ZC_RAPTRAVEL_DEMO
  as projection on ZI_RAPTravel_demo
  key UUID,  
  @Semantics.amount.currencyCode: 'CurrencyCode'
  @Semantics.amount.currencyCode: 'CurrencyCode'
  _Booking : redirected to composition child ZC_RAPBooking_demo

Behavior Definition

The behavior implementation was generated such that the semantic key was marked as read-only. Also a mapping was added that maps the ABAP field names to the field names of the CDS views.And we find a determination that was generated for the objectId field.

implementation managed;

define behavior for ZI_RAPTRAVEL_DEMO alias Travel
implementation in class ZBP_I_RAPTravel_demo unique
persistent table zrap_travel_demo
etag master LastChangedAt
lock master

  field ( readonly ) TravelID;
  field ( numbering : managed ) UUID;


  mapping for zrap_travel_demo
    UUID = UUID;
    TravelID = TRAVEL_ID;
    AgencyID = AGENCY_ID;
    CustomerID = CUSTOMER_ID;
    BeginDate = BEGIN_DATE;
    EndDate = END_DATE;
    BookingFee = BOOKING_FEE;
    TotalPrice = TOTAL_PRICE;
    CurrencyCode = CURRENCY_CODE;
    Description = DESCRIPTION;
    OverallStatus = OVERALL_STATUS;
    CreatedBy = CREATED_BY;
    CreatedAt = CREATED_AT;
    LastChangedBy = LAST_CHANGED_BY;
    LastChangedAt = LAST_CHANGED_AT;
  association _Booking { create; }
  determination Calculate on modify { create; }

Behavior Definition Projection

implementation projection;

define behavior for ZC_RAPTRAVEL_DEMO alias Travel

  use create;
  use update;
  use delete;

  use association _Booking { create; }

define behavior for ZC_RAPBOOKING_DEMO alias Booking

  use update;
  use delete;

  use association _Travel;

Metadata Extension View(s)

Last not least you will find it handy that also a Metadata Extension View has been generated that automatically publishes all field on the list page as well as on the object page by setting appropriate @UI annotations.

@Metadata.layer: #CUSTOMER
@UI: {
  headerInfo: {
    typeName: 'Travel', 
    typeNamePlural: 'Travels', 
    title: {
      type: #STANDARD, 
      label: 'Travel', 
      value: 'TravelID'
annotate view ZC_RAPTravel_demo with
  @UI.facet: [ {
    id: 'idCollection', 
    type: #COLLECTION, 
    label: 'Travel', 
    position: 10 
    id: 'idIdentification', 
    parentId: 'idCollection', 
    label: 'General Information', 
    position: 10 
    id: 'idLineitem', 
    label: 'Booking', 
    position: 20 , 
    targetElement: '_Booking'
  } ]
  @UI.hidden: true
  @UI.lineItem: [ {
    position: 20 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 20 
  } ]
  @UI.lineItem: [ {
    position: 30 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 30 
  } ]
  @UI.lineItem: [ {
    position: 40 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 40 
  } ]
  @UI.lineItem: [ {
    position: 50 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 50 
  } ]
  @UI.lineItem: [ {
    position: 60 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 60 
  } ]
  @UI.lineItem: [ {
    position: 70 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 70 
  } ]
  @UI.lineItem: [ {
    position: 80 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 80 
  } ]
  @UI.lineItem: [ {
    position: 90 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 90 
  } ]
  @UI.lineItem: [ {
    position: 100 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 100 
  } ]
  @UI.lineItem: [ {
    position: 110 , 
    importance: #HIGH
  } ]
  @UI.identification: [ {
    position: 110 
  } ]
  @UI.hidden: true
  @UI.hidden: true
  @UI.hidden: true
  @UI.hidden: true


Service Definition

define service ZUI_RAPTRAVEL_M_DEMO {
  expose ZC_RAPTRAVEL_DEMO as Travel;
  expose ZC_RAPBOOKING_DEMO as Booking;

Feel free to check out more of the generated code.



You must be Logged on to comment or reply to a post.
  • Great blog post Andre Fischer. This will make things substantionally easier when faced with creating several config tables for example.  I’ll test it out in the next few days.

    I guess I’ll have to edit my blog post after that as well 🙂



  • Can I ask what gets generated when you have a header and an item table e.g. sales order header and sales order item?

    The reason I ask is that every blog (often from different SAP employees) I read seems to have a different take on what CDS views need to be created in such a case. Sometimes one (or more) each for both tables, and one (or more) combined CDS view(s), sometimes just one combined view, or any combination of the above options.

    This is a wonderful step forward by the way. People are going to want to use this as a normal thing, not just for TechEd demos. It is just like the table control generator in DYNPROS or all the generated code in Web Dynpro or indeed the code that gets auto-generated when you want to call a BRF+ rule.

    In every case you do not want to do the exact same thing again and again, month after month, year after year, possibly doing it slightly differently each time and missing something, when your aim to to write the exact same code as you did before.

    Cheersy Cheers


  • Very interesting approach, thanks for sharing. Are there any prerequisites before creating the class zrap_cl_bo_generator?

    We are getting Errors since use of the sxco* elements is not permitted.

    • As I wrote the XCO framework is currently only available via a feature toggle. But we plan to make it available for all Steampunk system soon as well as for future on premise systems.

  • If I get this in console:

    XCO Generation: PUT exception:
    “action | association | create | delete | determination | determine |
    draft | factory | field | function | internal | mapping | static |
    update | validation | }” expected, not “;”.
    “action | association | create | delete | determination | determine |
    draft | factory | field | function | internal | mapping | static |
    update | validation | }” expected, not “;”.
    “field | mapping | use | }” expected, not “;”.
    “action | association | create | delete | determination | determine |
    draft | factory | field | function | internal | mapping | static |
    update | validation | }” expected, not “;”.

    what has failed?

    • The generator has failed because it contained coding that I had to implement to provide a workaround for a tiny bug in the XCO framework.

      This bug was fixed with Hotfix Collection 3 that has now been applied to the trial systems.

      I have updated the code in GitHub.

      Just pull it again.

      It should work now.

      Best regards,



  • Hi Andre,

    I’ve just tested your rap code in my Abap trial account, and its brilliant.

    I’ve uploaded your code in the following package:


    Rap code in cloud

    and i’ve generated my own tables and its generated successfully:



  • Hi Andre Fischer.

    the RAP Generator is absolute brilliant. Today I tried it for the first time successfully in a ABAP Cloud Trial environment.

    I think, you spent a lot of days (or/and evenings?) to bring the RAP Generator alive.

    Thanks you very much!


      • Thanks Andre for your prompt reply. Some of my use cases are to create ‘Display only’ apps and web APIs SAP S/4HANA 1909. So as I understand it, prerequisite to use this generator is to create the tables first with parent-child relationships. I am thinking of :

        1. creating them in ABAP cloud environment in ADT
        2. generate the RAP objects using the RAP generator ABAP cloud
        3. copy the generated package through abapgit into S/4HANA on-prem.

        Is it possible or unmanaged scenario is not supported by RAP generator?

        Best regards,


        • Hi Sumit,

          you are totally right. This is possible.

          You can create repository objects in a SAP Cloud Platform, ABAP Environment system and copy the generated objects via abapGit into S/4HANA 1909 on-prem. For this you can also use a trial system, but keep in mind that these systems are shared systems so the objects you are going to create are in principle visible for all trial users.

          For the use case you are interested in “unmanaged_semantic_key” the Generator only expects that there is a hierarchy of tables where the header table always contains all key fields of the item table. See also the file for more details

          Best regards,


          • Appreciate your detailed answer. Yes, I later realized that GitHub sample already contains sample JSON for unmanaged scenarios, should have peeked in there already.🙂 Thanks for directing me to the right sample.

            Best regards,