Skip to Content

We are excited to announce general availability of the new application programming model for SAP Cloud Platform. To understand what it adds, let’s consider the following scenario:

Cathy, an application developer, was given the task of creating an application on SAP Cloud Platform that integrates with existing data from a SAP S/4HANA backend, adds some new fields to it, as well as a “propose/approve” process to create new entries. And she’s given only a few days to get that done. 

Wouldn’t it be great if she could simply reuse the existing data model from the ABAP backend and just apply the necessary extensions? And as one is used to in SAP S/4HANA, just expose and serve that extended model to Fiori UIs?

And of course: to not spend most of her time worrying about things like implementing metadata providers, serving $metadata requests as well as each individual CRUD requests, i18n and localization, filling in auditing data, code lists and value helps, extensibility and customization, multi-tenancy, resilience, and so on, instead of focusing on her actual tasks.

These kind of questions led us to rethink how we could easily build business applications on SAP Cloud Platform within an SAP ecosystem. The result is what we call an (enterprise) application programming model: It guides application developers along a golden path of best practices allowing them to focus on their domain problems to solve instead of wasting time and efforts in technical disciplines and hard-to-maintain boilerplate code. How? By providing a set of enterprise-grade tools, languages and libraries that relieve them from technical disciplines.

 

Golden Path

Following the golden path of the programming model helps you implement data models, services and UIs in order to develop stand-alone business applications or extend other cloud solutions, like SAP S/4 HANA or SAP SuccessFactors.

In essence, the recommended way to build applications is as follows:

You do… using…

and let the framework take care of…

Define your Data Model CDS
  • automatic deployment to HANA
Define your Services CDS
  • translating to OData service definitions
  • serving requests out of the box
  • authorisation*) and standard validations
  • filling in primary keys and audit information
  • writing trace and audit logs
  • health checks
  • etc.
Add Custom Logic Java/JPA or
Node.js (later on)
  • handling database connections
  • including tenant isolation
  • parsing input and
  • serialising responses
Add Fiori UIs CDS Annotations
  • translation to OData vocabularies
  • generating a Fiori elements app skeleton
Reuse existing Services
(e.g. from S/4)

S/4 HANA SDK

CDS

  • Constructing and handling http requests
  • Providing APIs in Java / Node.js
  • Mash-ups with local data

(→ see the documentation for a more detailed walkthrough)

 

Key Ingredients

The figure below depicts the key building blocks and technologies which constitute the new programming model. The overarching approach is:

We use CDS to capture data models as well as service definitions on a conceptual level. These CDS models serve as input to frameworks on data, service and UI layers (indicated by the arrows in the graphic) where they are translated to native artifacts – e.g. SQL database schemas, or OData $metadata documents – as well as interpreted to automatically serve requests at runtime.

 

 

Core Data & Services (CDS) – we adopted CDS*) as known from S/4 HANA and ABAP to define data models as well as service interfaces on a conceptional level. As with S/4 HANA, you can annotate the CDS models with annotations for Fiori UIs.

(Generic) Service Providers that interpret CDS models to automatically serve metadata and CRUD requests out of the box.

Service Consumption libraries which facilitate reuse of and integration with existing services in the cloud or from S/4 HANA.

Data Access Layers which use the CDS models to support higher-level data access options. For example, from data models in CDS we generate corresponding sets of JPA classes.

SAP Web IDE with advanced support and tools tailored for the new programming model such as CDS Editors, Code Assists, Outline Views, new Project Explorer, etc.

Note: Currently we publicly released Java for runtime stacks with Node.js to follow later on.

 

Key Qualities & Benefits

We already emphasised the key focus on application development tasks, golden path of best practices and the automation of time-consuming tasks. There are still two more qualities we want to highlight:

1. No abstraction, minimal overhead

While we provide easy to use interfaces to things like databases, we do not introduce abstractions. Means: You always have access to all native capabilities, e.g. to leverage the power of HANA.

2.  Openness, freedom of choice

Even though we provide advanced support for and integration of the recommended set of technologies (→ see Golden Path above) we are not locked-in to them. In particular, you can add and use your preferred databases instead of HANA, can build UIs without Fiori can use other tools in local setups instead of WebIDE.

In summary:

By using declarative approaches like CDS, plus a combination of enterprise-grade tools and services, and a golden path of best practices, we greatly increase developer productivity and speed up the development process. This means we significantly reduce time to market. Moreover, this ensures many essential non-functional features, like multi-tenancy, extensibility, supportability and maintainability.

The golden path is recommended, but not mandatory. With our application programming model, you are not locked-in and can choose whichever path you are more comfortable taking.

 

See also…

 


*) based on a new, modular and lightweight implementation of CDS, that allows fast release cycles, with an enhanced feature set and openness for other databases than HANA.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Daniel Hutzel Post author

    Thanks.

    Yes, indeed many pieces can technically be used in varying environments, including the new CDS implementation, the service SDKs, etc. which is one of the reasons for open and modular design principles we chose to pursue; gives us flexible ways to combine things going forward. License-wise still needs follow ups; not decided yet in all cases.

    I understand, your question specifically goes to the SAP S/4 HANA Cloud SDK?

    (0) 
  2. Srdjan Boskovic

    Which approach/model/SDK shall be used to leverage the existing business functionality, of Purchase Order (MExx) or Sales Order (VAxx) for example, on SCP?

    (0) 

Leave a Reply