SAP Community - SAP BTP, serverless runtime

Develop SAP Cloud Platform Serverless Runtime application using SAP Business Application Studio

2020-08-18T18:58:23+02:00

Before you go ahead and read through this blog, you need to have some basic know-how on SAP Cloud Platform Serverless Runtime and SAP Business Application Studio.

If SAP Cloud Platform Serverless Runtime is new to you, I recommend you to go through the Overview of Function as a Service blog from dear carlos.roggan . Not only has he explained the concept and how to work with it beautifully, but also it has links to other reference blogs and materials associated with SAP Cloud Platform Serverless Runtime.

If you are even new to SAP Business Application Studio (BAS), please follow this info blog, which points to other blogs from this central blog.

Now that you have knowledge of both SAP Cloud Platform Serverless Runtime and SAP Business Application Studio, let us discuss in this blog how can you develop a SAP Cloud Platform Serverless Runtime application and build & deploy on SAP Cloud Platform using SAP Business Application Studio.

Let us understand the steps which need to be performed and than we will go in detail of each step.

Open BAS and Create Dev Space.

Create Project from Template

Open the Project in a workspace

Debug the Function as a Service

Deploy to SAP Cloud Platform

Let us dig deeper.

Open BAS and Create Dev Space - A dev space is a pre-configured environment with the required tools and extensions tailored for a specific business scenario. Before developing any application, you should create a dev space that is suitable to your development scenario.

In our case, we’ll need to create a dev space for developing applications using SAP Cloud Platform Serverless Runtime.

There are a couple of advantages for using a dev space. First, it contains only a pre-defined set of tools required to develop, so your environment is cleaner, faster, and easier to use. Second, you have the freedom to install your own tools to configure your dev space as you please, providing a local-like development experience.

The dev space Manager

Creating a new dev space

The dev space enables working environment to be cleaner by allowing to download only required tools and extensions. In our case, to be able to work, we need to select the application type as Basic and Extension Factory Serverless Runtime Development Tools from the list of available SAP basic tools extension. It automatically selects the MTA Tools.

The MTA Tools allow you to perform operations such as build, deploy & validation on multi-target applications. The MTA Tools are provided as an extension to SAP Business Application Studio and contains Cloud Foundry CLI, Cloud MTA Build Tool.

Create Project from Template - Now that the dev space with required extensions created, let us go ahead and create a new project using from template. We need to select "Serverless Extensions Project" template to create a new SAP Cloud Platform Extension Factory, serverless runtime project.

New project from template

On clicking Next button, the Business Application Studio opens a set of guided widget to create a project, a function and a trigger sequentially.

Create a FaaS Project

Create a Function

A function is part of an extension. If you notice here, while creating a function you need to have a module and a handler also. The module should be created locally. The handler method must contain parameters that call the function such as event, context, and so on. Also, it can have additional configuration data.

Create a Trigger for the Function

A Function is instantiated in response to events (trigger). Each trigger is defined as a JSON object in the following format:

- HTTP trigger - Sample Code
  “<trigger_name>” : {
  “type”: “HTTP”,
  “function”: <function_name_that_should_be_triggered>
  }
- Timer trigger - Sample Code
  “<trigger_name>” : {
  “type”: “Timer”,
  “function”: <function_name_that_should_be_triggered>
  “timerCronExpression”: <cronexpression_schedule>
  }

As of now, HTTP and TIMER based trigger are supported from BAS. AMQP and Cloud Events based triggers will be supported shortly.

Open the Project in a workspace - Once you complete all steps above, you will get an alert as below.

Select to open in new workspace and you will have your project open as below in a new workspace.

You can view the project structure in the Explorer. It is a node.js project. The lib folder contains the following sections describe how you can write function code using node.js 8 and node.js 10. Write a handler method as a JavaScript function in a node.js module. It receives the event and context parameters from the runtime. The handler is called for each function invocation. It can return a simple value directly, undefined or a promise to handle the asynchronous execution.

In the project we have created, if you notice in the index.js module, you can find the handler template as below. You can write your customized business logic here.

handler: function (event, context) {



/*Enter your function's business logic here*/



return 'hello world from a function!';



}

Debug the Function as a Service - It is always better to try out the function locally before deploying it in the SCP.If you give a close look, you will also find a test folder, which does contain an integration folder. This helps in debugging and thus helps in checking the correctness of the function before deploying it.

Below steps need to be performed for each function before starting debugging of it. It follows the standard Run Configurations for an Extension process. Do find the exact steps to be followed to be able to debug developed function.

Click on the Run Configuration as shown below.

Click on the Create Configuration as shown below.

Select the faas.json file from the command palate

Finally allow to execute the below command.

A configuration tree appears in the RUN CONFIGURATIONS view containing the run configurations that were created for the runnable objects. A new configuration is added to your launch.json file.

To run the configuration, select the configuration and choose the Run icon. Open the <<function_name>>.http file and you can send GET and POST Request to test if the functionality is working fine locally. You can also put a break point to check the flow.

Deploy on SAP Cloud Platform - Now that you have created a project having function and trigger, it needs to be deployed in SAP Cloud Platform for productive usage. Thankfully this also can be done directly from SAP Cloud Platform Business Application Studio.

As of now, building and deploying an MTA deployable directly from Project Context is yet to be done for SAP Cloud Platform serverless runtime. We need to do this using the Terminal feature of SAP Cloud Platform Business Application Studio.

The overall process of deploying on SAP Cloud Platform consists of two steps.

Connecting the Business Application Studio to the SAP Cloud Platform

Connect to the SCP Cloud Platform organization and space where you want to deploy the deploy-able.

With the right credentials, it allows to select the organization and the space. And you get an alert as below.

Deploying the deploy-able in the right SAP Cloud Platform space

To be able to deploy, we need to start a Terminal in Business Application Studio. Log in to the SAP Cloud Platform Extension Factory, serverless runtime CLI with following command.

Please make sure you have an SAP Cloud Platform Serverless Runtime instance with its service key created. After successful login, it will show the serverless instances available in the same space. Under BINDING heading is the service key name of the serverless instance.

Provide the service instance number which you want to use to deploy the created function project. Once successful log in is done, you can deploy the project to the selected service using following command.

After successful deploy, you can retrieve metadata, status information, and links to the project using the following command:

Congrats... Following the steps given above, you would have now been able to create a Function as a Service Project with a serverless runtime function. You can enhance your function logic to meet your business need and experience the magic. SAP Cloud Platform Serverless Runtime becomes quite powerful, when it is integrated with a service like SAP Cloud Platform Enterprise Messaging. It brings in a decoupled architectural essence, which definitely is one of the most important advantages of an Extension for which a serverless runtime is used. You can implement similar use cases from Business Application Studio.

In summary, you would have noticed, how easy the development process has become to develop a serverless runtime project and deploy the same in SAP Cloud Platform when you try to build it from SAP Business Application Studio.

So do enjoy working with SAP Business Application Studio and SAP Cloud Platform Serverless Runtime.

Do not hesitate to provide your feedback on the blog and of course do mention if any issue you face while following this blog.

Writing Function-as-a-Service [10]: Call protected endpoint across Subaccounts

2020-08-27T10:02:41+02:00

This blog is part of a series of tutorials explaining how to write serverless functions using the Functions-as-a-Service offering in SAP Cloud Platform Serverless Runtime

Quicklinks:
Quick Guide
Sample Code

Introduction

In the previous tutorial we‘ve learned how to call a service which is protected with OAuth and requires a scope.
The challenge was:
-> how can the function possess the scope?
The solution was:
-> configuration of both xs-security.json files

BUT:
There was a precondition:
-> both app and function have to live in the same subaccount

This is necessary because the central XSUAA of the subaccount creates one oauth-client for each instance and assigns the granted scope to the other client.
Thus, it has to resolve the names of the scope and involved clients
This is possible because the name of the scope is made unique and identifiable by adding the variable $XSAPPNAME to the scope name.
As we all know, the value of the variable is not just the same as the name of the property xsappname
The value of $XSAPPNAME is generated at runtime and contains some mystic suffix !t1234

OK.
Today we want to call from the function to a service which lives in a different subaccount.
So now, the XSUAA has to find not only the correct scope and oauth-client.
It has to find it in a different subaccount (identityzone)

How to do it?
-> communicate with the other central XSUAA

How to find that one?
-> By the unique identifier of the subaccount (identityzone)

As such, we have to add the subaccountID to the GRANT statement

And that’s already all for today

Nevertheless, let’s make it real

Overview

In this tutorial, we’re going to learn how to assign a scope to an application in a different subaccount

The scenario is almost the same as in the previous tutorial.
We can either re-use it and do the required little changes
Or create the project as described below, everything based on the previous blog

In the first part of this tutorial, we’re creating a very basic app which exposes an endpoint which is protected with OAuth and which requires a certain scope
In the second part, we’re creating a Function which tries to call that endpoint

Part 1: The Protected App
Create xsuaa, define scope
Create app, check scope

Part 2: The Calling Function
Create xsuaa, define authority
Create Function, do OAuth flow

Prerequisites

If you’re new to the topic, the previous tutorial is a prerequisite, along with all its prerequisites and blablabla

In addition:
To follow this tutorial, we need 2 different subaccounts.
In my example, I’m using my trial account, in addition to my FaaS-account (containing the instance of SAP Cloud Platform serverless runtime)
Limitation:
Both accounts have to live in the same data center (in my example, eu10)

Preparation: Create Project Structure

Same preparation like in previous blog: create files and folders

In addition:
We need to find the ID of the FaaS-subaccount.
It is easy to find: just open the subaccount in the cloud cockpit
Which subaccount?
We need the ID of the subaccount where the FaaS is located

Part 1: The Protected App

Almost same as part 1 of previous tutorial
Really only the xs-security.json file is little bit different

1.1. Security Configuration

This is the essential section of this tutorial:
Here we’re using the subaccount ID:
-> grant the scope to an oauth-client living in the specified subaccount

{

  "xsappname" : "xsappforsafeapp",

  "scopes": [{

      "name": "$XSAPPNAME.scopeformysafety",

      "grant-as-authority-to-apps" : [ "$XSAPPNAME(application, 12ab12ab-34cd-56ef-34cd-12ab12ab12ab, xsappforfaas)"]

  }]

}

Syntax:

"grant-as-authority-to-apps" : [ 

  "$XSAPPNAME(<service_plan>, <subaccount_id>, < xsappname_of_caller >)"

]

After clarifying the new security descriptor, we create an instance of XSUAA in our Trial account (or whatever account you’ve chosen)

We have to make sure that we're targeting the different account, e.g. trial
To change location:

cf t -o p123456trial

see:

OK, for your convenience, here's again the command to create a service instance:
In my example, we jump into C:\tmp_faas_callsafe\safeapp and run the following command

cf cs xsuaa application xsuaaforsafetyapp -c xs-security-safe.json

1.2. Create Application

No change needed to the app.
Just take the sample code (Part 1) from previous tutorial

1.3. Deploy and Run the App

Yapp, just deploy it to the different account.
No need to run it, we did it in the previous torture

1.4. Small Recap

We deploy a protected app to trial account.
We specify that the Function of FAC account is allowed to call us
So we add a statement to grant access to the calling xsapp
And here is the place to enter the ID of the FAC account

Part 2: The Calling Function

Again, all the same as in one of the other boring tutorials

2.1. Security Configuration

In part 1 we learned how to grant a scope to an xsuaa instance in a different subaccount
Now we’re on the receiving side: we receive the granted scope and we need to accept it
In the previous tutorial, we used the following statement:

"authorities":["$XSAPPNAME(application,xsappforsafeapp).scopeformysafety"]

Now we would need to make clear where to find that foreign xsapp
However, I haven’t found a way to add the subaccountID in this statement
OK, no prob.
-> we have to fall back to the generic statement:

"authorities":["$ACCEPT_GRANTED_AUTHORITIES"]

Using this statement, we accept all scopes granted by anybody to our app (xsapp, to be more precise)

So now we open the file xs-security-faas.json, in folder unsafefunction and enter the following content

{

  "xsappname" : "xsappforfaas",

  "tenant-mode" : "dedicated",

  "authorities":["$ACCEPT_GRANTED_AUTHORITIES"]

}

Note:
This statement doesn't apply only for different subaccounts, it can be used in any scenario

As usual. this JSON config can be used to create or update an instance of XSUAA.

Before executing a command, don't forget that this time, we have to make sure that we target the subaccount where FaaS is living

To create the XSUAA-instance for FaaS, we jump into the function folder unsafefunction then:

cf cs xsuaa application xsuaaforfaas -c xs-security-faas.json

And create a service key:

cf csk xsuaaforfaas servicekeyforfaas

BUT:
If you have the scenario in place, It is enough to update the existing service:

cf update-service xsuaaforfaas -c xs-security-faas.json

2.2. Create Function

All the same as in previous hands-on. It shouldn’t be necessary to do any change, register or deploy.
But it might be necessary to repeat steps, if the xsuaa instance was deleted, etc
Or to adapt the code, if the name of the protected app was changed in trial

