This is not a blog post about convincing you to adopt a clean core policy and why it is important, but instead, this blog post is more about asking the question: Can we keep the Core Clean with RAP Model?

If you’re still unfamiliar with this clean core policy, I would suggest reading through this blog post first Keep a Clean Core with SAP BTP to get an overview and the reasoning behind why you should consider keeping your Core (SAP System) Clean. The message from SAP can be seen in a different light that chances are that your SAP ERP System is messy, costing you money, and preventing you to innovate and make use of the latest advancements in technology — so in my opinion, they are probably enough compelling reasons why you should consider keeping your core clean.

With the concept and motivation already out of the way (and you are on board with it), let’s get into the action of applying it, and for this blog post, we will be using the RAP framework on the BTP ABAP Environment.

A minor point of clarification, this blog post will cover the Side-by-Side Extensibility scenario which will make use of an OData API service.

The Goal

The goal is to create a custom Fiori application on BTP (side-by-side extensibility scenario) using the RAP framework for the BTP ABAP Environment while leveraging the standard OData API service. This is to be achieved by creating a CDS Custom Entity that will act as a proxy entity for the remote OData service. The remote OData service is capable of providing full OData entity operations namely: create, read, update, and delete — so we will need to add behavior definitions and implement them at the same time. And since RAP is supporting the Fiori Elements framework, we will add the draft feature into the mix.

Bear in mind that this is not a tutorial, instead, it’s more of a sample project where you can use a reference. If you’re new to the RAP framework, I suggest going through some available SAP Developer Tutorials about RAP before trying to replicate or implement something similar on your own. But if you just want to understand the concept and run some tests using the demo project, you can get by just fine by reading the details I will explain below.

The Demo Project

The demo project is available in the BTP ABAP Trial under the package ZRFES (RAP FE Samples) or if you have your own BTP ABAP instance you can install it using the repository below:

https://github.com/jcailan/rap-fe-samples

ABAP Project

The main RAP project sample can be found in the ZRFES_RAP_EXTERNAL_SERVICE package. There are two service bindings, as you can see below:

• zui_products_es_o2 – OData V2
• zui_products_es_o4 – OData V4

Both services are exposing a single entity called the Products entity.

External Service: Products API

For the sake of simplicity and ease of testing in the BTP ABAP Trial environment, I have opted to use a publicly available OData V2 API service called product-api. This OData service is a CAP-based application, and you may be wondering why CAP? Well, things are simple and easy with CAP. So effectively, I’m using a CAP-based OData service as a replacement for an otherwise complicated setup of:

• SAP Cloud Connector
• On-premise System (i.e. S/4HANA)
• Creation of a bunch of BTP configs (i.e. destinations, communication scenario, communication system, etc.)

There are a lot of SAP Developer tutorials that provide step-by-step procedures on how to do those set up so I opted to skip all of those, again for simplicity’s sake.

In order to call the publicly available OData API service, I have used the method create_by_url of class cl_http_destination_provider — see zcl_product_model_es:

Testing

OData V4 Service

First of all, when I tested (using service binding preview) the OData V4 service with the draft feature, I was greeted with resistance from the RAP framework — stating that Draft is not supported. If you want to know more details then read through this Q&A: Can’t create behavior implementation against a Custom Entity.

Okay, so I was forced to take out the draft capability, but do note that the create, update, and delete behavior is still there in the behavior definition.

When testing the service zui_products_es_o4, you will notice that the create and edit buttons are not visible — only the delete button is visible:

This is because the Fiori Elements for OData V4 doesn’t support non-draft OData service. So we are now going to the not-so-fortunate case of downgrading to OData V2 service.

OData V2 Service

This time, test the zui_products_es_o2 using the service binding preview button and you will see that the create, edit, and delete buttons are all visible. They are all working except for certain limitations:

• The create operation of the remote OData service will always generate a new entity with the key `00000000-0000-0000-0000-000000000000` so there will always be one record with this key. So if you encounter an entity already exists error then you should delete the entity using this key before you can use the create successfully.
• The edit/update operation is only capable of updating the name field of the product because this is what is implemented in the behavior implementation
• The implementation is not complete, it just shows enough capabilities to prove what is possible.

See below screenshots are proof of the functionality is active and ready for you to use:

Closing

So going back to the question: Can we keep the Core Clean with RAP Model? The answer is not so straightforward YES and NO answer.

If you’re expecting that we can use RAP, OData V4, and Fiori Elements — the answer is NO, it is currently not supported. But if you’re willing to settle for the OData V2 version (non-draft Fiori Elements) then you got a YES as an answer.

But in my opinion, I think SAP should support the OData V4 version in order to back up the concept of keeping the core clean. I had a correspondence with SAP support about this matter, and all they can say for now is that they plan to support this feature but are unable to give a timeline for when it will be planned for release.

In the meantime, stay tuned for future blog posts as I explore other alternatives to keeping the core clean.