Skip to Content
Product Information

Developing for Analytics with the SAP BTP ABAP Environment

With the 2102 release, the SAP BTP ABAP Environment opened up the door for analytics developments. The programming model follows the same “RAP” paradigm as in the transactional world: The entity model is implemented with CDS views that make use of additional analytical annotations that were now also released for the usage in the BTP ABAP Environment (“Steampunk”).

As there is no access to the analytical backend transactions nor to the analytical key user tools, an analytical preview was also introduced, so that a developer can test his developments directly in the ABAP Development Tools.

Another novelty is the introduction of an analytical service exposure. For an analytical service to be used as real time connection with a supported client (like e.g., SAP Analytics Cloud), the SAP Information Access protocol (InA) is required whereas transactional services rely on the OData protocol. With 2102, InA was enabled for Steampunk by adding a new service binding type as well as by including the respective communication scenario SAP_COM_0065.

With these changes, a developer can now for the first time build an end to end scenario from an analytical model in the ABAP environment up to a consumption in an SAP Analytics Cloud story! There is already a step-by-step tutorial out there, that guides you through all development steps that are needed to do so.

This blog post starts a small series, where we want to give more background and explain the concepts that are applied when developing for analytics:

  • How does an analytical model look like in general
  • how does it compare to the transactional RAP paradigm and finally
  • how it can be practically applied

Today, we will start with the comparison to transactional RAP.

RAP Style Analytics

According to the documentation, the Restful ABAP programming model “is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating […] services with bindings to an […] protocol […]”. Let’s see if this holds true for analytics as well.

In the following graphic, I took the RAP based model (on the left side), tweaked it a bit, and then added the corresponding analytical development artefacts (on the right side) to compare the development flow:

  1. Development starts with data modelling based on existing CDS views and tables
  2. The analytical model is based mainly on so called cubes and dimensions that are also modelled in CDS
  3. The analytical equivalent to a consumption view is the analytical query. It is based on an analytical cube and is again also an ABAP CDS artefact
  4. The query is then used within service definition and binding (via InA)

So the analytics developments are really following the same paradigm with CDS views, service definition and binding and use the same data models as a basis – just as you are used to from the RAP style transactional world.

The differences (at least from the programming model perspective) are just small additions to adapt to the special needs for analytics:

  • The new service binding type InA is tailored to the needs of analytical clients, e.g., to serve different aggregation levels at once
  • and of course additional annotations are needed to describe the semantics that are unique to analytics

By the way, if you are not familiar yet with the ABAP Restful Programming Model, there is a great getting started blog post available.

What’s next?

In the next blog posts in this series, we will give an introduction to analytical modelling in general as well as how this is done using ABAP CDS entities. I will link the next posts here as soon as they become available.

Until then, stay tuned and healthy. Thanks for reading!

/
Be the first to leave a comment
You must be Logged on to comment or reply to a post.