Otherwise, we can just use the deployed function, if remaining from the previous blog

Or we create everything from scratch, based on the sample code Part 2

And then, finally, we invoke the function and are happy to see the same result which we had before
No shame to be happy:
We’ve learned the little trick which enables us to cross the borders of subaccounts

Summary

In this blog we’ve learned almost nothing
Just adding a cryptic guid in the middle of a cryptic statement
Luckily, the blog post hasn’t been too long…

Quick Guide

The protected app which is called by the Function has to grant the scope to the Function
If both are not located in the same subaccount, then the subaccountID of the Function has to be added (ID can be found in the cockpit)

xs-security.json of protected app:

"scopes": [{

      "name": "$XSAPPNAME.scopeformysafety",

      "grant-as-authority-to-apps" : [ 

         "$XSAPPNAME(application, 12345678-abcd-..., xsappforfaas)"

The calling Function has to accept the grant. In case of different subaccounts, the generic statement has to be used to accept all granted scopes

xs-security.json: of Function

"authorities":["$ACCEPT_GRANTED_AUTHORITIES"]

Links

Same as in previous tuutorial

Appendix: All Project Files

The whole project can be found in previous tutorial

However, we have to adjust the following files in both projects

Part 1: The Protected App

These files are located in the folder "safeapp"

xs-security-safe.json

{

  "xsappname" : "xsappforsafeapp",

  "tenant-mode" : "dedicated",

  "scopes": [{

      "name": "$XSAPPNAME.scopeformysafety",

      "grant-as-authority-to-apps" : [ 

         "$XSAPPNAME(application, 1a2b3c4d-0000-1111-aaaa-..., xsappforfaas)"

      ]

  }]

}

Part 2: The Calling Function

They are located in the folder "unsafefunction"

xs-security-faas.json

{

  "xsappname" : "xsappforfaas",

  "tenant-mode" : "dedicated",

  "authorities":["$ACCEPT_GRANTED_AUTHORITIES"]

}

The Evolution of SAP Cloud Platform Extension Factory into SAP Cloud Platform Extension Suite

2020-09-14T13:46:05+02:00

Note that this blog was published before our branding changes related to SAP technology announced in January 2021.

Where the story begins

When we first released the new concept of “SAP Cloud Platform Extension Factory”, our goal was to simplify the extension journey for our SAP customers. SAP Cloud Platform was and still is THE platform to build extensions for existing SAP applications. To improve that experience, we wanted to provide connectivity capabilities that would enable customers to easily and securely connect to the needed data sources, access APIs and events and manage those connections with an intuitive UI. Essentially, the goal of Extension Factory was to provide:

A standardized way to register SAP LoB solutions on SAP Cloud Platform

A central registry for registered solutions with their APIs, events, and credentials

One developer experience for applications built on the SAP Cloud Platform, regardless of the runtime

But as we soon realized, that was just the first step...

Where we are today

The SAP Cloud Platform Extension Suite not only includes everything outlined above, it also provides services, tools and low-code capabilities to help realize your extension use cases. The complete portfolio is available on the SAP Cloud Platform Discovery Center, but let’s break it down into 3 main pillars:

Digital Experience

Establish new, engaging and contextual multi-channel experiences to facilitate access to relevant data for both internal and external users. Enhance digital collaboration functionalities with intelligent technologies, like integrated chatbots to assist and guide users throughout their day. Create native mobile apps using our SAP Cloud Platform SDKs for Android and iOS.

Digital Process Automation

Digitalize and automate paper-based tasks and business processes to increase efficiency, empower the end user and allow your workforce to focus on value-adding tasks. Combine workflow capabilities with automation technologies to achieve your desired business result faster. Since Q2 2020, we offer live process content packages on the SAP API Business Hub to accelerate implementation of digital business processes.

Development Efficiency

Jumpstart or accelerate your project, from development through lifecycle management. Within this pillar you’ll find tools, services and APIs that can help you start building your application extension. For example,

Use our SAP Business Application Studio as your cloud-based IDE, complete with templates for mobile, workflow and UI development.

Implement important security concepts and develop secure applications with our Enterprise Security Services

Manage the lifecycle of your applications using our integrated DevOps portfolio.

Looking for deployment options? Choose the runtime that best fits your business requirements and skill set: Cloud Foundry Runtime on the Cloud Foundry environment, leverage Kubernetes-based technology with Kyma Runtime or Serverless Runtime. And of course, transform existing ABAP assets unlocking the full potential of ABAP in the cloud, a.k.a, the ABAP environment.

What comes next

We will continue to enhance the capabilities of our SAP Cloud Platform Integration and Extension Suites to cover more use cases. For information on what's to come, check out:

Introduction to SAP Cloud Platform Extension Suite (OpenSAP course)

SAP Cloud Platform Road Map

SAP Cloud Platform Discovery Center

Oh, and don’t be surprise if you stop seeing SAP Cloud Platform Extension Factory on slides, road maps or service names. For example, our runtime names, will no longer include “Extension Factory”. They’ll follow the regular service naming standards:

SAP Cloud Platform Cloud Foundry Runtime

SAP Cloud Platform Kyma Runtime

SAP Cloud Platform Serverless Runtime

In Summary, if you are looking for information on how SAP Cloud Platform can help you build and manage your extensions, look for SAP Cloud Platform Extension Suite and you’ll be in the right place.

SAP Cloud Platform [Extension Factory], serverless runtime | Function-as-a-Service | FaaS

2020-09-21T14:49:15+02:00

SAP Cloud Platform Extension Factory, serverless runtime

SAP Cloud Platform Serverless Runtime

SAP Cloud Platform Functions - Beta

Function-as-a-Service

FaaS

I'm confused...
What’s the difference?

To give a short answer: It’s all the same
(almost)
At the end, we can write some javascript code and it runs in a serverless environment

What is it, precisely?

It is a service offering in the SAP Cloud Platform, Cloud Foundry environment

But why that strange name?

While the name itself, Serverless Runtime, might still sound confusing, it makes more sense if we compare it to other “runtime” offerings in SAP Cloud Platform:

Application Runtime
The classic way of writing e.g. a java web application and deploying it to the cloud where it runs on classic java server with underlying JRE. The application developer takes care of operating and maintaining, etc.
Agree that these efforts are already less that in the even more classical onPrem world

Serverless Runtime
Here the developer doesn’t need to care about the runtime, meaning that he writes the code and the environment takes care about scaling etc just like it is expected of a serverless environment.
And, as expected, it causes cost only when running
This is the right choice for lightweight extensions, small portions of javascript code
It is nicely coupled with other offerings like Enterprise Messaging, Backend Service, OData Provisioning

Kyma Runtime
Bigger, more powerful, more flexible, more costly

While the Serverless Runtime is a "service" offering, it also provides a subscription-based tool:
The Extension Center

Nice, but where are the functions?

The screenshot helps us to understand:

The name "Serverless Runtime" is an umbrella for several capabilities that can be used to build serverless extensions.
Writing functions is only one of the capabilities, provided by "Serverless Runtime"
We don't see any "Function" in the Extension Center UI. Instead, a function project is called "Extension".

Why?

We understand that this is not a general worldwide FaaS technology product. Functions are meant to be part of a serverless extension scenario.
An extension scenario which is meant to be simple and still provides the possibility to write code.
And in fact: it is REALLY easy

Blablabla...

Really.
Try to imagine this example scenario:
Get notified about Backend changes with Enterprise Messaging
On every change, a Function is triggered
It can call an API with OData provisioning to get more details
The function can store data with Backend Service

Such a powerful extension scenario can be realized completely serverless, with few lines of code and little configuration
No local dev, no operation, no maintenance, no database trouble, no scaling headaches.
And at low cost, as everything has to be payed only when it does its work

OK, cool.
But what if the scenario grows and the offerings don't cover the required functionality?

In that case, the function can be easily and seamlessly migrated to Kyma

Sounds like a marketing slogan...

It can be easily proven:
Both Kyma and Functions have the same underlying technology (Kybernetes)

Cool, thanks

Cool, time to close the blog....

Ehmmm - didn't you forget anything?

Thank you for reading

Welcome. Missing info: which is the CORRECT name?

SAP Cloud Platform Serverless Runtime

Last question: how can we learn more?

This announcement blog gives an introduction and overview about Serverless Runtime
SAP Help Portal: Serverless Runtime official docu
Recommended series of tutorials which explain in detail how to implement functions

Thanks

Writing Function-as-a-Service [11]: How and Why access HTTP API

2020-10-15T09:57:49+02:00

This blog is part of a series of tutorials explaining how to write serverless functions using the Functions-as-a-Service offering in SAP Cloud Platform Serverless Runtime

Quicklinks:
Quick Guide
Sample Code

Introduction

In this blog we're talking about functions with HTTP trigger only. These are functions that are invoked with HTTP request.
In such scenarios, the function returns a value which ends up in the response body of the calling client (e.g. browser)
Sometimes, the function handler code needs more information that it gets from the FaaS runtime
Also, it may need to write custom info to the response

For these cases, the FaaS runtime allows access to the underlying native node.js HTTP API
For those of you who require such functionality, I’m providing a silly example, to make your life easier

First of all, 2 basic info that we have to understand:

In most cases, access to the underlying HTTP API is not needed.
As such, if we need it, we have to enable it
That’s done in faas.json, for each function definition

The underlying HTTP API is the standard node.js http module
As such, no special tutorial needed here, please refer to the standard documentation
Here: https://nodejs.org/api/http.html

And there’s one more basic info
We cannot mix both approaches
Either use the standard FaaS convenience methods OR use the HTTP API
With "FaaS convenience methods" I mean the following
Use return value to set the response:
return ‘Error, invalid function invocation’
Use convenience method to set the status
event.setUnauthorized()
With other words: if we want to add custom header to the response, we cannot use event.setUnauthorized() to set the status. We have to set the status with response.writeHead(400)

Overview

How to use HTTP API

Example use cases

Create sample function

Run sample function

Prerequisites

If you're new to Serverless Runtime, Function-as-a-Service, you should check out the overview of blogs and read all of them...

How to use HTTP API

First of all, the access to the API needs to be enabled.
This is done in a function definition in faas.json

"functions": {

   "function-with-httpapi": {

      "httpApi": true

Once enabled, the http property of event will be filled with request and response objects

module.exports = async function (event, context) {

    const request = event.http.request

    const response = event.http.response

The request object represents the class http.ClientRequest
and the response object the http.ServerResponse

And that's it about accessing the HTTP API

Example use cases

Now let's see why and how we might need to use it

A few example use cases where we need access to HTTP API:

HTTP method

Query parameters

Request Headers

Trigger name

Response Headers

Response Body

Response Status

HTTP method

Sometimes we need to know with which HTTP verb we've been invoked. For instance, if our function should distinguish between GET or POST, etc
We can throw an error, or react accordingly

const httpMethod = request.method

if (httpMethod != 'POST'){

    response.writeHead(405, {

        'Content-Type': 'text/plain',

        'Allow': 'POST'

    });

    response.write('Request failed. Method not allowed. See response headers for hint');

    response.end();

Query parameters

Query parameters are the params that can be added to a URL after the ?
Multiple parameters are appended with &
E.g.
xxxxx?customerName=otto&userid=123

They’re accessed via the query property

const name = event.http.request.query.customerName

It returns the value of the param

Request Headers

We can find the headers sent with the request in the headers property

request.headers

Trigger name

Two interesting headers are those provided by the FaaS runtime, giving info about the used trigger

const triggerName = request.headers['sap-faas-http-trigger-name']

const triggerPath = request.headers['sap-faas-http-trigger-path']

What is the difference?
/
Yes, the slash makes the path
In our example, the trigger name is customlogin and the path customlogin/

Response Headers

In case of response object, we're interested in modifying it.
For instance, we might want to send some additional information in the response header, as it might be required by the caller of our function
To add own headers to the response:

response.set('MyHeader', 'MyValue')



response.append('CustomHeader', 'CustomValue')

Alternatively, set multiple headers and status at once

response.writeHead(403, {

    'Content-Type': 'text/plain',

    'FailureHint': 'Authorization required, see docu'

});

Response Body

In most cases, we set the response body using the standard way in FaaS: as return value
However, we might need to switch to http API, due to requirements of caller who might need some custom text in the response body in case of failure, etc
If this is the case we can use standard way of http.ServerResponse class

response.write('Error. Don't ask admin. Don't see log for no info')

Note:
As mentioned, we cannot mix the used APIs.
If we set a header in the response, then we have to use this way of writing response

Response Status

There can be several reasons why we might wish to set the response status code.
For instance, if we don’t support all the HTTP methods, then we have to set the response status to 405, which means Method not allowed
Also, we might have special requirements to the incoming call, so we would have to decide on our own to set the status code to 400, Bad Request
Please see Links section for reference

Setting the response status code to a custom value can be again done in several ways

E.g. directly setting the property value:

response.statusCode = 405

Or again using the convenience method, where we can set a custom header at the same time:

response.writeHead(405, {

   'Content-Type': 'text/plain',

Create sample Function

To make things less theoretical, you can find here a reusable sample project, which is meant to showcase how the HTTP API can be used.
As usual, it is a small silly sample, without real use case, but focusing on demonstrating some capabilities for your convenience, so you can easily copy&paste and adapt for your own needs

Please refer to the Appendix for the full sample code

Note:
In case that it doesn’t suit your needs, you can send me a personal message

In this example, we’re simulating a kind of strange special login process for a customer app
The user of the function is required to pass a couple of pieces of login information:

Customer Name as query param
Customer Password as request header
Authorization scope as body in a POST request
As such, only POST is supported
In addition, our function simulates usage of multiple endpoints and only one of them is meant for productive usage with login
As such, the function code has to access request header to determine the used trigger

Code walkthrough

Our function does nothing than accessing the HTTP API and using it for some login-checks
In case of success, it does nothing, just return some silly text

Preparation

First we declare the usage of the HTTP API in faas.json

"functions": {

   "function-with-httpapi": {

      "httpApi": true

Then we can access the HTTP API in function code.
Otherwise, the object would be empty

const request = event.http.request

const response = event.http.response

Now, in our function, we can implement custom checks which wouldn't be possible without the HTTP API.
Our function contains 4 checks:

1. Check for correct HTTP verb:

const httpMethod = request.method

if (httpMethod != 'POST'){

    response.writeHead(405, {

        'Content-Type': 'text/plain',

        'Allow': 'POST'

    });

    response.write('Request failed. Method not allowed. See response headers for hint');

2. Check for desired productive endpoint

In faas.json we’ve defined 2 triggers.
The only reason for the second one (nologin) is to be able to run this check

const triggerName = request.headers['sap-faas-http-trigger-name']

if(triggerName != 'customlogin'){

    response.statusCode = 400

3. Check for authentication

Note that we don’t verify the customer name, only password – for the sake of simplicity
We need to access the request header

const customerAuth = request.headers['customer-auth']

if(! customerAuth){

    response.writeHead(401, {

        'Content-Type': 'text/plain',

        'FailureHint': 'Required: request header customer-auth containing customer password'

    });

4. Check scope

We use this to show how to access the request body

if((! request.body) || (JSON.parse(request.body).customerAccess != 'true')){

    response.writeHead(403, {

        'FailureHint': 'Authorization required...'

Success response

If the request has passed all checks, then we do nothing,
Just note that here we’re using the standard way of using a function:
The response body is sent as return value of the function
When I mentioned earlier that we cannot mix the HTTP API with standard API, I meant we cannot mix in one response definition. But here, in case of success, we don't do any custom header setting, etc, so we can just return a text

const customerName = request.query.customerName 

return `Function called successfully. Customer '${customerName}' is welcome.`

Run the sample Function

Let's deploy and run the sample action, to see our HTTP API implementation in action
After deploy, we want to see if your checks are executed properly and if we get the expected results in response body , status and header

➡️1. Wrong HTTP verb

In our first example, we choose to use a wrong HTTP method, to see our first check working

Request
URL	https://...faas.../customlogin/
Verb	GET
Header	-
Body	-
Response
Body	Error text
Status	405
Header	allow

See result:

➡️2. Wrong endpoint

Now we use the correct HTTP method, but the wrong trigger

Request
URL	https://...faas.../nologin/
Verb	POST
Header	-
Body	-
Response
Body	Error text
Status	400
Header	-

See result:

➡️3. Missing authentication

Next try: correct endpoint, but we don't send the required authentication data

Request
URL	https://...faas.../customlogin/
Verb	POST
Header	-
Body	-
Response
Body	Error text
Status	401
Header	failurehint

See result:

➡️4. Missing authorization

We send a request with mostly correct settings, only the scope, to be passed in the request body, is missing

Request
URL	https://...faas.../customlogin/
Verb	POST
Header	customer-auth : abc123
Body	-
Response
Body	Error text
Status	403
Header	failurehint

See result:

➡️5. Successful call

Finally we send a request with correct settings, including the name parameter in the URL

Request
URL	https://...faas.../customlogin/?customerName=otto
Verb	POST
Header	customer-auth : abc123
Body	{ "customerAccess" : "true" }
Response
Body	Success text
Status	200
Header	-

See result:

Summary

In this tutorial, we’ve learned which steps are required to access the HTTP API
This is probably not necessary in most use cases of serverless function
But sometimes it required, so we need to know how it works

We've learned that we need to enable it first in faas.json
Then we can access it via the event.http property
And we've understood that we can use the standard node.js http methods

Quick Guide

faas.json:

"my-function": {

   "httpApi": true

Function code:

const request = event.http.request

const response = event.http.response

Appendix: All Project Files

Here you can find the project files used for the sample, ready for copy&paste

faas.json

{

  "project": "httpapiproject",

  "version": "1",

  "runtime": "nodejs10",

  "library": "./src",

  "functions": {

    "function-with-httpapi": {

      "module": "mymodule.js",

      "httpApi": true

    }

  },

  "triggers": {

    "customlogin": {

      "type": "HTTP",

      "function": "function-with-httpapi"

    },

    "nologin": {

      "type": "HTTP",

      "function": "function-with-httpapi"

    }

  }

}

package.json

Adding dev dependency for local testing

{

  "devDependencies": {

    "@sap/faas": ">=0.7.0"

  }

}

mymodule.js

module.exports = async function (event, context) {



    // to access HTTP API, add param to function definition in faas.json: "httpApi": true

	const request = event.http.request

	const response = event.http.response

    

    // check request method

    const httpMethod = request.method

    if (httpMethod != 'POST'){

        response.writeHead(405, {

            'Content-Type': 'text/plain',

            'Allow': 'POST'

        });

        response.write('Request failed. Method not allowed. See response headers for hint');

        response.end();

        return

    }



	// check which HTTP trigger was used

    const triggerName = request.headers['sap-faas-http-trigger-name']

    if(triggerName != 'customlogin'){

        response.statusCode = 400

        response.write("Endpoint not supported. Use 'customlogin' endpoint")

        response.end();

        return

    }



	// check authentication via request header

    const customerAuth = request.headers['customer-auth']

    if(! customerAuth){

        response.writeHead(401, {

            'Content-Type': 'text/plain',

            'FailureHint': 'Required: request header customer-auth containing customer password'

        });

        response.write('Request failed. Unauthorized. Customer login data missing. See hint for more info');

        response.end();

        return

    }



    // check authorization via request body 

    if((! request.body) || (JSON.parse(request.body).customerAccess != 'true')){

        response.writeHead(403, {

            'Content-Type': 'text/plain',

            'FailureHint': 'Authorization for customer required: Request body with customer JSON access must be true'

        });

        response.write('Request failed. Forbidden. Customer authorization not sufficient. See hint for more info');

        response.end();

        return    

    }



    // use standard way of writing response

    const customerName = request.query.customerName 

    return `Function called successfully. Customer '${customerName}' is welcome.`

};

Writing Function-as-a-Service [13]: Secure scenario with scope and consumer

2020-10-29T15:06:37+01:00

This blog is part of a series of tutorials explaining how to write serverless functions using the Functions-as-a-Service offering in SAP Cloud Platform Serverless Runtime

Quicklinks:
Quick Guide
Sample Code

Introduction

In the previous blog we’ve learned the basics about protecting a function with OAuth
What we didn’t learn: our function didn’t require a scope
In this blog, let’s learn how to enforce a scope in the JWT token and
- assign the scope to our user and call the function (REST client)
- call the function from a client application (node.js)

Overview

Small recap:
In the previous tutorial, we’ve created a very silly small function and we’ve used framework functionality to protect it with small configuration snippet.
Furthermore, we created a very basic instance of XSUAA and connect the function to it
That was enough to protect our function with OAuth 2.0
The FaaS Runtime took care of rejecting HTTP requests which didn't send a valid JWT token
The FaaS Runtime used the connected XSUAA instance for validation
That was OK.
Fair enough for the beginning
Now, in today's tutorial we’re going to
- add a scope
- and in the function we check if the scope exists in the JWT

These are the steps we're going to cover:

Create XSUAA

Create Function
Implement scope check

Call Function in user centric scenario

Call Function with client app

Prerequisites

Basic understanding of OAuth, see easy intro and description for using REST client

Previous blog

HTTP API blog post

1. Create Instance of XSUAA

We need an instance of XSUAA which is configured with a scope
We can update the existing one, or create a new one
In my example, I create a new instance with the following security configuration in a file called xs-security_faas_scope.json

{

  "xsappname" : "xsappforfaaswithscope",

  "tenant-mode" : "dedicated",

  "scopes": [

    {

      "name": "$XSAPPNAME.scopeforfunction",

      "description": "Scope required for accessing function"

    }

  ],

  "role-templates": [ { 

    "name"                : "FunctionRoleTemplate", 

    "description"         : "Role for serverless function", 

    "default-role-name"   : "RoleForFunction",

    "scope-references"    : ["$XSAPPNAME.scopeforfunction"]

  }],

  "authorities":["$XSAPPNAME.scopeforfunction"]

}

Explanation:

scopes
We define a scope.
For us, thie means: when calling the function, a JWT token is not enough. The caller must have the scope. If yes, the scope is contained in the token
However, in the security configuration we only define the scope, such that XSUAA knows about it
If things go well (see below) XSUAA will issue a JWT token that contains the scope
However, XSUAA doesn't enforce the scope.

role-templates
A scope is nothing that can be assigned to a human user. For that, we need to define a “role”, along with “role-template”. That can be found in the Cloud Cockpit and an admin can assign the role to users

authorities
This attribute is meant for non-human users, for client apps, in a client-credentials scenario
With this statement, we accept that scope. A client application bound to XSUAA will get the scope in the JWT token

Create XSUAA

We create an instance of XSUAA and we use above JSON parameters
Can be done in the Cloud Cockpit, or on command line:

cf cs xsuaa application xsuaa_faas_scope -c xs-security_faas_scope.json

Create Service Key

As usual, we need a service key in order to reference it from FaaS and also from REST client (see below)

cf csk xsuaa_faas_scope xsuaa_faasscope_servicekey

See Appendix for all commands

2. Create Function

After creating an instance of XSUAA service, we need to register it in FaaS, and use it in the function definition.
We’ve learned that in a previous tutorial

Register the service in faas

For your convenience, find here the necessary commands

Always need to login first to Cloud Foundry and/or FaaS client

xfsrt-cli login

The convenient command to register a service interactively (the command line client will propose existing services, so we can choose. Precondition: only service instances with service key are proposed)

xfsrt-cli faas service register

After registration, in the console, we get the info which we need to specify in faas.json:
the service key and the GUID of the service instance

Use the service in FaaS project

faas.json

    "services": {

        "xsuaa-with-scope": {

            "type": "xsuaa",

            "instance": "<your GUID of service instance>",

            "key": "xsuaa_faasscope_servicekey"         

        }

    }

See Appendix for full faas.json

Configure Security

As learned in previous blog post, with below setting, we tell the FaaS runtime that we want them to enforce a valid JWT token

"triggers": {

   "prot": {

      "type": "HTTP",

         "function": "prot-func-with-scope",

            "auth": {

               "type": "xsuaa",

               "service": "xsuaa-with-scope"

Enforce scope

As mentioned earlier: the above setting will have the following consequence:

Whenever our function is called with HTTP trigger, the request must contain a valid JWT token
Otherwise the call is rejected by the FaaS runtime (with proper status code and error message) and our function code is not even invoked.

As such, the FaaS runtime enforces the authentication.
But it cannot take care of authorization in a generic way

For example, a function might have the following logic:
If EDIT scope is available, the function may accept POST requests, otherwise only GET
Such logic has to be implemented manually by us

We have to look into the JWT token, read the available scopes and check if the one which we require, is there.
The framework offers a convenience method which decodes the JWT token (if available)
We can then access the JWT payload as JSON object

const jwtToken = event.decodeJsonWebToken()

const jwtScopes = jwtToken.payload.scope

In order to check the scope, we need to know the exact scope name.
Background:

We defined the scope name as
$XSAPPNAME.scopeforfunction
The value of the variable $XSAPPNAME is generated on the cloud platform, as such we have to ask at runtime for the exact value.
The exact value is contained in the service key
And the service key is registered in FaaS
As such, we can ask FaaS for the xsuaa service
Then access the xsappname property

const xsuaaCredentials = await context.getServiceCredentialsJSON('xsuaa-with-scope')

const requiredScope = xsuaaCredentials.xsappname + '.scopeforfunction'

Based on above 2 code snippets we have the needed information:
Which scope do we expect (for whatever business case)
Which scope is contained in the JWT token

In our example, we require a scope for calling the function.
To check if the scope is sent, we just look into the array of available scopes
If not available, we reject the request.
In our case, the correct status code is 403, because use is authenticated, but lacking authorization
In order to set the status, we need to use the HTTP API (see previous blog post)

Below snippet puts the snippets together:

const xsuaaCredentials = await context.getServiceCredentialsJSON('xsuaa-with-scope')

const requiredScope = xsuaaCredentials.xsappname + '.scopeforfunction'



// read the JWT token and check required scope

const jwtToken = event.decodeJsonWebToken()

const jwtScopes = jwtToken.payload.scope

if(! jwtScopes.includes(requiredScope)){

   // fail with 403       

   const response = event.http.response // must be enabled in faas.json

   response.writeHead(403, {

   ...

See Appendix for full sample code

Note:
Before using the HTTP API, it must be enabled, which is done in the faas.json

Note:
SAP provides security libraries and there’s a little helper function, recommended to use for the scope check
The function I’m talking about:
@Sap/xssec: checkScope(scope)
Please refer to Links section
In my examples, I’d like to keep the code free from dependencies (as there might be changes, etc), so I’m not using it. Please forgive
But for your convenience, I've created little sample code based on the library. See Appendix

Deploy function

To deploy the function, you might find this command useful (run from project directory)
xfsrt-cli faas project deploy

3. Call function in user centric scenario

After deploy, we want to test the security of our function

If we call the function in browser –> error
Reason: no JWT token at all

If we call the function in REST client with OAuth flow –> error
Reason: JWT token available, but doesn't contain the required scope

Solution: To call the function we need to assign the required role to our user

The Role

In Cloud Foundry, authorization is controlled by means of Role Based Access Control (RBAC)
In the first step, we created an instance of XSUAA, based on a security configuration which defined a scope and a role-template.
After creating our instance of XSUAA, our role-definition has been added to the list of roles in the cockpit.
We can view it there

But viewing is not enough, we have to add the role to our user.

Assign Role to User

First, we create a new Role Collection, dedicated for your function
In the Cockpit, go to your subaccount->Security-> Role Collections

Second, we have to add the desired role to the new Role Collection
So we “edit” the new role collection and add our new role
Then press “save”

Third, we need to add our Role Collection to the Identity Provider (IDP)
Go to menu entry Trust Configuration
Click on default IDP
Enter the E-Mail Address of your user
Click “show Assignments”
Then “Assign Role Collection”

Test the function with human user

Now that our user has the required role, we can call the function
We don’t have a user interface in our scenario, so we use a REST client
See here for a detailed description about how to call an OAuth protected endpoint with REST client

Short description:
1. fetch a JWT token
2. Use token when calling our function

In my example, I’m using Postman which helps to do both steps in one request
To configure postman request, we need to view the service key of our xsuaa instance which we created above
To view the service key, we can use the following command (alternatively, use cockpit)

cf service-key xsuaa_faas_scope xsuaa_faasscope_servicekey

Back in Postman, we have to configure the request as follows

Method: GET
URL: The endpoint of our function, we get the info during deploy, or with xfsrt-cli faas project get
e.g. https://...-faas.....functions.xfs.cloud.sap/prot/
Don’t forget the slash at the end

Authorization: Oauth 2.0
Access Token:
press "Get new Access Token"
"Get Access Token" Dialog:
Grant Type: Password Credentials
Access Token URL: we copy the “url” property from the service key and append /oauth/token
Example: https://<subaccount>.authentication.....hana.ondemand.com/oauth/token
Username: <your cloud user>
Password: <your cloud user password>
Client ID: copy the value of property clientid from service key
Client Secret: copy the value of property clientsecret from service key
Client Authentication: choose "Send as Basic Auth header"

Then press “Request Token” on the dialog
After getting the token response, press “Use Token”
Then, back in the main Postman window, press “Send” to send the request to the Function endpoint

As a result, we get our success message, which proves that the scope was included in the JWT token

Now we want to do the negative test, to check our function implementation works correctly and if the correct status code is sent
To do so, we have to remove the role from our user.
We can simply unassign the role collection in the "Trust Configuration"
Afterwards, we need to fetch a new JWT token via “Get New Access Token”
Then send the request again to call the function without scope

The result is 403, as coded by us, and the response message shows that the scope is not contained in the JWT token

Note:
In this scenario, we’re using only one instance of XSUAA
The function uses an instance of XSUAA to protect its endpoint
The user who calls the function, uses the same ClientID to call the function
This is OK, because we as developers of the function trust our user
In case that 2 instances of XSUAA are required, please refer to this blog for more information

4. Call function in client credentials scenario

Now we want to call the protected function from an application
Again, we’re using only one instance of XSUAA.
We bind our application to the same instance which is used to protect the function
(Sure, in a future blog, we’ll describe a scenario with different XSUAA instances)

In client credentials scenario, we may wonder: how to assign the required scope to the calling app?
We cannot assign it in the cockpit like we did for our (human) user.
To answer this question, somebody wrote this useful blog post

Our example is a bit different from above blog post, because both the function and the client app are "bound" to the same instance of XSUAA
The solution in our example:
When creating an instance of XSUAA, we defined a parameter called authorities
This is interesting and might be a new learning for us:
The function is attached to the XSUAA instance and the client app is bound to the same instance
As such, we would expect that the xsuaa instance (== OAuth client) trusts itself, because it is the same instance
In fact, trust is there. But the scope is not automatically there
In a client-credentials scenario, the scope must be explicitly granted, just like we assign a role to a user
To assign the scope to the client itself, no “grant” statement is required, but the authorities statement is necessary
This statement declares: our application wants to take the scope

"authorities":["$XSAPPNAME.scopeforfunction"]

Create Client app

The only intention of our app is to call the function – and to send a JWT token which contains the required scope
Well... we’ve just learned how to get the required scope into the JWT token
Nothing special needs to be done in the app code
Just fetch a JWT token and then call the function
So we can skip explanations.
We can go ahead and copy the code from the Appendix

Note:
Don’t forget to replace the FUNC_HOST URL with the URL of your function

Note:
You might need to change the app name in the manifest.yml

Then deploy the clientapp with cf push
Finally, invoke the endpoint of our function caller app and hope to get a success message
http://functioncallerapp.cfapps.sap.hana.ondemand.com/call

To test the negative scenario, we have to remove the authorities statement from our xs-security_faas_scope.json file and then execute an update-service command in Cloud Foundry

cf update-service xsuaa_faas_scope -c xs-security_faas_scope.json

Note:
Instead of deleting the “authorities” statement, we can invalidate it by changing the name of the scope to anything non-existing
e.g.
"authorities":["$XSAPPNAME.scopeforfunctionXX"]

In fact, after running update-service, we can invoke our endpoint again and we get the expected error message:
It says that the function responded with 403, which was expected

Summary

We’ve learned that the FaaS runtime uses XSUAA for token validation, there’s no automatic check of available scopes
To manually check the available scopes, we can access the decoded JW T token
We need to access the scope prefix from xsuaa service key
In client-credentials scenario, we need to use the authorities statement to assign the scope to ourselves

Quick Guide

Few Code snippets

// access registered xsuaa service in order to get the value of variable $XSAPPNAME

const xsuaaCredentials = await context.getServiceCredentialsJSON('xsuaa-with-scope')

const requiredScope = xsuaaCredentials.xsappname + '.scopeforfunction'



// the decoded JWT token

const jwtTokenDecoded = event.decodeJsonWebToken()



// the raw JWT token

const jwtTokenRaw = event.auth.credentials

Appendix 1: Console Commands

cf cs xsuaa application xsuaa_faas_scope -c xs-security_faas_scope.json

cf csk xsuaa_faas_scope xsuaa_faasscope_servicekey
cf service-key xsuaa_client xsuaa_client_servicekey

cf update-service xsuaa_faas_scope -c xs-security_faas_scope.json

xfsrt-cli login

xfsrt-cli faas service register

xfsrt-cli faas project deploy

xfsrt-cli faas project get

xfsrt-cli faas project logs

Appendix 2: All sample project files

For your convenience, I'm pasting the structure of my example project.
Folder names can be changed

Protected Function

These are the files required for the function
They are located in the function project folder, with "lib" subfolder

xs-security_faas_scope.json

{

  "xsappname" : "xsappforfaaswithscope",

  "tenant-mode" : "dedicated",

  "scopes": [

    {

      "name": "$XSAPPNAME.scopeforfunction",

      "description": "Scope required for accessing function"

    }

  ],

  "role-templates": [ { 

    "name"                : "FunctionRoleTemplate", 

    "description"         : "Role for serverless function", 

    "default-role-name"   : "RoleForFunction",

    "scope-references"    : ["$XSAPPNAME.scopeforfunction"]

  }],

  "authorities":["$XSAPPNAME.scopeforfunction"]

}

faas.json

{

	"project": "protectedwithscope",

	"version": "0.0.1",

	"runtime": "nodejs10",

	"library": "./lib",

    "functions": {

        "prot-func-with-scope": {

			"module": "functionImpl.js",

			"httpApi": true,

			"services": ["xsuaa-with-scope"]

        }

    },

    "triggers": {

        "prot": {

            "type": "HTTP",

            "function": "prot-func-with-scope",

			"auth": {

				"type": "xsuaa",

				"service": "xsuaa-with-scope"

			}			

		}

	},

	"services": {

	    "xsuaa-with-scope": {

			"type": "xsuaa",

			"instance": "d8819eda-41e6-40b0-9286-0afa1a59d12c",

			"key": "xsuaa_faasscope_servicekey"			

		}

	}

}

package.json

{}

functionImpl.js

module.exports = async function (event, context) {  	

	// access registered xsuaa service in order to get the value of variable $XSAPPNAME

	const xsuaaCredentials = await context.getServiceCredentialsJSON('xsuaa-with-scope')

	const requiredScope = xsuaaCredentials.xsappname + '.scopeforfunction'



	// read the JWT token and check required scope

	const jwtToken = event.decodeJsonWebToken()

	const jwtScopes = jwtToken.payload.scope

	if(! jwtScopes.includes(requiredScope)){

		// HTTP API required for configuring response

		const response = event.http.response // must be enabled in faas.json

		response.writeHead(403, {

			'Content-Type': 'text/plain'

		});

		response.write(`Unauthorized: required scope '${requiredScope}' not found in JWT. Availbale scopes: '${jwtScopes}' ;-(`);

		response.end();

	} else{

		return `Reached protected function. Scope check successful: required scope '${requiredScope}' found in JWT. Availbale scopes: '${jwtScopes}'`

	}

}

Function Caller Client App

These are the files required for a little node.js app which calls the protected function
Make sure to adapt the URL of the function in the application code

manifest.yml

The application is bound to the same instance of XSUAA which we registered in FaaS

---

applications:

- name: functioncallerapp

  memory: 128M

  buildpacks:

    - nodejs_buildpack

  services:

    - xsuaa_faas_scope

server.js

const express = require('express')

const app = express()

const https = require('https');



const VCAP_SERVICES = JSON.parse(process.env.VCAP_SERVICES)

const CREDENTIALS = VCAP_SERVICES.xsuaa[0].credentials

//oauth

const CLIENTID = CREDENTIALS.clientid; 

const SECRET = CREDENTIALS.clientsecret;

const OAUTH_HOST = CREDENTIALS.url;



const FUNC_HOST = 'https://abcd1234-...-...-faas-...-functions.xfs.cloud.sap' // adapt URL

const FUNC_TRIGGER = 'prot'





app.get('/call', function(req, res){       

   // call function endpoint 

   doCallEndpoint(FUNC_HOST, FUNC_TRIGGER, OAUTH_HOST, CLIENTID, SECRET)

   .then((response)=>{

      res.status(202).send('Successfully called remote endpoint. Function response: ' + response);

   }).catch((error)=>{

      res.status(500).send(`Error while calling remote endpoint: ${error} `);

   })

});





// helper method to call the endpoint

const doCallEndpoint = function(host, endpoint, token_uri, client_id, client_secret){

   return new Promise((resolve, reject) => {

      return fetchJwtToken(token_uri, client_id, client_secret)

         .then((jwtToken) => {

            const options = {

               host: host.replace('https://', ''),

              path:  `/${endpoint}/`,

               method: 'GET',

               headers: {

                  Authorization: 'Bearer ' + jwtToken

               }

            }

            

            const req = https.request(options, (res) => {

               res.setEncoding('utf8')

               const status = res.statusCode 

               const statusMessage = res.statusMessage               

               let response = ''

               res.on('data', chunk => {

                  response += chunk

                })

                

               res.on('end', () => {

                  if (status !== 200 && status !== 201) {

                     return reject(new Error(`Failed to call function. Message: ${status} - ${statusMessage} - ${response}`))

                  }

                  resolve(response)

               })

            

            });

            

            req.on('error', (error) => {

               return reject({error: error})

            });

         

            req.write('done')

            req.end()   

      })

      .catch((error) => {

         reject(error)

      })

   })

}



// jwt token required for calling REST api

const fetchJwtToken = function(token_uri, client_id, client_secret) {

   return new Promise ((resolve, reject) => {

      const options = {

         host:  token_uri.replace('https://', ''),

         path: '/oauth/token?grant_type=client_credentials&response_type=token',

         // path: '?grant_type=client_credentials&response_type=token',

         headers: {

            Authorization: "Basic " + Buffer.from(client_id + ':' + client_secret).toString("base64")

         }

      }



      https.get(options, res => {

         res.setEncoding('utf8')

         let response = ''

         res.on('data', chunk => {

           response += chunk

         })



         res.on('end', () => {

            try {

               const jwtToken = JSON.parse(response).access_token                

               resolve(jwtToken)

            } catch (error) {

               return reject(new Error('Error while fetching JWT token'))               

            }

         })

      })

      .on("error", (error) => {

         return reject({error: error})

      });

   })   

}



// Start server

app.listen(process.env.PORT || 8080, ()=>{})

package.json

{

  "dependencies": {

    "express": "^4.16.3"

  }

}

Appendix 3: Sample code using @Sap/xssec

package.json

{

    "dependencies": {

        "@sap/xssec": "latest"

    }

}

functionImpl.js

const xssec = require('@sap/xssec')

const util = require('util');

const createSecurityContext = util.promisify(xssec.createSecurityContext);



module.exports = async function (event, context) {  	

	// access registered xsuaa service in order to get the value of variable $XSAPPNAME

	const xsuaaCredentials = await context.getServiceCredentialsJSON('xsuaa-with-scope')

	const requiredScope = xsuaaCredentials.xsappname + '.scopeforfunction'



	const jwtTokenRaw = event.auth.credentials

	const securityContext = await createSecurityContext(jwtTokenRaw, xsuaaCredentials)

	const jwtScopes = securityContext.getTokenInfo().getPayload().scope



	if(! securityContext.checkScope(requiredScope)){

		// HTTP API required for configuring response

		const response = event.http.response // must be enabled in faas.json

		response.writeHead(403, {

			'Content-Type': 'text/plain'

		});

		response.write(`Unauthorized: required scope '${requiredScope}' not found in JWT. Availbale scopes: '${jwtScopes}'`);

		response.end();

	} else{

		return `Reached protected function. Scope check successful: required scope found in JWT. All availbale scopes: '${jwtScopes}'`

	}

}

6 Months using serverless (FaaS) environment on BTP - My Review

2021-03-30T14:01:58+02:00

Introduction

I am a big fan trying to keep things as simple as possible. This is sometimes fighting against my philosophy as a developer but having the history and experience of doing operations in my mind, I was happy all the time if I did not have to read 5.000 lines of code before understanding what's going on. Moving from the onPremise world to the Cloud and therefore to BTP, it was my personal aim to implement in a microservice approach as much as possible.

Therefore I was quite happy as I saw the announcements about the serverless service on BTP (previously known as 'Extension Center'), giving me the opportunity to have an easy entry to the world of Function-as-a-Service (FaaS) on the BTP.

This blog post will provide my experience I did collect the last 6 months using serverless service on the Cloud Foundry environment, provide you some use-case ideas and background knowledge, but also show up the nuts and bolts of this service.

What's serverless-service and FaaS?

Function-as-a-Service is providing you a function as a service. Yes, it's the easiest way to explain it. The combination of the runtime and environment is missing in this description. So let's say it's a function we do deploy to a kubernetes cluster (K8s) who is running this function and waiting for someone who is going to call / consume this function. We do only pay per usage. So if nothing is happening and no one is using it, we do not need to pay for the container.

The function is sleeping in a fluffy cloudy container and only when it is needed, it wakes up and does something
And the good news:
A sleeping function doesn’t cause cost

# carlos.roggan

Check out this wonderful blog post series about more background details and your first hands-on with the serverless services. Thx for this good job, Carlos.

How is it working?

In a nutshell: You're setting up your own nodeJS application, define a trigger and additional configs in a separate config file (faas.json) and you're ready to deploy to the K8s instance. Therefore you're going to use a specific xfsrt-cli and you'll get the defined trigger endpoint back from the cli. Otherwise you can use the frontend to check the endpoint link, define secrets and have a look into the log.

My use cases

My clients project is going to do a digital transformation for their R/3 landscape to a S/4 HANA Public Cloud solution. A lot of process-gaps or custom UIs were implemented on the BTP to fulfill the transformation. For environment specific operations I searched for an easy approach to host microservices and get rid of containers around it, I need to document and to take care of. One important point you need to think about are runtime-costs (check Pro and Cons chapter).

Use case FaaS001 - Set up IAS user

On BTP we're using a lot of different services and I've sometimes the feeling that I am belonging to the glamour team of "first-customers" with some of them. Therefore we often do open OSS Incidents belonging to BTP services. Most of the time, SAP is requesting access to the cockpit / service-instance. I implemented a FaaS microservice to provide the ability to create a new IAS user on the IAS tenant, following a naming convention we defined first and assigning required rules.

The FaaS001 is the actual endpoint for some kind of 'user self service' where a developer can request such a 'OSS IAS User' with the required IAS-Groups.

This approach is required as the IAS-SCIM-API (connected through a destination-service-instance) is to powerful to provide it directly to a UI5 application and the naming convention and security aspects (like a random password with numbers, special characters and so on) are easier to maintain and control.

Use case FaaS002 - Deactivate IAS user

After generating users for the OSS support, we also want to check on these users and deactivate the users after 7 days automatically. So the next FaaS I did implement is doing exactly that. The endpoint published by FaaS002 is getting called by a Job Scheduler service instance.

Developer pro-tip:

Both FaaS microservices communicate with me (and the authority team) via the Alert Notification Service. I'll get notifications for everything that is happening immediately. Something similar I also did with APIM, check here. So this message I do receive via Google Chat every morning at 00:59 (job planned time).

Use case FaaS003 - Workflow checker

We're using a lot of workflow instances on our BTP. Unfortunately sometimes they crash if the developer did not check his code or the endpoint isn't there at runtime. I want to inform us developers about these circumstances so we can check the workflow instances and restart it, if necessary.

The Job Scheduler is calling every 20 minutes this microservice, who is using the workflow API to fetch workflow-instances in state "FAILURE". For every entry FaaS is sending a message via the Alert Notification Service to the developer Google Chat group.

Pro and Cons I did discover

PRO

Runtime-Costs: Instead of paying memory for deployed containers on the Cloud Foundry environment, we do only pay per usage of this microservice. This could be useful for functions getting called twice a day by a Job-Scheduler service but maybe expensive for 'wbs element checker invoked by a time-recording ui5 application' within 25.000 calls a day.

There is "more less to care about". I mean, yes, deploying to Cloud Foundry is already easy and my responsibility outside the container is already low. But here it's just about 1 service instance. That's it. More less is impossible (!?).

Easy handling. I like the xfsrt-cli and the approach, how to deploy FaaS projects to the serverless instance. We also managed to do this via an Azure DevOps pipeline within some minutes, so it's deploying now automatically.

It's stable. Within the last 6 months, there were no service-interruptions, key changes or anything else we had to deal with (beside the renaming)

CON

Per serverless instance, there are only 5 projects allowed. Each project can contain up to 5 functions, so we can have 5x5 = 25 functions up and running on one serverless instance

The maximum number of service instances allowed for a subaccount is 1. So 25 is the final sum of possible functions on our subaccount. Why, SAP? Are you afraid of earning money with this service???

Limitation continues; the maximum size of source code per project is 50mb. This sounds enough, but as soon as you're starting using modules from npm like suggested, this 50mb can be achieved very fast!

Bindings to service instances (beside XSUAA) isn't supported. You'll need to add your secrets (e.g. for your destination service instance) to your faas-secrets.

Logs. The logs are visible to you via the Extension-Center-UI and the xfsrt-cli. Fine! But there is no way to forward these log entries to Kibana / Cloud Foundry application logging service.

No HANA client usage possible. We wanted to connect a FaaS with an AMQP trigger, related to Enterprise Messaging Service, and generate something on a HANA database. Unfortunately, beside the missing bindings, the library would be too big to use it here.

Updates. I am sitting on the customer site, but it feels like there is some kind of silence on the "What's New Section" for serverless. Does this have future? Do I smell a new 'Deprecated soon' flag coming up?

Recommendation

Serverless is a nice service and opportunity on the BTP, providing microservice capabilities as easy as possible. Saving money included. But as soon as your requirements are involving something like a HANA database connection, you're out. So try to know your requirements first (I know, this is tough in times where we do agile-requirements) and set yourself a limit of coding-lines and complexity for a FaaS. Think about the usage / hits for your endpoint. Will this getting called twice a day? 1000 times? 500k times?

Size, complexity, hits per day. These are the 3 dimensions you need to know before starting with serverless (from my point of view).

I'd like to tell you my limits I set for my decision matrix:

Size: 500 lines of code (of course, 50mb with all modules :D)

Complexity: maximum 2/5 (that means for me, doing some request-promise calls, checking and formatting, transformation of in/out objects)

Hits per day: 5000 (equals 0.1 capacity unit)

Check the Cloud estimator tool to see, what 1 capacity unit does cost for you.

Conclusion

Serverless is the great entrance to the world of kubernetes and serverless hosted apps. It's not the solution for every application but it's an easy approach for nodeJS microservices and it's worth it, spending some time and energy into it. Thinking about productive scenarios and the real usage in customer projects, it completely depends on the use cases and the size. These kind of limitations existing for this service are following the feeling, that the service could be deprecated soon and the successor will be Kyma.

All screenshots and pictures made, designed and captured by myself.

Practical Guide to Clean Core Custom development for S4 HANA

2021-06-04T14:16:11+02:00

Objective

Objective of this blog is to help understand the need for buzz word "Clean Core", how to approach it and review the technical options available.

Why CLEAN CORE?

In this digital world, organizations have many challenges for a sustainable growth with heavy competition, budget constraints and many others. Bi-Model IT practice helped some of them to pivot their business model and enrich even during COVID times. SAP is a vast ERP solution available with many industry specific modules. In addition to the out-of-the-box standard processes available, many customers have developed their own secret sauce by building custom objects inside the system with ABAP development. So, with the Brownfield projects, where Customers are planning to migrate from ECC to S4 HANA, there are many challenges to overcome from the Business value perspective as well from Technical. Some of them are like their custom code is tightly coupled up with standard SAP, increased complexity with continuous changes to the solutions, maintainability, extensibility, and user friendliness. In addition, it is important that IT executives and Business Leaders think about the long-term strategy, rather than considering a system upgrade. To overcome the custom code mess, the buzz word CLEAN CORE, heard several times in many conferences and meetings will help address the pain points.

CLEAN CORE is nothing but decoupling and implementing the custom code secret sauce solution with minimal dependencies with S4/ECC solution. It gives opportunity to simplify the SAP upgrade processes in future, reduces upgrade timelines, enables easier extensibility, simplifies maintainability and deployment process following the best practices. In addition, gives a new opportunity for the customers to re-evaluate and re-think about the existing process like:

Whether it can sustain for the existing needs and solve business pain points

Can this process provide us the flexibility to operate in the modern digital economy?

Can any part of the process be replaced by Software-as-a-service products?

What additional benefits could be gained if we open the doors to new technologies like AI, Machine Learning?

Where would you like to see your organization 10 years from now?

CLEAN CORE methodology

Achieving pure CLEAN CORE is a hard challenge for any enterprise which has many custom-code enabled business processes. The objective of this blogs helps to brainstorm different aspects and setup foundation with different methodologies that are potentially available.

Define Drivers

Analyze current state

Identify suitable implementation options

Define roadmap

We will discuss about these steps in detail in further sections of the blog

Define Drivers

Customer priority is the biggest driver behind the scenes for enabling the clean core. Identifying customer priorities is the first step which kicks off the discussion between multiple user personas/actors like IT Executives, Architects, Business users and developers. We could broadly classify the priorities into 6 groups.

Cost of ownership
1. Licensing costs
2. Hardware costs
3. Scalability

Cost of maintenance
1. Defect leakage
2. Separate support team for issues, SLO, too many issues
3. Upgrades

Architecture Goals
1. Need to break down monoliths into microservice architecture
2. CI/CD pipeline need to be implemented
3. Alignment with AOM model for continuous delivery of new features
4. S/4 HANA simplification

Business Needs
1. Business pain points
2. UX issues
3. Technology issues like faster response time/access
4. Insufficient or missing functionality in our current process

Team needs
1. Current team’s skill set does not align
2. Product too big for team to maintain
3. Team should be able to maintain all aspects of the solution

Timeline
1. Timeline restrictions for continuous delivery
2. S/4 HANA upgrade timeline alignment - there might be couple of years in your roadmap to get into S/4

Once the sequence of the priority for this initiative is identified, it sets a path to think about the implementation strategies and brainstorm about technology options available.

Analyze Current State

It is very important to understand end-to-end current business process and its touch points. Gather as much information as you can about the custom code and its integration touch points with standard SAP process as well as external systems/business process. Understand the current usage of the objects; we might have 100's of custom objects developed, but after scanning through we might have realized only 10 programs/tables are very frequently used in production while the rest of them infrequently used. Understand more about type of usage as well, like whether it used as an API by external system or executed as a batch process or a user initiating the process, volume of data, frequency of changes to the program/process, etc. All this information is very useful in further process steps.

Identify Suitable Implementation options

We would not want to discuss about whether its ASAP methodology, AGILE Practice or any other. Instead, we would like to mention what strategies could be adopted and what technology options are available to deal with a CLEAN CORE project.

CLEAN CORE implementation strategies

We could summarize the strategies available to achieve CLEAN CORE goal based on the state of the existing custom code on how it is developed.

Lift and Shift

This is the best strategy to adopt if the current custom code is already defined in a good shape. It requires minimal migration effort to move to target architecture and boom, the code starts workings.

Improve and Move

In this strategy, we improve the current code base and make it isolated by defining clear boundaries. Get it ready for service-based architecture and migrate incrementally.

Rip and Replace Incrementally

This is slightly different from Improve and Move strategy. Here, we redesign part of the function or a specific feature as a new microservice and replace it in the current setup. Then move on the next feature.

Redesign and Replace

This is more about re-evaluating the existing functionality, identifying pain-points. Once done, we collect all the new features we would like, redesign feature by feature and completely replace with existing functions by the end.

Common mistakes to avoid:

Do not consider thinking about migration of one specific custom object like a report program or table. Instead think about the process the object is dealing with.

Technology Options/Tools

Undoubtedly there are several platforms/tools available to achieve the CLEAN CORE goal. After experiencing some of them, we could be broadly classify into 4 different flavors.

S/4 HANA Standard Functionality
- Look whether we have out-of-the-box functionality released by SAP for any of the custom process
- In-app extensibility which enables creation of S/4 HANA extensions. It allows key users to create fields, business logic, CBOs, and more.
- Here is the quick help https://help.sap.com/viewer/77cd6a531be5454ab16ccd8bb63c183f/PROD/en-US for all the SAP applications which supports In-app extensibility

Modular Monolith
- Apply simplification changes on S/4 HANA code. Simplification analysis can be identified in multiple ways based on the version of the current system like SAP_BASIS 7.52, S/4HANA 1809, etc.
  - Remote code analysis can be done with ABAP Test cockpit
  - We could download the simplification database to the current system and perform analysis

- SAP Fiori Custom Code migration app available in SAP Cloud Platform ABAP environment

- Isolate custom code from standard business functions, define clear boundaries
- Refactor code, add unit tests and integration tests
- Implement CI/CD pipeline for ABAP, Services and Fiori application

S/4 HANA Side by side extension
- Restful ABAP programming(RAP) model using ABAP on cloud platform - https://help.sap.com/viewer/923180ddb98240829d935862025004d6/Cloud/en-US/289477a81eec4d4e84c0302fb6835035.html#:~:text=The%20ABAP%20RESTful%20Application%20Programming,Environment%20or%20Application%20Server%20ABAP.

- Cloud Application Programming(CAP) Application model using Java/Node.JS - https://cap.cloud.sap/docs/
- SAP Cloud Platform services like Enterprise messaging / Extension factory, Workflows, etc. - SAP Cloud Platform in the Garage Virtual Event | Event-Driven Architecture
- SAP Cloud Platform Kyma runtime service, Kubernetes framework based on containers - https://community.sap.com/media/devtoberfest/project-kyma-jamie-cawley-sap-cloud-platform-kyma-runtime-introduction

4. Cloud Native Microservices

- Choice of Cloud provider and its services
  - AWS like SQS, SNS, ECS, EKS,
  - Google GKE, CGP services
  - Microsoft Azure like Azure Storage queues, logic apps, functions
- Cloud Independent microservice
  - Docker
  - Kubernetes
  - Service Mesh

- Language and Database based on use case and team skillset
  - Java
  - Node.js
  - Python

Define Roadmap

By this time, we have identified our Customer priorities, have gone through the current business process, have seen different implementation strategies and available Technology options. Now, comes the important task on how to organize and lay out the roadmap for successful implementation. We could follow these simple steps:

Use most common user-friendly tool Microsoft excel and define a decision matrix table for each process.

Lay down all the factors like Usage frequency, Number of users accessing the application, what could be expected growth, what type of processing (like Batch, Real time), Security, Data, Network, Implementation and maintenance costs, monitoring, UX significance, DevOps practice, Hardware requirements, monitoring capabilities, exception handling processes, etc.

Setup a pointing system against each platform

Discuss Pros and Cons of each

Finally, pick the best choice based on drivers defined (customer priorities) and setup implementation strategy.

Here is a sample matrix

Hope you have got some insight about how to start approaching the clean core methodology by this time. I would like to thank my friend @Austin who helped me in writing this blog.

How to Extend SAP S/4HANA Business Address Services (or any other SAP S/4HANA application) with Serverless Functions on Kyma Part-II

2021-09-23T09:07:03+02:00

In this blog post you will learn…

Overview:

We will learn about how we will create serverless function in Kyma Runtime and how they are deployed (i.e. how URLs are created to get which can be used to run serverless functions) .

We will also learn about how to use Google APIs to get Geocodes of any inputted address .

To Know what is serverless function and need of serverless function refer to previous blog post of this blog series

Prerequisites/Skills:

Access to SAP BTP Cockpit
You need access to a productive account of SAP BTP Cockpit
Note:
This service is available in Trial version of SAP BTP Cockpit

Node.js/JavaScript
Functions are written in JavaScript for Node.js runtime.
As such, some knowledge is helpful, however, most of the tutorials can be followed without any knowledge.

ABAP.

Kyma Environment Setup explained in Part-I of this Blog Series

Implementation Steps:

After successfully setting up the Kyma Runtime Environment as described in the steps above, we now must define the Kyma Namespace. This is where all our functions will be defined. The steps below are to set up your Kyma Namespace and get started with the Kyma environment.

1. Open Your Subaccount in SAP BTP Cockpit.

2. Click on Instances and Subscription.

3. Click on Environments.

4. Click on the Actions button in your Kyma environment and navigate to ‘Go to Dashboard’.

5. On the Dashboard click on ‘Select Namespace’ and choose your namespace.

Creating Serverless Function

Click on ‘Functions’ on left hand pane and then click on ‘Create Function’ to create a new function.

Enter name of your choice and press Enter. You will see the screen shown below.

There are two sections under code tab:
- First section will contain our source code to call the Google API.
- Second section will contain dependencies (if any).

We are now going to add code in Source section

const https = require('https');



const key = {Enter Your Key Here}



const generateGeoCode = (address) => {



let data = '';



return new Promise((resolve,reject) => {



https.get(`https://maps.googleapis.com/maps/api/geocode/json?address=${address}&key=${key}`,



(response)=>{



response.on('data',(chunks)=>{



data+=chunks;



})



response.on('end',()=>



{



// console.log('check123',data);



// response = data;



// return data;



resolve(data);



})



response.on('error',(error)=>{



console.log(error)



reject(error);})



});



//  console.log("google",response);



})



}









module.exports = {



main: async function (event, context) {



console.log('event',event.extensions.request.query.address);



address = event.extensions.request.query.address;



const output = await generateGeoCode(address);



let {results} = JSON.parse(output);



console.log('add',results[0].geometry.location.lat);



let final = '';



final +=`${results[0].geometry.location.lat}, ${results[0].geometry.location.lng}`



return final;



//console.log('f',f);



}}

In the above Picture you can see that there is a variable key that has been purposely left blank. Here you need to get your credentials from Google Cloud Platform before entering them. you can get them from Here

Here we can see that our code is dependent on HTTP module to run so we are going to put that in our dependency:

{



"name": "geocode-api",



"version": "1.0.0",



"description": "geocode api to get latitude and longitude",



"dependencies": {



"https": "^1.0.0"



},



"license": "ISC"



}

This Completes first part of our function. Now it’s time to create the URL to send request to API.

Creation of URL for Function to place request to API:

Click on Configuration tab next to Code tab and click on ‘Expose Function’.

Enter API Rule Name and Host Name and press Enter. This will generate the URL.

You can run the URL above in your browser and see the output.

Summary:

In this blog post we saw about

How to create serverless function in Kyma.

How to use Google APIs to find Geocodes using address send by user.

And How to deploy the serverless function and generate API URL which can be used to send get request to server.

Next Steps:

We will be seeing how to Integrate the Kyma serverless function in any SAP S/4HANA applications

For any queries and doubts please comment in comment section I will be more then happy to help you, also you can follow my profile to get updated of upcoming blog posts.

How to Extend SAP S/4HANA Business Address Services (or any other SAP S/4HANA application) with Serverless Functions on Kyma Part-III

2021-09-27T10:31:38+02:00

Introduction

This blog post explains how a Serverless Function developed in Kyma Runtime can be consumed in the SAP S/4HANA system for the extensibility of SAP S/4HANA applications. Specifically, this blog post covers the extensibility of Business Address Services and is in continuation of Blog Series of the same title(mentioned under Prerequisites).

Prerequisites/Skills

ABAP

Kyma Environment Setup explained in Part-I of this Blog Series

Kyma Serverless Function Implementation explained in Part-II of this Blog Series

In our example, we will be implementing the geocode functionality with the Business Partner (BP) transaction. Once our serverless function returns the geocodes, we will be updating a Custom Z table.

Since it is a customer modification, we can make use of the BADIs available. ADDRESS_UPDATE is the BADI that is used to trigger updates on Address Changes. We have implemented this BADI in SE18 as ZADDRESS_UPD_SRV_POC. The implementing class name is given as ZCL_IM_ADDRESS_UPD_SRV_POC

Based on the type of address created i.e. Organization, Person, or Workplace, add the logic in methods ADDRESS1_SAVED, ADDRESS2_SAVED, and ADDRESS3_SAVED respectively. Next, we must compile the complete URL which will be a combination of:
- URL generated by Kyma runtime
- Search parameters from BP transaction which will be components of address based on which Geocode will be found. For our PoC, we have considered House Number, Street, City, Region, Postal Code, and Country

 DATA(url) = 'https://get-geocodes.fdc4fe9.kyma.shoot.live.k8s-hana.ondemand.com/?address='.

    LOOP AT im_t_xadrc ASSIGNING FIELD-SYMBOL(<fs_xadrc>).



      IF <fs_xadrc>-house_num1 IS NOT INITIAL.

        full_address = <fs_xadrc>-house_num1.

      ENDIF.

      IF <fs_xadrc>-street IS NOT INITIAL.

        CONCATENATE full_address <fs_xadrc>-street INTO full_address SEPARATED BY space.

      ENDIF.

      IF <fs_xadrc>-city1 IS NOT INITIAL.

        CONCATENATE full_address <fs_xadrc>-city1 INTO full_address SEPARATED BY space.

      ENDIF.

      IF <fs_xadrc>-region IS NOT INITIAL.

        CONCATENATE full_address <fs_xadrc>-region INTO full_address SEPARATED BY space.

      ENDIF.

      IF <fs_xadrc>-post_code1 IS NOT INITIAL.

        CONCATENATE full_address <fs_xadrc>-post_code1 INTO full_address SEPARATED BY space.

      ENDIF.

      IF <fs_xadrc>-country IS NOT INITIAL.

        CONCATENATE full_address <fs_xadrc>-country INTO full_address SEPARATED BY space.

      ENDIF.

      REPLACE '#' WITH space INTO full_address.

      SHIFT full_address LEFT DELETING LEADING space.

      CONDENSE full_address.

      CONCATENATE url full_address INTO DATA(final_url).

    ENDLOOP.

Next, an HTTP client for the generated URL must be created. This is done by calling the method CREATE_FROM_URL of class CL_HTTP_CLIENT. This HTTP client is used to send the request to Kyma Serverless Runtime and receive in response the Geocodes of the provided search parameters.

"create HTTP client by url

    CALL METHOD cl_http_client=>create_by_url

      EXPORTING

        url                = final_url

      IMPORTING

        client             = lo_http_client

      EXCEPTIONS

        argument_not_found = 1

        plugin_not_active  = 2

        internal_error     = 3

        OTHERS             = 4.



    IF sy-subrc <> 0.

      "error handling

    ENDIF.



*** Send the request

    lo_http_client->send(

      EXCEPTIONS

        http_communication_failure = 1

        http_invalid_state         = 2 ).



*** Receive the respose

    lo_http_client->receive(

       EXCEPTIONS

         http_communication_failure = 1

         http_invalid_state         = 2

         http_processing_failed     = 3 ).

Finally, we read the result from the HTTP response and update our custom table with the Geocode.

*** Read the result

      lv_result = lo_http_client->response->get_cdata( ).

      IF lv_result NP 'Internal Server Error'.

        ls_geocode-mandt = sy-mandt.

        ls_geocode-addrnumber = im_address_number.

        SPLIT lv_result AT ',' INTO ls_geocode-latitude ls_geocode-longitude.



        MODIFY zaddress_geocode FROM ls_geocode.

      ENDIF.

The Custom table structure is as below:

Next, in BP transaction we must create an Organization BP with the values below for address fields which in turn will be considered for the final URL generation:

The address number of the BP above is:

On Save of the Business Partner, the custom table ZADDRESS_GEOCODE is updated:

Note: We did not enhance the BP transaction to display these coordinates, but such enhancements can be taken up if required for the project.

Summary

In this blog post, we have seen how a Serverless Function developed in Kyma Runtime can be consumed in the SAP S/4HANA system for the extensibility of Business Address Services or any other SAP S/4HANA applications.

SAP BTP, Serverless Runtime to be discontinued and replaced by SAP BTP, Kyma Runtime and SAP Integration Suite

2021-10-18T15:27:56+02:00

Serverless computing is a truly cloud-native paradigm. Servers and other computing resources are completely hidden away from the developer and the end user. There are servers in serverless, but these are operated by the cloud provider, which means you can almost forget about most tedious maintenance and operations activities. Nicer still is the fact that your cloud provider automatically scales the load for you. You don’t need to worry about peak loads on your side as this is taken care of.

Function-as-a-Service

Function-as-a-Service (FaaS) refers to an event-driven atomic piece of code that runs in stateless ephemeral containers created and maintained by a third party – typically a cloud provider. From a technology standpoint, FaaS is a combination of code, configuration, and dependencies executed on a compute service in an isolated container. Resource allocation is done in a serverless environment. The resources required to run code are dynamically allocated by the cloud provider.

As a result, developers are responsible for neither capacity planning nor the optimal allocation of resources. In practical terms, Function-as-a-Service allows adding event-driven, serverless functionalities that are completely decoupled from existing application landscapes.

SAP BTP's Function-as-a-Service Offerings until now

SAP’s Business Technology Platform until now has offered two Function-as-a-Service options with slightly different scope and feature sets.

SAP BTP, Serverless Runtime has been one of SAP’s Function-as-a-Service offerings to enable rapid development in serverless, event-driven environments specifically targeted at extensions in SAP landscapes. SAP BTP, Serverless Runtime is a fully managed cloud service for building, running, and managing stateless application functions.

SAP BTP, Kyma Runtime has been SAP’s second FaaS offering, allowing customers to build extensions by using both microservices and serverless functions. SAP BTP, Kyma runtime is a fully managed Kubernetes runtime based on the open-source project "Kyma". This cloud-native solution allows developers to extend SAP solutions with serverless functions and combine them with containerized microservices. The offered functionality ensures smooth consumption of SAP and non-SAP applications , running workloads in a highly scalable environment, and building event- and API-base extensions.

In short, SAP BTP, Kyma Runtime offers several technical capabilities and benefits:

Mesh Serverless Functions, Microservices or custom docker images in one runtime

Upskill your developers quickly due to open standards

Get a fully managed Kubernetes Runtime

Leverage the built-in capabilities of Kyma:
- API Microgateway
- Event bus
- Service mesh

These technical capabilities optimize development and give you tangible business benefits:

Reduction of both the TCO and time-to-market

Managed runtime that fits the needs and skillset of your work force for cloud-native solutions

Aligned with SAP operational and release processes and standards

Best services/tooling from hyper-scalers, combined with open standards + SAP specific value add on top

Customers so far have had the choice between these two great environments to develop their functions-as-a-service. Over time though, it has shown that SAP BTP, Kyma Runtime has proven the more beneficial and more well-rounded runtime for customers, offering more options and benefitting from the traction of its open-source community.

OData Provisioning

OData Provisioning exposes business data and business logic as OData services on SAP Business Technology Platform, thereby enabling customers to run user-centric applications on SAP Cloud. In the Multi-Cloud/Cloud Foundry environment context, OData Provisioning has been available as a part of the SAP BTP, Serverless Runtime.

SAP’s Business Technology Platform until now has offered OData provisioning with slightly different scope and feature sets:

SAP BTP, OData Provisioning (On the NEO environment only) to expose business data and business logic developed on the SAP Business Suite as OData services on the SAP BTP without any additional development effort.

SAP BTP, Serverless Runtime (On the multi-cloud /CF environment only) included OData Provisioning to expose business data and business logic developed on the SAP Business Suite as OData services on the SAP BTP without any additional development effort.

SAP Integration Suite is the enterprise-grade integration platform as a service offered by SAP. The Integration Suite is an open IPaaS and consists of a modular set of integration services that work together to support a comprehensive variety of end-to-end integration scenarios.

In particular, SAP Integration Suite supports:

The integration of SAP and non-SAP applications in the cloud and on premise (A2A)

Integration with business partners (B2B) and government agencies (B2G).

The design and runtime governance of APIs, including API-based integration.

Exposing business data and business logic as OData services on SAP Business Technology Platform

Extensions of business processes with workflows, including human interaction steps and business rules; as well as the integration of IoT devices and equipment.

Customers so far have had the choice between the different services for provisioning of OData services. With SAP Integration Suite enabling and end-to-end API based integrations, customers will have the added value of not just provisioning of OData services but to also manage the lifecycle of the service.

SAP BTP, Serverless Runtime to be replaced by SAP BTP, Kyma Runtime and SAP Integration Suite

It is due to this that SAP has decided to discontinue SAP BTP, Serverless Runtime and to instead increase the focus on and efforts for SAP BTP, Kyma runtime and SAP Integration suite for the respective capabilities.

Please note this however does not have any impact on the OData Provisioning service on the NEO environment.

The way forward

For all existing customers who already use the SAP BTP, Serverless Runtime, we are looking forward to engaging with you to help make the transition as smooth and non-disruptive as possible.

HP Enterprise - Interactive Digital Assistant powered by SAP Conversational AI

2021-12-15T16:29:22+01:00

Artificial Intelligence is the new Electricity!

Artificial Intelligence is everywhere! Just as electricity revolutionized lives 100 years ago, today AI is completely changing our lives. Companies are investing millions in intelligent systems for situation assessment, prediction analysis, learning-based recognition, conversational interfaces, and recommendation engines. Among these intelligent systems, conversational interfaces have become essential in allowing businesses to communicate with customers 24/7. For example, having a Chatbot in place, business becomes far more interactive, natural, and convenient for consumers which, in turn, can improve customer satisfaction.

In order to empower the Intelligent Enterprise, SAP Conversational AI provides all the tools necessary to create chatbots and conversational applications by providing an end-to-end Bot Building Platform covering different stages of development such as Training | Build | Connect | Monitor.

Customer Background

Hewett Packard Enterprise's vision is to leverage SAP Intelligent Technologies and leverage the SAP Industry Cloud application capabilities for the Hi-Tech industry to improve their customer experience, gain efficiency, and deliver next-generation business outcomes by following three principles:

Sustainable Foundation for Business Execution – SAP Business Technology Platform. Best-in-class implementation of business processes on a stable, resilient, and scalable platform by keeping the core clean.

Insight- to-Action driven applications – SAP Conversational AI. Create Chatbots for context awareness, real-time detection, and predictive insights to make informed and quick decisions.

Process optimization through Intelligent Technologies – SAP Intelligent Robotic Process Automation + Machine Learning + SAP Process Automation. Digital assistance, artificial intelligence, and robotic process automation eliminate more than half of manual tasks.

The goal of the project is to empower HPE’s Partners/Resellers by retrieving time-critical order details from their transactional systems. The chatbot was designed, developed, and deployed within 4 weeks. The SAP Conversational AI's initiative started with a few immediate value-driven discussions to :

Capture time critical order information based on the events from SAP S/4HANA

Providing real-time order status

Quickly display packing list for orders

Serial number of the ordered item

Shipment & delivery information

Export order information

The chatbot links complex skills, advanced memory management, and tactically utilizes the SAP Business Technology Platform (SAP BTP) to provide focused conversations and helps:

Retrieving search results through fuzzy search capabilities

Subscribing and unsubscribing to receive alerts for status changes to an order

Emailing detailed reports for both search results and a single order

Providing cross-platform support – Browser or Mobile devices

Highlights

The core of the chatbot is equipped with built-In intelligence and embedded machine learning. Resiliency is born from the fact that it is driven by intents and entities, which result in more natural and interactive conversations leading to a greater user experience. The outcome: greater customer satisfaction to drive a greater adoption rate.

Agile Collaboration

Adopted design thinking to blueprint one-bot to many-channels

Remote collaboration to build a holistic solution

Crowdsource expressions to derive meaningful interactions with robust intents

Discovery of necessary entities to enrich the conversation

Sample dialogues of human-to-human interactions to inform conversation workflows

BTP Extensions:

The chatbot is personalized with Built-In Intelligence and Advanced Memory Management through Handlebars concepts

Custom scripting to display the necessary information predicted by the information the chatbot retrieves

Economize screen real estate especially when interacting with SAP Conversational AI through mobile devices

SAP MaxAttention Engagement:

SAP MaxAttention is the trusted partner by HPE in their continuous innovation journey

The team from SAP MaxAttention and HPE used fact-based Industry exploration methodology with SAP MaxAttention services to enable and empower the customer

Understood the key requirements for HPE’s use cases with the industry best practices and supported the build of the pilot for production roll-out.

A successful pilot was delivered in under 4 weeks and supported scaling and industrializing of the industry-specific use-case and driving Innovation in their business processes.

Business Value:

The conversational chatbot illustrates the following values of the SAP Conversational AI platform with one bot that is successfully deployed to multiple channels. Please check out the customer’s video testimonial below.

Lower operating and maintenance cost

Faster ROI as a single bot that is flexible to work with different channels like MS Teams

Advanced skills and extensions to handle complex conversation scenarios lead to intelligent interactions.

Flexible bot constructed to minimize development overhead, maximize the SAP CAI platform, and strategically leverage SAP Business Technology Platform to make it the best-in-breed for chatbots.

Key Team Members

HPE Representative: Arun Navaneethan (Sr. Director, Global IT)

SAP Contacts: kiran.kola, rohit_dwivedi Balaji Gaddam, Thomas Walther

SAP Communications: Maria Jenkinson, Mirna Chaanine

Customer Video Testimonial: sap.com

MTA deployment, a starter

2021-12-26T20:51:01+01:00

INTRODUCTION

This blog post is aimed for developers who are very new to SAP BTP which requires a deployment descriptor (MTA or Manifest) to deploy applications.

It is always challenging to deploy an MTA or manifest based application be it NodeJS, GO or Java. Additionally we face a lot of challenges and jargons which slows our development.

Though creating MTA might feel overwhelming at first, it has a lot of advantages to offer. The deployment is one touch most of the time and creates an ecosystem where different components from a single application can collaborate together. Helps us create more resources without writing manual commands or collective shell scripts for every resource we consume. So the entire file is reusable

INSTALLATION OF CLOUD MTA BUILD TOOL

We can install the cloud MTA build tool using any of the methods below in the link

You have to consider the following limits for the MTA artifacts, which can be handled by the Cloud Foundry deploy service:

Maximum size of the MTA archive: 4 GB

Maximum size of MTA module content: 1 GB

Maximum size of MTA resource content: 1 GB

Maximum size of MTA descriptors (mtad.yaml and MANIFEST.MF😞 1 MB

MTA DEPLOYMENT TERMINOLOGIES

The different terminologies used in MTA deployments are

Multitarget application (MTA)

An application comprised of multiple software modules, which are created with different technologies and deployed to different runtimes.

Development descriptor -

A YAML file named mta.yaml that contains a list of all entities, such as modules, resources, and properties that belong to an application or are used by it at runtime, and the dependencies between them. It is automatically generated when an MTA project is created or modified, or when a module is added or removed. The developer needs to edit the descriptor manually to define resources, properties, and dependencies, as well as fill in missing information.

Deployment descriptor

A YAML file named mtad.yaml that contains a list of all entities which is created from the WEB IDE or from Multitarget Application Archive Builder tool or manually. This file is similar to Development Descriptor but is used from the MTA Deployer.

Module

A self-contained application of a certain type, which is developed, packaged, and deployed.

Module Type

A type that defines the structure and the development technology of a module. You can see a list of the module types at Modules.

Resource

Any resource, such as an external service that is required by a module at runtime but not provided by the module itself.

Property

A property (key-value pair) of an application, module, or resource, that is used during deployment or at runtime.

Parameter

A reserved variable belonging to a module or resource, whose value is used during deployment or at runtime.

Dependency

A relationship between a module and another module, resource, or property, such as provides and requires.

provides: indicates the properties or parameters that are provided by a module or resource to other modules.

requires: indicates other modules or resources that are required by a module in order to run.

MTA archive (MTAR)

Archive containing a deployment descriptor, the module and resource binaries, and configuration files. The archive follows the JAR file specification.

Example

Consider a nodeJS app having dependency to a hdi-container in a subaccount. This can be modelled like this

_schema-version: "3.1.0"

ID: simple-mta

version: 1.0.0



modules:

- name: anatz

  type: javascript.nodejs

  requires:

    - name: hdi-service



resources:

- name: hdi-service

  type: org.cloudfoundry.managed-service

  parameters:

    service: hana

    service-plan: hdi-shared

The sample file contains a nodejs module named anatz which ready to be deployed. You can also specify the path of the module by specifying the path property. Also few modules such as the launchpad do not contain the path property, as it takes the already created modules and configures them to deploy.

A requires property is specified which allows the module to be deployed only if the required dependencies are satisfied. The required dependencies can come from other modules or from the resources that will be created as services in SAP BTP. like databases or event meshes

Additionally we can also provide parameters such as memory and route to the module. This enables us to control all the modules in one place before deployment

_schema-version: 3.1.0

ID: anatz-keep-existing

version: 4.0.0



modules:

- name: anatz

  type: staticfile

  path: hello-world.zip

  parameters:

    memory: 64M

    route: new-custom-route-${space}

    keep-existing:

      env: true

      service-bindings: true

      routes: true

Sometime we would like to generate our files before starting the build. This can be done by running a shell script or individual commands like mvn clean install or npm install. All these can be speified under Build parameters.

build-parameters:

before-all:

- builder: custom

commands:

- npm install --production

Commands can also be run specific to modules.

Resources can also contain parameters which takes care of special hardcoded values such as url's or references such to files.

So before we plan an MTA deployment

It is advisable to look into the manifest.yaml file (If you have already) make note of modules and dependencies before starting to create one here.

Once you have the module files in place start creating the modules, if needed add a provide property to the module if it requires to be addressed by the upcoming modules by that name

CONCLUSION

Finally do an MTA build using the command mbt build on the module. resolve any errors shown. The final MTAR file will be generated in mta_archive as an .mtar file

You can deploy the mtar file to cloud foundry by using the command cf deploy filename.mtar

If deployment is successful you will receive no process failed message at the end of deployment.

For more information on MTA's checkout the help portal

SAP BTP Serverless Runtime to SAP BTP Kyma Runtime Migration Examples

2022-08-17T20:14:14+02:00

SAP BTP, serverless runtime has been discontinued and replaced by SAP BTP, Kyma runtime. Read more about this in the blog post by karsten.strothmann.

Because of the sunset of the previous SAP BTP, serverless runtime offering, SAP BTP users will look into SAP BTP, Kyma runtime as an alternative to host their functions.

Hi, my name is Krzysztof and I' am working on the Kyma project. In this blog post, I want to help you get started with SAP BTP, Kyma runtime and point you to some useful code samples that will help you migrate common FaaS scenarios from SAP BTP, serverless runtime into SAP BTP, Kyma runtime.

SAP BTP, Kyma runtime - more than meets the eye

SAP BTP, Kyma runtime offers fully managed Kubernetes where you can mix the BTP, serverless runtime functions, microservices, or custom docker images in one runtime. Additionally, it offers built-in capabilities to get you up to speed with your cloud-native application development, such as API gateway, event bus, or service mesh.

Get Started

The best way to get started with SAP BTP, Kyma runtime functions is to create one.

First, you need to create a Kyma instance (if you don't have one already), and then simply follow our tutorial to create a function. Visit the Kyma project website for more tutorials.

Migration Examples

To help you with the transition from SAP BTP, serverless runtime to SAP BTP, Kyma runtime, we have prepared a few examples to demonstrate how to migrate the most common scenarios.

You can learn how to expose Kyma function via HTTPS to the outside world using API Gateway, how to subscribe your function to events from SAP BTP Event Mesh, or how to use Kubernetes Secrets and ConfigMaps to inject environment variables to your function.

Those scenarios are based on a selection of the original SAP BTP, serverless runtime code samples

Conclusion

The migration examples show how to use SAP BTP, Kyma runtime features (serverless, API gateway, and eventing) to model the same scenarios that were possible with the discontinued SAP BTP, serverless runtime.

I hope they will help you get started with the SAP BTP, Kyma runtime. Please share your feedback in the comments section. You can also get in touch with our team via Slack.

SAP Inside Track 2023 # Bengaluru–My experience as a Speaker

2023-04-05T02:20:19+02:00

Greetings, Community friends!

Wishing you all a wonderful day!

I’m very excited to share that I have taken part in SAP Inside Track Bengaluru on 4th March 2023, at SAP Labs, as a Speaker on “SAP Integration Suite implementation from Customer Perspective” topic. It was an excellent experience. It was like a mini-SAP TechEd. More than 1000 professionals and enthusiasts from different organizations participated in the largest SIT to date.

This blog will describe my experience at SIT Bangalore 2023. It has registration, keynote, Key take aways from my session and recognitions.

Registration:

Registration was well organized by the volunteering team. They guided us to the sessions and hospitality that would interest us throughout the day. I would like to extend my special thanks to all the sponsors.

Keynote:

The event kickstarted with a keynote session by Sindhu Gangadharan, MD and SVP of SAP Labs India, The interaction with her is always fascinating, and this time she highlighted the importance of community and future SIT events. Thanks for always supporting to community events.

Key take aways from my session:

SAP Integration Suite – Customer Perspective Introduction

SAP Integration Suite is a cloud-based platform that enables customers to integrate their various systems, applications, and data sources. It provides integration services that help businesses connect and manage data and processes across different systems, both within and outside the enterprise. I have explained about customer challenges, business automation via Integration suite and top10 reasons to choose integration suite.

Use cases discussion and demos.

First Demo: SF integration with Cloud to on premise – In this demo I have created SIT-BLR as an employee and replicated it to SAP S/4 on premise. I have explained the end-to-end scenario including the configuration. Specifically, I have explained on standard integration which helped us in seem less integration in replicating the data. In addition to standard interfaces, I have taken a walkthrough of custom interfaces like FBP to SAP. In this interface we have used almost all key functions in I flow. Almost 9 groove scripts have been used to fulfil the requirement.

Second demo: DCS integration with cloud to on premise –SAP Digital Compliance is a cloud-based solution that helps businesses manage the tax compliance obligations. SAP S/4HANA On-Premises system configured with SAP Digital Compliance via Cloud connector and client certificates. The configuration steps are explained in the end-to-end demo.

Please find the following link to my presentation and demos.

https://drive.google.com/drive/folders/1r8m2ZQdnNANErsFYV6p4nZ2-MSykdzrs

Please find the link below to view the presentations from the other tracks sessions.

https://drive.google.com/drive/folders/14ol_h2q3LanEpWZr3FUJy49VcWJ6tkR5

Recognition: Certificates were distributed at the end of the event, and I carry with me wonderful memories.

My sincere thanks to Abhishek Chatterjee , Mahesh Palavalli , syambabu.allu and #sapcommunity for great opportunity given to me on sharing my possible best knowledge on Integration Suite spend on the #sitblr stage, it encourages me to participate in many more events and gain knowledge.

In closing, I would like to express my gratitude to the organizers and volunteers.

Mohammed AK Rao, Peeyush Chaurasia, Pavan Kumar PVN, Pushpendra Yadav, Priti Dhingra, Gopal Anand ,Ahsan Farooqui, , Kavya Krishnan, , Anjitha K A, Megha Panjwani, Swati Maste, Chinmayi Shetty, Srinivasa Raghavan S

Best Regards,

Azmath.

SME – SAP & Non-SAP Integrations, Certified Integration Blackbelt.

References about SIT:, SIT 2023, About SIT.

Benefits of Keeping the Core Clean with SAP BTP

2023-07-03T17:12:28+02:00

Introduction:

In the world of enterprise software, maintaining a clean and optimized core system is vital for organizations to adapt and thrive in an ever-evolving business landscape. SAP Business Technology Platform (BTP) offers a powerful solution by enabling businesses to keep their core clean while leveraging cloud-based services and innovation capabilities. In this blog post, we will explore what "keeping the core clean" means in the context of SAP BTP and why it is essential for unlocking agility and innovation.

What Does "Keeping the Core Clean" Mean?

Keeping the core clean refers to the practice of minimizing customization and modifications to the core ERP system, such as SAP S/4HANA, and leveraging cloud-based services provided by SAP BTP for additional functionalities, extensions, and innovation. It involves adopting a modular and decoupled approach where the core system focuses on essential business processes and data integrity, while non-core functions are handled through integration with SAP BTP services.

Benefits of Keeping the Core Clean with SAP BTP:

Enhanced Agility: By minimizing modifications to the core system, organizations can upgrade their ERP system more easily and frequently, benefiting from the latest innovations and bug fixes offered by SAP. This results in faster time-to-market for new features and capabilities.

Reduced Complexity: Keeping the core system clean helps to reduce the complexity of managing and maintaining customizations. It allows businesses to leverage pre-built integration scenarios, extensions, and applications available on SAP BTP, eliminating the need for extensive custom development within the core system.

Scalable and Future-Proof Architecture: SAP BTP provides a scalable cloud platform with a wide range of services, such as SAP Cloud Platform Integration, API Management, and Workflow, which can be seamlessly integrated with the core system. This enables organizations to meet evolving business needs without compromising system performance or stability.

Innovation Enablement: By utilizing SAP BTP, businesses can tap into a rich ecosystem of ready-to-use applications, industry-specific solutions, and partner offerings. They can leverage these innovations to extend the functionality of their core system and drive digital transformation initiatives without impacting the stability of their core processes.

Examples of Keeping the Core Clean with SAP BTP:

Customer Experience: Organizations can use SAP BTP services, such as SAP Commerce Cloud or SAP Marketing Cloud, to enhance customer engagement and deliver personalized experiences without heavily customizing the core ERP system.

Integration and Connectivity: SAP BTP offers robust integration capabilities, allowing organizations to connect their core system with external systems, suppliers, and customers. This enables seamless data exchange and process automation while keeping the core system lightweight and efficient.

Advanced Analytics: Leveraging SAP Analytics Cloud or SAP Data Warehouse Cloud on SAP BTP, organizations can perform advanced analytics and reporting on data from multiple sources, providing valuable insights without burdening the core ERP system.

Conclusion:

Keeping the core clean with SAP BTP is a strategic approach that empowers organizations to maintain a stable, scalable, and future-proof core system while leveraging cloud-based services for agility and innovation. By adopting this approach, businesses can reduce complexity, accelerate innovation, and drive digital transformation without compromising the integrity of their core processes. Embrace SAP BTP as your strategic technology platform and unlock the full potential of a clean core for enhanced business agility and continuous innovation.

Unleashing limitless Innovation with SAP Blue - The Internal Gig Platform

2023-07-18T21:13:30+02:00

Crowdsourcing platforms have gained popularity as an effective means for organizations to tap into a global community of problem solvers. From simple tasks to complex scientific challenges, these platforms cater to diverse needs and audiences. However, what happens when a gig platform is brought within an organization? In the era of digital transformation, it is necessary for organizations to adapt to new ways of working and innovating. SAP Blue2.0, a revolutionary internal gig work platform, went live on June 14th, 2023, serving as a catalyst for innovation at SAP Labs India.

Platform Features and Benefits:

Built on the renowned SAP BTP (Business Technology Platform) and leveraging cutting-edge technologies such as React, SAP Blue is a digital marketplace that empowers employees to discover, apply for, and work on a wide range of projects across different departments and business units. While the earlier version of SAP Blue saw initial success, it had lost momentum over time due to a lack of knowledge among the employees and outdated user experience. The revamped platform offers an intuitive user interface and introduces new features like feedback and testimonials to enhance the overall user experience.

SAP Blue is not limited to developers or product development teams. It encompasses various areas, including strategy, marketing, communications, UX/UI, and more. By tapping into SAP Blue, employees have the opportunity to work on short-term projects, fostering collaboration, agility, and professional development. The platform encourages individuals to expand their horizons by engaging in projects that requires technologies like UI5, machine learning, and artificial intelligence. It serves as a powerful tool for both experts and enthusiastic learners, promoting a sense of ownership and driving professional growth while adapting to changing business needs.

Additionally, SAP Blue provides a platform for Lines of Business (LoBs) to obtain cost-effective solutions for their problem statements. Rather than seeking external hires, leaders can present these challenges as stretch assignments within the platform, maximizing efficiency and effectiveness.

Testimonials and the journey:

The journey of SAP Blue began in November 2022, with contributions from both new and seasoned team members.

“We knew we have to upgrade the user experience for the people. Ideation started November 2022. After multiple check points, design thinking sessions and scope finalization, within in 6 months, we revamped the whole platform. We soft launched it in dkom earlier this year and we had over 600+ unique enagements.14th of June we went live. And we already have 1.2K users & 23 + live projects, including some from the SAP Labs India management.” – Akshay Sureshchand, Program Head - SAP BLUE

“With the world venturing into unexplored territory filled with limitless opportunities that can be unleashed by technology, there exists tremendous untapped potential in harnessing bottom-up innovation. SAP Blue exemplifies the extensive engineering elasticity in product development that an organization can achieve by integrating diverse talents from within. It allows us to access the collective wisdom and ingenuity of a diverse group, presenting a distinct and effective approach to fostering innovation.” - Mohammed Anzy S, Chief Operating Officer, SAP Labs India

“We’d like to refer SAP Blue as our in-house gig platform where colleagues can take up projects and interests beyond their daily scope of work to expand their horizons, discover new skills, get inspired by new possibilities, challenge their boundaries, network with like-minded people, and get a deeper understanding of SAP strategy through varied perspectives.”- Sindhu Gangadharan, SVP & MD, SAP Labs India and Head, SAP User Enablement

By embracing SAP Blue, organizations can foster innovation, agility, and employee engagement, unlocking their true potential. This internal gig work platform offers a gateway to endless possibilities, enabling individuals to drive their professional growth and contribute to changing business needs. With SAP Blue, SAP Labs India is embarking on a journey of collaboration and unleash a future with limitless innovation.