API’s are digital building blocks for an intelligent enterprise and constitute to be the back-bone for digital transformation which makes API based integrations very relevant. In S/4 HANA world, apart from use of standard API’s made available via API Business Hub for extension, there is also a need to write new API’s for use withing the extension framework. The need to write new API’s steams from the fact that it is a means to extend behavior of application and/or extend its capability.

There are various ways in which an API can be written such as

1. CAP – SAP Cloud Application Programming Model
2. SAP Cloud Integration
3. In ECC using SEGW and exposing it as oData
4. RAP – The ABAP RESTful Application Programming Model

And many more

If you are a ABAP programmer and wondering how do I transition my ABAP programming skills into Cloud world then you would find this blog beneficial.  For an ABAP developer, using RAP is the easiest to build API’s.

S/4 HANA – Different Flavors

ADT is the Eclipse-based ABAP Development Tools (ADT) and has been in existence before introduction of S/4

S/4 HANA comes in three flavors and depending on which of the three options you are working with, the options of developing custom API’s are different

1. S/4 HANA Cloud
2. S/4 HANA Private Cloud Edition (PCE)
3. S/4 HANA On-Premise.

Depending on whether your S/4 HANA is On-Premise, PCE or Cloud, the options available for building API’s vary viz.,

S/4 HANA On-Premise or S/4 HANA PCE:

1. Full availability of SAP GUI with ability to modify any SAP object
2. ABAP coding:
   1. SAP GUI (transactions like SEGW, SE80, SM59)
   2. Steampunk that operates via ADT.

S/4 HANA Cloud:

1. Only access to API’s released by SAP
2. CAP model using SAP Cloud SDK
3. Steampunk that operates via ADT.

The SAP Cloud SDK is based on and replaces the previously available SAP S/4HANA Cloud SDK. It draws on the existing capabilities of the SDK to communicate to many SAP solutions.

SAP Business Application Studio is the evolution of SAP Web IDE; A modern cloud-based development environment, tailored for efficient development of business applications such as SAP Fiori, SAP S/4 HANA extensions, Workflow, Mobile and more.

In addition, Key User Extensibility is a part of In-App Extensibility in the S/4HANA Cloud and is mainly pointed towards the needs of Key Users of any organization and is managed through web based Key User Tools. To understand more about Key User Extension, please refer to the blog here.

For customers moving from ECC to S/4, if there are existing OData services, bring them to S/4 as is and in case of new OData services to be build, use of RAP is recommended.

SAP S/4HANA Extensibility – Big Picture

SAP S/4HANA Extensibility – Big Picture

When extending SAP S/4HANA, one can choose between using the In-App or the Side-by-Side extensibility paradigm. Each option is tailored for different use cases.

We see various integration levels:

• UI Integration: an important option where custom specific tiles can be embedded in SAP Fiori launchpad.
• Business rules and workflows can be applied across BTP and SAP S/4HANA and other systems.
• On the process level, you can take advantage of our API catalog. To see more you can explore the SAP API Business Hub.
• Important to note that Events are a key differentiator for SAP and the event framework goes in both directions.
• Data replication is also important. It’s not intended that every side-by-side extension replicates all data relevant for this extension. The general rule or what we recommend on a general sense is that data that remains in the SAP HANA database of S/4HANA should be read through APIs and perhaps also stored back if some changes happen or new data is created through APIs. That is general pattern to have a single source of truth on the left hand side.

As with every rule, there is some exceptions and if for example a heavy workload or a B2B scenario on the right hand side indicated that this workload should not destroy the ERP or S/4HANA on the left hand side, it may makes sense to replicate some data, but it is not recommended to replicate all data from the left to the right.

In-App Extensibility; Enrich the core

• Variants of standard processes and business logic (for example, micro-vertical solutions, localization)
• Focus on company-owned business documents (for example, legal compliance)
• Analytics extensibility (for example, tailored operational
  reporting for minimized asset allocation)

Side-by-Side Extensibility with BTP

• Integrate with SAP Cloud apps and third-party solutions
• Extend core processes by before and after steps (for example, customer service or triggers from sensor data)
• New standalone cloud apps (Internet of Things)

ABAP RESTful Application Programming Model Overview (RAP)

The ABAP RESTful Application Programming Model consists of three main layers:

1. Data Modeling & Behavior
2. Business Services Provisioning
3. Service Consumption

The data modeling and behavior layer contains domain-specific business objects, that are defined with Core Data Services (CDS) and transactional behavior.

The business service provisioning layer consists of projection views with their projection behavior to focus on a particular aspect of the data model which is exposed as business services through the OData protocol.

The service consumption layer allows you to consume all types of OData services as well as OData Web APIs.

Service Consumption

Development flow is as per the diagram below where database layer is defined by the definition of dictionary tables:

Development Flow

