Skip to Content
Product Information

SAP Cloud Platform Serverless Runtime: Getting Started

I just need to extend the core application.

I just need to extend the core application. I don’t want to manage service myself.

I just need to extend the core application. I don’t want to manage service myself. I should be charged for the time my codes get executed.

With the inception of cloud and its different platforms like SaaS, PaaS, IaaS etc, such demand and hence features are getting introduced by cloud providers taking the onus of complete life cycle of the environment and just allowing the developers to concentrate on business logic.

Welcome to the world of SAP Cloud Platform Serverless Runtime that lets you build, run, and manage serverless applications that extend your digital core and can react to the latest business changes.

This service runs in the Cloud Foundry environment and supports node.js 8 and node.js 10 versions.

A serverless runtime resolves above queries by taking care of following key areas.

  • State: No persistency and hence no state maintained. Should use external services to achieve.
  • Execution Duration: Very short, only for services which can be executed below few seconds. Not suitable for long tasks.
  • Startup Latency: Minimal startup latency until the runtime is spun off.
  • Scalability & Cost: Scaling is taken care by the provider and cost is pay per execution.

The goal of SAP Cloud Platform Serverless Runtime is to become the lightweight option for extending business systems like the extension spots in on-premise ABAP systems. 

Following features define SAP Cloud Platform Serverless Runtime.

  • Holistic user experience: The Extension Center business application provides a full-fledged user interface to build and manage your serverless extensions.
  • Fully-managed environment: Run your cloud-native extensions in a fully-managed, serverless environment decoupled from your digital core.
  • Extend business logic: Create serverless functions that can be triggered on demand as defined in your extension.
  • Connected systems: Connect your SAP systems to access highly available, scalable, and resilient OData APIs.

SAP Cloud Platform Serverless Runtime makes it simpler to run solutions using your business logic. It provides capabilities such as Extensions, Functions, OData provisioning, and so on.

Extension:  An Extension allows you to write loosely coupled business logic that is quick to build and scales automatically.  It contains functions that define your business logic and triggers that invoke the function(s).

OData Provisioning: OData Provisioning exposes business data and business logic as OData services on SAP Cloud Platform, thereby enabling customers to run user-centric applications.

Once an SAP Cloud Platform Serverless Runtime instance is created, you need to subscribe to the Extension Center business application to access its user interface and manage the Extensions and Services.

The SAP Cloud Platform Extension Center has Extensions and Services menu to create a New Extension and to Register OData Provisioning Services respectively.


  1. Create an SAP Cloud Platform Serverless Runtime instance using

SAP Cloud Platform cockpit


Cloud Foundry Command Line Interface (cf CLI)

You can even delete an existing SAP Cloud Platform Serverless Runtime service instance.

  1. Subscribe to Extension Center. And assign the required roles to the users.
  2. Once you are in SAP Cloud Platform Extension Center

You can start the process of creating an Extension by clicking on the Extensions menu and then clicking on New Extension button. You must have FunctionsManage role assigned to you.

An Extension allows you to write loosely coupled business logic that is quick to build and scales automatically.

The functions that represent your business logic processes, transforms, and stores data on the cloud. You can also use functions to receive and respond to events across the SAP Cloud Platform and external event sources to validate data, process files, and send notifications. Along with these functions, you can create triggers that invoke the function.

An Extension follows a well-defined structure that is described below.

File or Folder Name Description
faas.json Created under the root folder and contains all the functions, triggers, secret and configurations used in the project.
lib Folder contains the source code for all the functions in the project
data Defines all the secret configurations in the project
deploy Contains the value of the properties of the secrets to be used during the deployment.

Detailed information on structure can be found here.


Once you are in Extension Center, follow these steps to

  1. Manage Extensions by
    • Create, delete, and deploy extensions to SAP Cloud Platform Serverless Runtime using the CLI​.
    • Create, edit, and delete functions and their triggers (HTTP, Timer, AMQP). ​
    • Add secrets and config maps to functions​.
    • View information on extensions, functions, triggers, secrets, and config maps​
  2. Register OData Service
    • Provision OData services​
    • Monitor errors for registered OData services​
    • Manage metadata validation and cache for registered OData services​

Pricing Model:

Being serverless in nature, both Functions and OData Service Provisioning are charged based on the usage.


   A Function is charged based on the number of invocations and the memory usage by the Function during the execution.

Below is the pricing detail.

Services/Components Unit of Measure Capacity Unit Value
Functions – Invocations Mio Invocation/API Calls per Month 1.2
Functions – Memory 100K GB-sec per Month 6


Piece Size   1 Capacity Unit = 1 Unit of resources per month

Additional Terms & Conditions

  • Runtime Memory is the amount of memory (128MB to 1GB in multiple of 128MB) allocated for an execution unit for the duration of all the executions of an extension function.
  • An execution unit gets invoked for all the executions of an extension function that is deployed.
  • Duration is a period of time where there is at least one execution of the extension function in progress, rounded up to the next nearest 100ms with a minimum duration of 100ms and Max timeout is 5 Mins.
  • All the executions of an extension function in an execution unit share the same allocated runtime memory.
  • The Runtime Memory stays allocated for the execution unit of the extension function until no executions/invocations are in progress.
  • During the course of execution if an extension function tries to use more than the allocated memory, then the execution terminates.
  • Invocations are counted each time an extension function is executed in response to an event (Business Event, HTTP, timer etc..).
  • Invocations are counted irrespective of the outcome of the function.
  • API Calls are the Invocations of the APIs/Services (Odata Services, REST APIs, any other end points) that are registered in the services with a meter size of 5 MB (Request & Response payloads, together) Each API call can have up to a maximum of 50MB of Request/Response Payload in total.
  • API Calls are counted irrespective of the outcome of the API call response.


OData Provisioning:

OData provisioning comes with a standard and comparatively easier approach of pricing model which goes as below.

Services/Components Unit of Measure Capacity Unit Value
OData Provisioning 100K API Calls per Month 2


And for capacity units to price conversion, please follow the SAP Cloud Platform Estimator.

With SAP Cloud Platform Serverless Runtime, extend your application and yet KEEP YOUR CORE CLEAN and You can extend the core application. You do not have to manage service yourself & you shall be charged for the time your codes get executed.

You must be Logged on to comment or reply to a post.
  • Hi Pradeep,

    thanks for this blog. It is very interesting. However it is not clear in the greater context. How does this runtime relate to the SAP Extension Factory "serverless, powered by Kyma" runtime or generally with the "serverless" implementations that are marketed in this area (amazon lambda function from Extension Cockpit, etc.). It is quite confusing at the moment.

    Thanks and regards,


  • How to size with on example. Let say we have three types of extensions: one small, one medium, and one complex. I have a difficult to understand how to size in capacity units as I dont know how costly would be one exection.



  • /
  • Hi Pablo,

    In addition to the fix in documentation, there is also a fix required at the code level.  This is currently in progress.  Once the fix is available, we will update you about the same.

    Best Regards,