Depending on the need to either develop read only application or full transactional application different steps within the programming model would need to be performed. For additional information on RAP, please refer here.

Steampunk and Embedded Steampunk

At SAP TechEd 2018 the availability was announced for the ABAP environment on the SAP Cloud Platform (now BTP). In short Steampunk is nothing but ABAP Platform-as-a-Service or ABAP PaaS.

The default environment for Cloud partner solutions is BTP, with Steampunk for ABAP minded folks. Embedded Steampunk is an option to run (parts of) the solutions directly on S/4HANA Cloud. Embedded Steampunk would be released in upcoming releases.

SAP S/4 HANA Cloud Extensibility – Extensibility Options

For the developer embedded Steampunk shall allow to develop new ABAP objects (e.g. a CDS view or ABAP class) and to extend SAP objects (e.g. via the ADT BADI editor).

The Embedded Steampunk model is similar to the on-premise partner add-on model. The customer and partner deploy and run the add-ons on the S/4HANA Cloud tenant. SAP is responsible for the operation of the S/4HANA solution and Cloud tenant. The partner and the customer are responsible for the partner solution

It is to be remembered that direct database access is not allowed. Database read access is possible via released CDS views only while write access is with the corresponding released API.

Internal public interfaces can be accessed only in the “embedded Steampunk” environment. To access these, one does not require the API’s to be remote enabled as The ABAP Platform Cloud and Embedded Steampunk exists within the S4HANA environment itself.

ABAP Environment in BTP

Build your own API – Example

Refer to the hands on exercise found on SAP Developer here or in the blog here.

For additional details and deep dive on ABAP in Cloud, please refer to the OpenSAP course here

One commonly asked question is how do I bring my ABAP source code from on-premise ERP to SAP Business Technology Platform ABAP Environment instance. One point to remember is that the programming model of traditional ABAP Vs ABAP in Cloud is different. The classical ABAP application programming paradigm was data-to-code, where a huge amount of data is fetched from the database, stored in internal tables and then processed on the application server, shifts to the in-memory database-powered code-to-data programming paradigm (aka code pushdown), where data-intensive computations are delegated to the database and only the result sets sent back to the application server. This reduces both memory consumption and workload on the application server, as well as the network load.

Custom code written in ECC needs to be analyzed before migrating it to ABAP on Cloud. Refer to the blog here for details on how to achieve this.

Github Repository using the abapGit report and the ADT plugin for abapGit is option for migrating the code after analysis. Refer to the blog here on details about it.

Customer Use Cases

Some of the scenarios for SAP BTP ABAP Environment

Scenario 1: Cloud ERP – Use SAP BTP ABAP Environment to create or extend SAP S/4HANA Cloud or other SAP cloud solutions

Scenario 1

1. SAP Cloud solutions like SAP S/4HANA Cloud provide in-app extensibility to extend SAP apps and processes, but there is no support for classic custom ABAP development on top of SAP S/4HANA Cloud
2. SAP BTP is the foundation to develop and run custom cloud extensions and the ABAP environment shall be used for ABAP based cloud extensions

Scenario 2: Innovative Platform. BTP allows you to develop and run ABAP on a PaaS in the Cloud

Scenario 2

1. Benefit from the newest ABAP Platform and SAP HANA database technologies independent from your existing on-premise system landscape
2. Build API’s, Fiori apps with the new future proof ABAP RESTful Programming Model
3. Utilize other SAP BTP services like IoT, machine learning etc.

Scenario 3: Use as a Hub – Decouple ABAP implementations from core

Scenario 3

1. Make cloud app available to a broader audience that does not have access to the core business systems
2. Integrate in the cloud extension multiple cloud/on-premise systems with SAP Cloud Services
3. Collect data from multiple sources in cloud for further processing and analysis
4. Cloud extensions use only well defined (remote) APIs of the Business system. Also develop new API’s

Scenario 4 – Embedded Steampunk

Scenario 4

API Management

Modern enterprises look at APIs as the digital building blocks to achieve agility, composability, connected multi-experiences and innovate on new business models. Our customers look for a 360^o  API Platform to support with running

1. API Businesses
2. API Engagement through Marketplaces and
3. Agile & Accelerated API Development and Delivery

SAP API Management supports our enterprise customers with all these use-cases, to name a few:

Improving Process Excellence by adding more agility and composability in their enterprises across value streams such as lead-to-cash, recruit-to-retire, source-to-pay and design-to-operate

Deliver Superior Connected, Intelligent Experiences across omni-channels and multi-experience for their customers. In the experience economy, enterprises win by closing the experience gap by constantly measuring brand, product and employee experiences and delivering these superior experiences with agile business operations.

Innovate with Digital Ecosystems and New Business models, by unprecedented collaboration across business networks and driving growth through new subscription-based business models.

Learn more about API Management by joining our Discovery Center mission and our OpenSAP Course