SAP Community - SAP Cloud SDK

Customized Project Budgeting in SAP Business ByDesign

2023-04-05T15:35:49+02:00

Requirement:

Customers needs the ability to specify a budget amount at the project level.

When expenses are posted to a project, the system should validate this expense against the project budget amount

If this expense will cause the total incurred expense for the project to exceed the budgeted amount, the system should stop the transaction from being posted and issue an error message or trigger a mail.

Project Budgeting

Solution:

Build the capability to specify a budget amount at the project level as well as the ability to upload this data from MS Excel. Only an overall budget amount can be specified at the project level

Design:

Budget validation will be provided for the following transactions

Purchase Order

Supplier Invoice

Expense Report

Journal Entry Voucher

Business Benefits:

Hassle free Cloud Solution.

Custom reports to track every Project based on Budget.

Conclusion:

The Solution which describes the Budgeting at Project Level in SAP Business ByDesign

Kindly post your questions in ask a question section and feedback in the below comments section.

How to Calculate the Difference Between Two DateTime Fields in SAP C4C

2023-04-06T00:06:39+02:00

Hello everyone,

In the course of implementing a business requirement, I recently had to calculate the difference between two DateTime fields in SAP C4C for reporting which calculates ticket assignment time from the creation. However, I couldn't find any straightforward blog that provided a simple solution to this problem.

Fortunately, SAP provides a function called Delta() that can be used to calculate the difference between two DateTime fields. The only catch is that Delta() is only accessible for the GlobalDateTime data type.

So, how can you use Delta() for DateTime fields? It's simple - just use the ConvertToGlobalDateTime() function after your DateTime field. This will convert your DateTime field to GlobalDateTime format, allowing you to use Delta().

The result of Delta() is returned in a "Duration" format, which was not convenient for my purposes. To convert the result into minutes or hours, I simply used the ConvertToMinutes() / ConvertToHour() functions, respectively.

Here's a code snippet that demonstrates how to use Delta() to calculate the difference between two DateTime fields:

// Creation time in Datetime format.

var ZV_CreationDateTime = this.RequestInitialReceiptTimePoint.TimePoint.DateTime; 





//Converting local datetime to global datetime to use standard Delta function.

var ZV_CreationDateTimeGlobal = Library::DateTime.ConvertToGlobalDateTime(ZV_CreationDateTime);





//Ticket reassigned datetime.

var ZV_AssignedDateTime = Context.GetCurrentGlobalDateTime(); 





//Calculating the difference between two dates.

var ZV_DeltaDifference = ZV_AssignedDateTime.Delta(ZV_CreationDateTimeGlobal).ConvertToMinutes();

I hope this solution helps you as much as it helped me. If you have any feedback or questions, please don't hesitate to leave a comment.

Links for ref.:Duration (Reuse Library)

Best regards,

Pratik Shekokar

SAP C4C Technical Consultant

SAP private linky swear with Azure – enabling SAP CAP with Azure services without OData APIs using SAP Private Link

2023-04-24T13:07:20+02:00

This post is part of a series sharing service implementation experience and possible applications of SAP Private Link Service on Azure.

Find the table of contents and my curated news regarding series updates here.

Find the associated GitHub repos here and here.

Dear community,

Continuing with the implementation journey of SAP Private Link Service (PLS) for Azure we will have a closer look at connecting privately to Azure services that don’t have an OData interface today from apps implemented with SAP Cloud Application Programming Model (CAP). You might say that SAP CAP can connect to non-BTP sources via the SAP Cloud SDK or custom coding. However, if an OData API is available, it works out of the box and allows for separation of concerns. Multiple BTP apps may use the same interface without the need for each of them to take a dependency on the Azure SDK.

So, why not meet CAP halfway?

We will do so using a translator app running on Azure App Service in a private virtual network on Azure exposed via SAP Private Link.

The provided translator app is pre-configured to work with Azure Cosmos DB and Azure Blob storage. Its structure is modular and open for you to add any service you desire.

Any scenario top of mind already? Reach out via GitHub or leave a note down below under this post.

Fig.1 Architecture overview depicting the protocol translation and the SAP Private Link exposure.

Let’s take a look under the hood

To replicate the scenario, create a basic private Azure VNet, provision a serverless Azure Cosmos DB for NoSQL instance and windows-based Azure App Service into it. Make sure all resources are in the same region. You may do this via CLI, the Azure portal, bicep, or terraform for instance. See below guidance for the portal-based approach.

Fig.2 Detailed Azure deployment view from the Azure portal

Data setup and integration test

Before we make everything private and troubleshooting becomes harder (would require private VNet access via Azure Bastion service for instance or VPN), let’s verify initial integration.

I am using the famous SAP SFlight demo data set on Cosmos as a sample. It is stored in database “saps4” in container “sflight”.

Fig.3 Screenshot of Sflight data set in Data Explorer of Cosmos DB

You may synch the data from SAP or for the sake of quicker getting started generating it using the Cosmos DB Data Explorer with below steps:

Fig.4 ChatGPT generated guidance to create SFlight data set in Cosmos DB

{

  "id": "006",

  "carrid": "AA",

  "connid": "64",

  "fldate": "2016-06-17",

  "planetype": "A310-300",

  "seatsmax": 280,

  "seatsocc": 10

}

Deploy the code for the translator app via the provided script for convenience:

az login

.\publish.bat [your resource group] [name of above created app service]

Once finished call the APIs to verify proper setup with public endpoints still.

Local execution (or from GitHub Codespaces) is also possible at this point:

cd .\GenericODataWebAPI\

dotnet run

Find a sample call library on the repos here.

Call http://localhost:52056/api/odata/Sflight for the integration test. It should look something like this:

Fig.5 Sflight output from local OData request via translator app

So far so good. Now we will inject all services into our private VNet and prepare the SAP Private Link.

Fig.6 Screenshot of Cosmos DB private network setup

Note the associated VNet in above screen and the marked checkbox to retain access to the database via the portal. Believe me been there, done that 😉

Fig.7 Screenshot of App Service private network setup

Inject the Azure App Service into the same VNet as your Cosmos instance. See above for a reference.

Swoosh 🌪️ At this point you can reach the database only via the App Service! Don’t believe me? Go on and check. Trust is good but verification is better as they say🧐

Now onwards to the private link. Collect the resource id of your app service either from the properties pane or my favourite option: From the JSON view of the Overview pane.

Fig.8 Screenshot of App Service resource id retrieval

Login into your BTP subaccount and create a new instance of SAP Private Link called “odata-proxy-pls” providing the required properties for Azure App Service. See the SAP docs for further details.

Fig.9 Screenshot of SAP Private Link create view for Azure App Service

This triggers the connection request on the Azure App Service from your BTP account. Go on hit approve. I will wait ⏳

Fig.10 Screenshot of SAP Private Link approval in Azure

Done? Ok, great. Now we are ready to deploy our CAP app to “seal” the private link and create the Cloud Foundry service binding.

I provided a repos for this purpose. Find more details on how to deploy via Business Application Studio (BAS) or the likes there too. I ran “cf deploy”.

Fig.11 Screenshot of CAP app config with emphasis on SAP Private Link config

See above the reference on the CAP app binding itself to the SAP Private Link pointing to the Azure App Service.

Be aware that you require an SSH tunnel on BAS for local testing reaching through the private link to Azure. Otherwise only deployed apps have access due to the Cloud Foundry security groups. Find more details here.

With that we can retrieve the hostname to reach the private link and maintain our destination on BTP.

Fig.12 Screenshot of SAP BTP Destination setup using Private Link

For now, I didn’t put authentication on the App Service but is pre-configured to use Azure AD. Have a look here. Once you decided what authentication flow to use adjust the destination above accordingly.

Broke a sweat yet? 🥵

Either way you may be glad to hear we are done 💪Yes, go on call the CAP app URL and marvel and the privately served data from Cosmos DB as OData stream:

Fig.13 Screenshot of SAP CAP app OData output requested from Cosmos DB

Thanks to the translator app we are serving OData from Azure Cosmos DB tapping into the dotnet NoSQL API even though Cosmos DB doesn't have an OData interface for the NoSQL API. And all of that privately!

Focus of this blog was on advocating for the private link approach and deeper understanding of the setup rather than enterprise scale. However, all steps taken can be accomplished via infrastructure-as-Code. I can highly recommend the Azure Developer CLI (AZD). For BTP components consider the BTP Setup Automator.

In addition to that I am considering adding the AZD configuration to the repos at later point in time. Would appreciate any help from the community!

Thoughts on production readiness

SAP Private Link is generally available and therefore completely ready for prime time (quoting gowrisankar.m2 from the SAP engineering team 😊).

Cosmos DB powers critical globally available solutions like NEXT GAMES apps with real-time leader board requirements or the data hub of Deutsche Börse AG for instance. For additional stories, have a look at the official portal or the nice community offering Azure Charts.

Cosmos DB scales on its own, match that setup for your CF app on BTP where required with the Application Autoscaler.

Azure App Service is a full-blown PaaS offering to run apps, APIs in all major programming languages, with native integration with Azure AD (no need for custom code), Log Analytics, Application Insights, and Key Vault etc. Have a look here for more goodies. You may even run the SAP Cloud SDK on App Service.

Final Words

Alrighty, folks! Today we continued our SAP Private Link with Azure journey to the Azure App Service - a match made in tech-heaven! We took a closer look at how to connect privately to Azure services that don’t offer an OData interface today, using a translator app running on the App Service.

The provided repos is fully operational to translate to OData for Azure Cosmos DB and has the foundation pre-configured for Azure Blob Storage. You need a different service or prefer to private-link directly sacrificing OData? Let me know in the comments or open an Issue on GitHub or go all-in with a Pull-Request 😊

Till then: sit back, relax, and let's get private linking!

Any comments regarding your individual integration journey with SAP Private Link SAP @Developers and @Architects?

Find the related GitHub repos here and here.

Find your way back to the aggregator blog post here.

As always feel free to ask lots of follow-up questions.

Best Regards

Martin

SAP BTP Destinations in a Nutshell Part 1 - Motivation & NoAuthentication Destinations

2023-05-23T22:08:10+02:00

Motivation

We are in the midst of the age of cloud computing and the change in IT system landscapes and software development projects is both noticeable and irreversible. Large, heavyweight monoliths are no longer in vogue, IT systems are becoming smaller and more distributed, technology stacks more heterogeneous, a development that also no longer stops at the SAP world. In future, the core systems are to be kept clean; instead of Z-tables, the migration-plagued IT professional now prefers to use side-by-side extensions. If the standard functionality of a system does not sufficiently reflect the process reality of a company, additional functionality is provided as independent, small and lean Fiori apps. So far, so good. But of course these extensions do not exist on their own in a vacuum, but should be loosely coupled with other extensions and of course also with the underlying back-end systems in order to achieve a noticeable business benefit across the entire process chain. This sounds simple at first, but is quickly accompanied by hard nuts to crack:

As a rule, and ideally, the interfaces of individual systems are not located on the internet with the gates wide open, but only grant entry if the corresponding authentication protocols are meticulously followed and adhered to.

Not all systems are operated in the cloud; the older generation of business standard software still prefers to cavort on the company's internal on-premise infrastructure, into which one first has to laboriously dig connection tunnels before even being allowed through to the entry control.

In the simpler case, a technical user is sufficient to gain access to an interface, but this is not always sufficient. Sometimes it is necessary for system A to pass the identity of the user initiating an operation to system B so that the operation can continue there for that user. In complex and evolved IT landscapes, the identities of users are often distributed among different identity providers for different systems, which does not necessarily facilitate the transfer of identity information.

Communication with another system via an interface usually runs via HTTP, which nevertheless leaves enough leeway for the design of the data transfer, depending on whether it is based on classic REST, OData, GraphQL or gRPC. If you are very lucky (as I was a few months ago in one of my projects), you will still occasionally come across rare examples of the SOAP interface, a protocol from long ago, when XML was still considered the solution to all present and future problems.

To master at least part of this challenge, SAP Business Technology Platform offers so-called destinations. Destinations are used to configure connection information and to simplify the handling of individual communication steps and outsource them to a destination service. The main focus here is on the respective mechanisms for authentication. There is already a lot of official documentation on Destinations on the Internet, as well as many great blog articles and other community contributions that help to familiarise oneself with the cosmos of SAP BTP Destinations. Nevertheless, in my day-to-day work with developers and architects, I notice that there is often a lack of clarity about how destinations are to be used and which destination type is suitable for the respective integration scenarios. What I personally have often lacked in my research over the past years were tangible and touchable examples. This motivated me to create a GitHub repository in which I gradually provide examples for the different destination types, supplementing them with text contributions in which I describe the use cases for which the respective destination type is suitable. I also provide some background information on what goes on behind the scenes of such a destination.

Prerequisites

In order to try out the examples in the repository, you should have some basic experience in working with the SAP BTP Cloud Foundry environment. Knowledge of node / npm / JavaScript is also definitely an advantage. All examples are built with SAP CAP with Node.js and use Multi Target Applications (MTA) for deployment. To build and deploy the examples you will need in any case:

Access to an SAP Business Technology Platform subscription with an activated Cloud Foundry environment and a corresponding Cloud Foundry space, e.g. with a SAP BTP Trial account

node and npm

Cloud Foundry CLI

MTA Build Tool (MBT) CLI

For each destination type there is a separate branch with a README file describing how to deploy client and server on Cloud Foundry and how to test the connection between client and server.

Cloud 2 Cloud - NoAuthentication

https://github.com/jfranken/sap-btp-destinations/tree/cloud-2-cloud-no-authentication

To make the introduction pleasant, I start at a very low level with the simplest conceivable integration scenario: System A (client) communicates with System B (server) via HTTP over the internet, the interface of System B is openly available and does not require any authentication. A classic use case for this is the consumption of a public API.

The repo contains two SAP CAP applications, client and server. The magic here takes place in the client-service.js file. Two service endpoints are defined in the client-service.cds file, both of which call a Hello Word endpoint of the server app, one using the Cloud SDK, one using step-by-step direct communication with the destination service, to better illustrate what happens behind the scenes in the Cloud SDK.

Cloud SDK

srv.on('helloWorldClientCloudSDK', async () => 

  return executeHttpRequest({ destinationName: 'Server' })

    .then((response) => response.data)

})

Plain

const { executeHttpRequest } = require('@sap-cloud-sdk/http-client'

const axios = require('axios')





module.exports = async (srv) => {

    srv.on('helloWorldClientPlain', async () => {

        // get all the necessary destination service parameters 

        // from the service binding in the VCAP_SERVICES env variable

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

        const destinationServiceUrl =

            vcapServices.destination[0].credentials.uri +

            '/destination-configuration/v1/destinations/'

        const destinationServiceClientId =

            vcapServices.destination[0].credentials.clientid

        const destinationServiceClientSecret =

            vcapServices.destination[0].credentials.clientsecret

        const destinationServiceTokenUrl =

            vcapServices.destination[0].credentials.url +

            '/oauth/token?grant_type=client_credentials'





        // before we can fetch the destination from the 

        // destination service, we need to retrieve an auth token

        const token = await axios.post(destinationServiceTokenUrl, null, {

            headers: {

                authorization:

                    'Basic ' +

                    Buffer.from(

                        `${destinationServiceClientId}:${destinationServiceClientSecret}`

                    ).toString('base64'),

            },

        })

        const destinationServiceToken = token.data.access_token





        // with this token, we can now request the 

        // "Server" destination from the destination service

        const headers = {

            authorization: 'Bearer ' + destinationServiceToken,

        }

        const destinationResult = await axios.get(

            destinationServiceUrl + 'Server',

            {

                headers,

            }

        )

        const destination = destinationResult.data





        // now, we use the retrieved the destination 

        // information to send a HTTP request to the server endpoint

        const destinationResponse = await axios.get(

            destination.destinationConfiguration.URL

        )

        return destinationResponse.data

    })

    srv.on('helloWorldClientCloudSDK', async () => {

      return executeHttpRequest({ destinationName: 'Server' })

        .then((response) => response.data)

      })

  })

The result is expected to be the same for both endpoints:

This example is far from passing for rocket science. But don't worry - in terms of complexity, it is guaranteed to increase in the coming parts of this series!

What are your experiences with destinations in SAP BTP so far? Which integration scenarios have you already had to deal with? What were the biggest challenges? If you have any suggestions or improvement requests, or if something doesn't work as you hoped, please let me know. It is my wish and goal to continuously expand and improve this repository, and for that I depend on your feedback from the SAP BTP community! 🙂

Disclaimer

The code examples provided are not suitable to be transferred 1:1 into productive implementations, but they only serve to illustrate the functioning of destinations and Destination Service. In some cases, the interaction with the Destination Service is deliberately implemented in a "cumbersome" manner in order to illustrate the communication processes as explicitly and in detail as possible. SAP CAP and the SAP Cloud SDK provide various functionality to simplify and abstract the use of destinations. However, this would be more of a hindrance than a benefit to the purpose of the illustration.

SAP BTP Destinations in a Nutshell Part 2 – Basic Authentication

2023-06-01T13:14:42+02:00

Introduction

This series is about taking a closer look at the different destination types of the SAP BTP Cloud Foundry environment and making them more tangible with executable code examples. In the first part, we addressed the underlying motivation and started with the easiest scenario for an easy-to-digest introduction: two SAP CAP applications deployed in the Cloud Foundry environment in the same space communicate with each other via Internet / HTTP without requiring authentication in any way. Such scenarios are of course very pleasant and thankful from a developer's point of view, however, they are only practical in the rarest of cases. Sensitive and confidential data is almost always involved, and then it must be ensured that only trusted parties can access corresponding interfaces. We will therefore take the first step in this direction in the second part of this series, which deals with destinations for what is probably the simplest type of authentication: System A (client) communicates with System B (server) via the Internet / HTTP and sends an Basic Authentication header with each request, since the server would otherwise reject the request in a friendly but firm manner.

Basic Authentication

Before we look into the actual code example, let's briefly review the theory behind Basic Authentication. Basic Authentication is a method by which a client sends username and password to a server with an HTTP request for authentication purposes. The server uses this information to verify whether or not the client is authorized to make this request based on correctly supplied authentication information. Basic Authentication is stateless, i.e. the Basic Authentication header needs to be send again with every request.

The user data is sent as an HTTP request header with the Authorization header key. The value here is a Base64 encoded string with the format username:password, together with the prefix Basic. Example:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ

Important: even if the cryptic appearance may suggest it, Base64 is only suitable for encoding, not for encryption! 😉

Basic Authentication is particularly suitable for server-side authentication for a service using a technical user. Basic authentication via an application that runs on the client side, e.g., in the web browser, should be avoided. Since this requires the unencrypted password, there is a high risk that attackers will succeed in stealing the data and thus gaining unauthorized access to the service. Since credentials are transmitted unencrypted using this method, it should be ensured in any case that communication takes place encrypted via HTTPS to prevent data loss through man-in-the-middle attacks. If a generic technical user is not sufficient for authentication, but a real personal user is required, Basic Authentication is also not the means of choice, because then the disadvantage is that the server side receives not only the username but also the password in plain text and the user has no control over how this sensitive information is further processed. In this case, a token-based protocol such as OAuth2 should be used. We will look at this in detail in later parts of this series.

Cloud 2 Cloud – Basic Authentication

https://github.com/jfranken/sap-btp-destinations/tree/cloud-2-cloud-basic-authentication

The underlying architecture of the Basic Authentication Destinations example is almost identical to the architecture of the No Authentication example. Two SAP CAP applications, client and server, are deployed in the same Cloud Foundry space. A destination to the server is stored in the destination service, the client application reads the detailed information about this destination via HTTP request to the destination service. In order to be able to execute this request successfully, an access token must first be requested via the platform UAA, and this token must then be sent to the destination service in the request. To obtain a token, the client ID and client secret of the destination service are sent to the platform UAA; basic authentication is also used here.

The complete communication flow is shown in the diagram below:

For a better illustration, the complete response of the Destination Service is also shown here. As you can see, it not only contains the destination configuration, but also a kitchen-ready AuthToken that contains the Base64-encoded username-password pair:

{

  "owner": {

    "SubaccountId": "00000000-0000-0000-0000-000000000000",

    "InstanceId": "00000000-0000-0000-0000-000000000000"

  },

  "destinationConfiguration": {

    "Name": "Server",

    "Type": "HTTP",

    "URL": "https://00000000trial-dev-server.cfapps.0000-000.hana.ondemand.com/server/helloWorldServer()",

    "Authentication": "BasicAuthentication",

    "ProxyType": "Internet",

    "User": "myUsername",

    "Password": "superStrongPassword"

  },

  "authTokens": [

    {

      "type": "Basic",

      "value": "bXlVc2VybmFtZTpzdXBlclN0cm9uZ1Bhc3N3b3Jk",

      "http_header": {

        "key": "Authorization",

        "value": "Basic bXlVc2VybmFtZTpzdXBlclN0cm9uZ1Bhc3N3b3Jk"

      }

    }

  ]

}

Client Implementation

As in the first part of the series, the client includes two alternative implementations. On the one hand, the server call via Cloud SDK, and on the other hand, a plain variant that illustrates the communication processes step by step.

Cloud SDK

srv.on('helloWorldClientCloudSDK', async () => {

    return executeHttpRequest({ destinationName: 'Server' })

        .then((response) => response.data)

})

Plain

srv.on('helloWorldClientPlain', async () => {

    // ...

    // fetching token for destination service and reading

    // destination from destination service is handled

    // in the same way as in part 1 of this series

    // ...

    const destinationResponse = await axios.get(

        destination.destinationConfiguration.URL, {

            headers: {

                // alternatively, you can also read the already

                // encoded value from destination.authTokens[0].value

                Authorization: 'Basic ' + 

                    btoa(

                        destination.destinationConfiguration.User + 

                        ':' + 

                        destination.destinationConfiguration.Password

                    ),

            },

        }

    )

    return destinationResponse.data

}

Server Implementation

The server implementation is kept relatively simple, and despite the disclaimer at the end of this chapter, I explicitly point out once again: this implementation presented here is not suitable for productive use!

When the request arrives, the server reads the authorization header, decodes username and password and checks if they match the expected values. If yes, the already known response "Hello World from Server" is returned. Otherwise, the string "Unauthorized" is used to indicate that the credentials are not correct.

module.exports = async (srv) => {

    srv.on('helloWorldServer', async (req) => {

        const authHeader = req.headers.authorization

        if (authHeader.indexOf('Basic ') === 0) {

            const username = atob(authHeader.split(' ')[1]).split(':')[0]

            const password = atob(authHeader.split(' ')[1]).split(':')[1]

            if (username === 'myUsername' && password === 'superStrongPassword') {

                return 'Hello World from Server'

            }

        }

        return 'Unauthorized'

    })

}

Execution

Once the client and server are deployed and the destination is configured correctly, calls to both client endpoints should return the following result:

The moment has come for us to give ourselves a quick appreciative pat on the back. We have implemented a server that is secured by a technical user and that our client can access with an appropriately configured destination. This is still quite "basic", but admittedly the name of this authentication type doesn't promise more. In the next part of the series we will deal with the OAuth2 client credential flow (OAuth2ClientCredentials). While we are still on the level of technical users, the following parts will then deal with the question of how the identity of a real end user can be passed on from the client to the server, where we will distinguish between two different scenarios:

Client and server are deployed within the same subaccount (OAuth2UserTokenExchange).

Client and server are deployed in different subaccounts (or even different global accounts) (OAuth2SAMLBearerAssertion)

Until then, have fun trying it out and as always, I'm looking forward to your feedback! 🙂

Disclaimer

The code examples provided are not suitable to be transferred 1:1 into productive implementations, but they only serve to illustrate the functioning of destinations and Destination Service. In some cases, the interaction with the Destination Service is deliberately implemented in a “cumbersome” manner in order to illustrate the communication processes as explicitly and in detail as possible. SAP CAP and the SAP Cloud SDK provide various functionality to simplify and abstract the use of destinations. However, this would be more of a hindrance than a benefit to the purpose of the illustration.

Why the TypeScript Sheriff has come to clean up your JavaScript (Part 1 of 3)

2023-07-05T18:26:31+02:00

TLDR: TypeScript simply adds types to JavaScript. We can reduce run-time errors by catching more bugs at design-time. It doesn't ruin the flexibility and expressiveness of JavaScript and it's easy to start using TypeScript in your SAP development today.

JavaScript is one of the most important programming languages. In the 2023 Stack Overflow developer survey it was listed as the most commonly used language amongst professional developers. I enjoy using JavaScript because I find it's flexibility is conducive to good 'flow'. It's easy for me to 'express myself' as I write.

It's also pervasive because it runs almost everywhere. Every modern browser has a JavaScript runtime, but of course it can run on servers too.

A downside of the dynamic typing inherent in JavaScript (as opposed to the static typing of Java, for example) is that it's easy for type-related bugs to slip through the net and materialise as run-time errors.

What if there was a way to catch these bugs at design-time, without spoiling the expressiveness and flexibility of JavaScript? Such a tool would have a big potential to change the world, because of the near-ubiquity of JavaScript . Happily there is such a tool, and it goes by the name of TypeScript.

In this short series I would like to introduce you to TypeScript and explain how it can improve your JavaScript development. I will focus on the SAP ecosystem and I hope to share the perspective of a new convert, not an expert (because I am not a TypeScript expert).

To learn more we must head to the 'old west' where we will meet the TypeScript Sheriff. He's tough on type errors but don't worry for your safety. As long as you aren't a cowboy coder you have nothing to fear...

The TypeScript Sheriff

Why TypeScript?

The easiest way to explain why TypeScript exists is to consider a simple example. Here we scaffold a function to book a ticket on a stagecoach, then we call the function to book a seat from San Francisco to Boulder City

function stagecoachBook(startPoint, endPoint, date) {

    //logic here

}



stagecoachBook(new Date("1860-06-17T00:00:00"), "San Francisco", "Boulder City");

This JavaScript code looks good, but when we run it what will happen? A run-time error! Whilst we have the correct number of parameters, they aren't in the right order. Many IDEs (& linters) won't pick this up. It might be easy enough to find the bug (depending on our test coverage) but what if the mistake is in a obscure piece of code that only runs in exceptional circumstances?

Far better to introduce static types, as in this TypeScript example below. Now we specify the types of the function parameters

function stagecoachBook(startPoint: string, endpoint: string, date: Date) {

    //logic here

}



stagecoachBook(new Date("1860-06-17T00:00:00"), "San Francisco", "Boulder City");

The IDE will give us an error like this:

Argument of type 'Date' is not assignable to parameter of type 'string'.

So much better to find our error at design-time! Other common type errors prevented are typos in function names and assignments to constants (using const when you should have used let).

Zooming up from the desert weeds to a wider vista it should be obvious that the advantages are more than just avoiding the errors shown in these simple examples. Explicitly declaring types makes code easier to read. In larger codebases it makes life much easier if consumers of library functions can see exactly what parameters they should pass.

Another big advantage is that including types enables the IDE to support code completion, which makes us more productive. Imagine if you have an entity with a large number of properties. How great to have code completion on those property names.

Do you think TypeScript might assist you in your JavaScript programming? Would you like to reduce the number of runtime errors you have to remediate? If so move on to Part 2 in the series, in which we will discuss how to use TypeScript in the SAP ecosystem. Part 3 will cover some tips to help you get started.

TypeScript Sheriff: How can I use TypeScript in the SAP ecosystem? (Part 2 of 3)

2023-07-05T18:30:19+02:00

TLDR: TypeScript is nothing more than JavaScript plus types. TypeScript files with a .ts extension are transpiled to plain JavaScript files with a .js extension, so that they will be understood by a JavaScript runtime. We can use TypeScript wherever we can use JavaScript, and it's well supported in the SAP ecosystem.

Now that we have covered why we use TypeScript (see Part 1), lets move on to explaining what it is and how we can use it.

What is TypeScript?

As explained in the documentation, TypeScript is simply JavaScript plus types. All of JavaScript is in TypeScript. If you are familiar with JavaScript then you will be instantly familiar with TypeScript.

TypeScript is JavaScript plus types

How does TypeScript work?

If you have built front-end apps using JavaScript (e.g. SAP UI5) you will be familiar with minifying your code. The code we write gets transformed before it runs in the browser. This is just for performance reasons (to speed download). Variable names are shortened, whitespace is removed and files are combined.

With TypeScript we just add a predecessor step. The code we write gets transpiled by the TypeScript compiler before minification. The types, which the runtime doesn’t understand, are removed.

In the example above we've added types to the function signature. We've made it clear that the arguments passed in must be of type string/string/Date (see inside parenthesis) and that a string will be returned (see immediately following parenthesis).

As you can see from the diagram, TypeScript files are distinguished by the extension .ts (rather than .js). If you open these files they will look just like JavaScript, apart from the types you find here and there. The transpilation step transforms .ts files to .js files, removing the types. It is the .js files which can be interpreted by the JavaScript runtime.

Happily, when testing we can still debug the original TypeScript source code (.ts), because these files are still available (to the client browser) for download when in debug mode.

NB this example is for front-end code. With back-end code (e.g. with Node.js running on the server) we don’t need the minification step because the code doesn't need to be downloaded to a client.

Where can we use TypeScript in an SAP context?

Consider the following scenario. We are extending the standard functionality of our S/4HANA system. We are using SAP BTP to build a side-by-side extension because we want to keep our 'core clean' and enable easy upgrades of S/4HANA.

Where can we use TypeScript in this scenario? Everywhere of course! Out of the box we get TypeScript support from

The SAP Cloud Application Programming Model (a.k.a. CAP) which we can use to provision OData services for the back-end of our application

SAP UI5, which we can use to build the user interface for the front-end of our application (consuming the CAP services)

The SAP Cloud SDK which makes it easy for us to consume external services (APIs), such as those provided by S/4HANA

At the time of writing these frameworks differ slightly in the level of support they provide for TypeScript. The Cloud SDK, for example, already generates OData Clients in TypeScript form (.ts files) by default. UI5 provides types for controls and modules and the tooling supports TypeScript too.

CAP does provide standard types (e.g. for Request) and generating types for the OData services you create is a new feature (see @cap-js/cds-typer). It's aimed at those using JavaScript (not TypeScript) and in its current form there are some compatibility issues with TypeScript (running cds-ts commands can overwrite the files generated by cds-typer). I would prefer that cds-typer would support TypeScript so that we can simply say 'the SAP BTP stack has full TypeScript support' without need of caveats.

NB I have shown an SAP-only stack here, but of course I could use non-SAP tools and frameworks too. For example I could build the front-end with React and use TypeScript with that.

Where can I find all the information I need to get started?

The official TypeScript documentation is a great place to begin your learning. It's comprehensive, gives a good introduction and can serve as a reference once you get going.

For UI5 there is a central UI5 vs. TypeScript page. I also recommend Peter Muessig's blog Getting Started with TypeScript for UI5 Application Development as an introduction.

andreas.kunz has put together a comprehensive UI5 TypeScript Tutorial based on a recent workshop at UI5Con. See also the video presentation.

See Using TypeScript for the lowdown on using TypeScript with CAP.

There isn't a specific page in the SAP Cloud SDK on using TypeScript (that I can find), however support is good and TypeScript is referenced across the documentation.

SAP have created a full-stack reference app that uses TypeScript. I found it very useful to see what a working TypeScript app looks like.

Andreas Kunz has investigated the easiest ways to generate types from OData metadata in his blog post UI5 and TypeScript: how to generate types for OData services. If you have entities in your services with a non-trivial number of properties then you might want to generate interfaces to use in your code (rather than just creating them manually), and CAP doesn't currently do this for you.

Now read Part 3 of this series, to get some tips to help you get started with TypeScript.

So, be a good citizen and use types with your JavaScript. That way you can stay on side with the TypeScript Sheriff...

The TypeScript Sheriff

TypeScript Sheriff: Tips for newbies (Part 3 of 3)

2023-07-05T18:31:48+02:00

TLDR: We can use TypeScript types in every line of our code, but that doesn't mean that we have to use them in every line. You can configure the TypeScript compiler as well as clearing its cache, if you need to. Let the IDE handle those imports.

If you need a recap on why we use TypeScript and how we use it check out Part 1 and Part 2 of this series.

In this final post of the series I will share some tips on how to use TypeScript in your SAP-ecosystem development. I'm a recent convert (or 'reformed character' if you prefer) rather than a TypeScript expert, but I hope this perspective will be useful for others.

Use the import prompt

We use import statements to reference the types provided by the various frameworks that I discussed in the previous post. This is particularly important in UI5 development where we need to need to use the types that correspond to the UI controls on our views. The good news is that our IDE can add the import statements for us.

In this example, from SAP Business Application Studio, we can click on the Quick Fix prompt.....

...and then choose from the list of matching types

The import statement will be added for us. In this case there is ambiguity (which 'Button' class are we referencing?) but if the module name is unique the import will be added automatically.

Watch your case

In TypeScript, as in JavaScript, primitives are written all lower case: e.g. string, number, boolean. Object types have title case: e.g. Date. With string in particular you need to be careful to use the correct case. As we are usually referring the primitive type we should almost always be using string rather than String in our types.

Less is more

Once I was up and running with TypeScript I loved using types and declared an explicit type everywhere I could. The downside to this is that the code becomes a little 'busy'.

TypeScript is smart enough to distinguish between situations in which an explicit type is needed and when there is no ambiguity and the type can be inferred, so in my opinion it's best to leave out the explicit types unless they add value. Consider the following example. The calculateAgeAtDeath function accepts a Sheriff object as a parameter and returns the age of the that sheriff (a number). The return type of the function is explicitly declared as is the type of the variable we assigned to it.

Both of these declarations are redundant and can be removed. The return type of the function will always be number, because are returning the difference between two numbers. If so, the variable to which we assign that return value will also be a number. We can dispense with the types altogether.

Clearing the cache

Very occasionally your IDE may report spurious errors. This can be resolved by clearing the cache of the TypeScript compiler. In Business Application Studio (or Visual Studio Code) this can be done with the Restart TS Server command.

Use the menu path View->Command Palette then type to filter the commands until Restart TS Server appears. NB You must have a .ts file open in the editor when you launch the Command Palette, otherwise this command won't appear.

Taking a break from types

Of course when using TypeScript we want to declare types wherever they resolve ambiguity and add value (see above). There may occasionally be times however when you feel that including types is too difficult or impedes your 'flow' too much.

One simple approach in this scenario is to use the generic any type. This is a way to acknowledge that a type is appropriate but still leave the exact type to be inferred at run-time.

let something: any = …

If you're doing this then your code may have a .ts suffix but it isn't really superior to the plain JavaScript we are replacing! For this reason you are risking a knock at the door from the TypeScript Sheriff

The TypeScript Sheriff

There are also annotations which give the TypeScript compiler instructions. With these you can use proper types for the vast majority of your code, but allow for the odd exception case.

@ts-ignore        //no checks for the next line

@ts-nocheck       //no checks for the whole file

@ts-expect-error  //expecting an error, only highlight if there isn't one

Confgure the TypeScript Compiler

The tsconfig.json file sits in the root of your project. It contains various options for the TypeScript compiler, controlling for example the destination folder and language version (e.g. es6) for the .js files generated.

Don't be a cowboy coder....

Don't be a 'cowboy coder', use TypeScript to stay on the right side of the law and hopefully these tips will assist you on your journey to more reliable and readable code

Lets Deep dive into CAPM and HANA Cloud --> HANACap

2023-07-16T22:03:44+02:00

Hello everyone!

I hope you're coding and having a great time!!!

Currently, I am engaged in working on various BTP (Business Technology Platform) services, and designing and development constitute my everyday tasks. As expected, we encounter some challenges along the way, which is quite normal 🙂 Therefore, I've decided to document these challenges along with their corresponding solutions in my GitHub repository. This compilation is expected to grow into a substantial list over time, but for now, I have already included two challenges and their respective solutions.

Pre-requisite:

Get your BTP Trial Account setup before you jump into Coding 🙂 + VSCode or BAS

Here you go GitHub Repo - https://github.com/shivamshukla12/SAP-CAP/tree/main

Write your first CAP Application - Its a simple one Hello World

Create one entity in your CAP App and Insert / Retrieve some Hard coded Values

Add some CSV Data in your CAP Application

Run and retrieve your CSV Data

Connect your CAP Application to BTP Space

Provision Services for your CAP Application

Enable HANA Cloud Instance and Add HDI Containers

Build and Deploy your CAP Application on CF ( Cloud Foundry )

Run and Debug your CAP Application

Tutorial Highlights:

Say Hello to SAP CAP

Supplier Entity for Projection

Supplier JS File For logic and data export

GET Request :

Using CDS in CAP - you can simply write select statement and Wrap it in NodeJS and run the query to get data back from the database

POST Request :

Using CDS in CAP - you can make POST Calls directly on Entity exposed which will Create New entry in Database

Delete Request :

Using CDS in CAP - You can use custom handler function to delete records from the database - A Custom logic or i would say simply wrap your delete statement in Nodejs and run it on CDS.

Highlights

CRUD Operations in CAP Entity

Coming up Next...

 How SQL is giving the real value to your cloud Application Programming -- SQL is the magic

 Working with multiple entities and Association

 Projection , Aggregate functions and Joins

```
 Function Import in CAP
```

Keep Learning and Keep Sharing 🙂

PS: I will Keep posting Updates in my this blog and Updating the repo for promised exercises

Thanks Shivam

Up-level your SAP OData APIs with Azure API Management

2023-07-21T08:20:38+02:00

🦄Featured GitHub repos SAP Cloud SDK on Azure App Service Quickstart

👉🏿Annoucement post on the Microsoft TechCommunity by my Engineering colleagues

🔍Find the Preview note here.

*Beforehand an API definition conversion to OpenAPI had been necessary. See this blog for more info.

Dear community,

As of yesterday, you may directly consume* SAP OData APIs via Azure API Management from any-premise no matter where they live from all Azure regions🎉: SAP Gateway, BTP ABAP environment, S/4HANA Cloud private or public edition in RISE or GROW, SuccessFactors, Ariba, Concur, Commerce Cloud, or SAP Business Technology Platform (BTP) etc.🤩

Azure API Management secures and simplifies the SAP API integration with popular Microsoft services like Power Platform, Azure Functions, Microsoft Entra ID (formerly Azure AD) and Microsoft Sentinel to name a few.

And of course, you get standard API Management features like fully private virtual network integration, multi-location deployment, hybrid and multi-cloud gateways, global presence (more regions that any other cloud provider), throttling, quota handling, request validation before it even hits SAP, and cloud native authentication flows in one central place🤘.

In case you favor SAP API Management on Azure, find your way to SAP Integration Suite on Azure here. See SAP Edge Integration Cell to run your iFlows on any-premise including any Azure region or Edge deployments.

Find your way around the highlighted Azure API Management features, SDKs, quickstart repos, deep-dive blog posts, and more from below.

API Creation, Design & blueprints

Enable modern GraphQL for your OData APIs.

See this ABAP Cloud scenario from my BTP ABAP environment (steampunk) blog series.

Spin up your SAP app extension powered by the SAP Cloud SDK on Azure with API Management with one command

The Azure Developer CLI handles the whole app lifecycle including the API create from schema and attaching policies.

Speed up your Azure API Management Policy design with GitHub Copilot and ChatGPT

Since there are many policies published out there the Large-Language-Model is quite good at creating APIM policies.

Try below prompt either in GitHub Copilot chat or ChatGPT to get started:

Create an azure apim policy handling csrf tokens with sap odata apis

Reason about and debug complex policies on Azure API Management using breakpoints from Visual Studio Code

Don’t forget to turn on tracing on APIM! Otherwise, there is no process attach 😉

Create an Azure API Management service including APIs using Terraform

Check out our SAP Cloud SDK quickstart repos for more details on injecting APIs into existing API Management instances.

Authentication & Security

Activate Defender for APIs in Azure API Management to automatically detect threats in your SAP APIs

Unused days, authentication type, classification of sensitive data in response, and detection of suspicious API traffic patterns, already go a long way in securing your API estate.

Apply our standard policy for SAP Principal Propagation to map Microsoft authenticated users to SAP backend users

Learn more from this blog post.

Take a deep dive on the involved SAP OAuth server from here:

Apply Azure API Management to lift the burden of X.509 client certificate handling for consumers apps integrating with BTP ABAP environment

Utilize Azure API Management Authorization Provider to streamline your auth setup and ease policy design

Use Azure API Management Authorizations🎥 with apps like Power Platform or SAP Build Process Automation to integrate with SAP faster.

Stay tuned for further simplifications in this space for SAP workloads specifically.

APIOps

UI-based API creation, modification, and deletion is doable for smaller API estates. However, enterprise scale requires API-as-Code and pipelining approaches with CD/CD.

Use Azure Developer CLI to handle the complete lifecycle of your SAP extension app, including the SAP OData API in Azure API Management

You may choose from Bicep or Terraform. See this repo for more details.

Apply the Azure API Management DevOps kit including GitHub Actions. Automate API deployments with APIOps and Azure DevOps

For the ABAP RAP part of the house have a look at combining the git-based flows via Git-enabled Change and Transport System (gCTS)

Either have Azure Developer CLI (AZD) trigger the gCTS workflow or receive the trigger from gCTS using AZD hooks.

Connectivity

Connect SAP BTP based apps like SAP CAP, Cloud Integration, Build Workzone Standard Edition, or SAP Build Apps with your APIs via SAP Private Link

Reach your private Azure API Management instance securely via the private link traversing the Azure Application Gateway and the its web application firewall. Learn more from this blog post.

Keep your SAP OData APIs fully private by injecting an internal Azure API Management instance into the private Azure virtual network

You may customize this approach to securely expose the private SAP APIs via Azure API Management to the Internet using the external mode.

Use the Self-hosted Gateway of Azure API Management for hybrid deployments

The use cases span from multi-cloud, any-premise (your local data center etc.) to the Edge (think factories, oil-rigs, etc.).

Export APIs from Azure API Management to the Power Platform

Final Words

Only thing left to say: happy integrating everyone 😎

Start your Azure Journey regarding your SAP integration here for free. See the Azure API Management serverless and developer tier for cloud credit effective use. For SAP API Management on Azure see FREE tier and trial plans.

Find the announcement blog post by my Azure APIM colleagues on the Microsoft TechCommunity here.

Discover additional Microsoft integration scenarios from our aggregator article.

Reach out to me for a deep dive into SAP integration with APIs 🤝

Cheers

Martin

SAP Configure,Price,Quote (CPQ) APIs with resilience with SAP BTP, Kyma runtime

2023-07-28T08:44:58+02:00

SAP Configure, Price and Quote APIs with OAuth2SAMLBearerAssertion

SAP CPQ configure, price, and quote solution is part of the SAP Customer Experience solutions portfolio.

Furthermore, SAP CPQ offers a reach palette of integration capabilities with other SAP Solutions, for instance, with SAP Commerce Cloud

So how does SAP Configure, Price and Quote relate to SAP Kyma and SAP Cloud SDK?

Surprise, surprise...

Putting it all together

Table of Contents

About me

SAP CPQ APIs

Per aspera ad astra. Solution brief.
1. SAP CPQ easy with kyma-powered multi-tenant application

Setting up a SAP CPQ Trusted Application (OAuth2 client).

SAP BTP sub-account and instance level destination definitions.
1. Examples of SAP CPQ destination definitions

Implementation and troubleshooting notes.
1. SAP Cloud-SDK with built-in resilience middleware with Kyma runtime to the rescue
2. DIY: SAML Assertion and the bearer access token

SAP CPQ APIs

From the documentation...

With API you can update quotes, execute quote actions, create customers or business partners, update users and so on.

For example, if a company uses a separate application to process shipping information after an order has been placed, SAP CPQ API can be used to update a quote with shipping information, such as a tracking number, tracking URL, estimated shipping date, and so on.

The focus of this brief is the SAP CPQ REST APIs with Token API Authentication as documented here:

SAP CPQ API Documentation | SAP Help

SAP CPQ API Documentation | SAP PDF.

Per aspera ad astra. Solution brief and architecture

At the heart of the solution are:

SAP CPQ tenant, SAP BTP, Kyma runtime and SAP BTP services.

SAP BTP multi-tenancy model - with a standalone multi-tenant @sap/approuter deployed to a kyma cluster.

SAP BTP destination service - with a single instance-level OAuth2SAMLBearerAssertion destination

optionally one or more sub-account level S/4HANA Private and Public Cloud destinations

standard SAP components and libraries/SDKs - meaning same application code is deployable to multiple runtime environments.

SAP CPQ easy with kyma-powered multi-tenant application

Good to know:

all destinations are consumed using executeHttpRequest SAP Cloud-SDK method with a built-in resilience mechanism.

communication between the SAP approuter's frontend and kyma backend service is intrinsic (local) via the in-cluster mesh.

on premise destinations are accessible via a supported kyma connectivity proxy component

Setting up a SAP CPQ Trusted Application (OAuth2 client)

Token API Authentication. OAuth 2.0 Assertion Profiles

OAuth 2.0 Assertion Profiles authentication is implemented in SAP CPQ with the aim of standardizing server-to-server authentication. This type of authentication allows administrators to generate an access token without relying on the logged-in user (no need to store passwords).

You will be asked to set up a Trusted Application (an OAuth2 client) with your SAP CPQ tenant and required to enter there an issuer URL.

Issuer - the URL of the system to which the access token needs to be issued. From that URL users will be accessing SAP CPQ .

With SAML bearer grant type, this must be the value of the SAML Assertion issuer.

The redirect_uri is to be used only with the Authorization code grant type so best is to void it.

You will also be provided with the client id, client secret and the token issuance endpoint. Please make a note of them as these values will no longer be available after you have saved the Trusted Application.

Once the OAuth2 application has been created you can choose between JWT and SAML bearer grant types as documented here: OAuth 2.0 Assertion Profiles | SAP Help.

Lets' assume you want to use the SAML bearer grant type as documented here: Generate SAML Bearer Grant Type | SAP Help

In a nutshell, a SAML bearer grant type consists of exchanging a BTP user identity against a bearer access token coming from a SAP CPQ tenant.

We shall be using an OAuth2SAMLBearerAssertion destination to implement the above grant type.

In a nutshell, a BTP user JWT token's user claim is used to create a SAML Assertion as to trigger an IDP-delegated authentication flow to eventually execute a remote (password-less and unmanned) login into SAP CPQ from a BTP application.

Furthermore, a SAML Assertion must be digitally signed with a private key of a signing certificate. That's why you need to provide a public x509 certificate of the signing key in the Trusted Application definition, as follows:

SAP CPQ OAuth2 configuration

The second parameter is the value of the user claim.

SAP BTP sub-account and instance level destination definitions

The very fact the issuer must be a valid URL with the https scheme has another very important ramification.

Namely, that issuer URL requirement disqualifies the usage of a default destination service trust as explained below:

For the assertionIssuer property to work, one would need to have KeyStoreLocation and KeyStorePassword defined (a key pair) for a SAP CPQ destination.
Otherwise, as a fallback, the sub-account's trust key pair would be used, but these settings are configured to always use the issuer which doesn't have https://.

The solution here is to generate or upload a keystore (for example in a p12 file) through the Certificates button, and point KeyStoreLocation to the name of such certificate, with KeyStorePassword as the appropriate password if applicable. Then the assertionIssuer property of a destination would work.

In other words, you must use your own keystore with both private and public keys instead and declare the issuer URL via a destination assertionIssuer property. Please refer to this gist for further details.

Examples of SAP CPQ destination definitions

a sub-account level destination definition

an instance level destination definition

In order to test these definitions you will need to provide a BTP user JWT token that will have your SAP CPQ user's claim (for instance user_name if NameId selected in SAP CPQ OAuth2 client definition, as depicted above)

Then, you could test the CPQ destinations leveraging SAP Cloud-SDK, for instance:

https://<approuter host>/srv/harmony?destination=cpq-anywhere&path=/customapi/executescript?scriptname=GetOpportunityQuotes



{

  "data": [

    {

      "Quotes": [

        {

          "DateCreated": "<DateCreated>",

          "Offer_Exp_Date": "<Offer_Exp_Date>",

          "EditableforSAP": null,

          "QuoteEngine": "Quote 1.0",

          "TotalSummary": {

            "TotalRevenue": 0,

            "Service": 0,

            "Cloud": 0,

            "TotalContractValue": 0,

            "OnPremise": 0

          },

          "OnPremiseRevenue": false,

          "DealHealth": "High Risk",

          "ContractStart": "<ContractStart>",

          "ProcessTypeCode": null,

          "IsECS": false,

          "ServiceRevenue": false,

          "QuoteNumber": "<QuoteNumber>",

          "LinkedServicesContract": "New Contract",

          "CMSID": "",

          "CloudRevenue": true,

          "Currency": "EUR",

          "QuoteStatus": "Quote In Progress",

          "Description": null,

          "ValidUntilDate": "<ValidUntilDate>",

          "Total": 0,

          "ProcessType": "",

          "WriteAccess": true,

          "IsMain": true,

          "QuoteStatusId": 45,

          "RestructureType": null,

          "PSBundleExtConfigFlag": false,

          "ReadAccess": true,

          "VisibletoChannelPartner": null,

          "ContractEnd": "<ContractEnd>",

          "WorkAtRisk": false

        }

      ],

      "OpportunityId": "<OpportunityId>"

    }

  ]

}

or...simply using a curl command as explained here.

Implementation and troubleshooting notes

During the implementation of the SAP CPQ APIs I have encountered a number of major road blocks. And, to a large extent, both kyma runtime and SAP Cloud-SDK have proven very helpful in overcoming them.

I have gathered a number of implementation and troubleshooting notes to help explain what it was and how it was addressed, namely:

SAP Cloud-SDK with built-in resilience middleware with Kyma runtime to the rescue

DIY: SAML Assertion and the bearer access token

SAP Cloud SDK destinations | SAP Cloud SDK

Per aspera ad astra. Who am I?

You can follow me in SAP Community: piotr.tesny

SAP Kyma Community and SAP BTP, Kyma runtime Q&A Tags

Be balsamiq;

Technical User Date & Time format Settings Change in C4C

2023-08-23T05:21:58+02:00

Hello Developers!!!

I hope you’re doing well.

The blog is about the Date and time format in the response while querying a C4C OData service with a technical user through Postman. Later, we will also discuss how to assign a fixed time zone for a Technical User as well.

Issue:

We created a KUT field in the UI and wrote code to capture the date & time on save based on conditions. Then these fields were extended to the OData services as well.

When we began to test the OData service via Postman I noticed that the newly added Data Time fields in the response body are being populated like below.

{

    "d": {

        "results": [

            {

                "__metadata": {

                    "uri": "Removed due to security reasons",

                    "type": "sapbyd.RPZVVVVVVVVVVVAD3DQueryResult"

                },

                "CVDOC_CREATEDATE_LOCAL": "/Date(1690070400000)/",

                "CVDOC_ID": "1XX55",

                "CVYLD0005Y_D2E80000A9": "5XX4",



                "CVs1A000000000031DB8A": "08/01/2023 11:49:45 INDIA"",

                "CVs100000000000047919": "08/01/2023 09:49:45 INDIA",



                "TDSC_ZSALPHASE_01": "In-Progress",

                "TUSER_ZSTATUS_CODE_01": "Converted"

            }

        ]

    }

}

(I have separated the two new fields in the middle of the above response.)

Here in the response, we are receiving the time zone as INDIA for both fields. When I checked the Technical user time format, it was empty.

In our case, we are using a third-party middleware so they require all the possible time zones to be configured to transform the data, else the data being displayed will be irrelevant in the destination system.

Resolution:

Hence the time zone configuration will be a lengthy process in the middleware we have set a Time Zone for that specific Technical user so whenever you query, in the response you will have the fixed time zone.

You may follow the below steps to navigate to Technical User settings & view the current time zone for the user.

1) Go to Administrator > General Settings & from there open Support and Technical Users.

Support and Technical Users

2) Click & Open the Technical user, to view the current time zone settings before change.

Choose User

3) Scroll down and navigate to the Regional Settings, where you can see the current Time zone.

Current Time Zone

Kindly follow the below steps to assign a constant Time Zone for the Technical User.

1) Login to C4C using Technical User.

Navigate to Settings

2) Go to My Settings > Regional Settings & Choose the preferred time zone.

Time Zone Changed

Result:

When we set a fixed time zone for the Interface/Technical User. Thereafter, the response had a constant Time Zone.

The below sample response will give you the result of the change.

{

    "d": {

        "results": [

            {

                "__metadata": {

                    "uri": "Removed due to Privacy reasons",

                    "type": "sapbyd.RPZVVVVVVVVVVVAD3DQueryResult"

                },

                "CVDOC_CREATEDATE_LOCAL": "/Date(1690070400000)/",

                "CVDOC_ID": "1XX55",

                "CVYLD0005Y_D2E80000A9": "5XX4",



                "CVs1A000000000031DB8A": "08/01/2023 11:49:45 UTC+3"",

                "CVs100000000000047919": "08/01/2023 09:49:45 UTC+3",



                "TDSC_ZSALPHASE_01": "In-Progress",

                "TUSER_ZSTATUS_CODE_01": "Converted"

            }

        ]

    }

}

Hope you enjoyed the blog. We have a lot more coming, so do like and follow for more such content.

Bye bye!! 🙂

Ananthu R Biju

Senior C4C Consultant

SAP BTP Destinations in a nutshell Part 3 - OAuth 2.0 Client Credentials

2023-10-08T09:15:07+02:00

Introduction

The goal of this series is to introduce the different destination types of the SAP BTP, to show how they work and also to make them tangible with basic and easy to execute code examples. In parts one and two of this series, I looked at the basics, as well as the simplest destination types, NoAuthentication and BasicAuthentication. In this part, I'll dive into a more complex topic for the first time: I'll show you how to implement an OAuth 2.0 client credentials flow using Destination.

OAuth 2.0

Before I turn to the concrete scenario and implementation, I will first take a closer look at the topic of OAuth. Most people in the IT environment have come across this term before, and a majority is still able to provide information when it comes to explaining at a high-level what it is and what it is used for. But as soon as it comes to the technical details, the exact workings of the protocols, the different authentication flows, etc., many (including me) quickly get tripped up. But fortunately I'm not alone in providing the most important information about OAuth, because there are also a large number of wonderful people who have a very deep understanding of the subject and are willing to document this knowledge and make it digitally available to their fellow world in an easy to understand way. One resource I came across a couple of years ago that has helped sharpen my understanding of this topic is this talk by Nate Barbettini: https://www.youtube.com/watch?v=996OiexHze0 I can highly recommend this video to anyone who would like to learn more about OAuth 2.0 (and for good measure, OIDC) or is looking for a simple yet solid introduction to the topic. The investment of this one hour is definitely worth it.

For those who are in a hurry, here is the most important information in a nutshell:

OAuth 2.0 is an open protocol that allows standardized, secure API authorization for desktop, web and mobile applications. This also covers the scenario of access delegation, i.e. that an application gets access to certain data or functionalities of another application with the permission of the user. Classic example: an application is granted permission by a user to send posts on Facebook or read contact data on their behalf.

4 Roles

Resource Owner - The owner of a resource (data). As a rule, this is simply a user, i.e. the person sitting in front of the computer / smartphone / tablet / ...

Resource Server - This is the application that stores the resources (data) of the resource owner (user)

Client - The client is the third-party application that wants to access resources (data) of the resource server on behalf of the resource owner (user) and needs a token for authentication that contains the corresponding authorization grant (so to speak, the proof that the client has received permission from the resource owner to access the resource server)

Authorization Server - The Authorization Server is the instance that manages Authorization grants and issues the tokens (these are usually JWT (JSON Web Tokens), i.e. JSON objects that contain the relevant token information) that authorize the client to access the Resource Server on behalf of the Resource Owner. In some cases, Resource Server and Authorization Server are identical, but often they are separate instances

Client Credentials Flow

Depending on the specific use case, there are different flows in the OAuth 2.0 standard. In this part of the series, we will look at the client credentials flow. In order for a client to access a resource server, it must be registered with the Authorization Server, for each registered client there are client credentials, these are ultimately username and password. In the client credentials flow, the client also acts as the resource owner, because it does not obtain delegated access to the resource server, but instead requests a token for itself from the authentication server (using basic authentication with the client credentials) in order to then authenticate itself to the resource server with its own (technical) identity outside of a user context.

XSUAA

The XSUAA service, inside of the SAP BTP, handles the authorization flow between users, identity providers, and the applications or services. The XSUAA service is an internal development from SAP dedicated for the SAP BTP. In the Cloud Foundry project, there is an open-source component called UAA. UAA is an OAuth provider which takes care of authentication and authorization. SAP used the base of UAA and extended it with SAP specific features to be used in SAP BTP.

https://learning.sap.com/learning-journey/discover-sap-business-technology-platform/illustrating-sap-authorization-and-trust-management-service-xsuaa-_b9fde282-4cff-4dca-b146-7c8f8dde9955

In the context of OAuth 2.0, XSUAA is acting as the authentication server, i.e. it manages authorization grants and issues and validates JWT tokens. Important to know is, that there is always one XSUAA service instance per subaccount. As you will also later see in the concrete example, it is best practice to bind a dedicated XSUAA "service" resource to every application service (in our example: Client and Server). It took me a while to understand that those XSUAA services are not real running services in terms of a deployed container or something similar, but actually this are "only" pairs of Client ID and Client Secret (plus some additional meta information) that are injected into the application environment variables (VCAP_SERVICES). I.e. this binding represents a client in the sense of OAuth 2.0 terminology.

Cloud 2 Cloud - OAuth 2.0 Client Credentials

https://github.com/jfranken/sap-btp-destinations/tree/cloud-2-cloud-oauth2-client-credentials

This all sounds rather abstract so far, so at this point I will fall back on our well-known example from the previous parts of this series to illustrate the use case:

In this scenario, the BTP Destinations Enthusiast acts as the resource owner, the server app is the resource server, and XSUAA represents the authorization server. When the user calls the client/helloWorldClientPlain(), the client app subsequently attempts to access the /server/helloWorldServer() endpoint upon execution, but not on behalf of the user, but in this scenarios by means of technical client credentials. This endpoint is secured using XSUAA, which means that the server app expects a JWT token in the request header, which is issued and validated by XSUAA. To obtain this token, the client makes use of an according OAuth2ClientCredentials destination in the destination service.

Server Implementation

At first, I will show you the basics of the implementation of the server app.

To be able to secure any endpoint of this service via XSUAA, we need to establish a binding between server app and XSUAA. This is done in the mta.yaml file that we use for the server app deployment:

...

resources:

...    

    - name: xsuaa-server-service

      type: org.cloudfoundry.managed-service

      parameters:

          service: xsuaa

          service-plan: application

          service-name: xsuaa-server-service

In addition, it is required to enable JWT authentication. With SAP CAP, this is pretty staightforward within the cds configuration, which is located in the .cdsrc.js:

{

    "requires": {

        "auth": {

            "kind": "jwt-auth"

        },

        "uaa": {

            "kind": "xsuaa"

        }

    }

}

Authentication checks can be added by means of annotations which can be added in the service CDS files (the example below shows the server-service.cds file), either on service level or for single entities / functions / actions. In the given example, I only add a very rudimentary check that requires nothing else than the caller to be authenticated at all (i.e. sending a valid JWT token, authenticated-user is an according pseudo role). It is also possible to check for concrete role assignments within the annotation, which is in real world scenarios normally the case, however, since this series aims at keeping the focus on the pure communication flow between the different instances, I try to keep it as simple as possible:

service ServerService @(requires: 'authenticated-user') {

    function helloWorldServer() returns String;

}

The service implementation within the file server-service.js isn't very spectacular and should be familiar to the attentive readers of the first two parts of the series:

module.exports = async (srv) => {

    srv.on('helloWorldServer', async (req) => {

        return 'Hello World from Server'

    })

}

Destination

As described above, the client app needs to use a destination to obtain a valid JWT token that allows access to the endpoint of the server app, which is secured via XSUAA. The most important aspect here is that I store the client credentials from the XSUAA binding of the server app in the destination, because these represent the OAuth 2.0 client that is authorized to access the server app. The destination configuration in detail is as follows:

Name: Server

Type: HTTP

URL: https://${SERVER_APP_ROUTE}/server/helloWorldServer()

ProxyType: Internet

Authentication: OAuth2ClientCredentials

Client ID: Server XSUAA Client ID from Service Binding

Client Secret: Server XSUAA Client Secret from Service Binding

Token Service URL: https://????????trial.authentication.????.hana.ondemand.com/oauth/token

Please check the README.md file in the github repo. There you find a detailed description how you can find the concrete URLs and credentials via the BTP Cockpit and the Cloud Foundry CLI.

Client Implementation

As always, the client includes two alternative implementations. On the one hand, the server call via Cloud SDK, and on the other hand, a plain variant that illustrates the communication processes step by step.

Cloud SDK

srv.on('helloWorldClientCloudSDK', async () => {

    return executeHttpRequest({ 

        destinationName: 'Server' 

    }).then((response) => response.data)

})

Plain

First, the client authenticates against XSUAA with the client credentials from the destination service binding. I.e. here we already have the first client credentials flow to obtain a token that allows the client app to access the destination service. Afterwards, the client app requests the destination "Server" from the destination service, which is described in the chapter above. During this call, the destination service executes another client credentials flow and adds the token into the response which is then sent back to the client app. This could already be used to access the endpoint of the server app. However, for demonstration purposes, the client app implementation triggers another client credentials flow against XSUAA with the client credentials of the destination configuration.

srv.on('helloWorldClientPlain', async () => {

    // get all the necessary destination service parameters from the  

    // service binding in the VCAP_SERVICES env variable

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

    const destinationServiceUrl =

        vcapServices.destination[0].credentials.uri + 

        '/destination-configuration/v1/destinations/'

    const destinationServiceClientId = 

        vcapServices.destination[0].credentials.clientid

    const destinationServiceClientSecret = 

        vcapServices.destination[0].credentials.clientsecret

    const destinationServiceTokenUrl = 

        vcapServices.destination[0].credentials.url + 

        '/oauth/token?grant_type=client_credentials'



    // before we can fetch the destination from the destination 

    // service, we need to retrieve an auth token

    const token = await axios.post(

        destinationServiceTokenUrl, 

        null, 

        {

            headers: {

                authorization: 'Basic ' + 

                    Buffer.from(

                        destinationServiceClientId + 

                        ':' +            

                        destinationServiceClientSecret'

                    ).toString('base64'),

            },

        }

    )

    const destinationServiceToken = token.data.access_token



    // with this token, we can now request the "Server" destination 

    // from the destination service

    const headers = {

        authorization: 'Bearer ' + destinationServiceToken,

    }

    const destinationResult = await axios.get(

        destinationServiceUrl + 'Server', 

        { headers }

    )

    const destination = destinationResult.data



    // now, we use the retrieved the destination information to send 

    // a HTTP request to the token service endpoint;

    // to authenticate, we take the Client ID attribute and the 

    // Client Secret attribute from the destination,

    // encode ClientId:ClientSecret to Base64 and send the resulting 

    // string prefixed with "Basic " as Authorization

    // header of the request;

    // as a response, we receive a JWT token that we can then use to 

    // authenticate against the server

    // alternatively, the JWT token could directly be fetched from 

    // destination.authTokens[0].value

    const jwtTokenResponse = await axios.get(

        destination.destinationConfiguration.tokenServiceURL + 

        '?grant_type=client_credentials', 

        {

            headers: {

                Authorization: 'Basic ' +

                btoa(destination.destinationConfiguration.clientId + 

                ':' + 

                destination.destinationConfiguration.clientSecret),

            }

        }

    )

    const jwtToken = jwtTokenResponse.data.access_token



    // here we call the server instance with the bearer token we 

    // received from the token service endpoint

    const destinationResponse = await axios.get(

        destination.destinationConfiguration.URL, 

        {

            headers: {

                Authorization: 'Bearer ' + jwtToken,

            },

        }

    )

    return destinationResponse.data

})

Execution

Once the client and server are deployed and the destination is configured correctly, calls to both client endpoints should return the following result:

That's it! In the next part of this series, I will go one step further. Instead of using technical client credentials, I will show you how you can use OAuth2TokenExchange destinations with authorization delegation. The client app will call the server app by propagating the identity of the user who calls the client endpoint in the beginning, i.e. we will cover one of the core scenarios for which OAuth 2.0 has been invented.

Disclaimer

The code examples provided are not suitable to be transferred 1:1 into productive implementations, but they only serve to illustrate the functioning of destinations and Destination Service. In some cases, the interaction with the Destination Service is deliberately implemented in a “cumbersome” manner in order to illustrate the communication processes as explicitly and in detail as possible. SAP CAP and the SAP Cloud SDK provide various functionality to simplify and abstract the use of destinations. However, this would be more of a hindrance than a benefit to the purpose of the illustration.

ABAP RFC connectivity from BTP Python buildpack

2023-10-30T15:52:39+01:00

ABAP RFC connectivity from BTP to ABAP systems is supported by SAP Cloud Connector, for BTP Java runtime only. This blog describes the RFC connectivity enablement for Python runtime, so that Python BTP applications can consume ABAP RFCs, as described in Deployment options section of Powerful web applications with old and new ABAP systems and related blogs.

Our "hello world" example is BTP Python buildpack, with Flask server, SAP/PyRFC and SAP NW RFC SDK.

The example source code: SAP-samples/node-rfc-samples/integration/pyrfc_btp can be deployed on BTP, or tested locally inside SAP/fundamental-tools/docker/btp_cflinuxfs4.Dockerfile docker container.

ABAP RFC connectivity from Python on Kyma works practically out of the box, using SAP/PyRFC and SAP NW RFC SDK inside docker container. Try SAP/fundamental-tools/docker/cflinuxfs4.Dockerfile for example.

Preparation

The ABAP RFC enablement of BTP Python buildpack requires the installation of SAP/PyRFC package and SAP NW RFC SDK registration on BTP host instance. It is similar to RFC enablement of NodeJS buildpack: ABAP RFC connectivity from BTP Node.JS buildpack and Kyma,

Python buildpack structure is shown on figure below

Buildpack

SAP NW RFC SDK files for Linux x64 are copied to app/nwrfcsdk folder and excluded from repository, in .gitignore.

SAP NW RFC SDK is not included in SAP/PyRFC because the license is different. SAP Support Portal is the only allowed public distribution channel for SAP NW RFC SDK.

The nwrfcsdk folder is added to app MANIFEST.in, to be included in app deployment

buildpack/app/MANIFEST.in

include nwrfcsdk

include sapnwrfc.ini

SAP NW RFC SDK home and library paths are added to buildpack manifest.yaml, for build and runtime registration

buildpack/manifest.yaml

buildpack/manifest.yaml

Local test

cd buildpack/app

pip install pyrfc flask

# do not install from requirements.txt unless your notebook runs on Linux



python serve.py

 * Serving Flask app 'serve'

 * Debug mode: off

 * Running on all addresses (0.0.0.0)

 * Running on http://127.0.0.1:3000

 * Running on http://10.98.207.132:3000

PyRFC and SAP NW RFC SDK are loaded and PyRFC version shown below

Flask server on http://127.0.0.1:3000

BTP Deployment

cd buildpack

cf push                                                           (py3.11.6) main

Pushing app pyrfcapp to org <redacted> / space dev as <redacted>...

Applying manifest file <redacted>/node-rfc-samples/integration/pyrfc_btp/buildpack/manifest.yaml...



Updating with these attributes...

  ---

  applications:

  - name: pyrfcapp

    path: <redacted>/node-rfc-samples/integration/pyrfc_btp/buildpack/app

    memory: 128M

+   default-route: true

    stack: cflinuxfs4

    buildpacks:

      https://github.com/cloudfoundry/python-buildpack.git

    command: python serve.py

    env:

      LD_LIBRARY_PATH: /home/vcap/app/nwrfcsdk/lib

      SAPNWRFC_HOME: /home/vcap/app/nwrfcsdk

    routes:

    - route: pyrfcapp.cfapps.eu10.hana.ondemand.com

Manifest applied

Packaging files to upload...

Uploading files...



Instances starting...



name:              pyrfcapp

requested state:   started

routes:            pyrfcapp.cfapps.eu10.hana.ondemand.com

last uploaded:     Mon 30 Oct 15:44:40 CET 2023

stack:             cflinuxfs4

buildpacks:        

        name                                                   version   detect output   buildpack name

        https://github.com/cloudfoundry/python-buildpack.git   1.8.15    python          python



type:            web

sidecars:        

instances:       1/1

memory usage:    128M

start command:   python serve.py

     state     since                  cpu    memory        disk           logging            details

#0   running   2023-10-30T14:44:56Z   1.1%   31M of 128M   372.2M of 1G   0/s of unlimited

When finished, the test route https://pyrfcapp.cfapps.eu10.hana.ondemand.com/ shows the same result as local test:

PyRFC with SAP NW RFC SDK on BTP

Next Steps

Once the RFC connectivity from Python is enabled, the connection parameters for ABAP system shall be configured, as described in Deployment options section of Powerful web applications with old and new ABAP systems and in related blogs

WebSocket RFC – RFC For the Internet

WebSocket RFC to Cloud Using SAP Business Connector

Hope you enjoyed reading and stay tuned for more updates.

Transient field’s usage in C4C custom development in Event-AfterLoading.absl script file

2023-11-22T00:36:31+01:00

In this blog, I am going to provide a solution for a product gap using transient field in custom development.

Below requirement has been taken as an example to explain the Transient field’s usage in a custom development using C4C Cloud application studio.

Problem statement: Appointment is cancelled when one of the attendee cancels in C4C

Requirement: When an attendee cancels the appointment in C4C (synced teams meeting from outlook), system is cancelling the appointment and sending the cancellation notification to all attendees though he is not the organizer. This is a gap in the solution. Ideally only organizer should be able to cancel the appointment and not the attendees.

Challenge: As per the business custom logic this cannot be achieved from the SAP C4C UI. Only option is to do in SAP Cloud application studio. We need to develop the solution at the time of After-loading the appointment, but the challenge is custom KUT or standard SAP field’s can’t be modified because fields are read-only in after-loading event of the business object.

Solution: To achieve this requirement, create a Transient Element (Field created in SDK) type indicator in business object extension and development custom logic updating this transient field to ‘True’ or ‘False’. Now when an user open an appointment in the after-loading event our custom logic will run and update transient element accordingly. Based on this transient element we can create a validation rule in the adaptation and apply the rule to the standard actions.

Below are the detailed steps with screenshots provided to achieve this custom development through SDK.

Step1: First open a solution in the SDK and we need to create a Business object extension for Activity management and then create a Transient Element type Indicator in the main node with proper naming.

Step2: Create an Event-AfterLoading.absl script file under Root.node and write the custom logic as per the requirement.

Step3: Here is the logic that I have used for this development.

import ABSL;

import AP.PC.IdentityManagement.Global;

import AP.Common.GDT;

import AP.FO.BusinessPartner.Global;



//development for hiding actions complete & cancel based on user loggedin with involved parties.

var lv_emp = Context.GetCurrentIdentityUUID();



if(!lv_emp.IsInitial())

{

 var query = Identity.QueryByElements;

 // 2. Selection

 var selectionParams = query.CreateSelectionParams();

 selectionParams.Add(query.UUID.content, "I", "EQ", Context.GetCurrentIdentityUUID().content);

 // Result

 var resultData = query.ExecuteDataOnly(selectionParams);

 if (resultData.Count() > 0)

 {

  var lv_query = Employee.QueryByIdentification;

  // 2. Selection

  var lv_selectionParams = lv_query.CreateSelectionParams();

  lv_selectionParams.Add(lv_query.UUID.content, "I", "EQ", resultData.GetFirst().BusinessPartnerUUID.content);

  // Result

  var lv_resultData = lv_query.Execute(lv_selectionParams);

  var empname;

  if(lv_resultData.CurrentCommon.GetFirst().IsSet())

  {

   if(!lv_resultData.CurrentCommon.GetFirst().BusinessPartnerFormattedName.IsInitial())

   {

    empname = lv_resultData.CurrentCommon.GetFirst().BusinessPartnerFormattedName;

   }

  }	

   if(this.Party.GetFirst().IsSet())

   {

    var lv_x = this.Party.Where(n => n.PartyName == empname);

    if(this.Party.Count() > 0 && this.Party.Where(n => n.PartyName == empname).Count() > 0)

    {

	 if(lv_x.Where(n=>n.RoleCode == "36").Count() != 0 && lv_x.Where(n=>n.RoleCode == "35").Count() == 0 && lv_x.Where(n=>n.RoleCode == "39").Count() == 0 )

	 {

	  this.GetFirst().Z_Action_Cancel = true;

	 }

    }

	else

	{

	 this.GetFirst().Z_Action_Cancel = true;

	}

   }

 }

}

Step4: Now we need to add the transient field to the Appointment header using UI designer.

Go to Administration >> Open UI Designer.

Open COD_Appointment (TI screen) >> using Extensibility explorer add the transient field to the appointment header section( This field can be hidden from the frontend adaptation if not needed)

Step5: Now Save and Activate the Event-AfterLoading.absl and .XBO and entire solution. Till this step we have done from the SDK side and moving to SAP C4C UI.

Step6: Logon to SAP C4C with admin credentials >> Open Appointment’s Business object under activities >>Now open any Appointment and you will see the transient field which we have added at the header section(Default value as NO).

Step7: Now Open Adaptation mode and click on the action’s menu >> Select the ‘Set as Cancelled’ >> Now create a validation rule and assign it under the visibility of the ‘Action Cancelled’.

The below images shows the logic that I have written in the Validation Rule.

Note: Transient field’s created from SDK can be extended to UI but are not visible in Validation Rule because transient field’s are not available at the database level, So I have copied the namespace of the transient field from the properties in UI Designer.

Step8: Now test the scenario in the SAP C4C.

Hope this blog is helpful and addresses one of the product gap in groupware integration. Please let me know for any queries in the comments section.

Released: SAP Cloud SDK for Java Version 5

2023-12-07T00:32:08+01:00

The SAP Cloud SDK for Java has recently launched its latest major version (v5) on Maven Central.

In this blog post, we'll explore the key values and improvements that will assist in planning your upgrade to SDK version 5.

Open Source Migration

One of the key highlights of SAP Cloud SDK for Java 5 is its commitment to open source migration. (repo)

Historically, the SAP Cloud SDK for JavaScript (repo) has been open sourced since 2020 with very positive experience and feedback. Over the years, the community has asked for the second open source migration of the Java variant. Now, this is the answer from the team.

This move not only enhances transparency but also invites developers to actively contribute to the SDK's evolution. By opening up the source code, the SDK becomes a truly community-driven project, allowing developers to play a direct role in shaping the future of the SDK.

Please contact us via the GitHub issues (link) for questions, bug fixes, or feature requests.

If you want to contribute to the SDK, please check our contribution guidelines.

Support: Java 17, Spring 6 and Spring Boot 3

The SAP Cloud SDK for Java version 5 brings native support for the modern versions in the Java ecosystem, including Java 17, Spring 6, and Spring Boot 3. This ensures that developers can leverage the full potential of Java/Spring, taking advantage of the latest features and improvements for optimising application development.

The SAP Cloud SDK for Java is used by CAP (SAP Cloud Application Programming Model). As CAP version 2 needs Java 17 & Spring Boot 3 as minimal versions, you will gain the best user experience, when upgrading to SDK version 5 together with CAP 2.

For users who have already tried our experimental feature of the Java 17 support in SDK v4, potential workarounds are no longer needed.

Check our upgrade guide for more details.

Support: Apache HttpClient 5

In SDK version 4, the experimental feature introduced the use of Apache HttpClient v5. Now, as an official feature, developers can confidently benefit from robust APIs.

You can find a minimal code example for using the HttpClient v5:

Destination destination = DestinationAccessor.getDestination("my-destination");

HttpClient client = ApacheHttpClient5Accessor.getHttpClient(destination);

To compare the usage of the HttpClient v4, here is another example for the v4:

Destination destination = DestinationAccessor.getDestination("my-destination");

HttpClient client = HttpClientAccessor.getHttpClient(destination);

The complete documentation about the HttpClient v5 feature can be found here.

Improved Module Structure

Thanks to the new platform agnostic maven module structure, as a user, you only need to add the essential dependency (com.sap.cloud.sdk:sdk-core) for most of the use cases, instead of "scp-cf" or "scp-neo" for dedicated platforms. As a result, your SDK related maven dependency tree should be cleaner and smaller.

In addition to that, users will also benefit from a simplified, more powerful, and more extensible connectivity API. For example, you can build a destination from destination properties, a map, or another destination:

DefaultHttpDestination.fromProperties(myDestinationProperties)

DefaultHttpDestination.fromMap(myMap)

DefaultHttpDestination.fromDestination(myDestination)

You can conveniently modify properties form an existing instance by using "toBuilder":

myHttpDestination.toBuilder()

Check our release notes for more details.

Lastly, as a side note, SDK version 5 also provides complete support for the DwC (Deploy with Confidence) Orbits architecture. Check the DwC documentation for more details.

Recommendation

We strongly recommend upgrading your SAP Cloud SDK for Java dependency to version 5 at your earliest convenience, as it introduces significant improvements and new capabilities. Although SDK v4 will remain in maintenance mode for another six months, active development has shifted to SDK v5.

If you have any questions during the upgrading, please open an issue here.

Utilizing SAP Cloud SDK for JavaScript in a BTP Proxy App for non-Web-Apps to access onpremise SAP Systems

2023-12-31T03:44:52+01:00

Introduction

Oftern there is a need for Apps running outside of the corporate network to access SAP onpremise systems. Using a Proxy App running in the BTP (Business Technology Platform) Cloud Foundry Environment utilizing the SAP Cloud Connector is a well known pattern for such requirements.

However using the destination and connectivity service to get access to the tunnel to the onpremise systems is not trivial and is best done with the help of libraries.The approuter (cf. https://www.npmjs.com/package/@sap/approuter) is a well known and proven solution for this. However approuter is aimed at web applications. Using it for eg native applicatios is a bit troublesome.

Since March 2019 there is also the SAP Cloud SDK for JavaScript (in the beginning known as the SAP S/4HANA Cloud SDK for JavaScript and also going by SAP Cloud SDK for Node.js) available. The http-client of this SDK completly handles the interaction with the destination and connectivity service, you just have to provide the destination name (please check out other features of this SDK, there is a lot of other useful stuff there!). This blog intends to give you some guidance for using this SDK for this porpose.

Basics

The SDK is availabe in the public npm repository. Add the line

"@sap-cloud-sdk/http-client": "^3.9.0",

to the dependencies section in your package.json. Use at least version 3.9.0 to avoid being hit by the xssec security vulnerability (cf. Security Note 3411067).

In your JavaScript file to be run add

const httpclient = require('@sap-cloud-sdk/http-client');

The object thus obtained follows the axios HTTP client API with an added first object parameter (second parameter is compatible to RawAxiosRequestConfig), eg to make a POST call to an onpremise destination use this code

await httpclient.executeHttpRequest(

        {

            destinationName: 'MYDESTINATION'

        },

        { 

            method: 'POST',

            url: "/sap/opu/odata/sap/ZMY_SERV_SRV/MyEntitySet",

            headers: {

                "Content-Type":"application/json; charset=utf-8",

                "Accept":"application/json"

            },

            data: body

        }

    ).then(response => {

        // use eg response.status and response.data 

    }).catch(err => {

        // use eg err.code or message

    });

(Note: All code examples in this blog are just examples, do not use in your productive code, eg consider adding logging and a more robust coding)

CSRF handling is done by default.

Proxy with Basic Authentication

For a first simple proxy example we will use Basic Authentication from Outside and also Basic Authentication to the onpremise system. The latter is an easy brainer: Just use Basic Authentication as Authentication Type when defining the destination in the BTP cockpit:

(Do yourself a favor and pay attention to the warning in the picture!)

With such a destination you need merely give the destinationName in the example above.

In the mta.yaml define the depencies to the destination and connectivity service:

...

modules:

- name: myproxy

  type: nodejs

  requires:

  - name: myproxy-destination-service

    parameters:

      content-target: true

  - name: myproxy-connectivity-service

  parameters:

    health-check-type: process

...

resources:

- name: myproxy-destination-service

  type: org.cloudfoundry.managed-service

  parameters:

    config:

      version: 1.0.0

    service: destination

    service-name: myproxy-destination-service

    service-plan: lite

- name: myproxy-connectivity-service

  type: org.cloudfoundry.managed-service

  parameters:

    service: connectivity

    service-plan: lite

Health check is set to process because otherwise health check uses an unauthenticated HTTP access to / which won't work with our basic authentication requirement and thus would give constant app restarts.

For the proxy function we use express and passport, ie in the package.json

      "express": "^4.17.3",

      "body-parser": "^1.20.2",

      "passport": "^0.6.0",

      "passport-http": "^0.3.0"

Preperation in the JavaScript file

const express = require('express');

const bodyParser = require('body-parser')

const passport = require('passport');

const passportHTTP = require('passport-http');



const auth_env = {login: process.env['AUTH_LOGIN'], password: process.env['AUTH_PASSWORD']};

const app = express();

passport.use(new passportHTTP.BasicStrategy(

    function(username, password, done) {

        if (username === auth_env.login && password === auth_env.password) {

            return done(null, username);

        } else {

            return done(null, false);

        }

    }

));

app.use(passport.initialize());

app.use(passport.authenticate('basic', { session: false }));

app.use(bodyParser.text({ type: 'application/json' }));

...

app.listen(process.env.PORT || 5000, function () {

    console.log('Proxy app started');

});

and code for proxying a POST call

app.post('/MyEntitySet', async (req, res) => {

    if (!req.user) { res.sendStatus(403); return; }

    await httpclient.executeHttpRequest(

        {

            destinationName: 'MY_DESTINATION'

        },

        { 

            method: 'POST',

            url: "/sap/opu/odata/sap/ZMY_SERV_SRV/MyEntitySet",

            headers: {

                "Content-Type":"application/json; charset=utf-8",

                "Accept":"application/json"

            },

            data: req.body

        }

    ).then(response => {

        res.send(response.data);

    }).catch(err => {

        res.status(500).send('Backend Error');

    });    

});

(in real life you might want to use wildcards and parse req.url)

Proxy with Principal Propagation

Principal Propagation means the client needs to authenticate the user aka principal against the BTP and obtain tokens which need to be stored securely. When accessing the proxy the token needs to be presented. The token is then forwared to the cloud connector which generates authorization info using the principal for the onpremise system (configuring cloud connector and onpremise systems to achieve this is beyond the scope of this blog).

In this example the native client needs to obtain a JWT token and send it along with request to the proxy. The JWT token will eg be obtained and renewed by utilizing SAML 2.0 and OAuth 2 protocols with the XSUAA service, cf. https://sap.github.io/cloud-sdk/docs/java/guides/cloud-foundry-xsuaa-service . The native client should use libraries for this tasks (this is however beyond the scope of this blog). After deploying the proxy app to the BTP go to the deployed app in the BTP cockpit, select "Service Bindings" on the left and click on "Show sensitive data" to obtain the data for the libraries. You need

token_service_url : Add /oauth/authorize for the SAML 2.0 login endpoint, /oauth/token for the OAuth 2.0 endpoint and /logout.do for the SAML 2.0 logout endpoint

clientid and clientsecret for the OAuth 2 protocol

Also go to "Scopes" on the left and use the displayed scope name in the OAuth 2 protocol.

The configuration for xsuaa in the xs-security.json file is needed (add scopes and role-templates as needed):

{

    "scopes": [

      {

        "name": "$XSAPPNAME.access",

        "description": "Access"

      }

    ],

    "role-templates": [

      {

        "name": "Access",

        "default-role-name": "My Proxy Access Authorization",

        "scope-references": [

          "$XSAPPNAME.access"

        ]

      }

    ],

    "oauth2-configuration": {

        "redirect-uris": [

            "http://localhost:9999/success"

        ]

    }

  }

Use Redirect-URIs as needed by the native libraries (can also use different schemes than http oder https as commonly used on mobile OS).

In the mta.yaml there is now a depedency to the xsuaa service (add role-collections as needed):

  requires:

  - name: my_proxy-uaa

...

resources:

- name: my_proxy-uaa

  type: org.cloudfoundry.managed-service

  parameters:

    path: ./xs-security.json

    service-plan: application

    service: xsuaa

    config:

      xsappname: my_proxy-${space}

      tenant-mode: dedicated

      role-collections:

        - name: 'my_proxy-Access-${space}'

          role-template-references:

            - $XSAPPNAME.Access

The xsappname and the role collections name thus contains the space name in order to be able to deploy the proxy app to multiple spaces in the same subacount (eg for three-tier development, test, production spaces). In this case the destination need to be defined at app-level in the respective destination service instance instead of subaccount level to have identical named destinations pointing to development, test, production onpremise systems respectivly (destination can't be defined at space level). Assign the role collection to users, either individually or via groups or via IdP configuration.

The destination is defined with Principal Propagation:

In the package.json we need now additional dependencies to xsenv and xssec:

       "@sap/xsenv": "^4.2.0",

       "@sap/xssec": "^3.6.0",

(Use at least version 3.6.0 of xssec because of mentioned security issue)

In the JavaScript file the preperation now includes verification of the JWT token with the xsuaa service:

const httpclient = require('@sap-cloud-sdk/http-client');

const express = require('express');

const bodyParser = require('body-parser')

const xsenv = require('@sap/xsenv');

const passport = require('passport');

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



xsenv.loadEnv();

const app = express();

const services = xsenv.getServices({ uaa: 'my_proxy-uaa' });

passport.use(new xssec.JWTStrategy(services.uaa));

app.use(passport.initialize());

app.use(passport.authenticate('JWT', { session: false }));

app.use(bodyParser.text({ type: 'application/json' }));

The code for proxying a call now contains code for checking the scope and for fowarding the JWT token for principal propagation:

app.post('/MyEntitySet', async (req, res) => {

    if (!req.authInfo.checkLocalScope('access')) {

        return res.status(403).send('Forbidden');

    }

    await httpclient.executeHttpRequest( 

        {

            destinationName: 'MY_DESTINATION'

            jwt: req.authInfo.getAppToken()

        },

        { 

            method: 'POST',

            url: "/sap/opu/odata/sap/ZMY_SERV_SRV/MyEntitySet",

            headers: {

                "Content-Type":"application/json; charset=utf-8",

                "Accept":"application/json"

            },

            data: req.body

        }

    )

Conclusion

The SAP Cloud SDK for JavaScript makes it easy to use onpremise destinations with principal propagation in a BTP proxy app and hides the complexity in dealing with the destination, connectivity and xsuaa service. Happy Coding and have a succesful and peaceful new year!

Validation for different Identity Cards via ABSL code in SAP C4C

2024-04-18T08:27:04.382000+02:00

Validation for different Identity Cards via ABSL code in SAP C4C

In day–to-day life, the need of unique identification cards are common. So verfifications on identity cards in different sectors are also a basic requirement. Suppose we are working for a client from India and the project is about Sales cloud. In this case, the client wants to maintain every customer’s data like Name, Contact, Address, PAN number, Adhaar number, Passport details etc. Out of those fields PAN number, Adhaar number & Passport number are unique IDs provided to each person in India. So we need to put some validations against them, so that wrong values should not be stored.

We have an option to put the validations on these Identity card numbers is via ABSL validation logic through cloud application studio. Here the steps mentioned below to validate different identity cards.

Identity cards mostly required in customer/Employee work centers. So, we can add the below logics in Event- Validation on Save and Event – After Modify of Customer/Employee BO in SDK.

Case1 – PAN Card number should be alphanumeric and should maintain exact pattern. Also PAN card number should have only 10 characters length.

To validate the length of any field we have the method “.length()”Which we can use for this requirement.

For PAN Card number the format in India as

The PAN Card number should be only 10 characters long.
First five characters should be alphabeting ranges from [A-Z]
From 6th to 9th places should be numeric values ranges from [0-9]
Last digit should be alphabetic values within [A-Z]

Using ABSL we have some logic using substring to implement the validation for any mismatch of the above-mentioned format. Added the code snippet for your reference.

Here we will use FindRegex() : This function Searches from left to right and returns the position of a regular expression pattern in a string. If it doesn’t find same pattern then it returns the value “-1” and raises a message as we define.

First five characters should be alphabeting ranges from [A-Z].

From 6th to 9th places should be numeric values ranges from [0-9]

Last digit should be alphabetic values within [A-Z]

The PAN Card number should be only 10 characters long.

Result: - After implementing the above ABSL code, when user tried to add wrong values of PAN Card or incorrect length, the error displayed and not allowed to SAVE the data.

Case 2 – Adhaar Card number should be 12 characters length & all digits should be numeric values.

To validate the length of any field we have the method “.length()”Which we can use as of the requirement.

For Adhaar card all the digits should be numeric and length should be 12 characters only. The below ABSL code can restrict any mismatch to the Adhaar card format.

Result: - After implementing the above ABSL code, when user tried to add wrong values of Adhaar Card or incorrect length, the error displayed and not allowed to SAVE the data.

Case3 – Indian Passport number should be alphanumeric and should maintain exact pattern. Also Passport card number should have only 8 characters length.

To validate the length of any field we have the method “.length()”Which we can use as of the requirement.

For Passport number the format in India as

The Passport number should be only 8 characters long.
First one character should be alphabeting ranges from [A-Z].
For 2nd position, it should be numeric value within range 1 to 9.
For 3rd position, it should be numeric value within range 0 to 9.
From position 4th to 7th position, digits should be numeric value within range 0 to 9.
For the last one digit, it should be numeric value within range 1-9.

Using ABSL we have some logic using substring to implement the validation for any mismatch of the above-mentioned format. Added the code snippet for your reference.

First one character should be alphabeting ranges from [A-Z].

For 2nd position, it should be numeric value within range 1 to 9.

For3rd position, it should be numeric value within range 0 to 9.

From position 4th to 7th position, digits should be numeric value within range 0 to 9.

For the last one digit, it should be numeric value within range 1-9.

The Passport number should be only 8 characters long.

Result: - After implementing the above ABSL code, when user tried to add wrong values of Adhaar Card or incorrect length, the error displayed and not allowed to SAVE the data.

Conclusion: -

This solution can help customers to restrict unauthorized entry of identity card numbers.

Handle the behavior of extension field by toggle button using SDK UI designer.

2024-04-22T11:07:54.330000+02:00

Handle the behavior of extension field by toggle button using SDK UI designer.

Suppose there is one such requirement: We should have one toggle button and using that toggle button we can control the field behaviors like “Mandatory”, “Read Only” or “Visible” so, fields will behave the same as mentioned above when toggle button is set to true. To implement this requirement, we have created 3 different extension fields as “Extension field M”, “Extension field V”, “Extension field R” and one indicator field as “Manage Field” (indicator field act as a toggle button in front-end) in Service Request (Ticket) standard BO. We can make the “Extension field M” field as mandatory, the “Extension field V” field as visible, and the “Extension field R” field as read-only by toggle button (“Manage Field”) using UI designer in SDK.

Procedure: -

Here We have added extension fields in Service Request Extension BO (Ticket).

To add extension field to Extension BO we need to follow below steps:

Open your solution and click on Add New Item and select the “Extension” and from the list select “Business Object Extension” then click on Add. Select required namespace and BO name then click ok.

2. After creation of “Business Object Extension” then add extension fields in this BO as shown below.

We now have extension fields created in Service Request Extension BO in Cloud Application Studio. Based on our requirement add these extension fields in the UI screen of Extension BO in Cloud Application Studio. Here We have added these extension fields in the TI screen of Service Request Extension BO. Now you can see these Extension fields in below SS.

To add extension field in UI screen of Extension BO we need to follow below steps:

Right click on BO and select “Enhance Screen” then select the screen as your requirement.
In screen, select group section and select “Add Extension field to Section Group” under the “Extensibility explorer” then select field which need to add in the screen then save and activate the UI screen.

Extension fields have been added successfully in UI screen as below.

As per our requirement, now we will make the "Extension field M" field as mandatory field, the "Extension field R" field as read-only field and the "Extension field V" field as visible field in the UI screen using toggle button ("Manage Field") in cloud application studio. Here you need to follow the below steps:

Open the UI screen in cloud application studio where we have added to the extension fields. Here we have opened the TI screen of Service Request Extension BO. Select the field group where we have added the extension fields and click on “Adjust Properties” under the “Extensibility Explorer” as shown below.

2. Now we need to bind "Extension field M" field to the indicator field (toggle button) for mandatory, bind "Extension field R" field to the indicator field for ReadOnly and "Extension field V" field to the indicator field for Visible. Then, click on “Apply” as shown below, save and activate to the UI screen to finish this setup.

Note- if we do not bind these fields with indicator field and select the “True” value there, then by default these fields will have same behavior every time.

For an example: if for "Extension field M" field, property “Mandatory” is set to “True” then this field will become mandatory by default.

Result: -

After Completion of all the setup in SDK, now we can preview our changes when we will turn on the toggle button (“Manage Field”), then all the fields will behave as we expected.

when we will turn off the toggle button (“Manage Field”), then all the fields will behave as we expected.

Conclusion: -

Now you can change the behavior of these fields based on toggle button (Manage field).

Configuration as code (CaC) with destinations.

2024-05-13T12:54:57.123000+02:00

Configuration as code (CaC) with destinations.

Destinations are very handy and powerful mechanism to facilitate access to target systems and devices.

When it comes to SAP BTP destinations, the idea is to manage both subaccount and instance level destinations (and/or their certificates) as shared configuration resources on a provider subaccount level.

That way, the destinations configurations can be stored as versioned assets in a source repository and need to be maintained only once per provider, thus, without incurring application runtime tie-in.

Last but not least, BTP destination service is used as a self-configuration tool.

Configuration as code with SAP BTP destination service

Table of Contents

Configuration as code with SAP BTP destination service.

create shared destination service instance and binding.

Provision bootstrap destinations.

Configure destination resources.

Documentation.

PS.

Bootstrap destinations definitions.

Even, if there is no intrinsic BTP CLI command to assist in creation of destinations from service bindings, this can be achieved quite easily with a bit of jq gimmick by applying service binding credentials to a json payload template, for instance:

{
    "init_data": {
        "subaccount": {
            "destinations": [
                  {
                    "Description": "dest-httpbin",
                    "Type": "HTTP",
                    "clientId": "sb-clone12847c4c89544b4f9234b26ede429f62!b282590|destination-xsappname!b62",
                    "HTML5.DynamicDestination": "true",
                    "HTML5.Timeout": "60000",
                    "Authentication": "OAuth2ClientCredentials",
                    "Name": "dest-httpbin",
                    "tokenServiceURL": "https://<subdomain>.authentication.us10.hana.ondemand.com/oauth/token",
                    "ProxyType": "Internet",
                    "URL": "https://httpbin.org",
                    "tokenServiceURLType": "Dedicated",
                    "clientSecret": "<clientSecret>"
                  },
                  {
                    "Description": "SAP Destination Service APIs",
                    "Type": "HTTP",
                    "clientId": "sb-clone12847c4c89544b4f9234b26ede429f62!b282590|destination-xsappname!b62",
                    "HTML5.DynamicDestination": "true",
                    "HTML5.Timeout": "60000",
                    "Authentication": "OAuth2ClientCredentials",
                    "Name": "destination-service",
                    "tokenServiceURL": "https://<subdomain>.authentication.us10.hana.ondemand.com/oauth/token",
                    "ProxyType": "Internet",
                    "URL": "https://destination-configuration.cfapps.us10.hana.ondemand.com/destination-configuration/v1",
                    "tokenServiceURLType": "Dedicated",
                    "clientSecret": "<clientSecret>"
                  }
            ],
           "certificates": [
           ],

            "existing_certificates_policy": "update",
            "existing_destinations_policy": "update"           
       }
   }
}

Alternatively, one could resort to using SAP Cloud SDK built-in service binding destinations.

The below nodejs code snippet demonstrates how to leverage SAP Cloud SDK with its service binding destinations with the likes of service manager and destinations services.

apiVersion: serverless.kyma-project.io/v1alpha2
kind: Function
metadata:
  name: {{ .Values.services.srv.name }}
  labels:
    {{- include "app.labels" . | nindent 4 }}
    app: {{ .Values.services.srv.name }}
spec:
  runtime: {{ .Values.services.srv.runtime }}
#  runtimeImageOverride: {{ .Values.services.srv.runtimeImageOverride }}
  source:
    inline:
      dependencies: |
        {
          "name": "{{ .Values.services.srv.name }}",
          "version": "0.0.1",
          "dependencies": {
            "axios":"latest"
            ,"debug": "latest"
            ,"@sap/xsenv": "latest"
            ,"@sap-cloud-sdk/http-client": "latest"
            ,"@sap-cloud-sdk/connectivity": "latest"
            ,"@sap-cloud-sdk/resilience": "latest"
            ,"async-retry": "latest"
          }
        }
      source: |
        const debug = require('debug')('{{ .Values.services.srv.name }}:function');
        const NOT_FOUND = 'Not Found';
        const xsenv = require('@sap/xsenv');

        const services = xsenv.getServices({
          sm: { label: 'service-manager', name: 'saas-sm' }
          ,
          dest: { label: 'destination' }

        });
        console.log('saas-sm: ', services.sm);

        const readServices = xsenv.readServices();
        console.log('readServices: ', readServices);

        const httpClient = require('@sap-cloud-sdk/http-client');

        const cloudSdkConnectivity = require('@sap-cloud-sdk/connectivity');
        const { retrieveJwt, decodeJwt, Destination } = require('@sap-cloud-sdk/connectivity');
        const { setGlobalLogLevel, createLogger } = require('@sap-cloud-sdk/util');
        const { retry } = require ('@sap-cloud-sdk/resilience');
        const { resilience } = require ('@sap-cloud-sdk/resilience');
        const ResilienceOptions = {
          retry: 10,
          circuitBreaker: false,
          timeout: 300*1000 // 5 minutes in milliseconds
        };          

        const retryme = require('async-retry');

        setGlobalLogLevel('debug');
        const logger = createLogger('http-logs');

        module.exports = {
          main: async function (event, context) {
            const req = event.extensions.request;

            const message = `Hello World`
              + ` from the Kyma Function ${context['function-name']}`
              + ` running on ${context.runtime}!`
              + ` with the request headers ${JSON.stringify(req.headers,0,2)}`;
            console.log(message);
            
            if (typeof req.path !== undefined) {
              console.log('path: ', JSON.stringify(req.path,0,2))
            }
            if (typeof req.params !== undefined) {
              console.log('params: ', JSON.stringify(req.params,0,2))
            }
            if (typeof req.url !== undefined) {
              console.log('url: ', JSON.stringify(req.url,0,2))
            }
            if (typeof req.authInfo !== undefined) {
              console.log('authInfo: ', JSON.stringify(req.authInfo,0,2))
            }

            const { pathname } = new URL(req.url || '', `https://${req.headers.host}`)
            console.log('pathname: ', pathname)

            const url = require("url");
            var url_parts = url.parse(req.url);
            console.log(url_parts);
            console.log(url_parts.pathname);

            // returns an array with paths
            let path_array = req.url.match('^[^?]*')[0].split('/').slice(1);
            console.log(path_array)

            console.log(req.url.match('^[^?]*')[0])

            if (!path_array?.length) return 'Please use an API verb';  
            const actions = [ 
               { name: 'offerings', verb: 'service_offerings', dest:  'saas-sm', url: '/v1/' },
               { name: 'plans', verb: 'service_plans', dest:  'saas-sm', url: '/v1/'  },
               { name: 'instances', verb: 'service_instances', dest:  'saas-sm', url: '/v1/'  },
               { name: 'bindings', verb: 'service_bindings', dest:  'saas-sm', url: '/v1/'  },
               { name: 'instanceDestinations', verb: 'instanceDestinations', dest:  'faas-dest-x509', url: '/destination-configuration/v1/'  },
               { name: 'subaccountDestinations', verb: 'subaccountDestinations', dest:  'faas-dest-x509' , url: '/destination-configuration/v1/' }
            ];
            
            const action = actions.find( ({ name }) => name === path_array[1] )
            console.log('action found: ', action)

            if (path_array[0] == 'srv' &&  action !== undefined) {

              path_array = req.url.match('^[^?]*')[0].split('/').slice(2);

              console.log('path_array: ', path_array)

              const queryString = req.query;
              console.log('queryString: ', queryString)
              const urlParams = new URLSearchParams(queryString);

              const params = req.params;
              console.log('params: ', params) 

              try {
                  // https://sap.github.io/cloud-sdk/docs/js/features/connectivity/destinations#service-binding-environment-variables
                  const endpoint =  path_array[1] !== undefined ? '/' + path_array[1] : '';
                  console.log(endpoint)
                  let res = await httpClient.executeHttpRequest({ destinationName: action.dest }, {
                      method: 'GET',
                      url: action.url + action.verb + endpoint
                  });
                  return res.data;
              } catch (err) {
                  console.log(err.stack);
                  return err.message;
              }
              
            }            
          }
        }
   scaleConfig:
    maxReplicas: 5
    minReplicas: 3
  resourceConfiguration:
    function:
      profile: S
  env: ## https://kyma-project.io/docs/kyma/latest/05-technical-reference/00-configuration-parameters/svls-02-environment-variables/#node-js-runtime-specific-environment-variables
    - name: FUNC_TIMEOUT ## Specifies the number of seconds in which a runtime must execute the code.
      value: '1800'
    - name: REQ_MB_LIMIT ## payload body size limit in megabytes.
      value: "10"

    - name: DEBUG
      value: '{{ .Values.services.srv.name }}:*'
    - name: SERVICE_BINDING_ROOT
      value: /bindings
    

  secretMounts: 
    - secretName: {{ .Values.services.sm.bindingSecretName }}
      mountPath: "/bindings/saas-sm"
    - secretName: {{ .Values.services.dest.bindingSecretNamex509 }}
      mountPath: "/bindings/faas-dest-x509"

SAP Community - SAP Cloud SDK

Customized Project Budgeting in SAP Business ByDesign

Requirement:

Solution:

Design:

Purchase Order

Supplier Invoice

Expense Report

Journal Entry Voucher

Business Benefits:

Conclusion:

Kindly post your questions in ask a question section and feedback in the below comments section.

How to Calculate the Difference Between Two DateTime Fields in SAP C4C

SAP private linky swear with Azure – enabling SAP CAP with Azure services without OData APIs using SAP Private Link

The provided translator app is pre-configured to work with Azure Cosmos DB and Azure Blob storage. Its structure is modular and open for you to add any service you desire.

Let’s take a look under the hood

Data setup and integration test

Once finished call the APIs to verify proper setup with public endpoints still.

So far so good. Now we will inject all services into our private VNet and prepare the SAP Private Link.

Swoosh 🌪️ At this point you can reach the database only via the App Service! Don’t believe me? Go on and check. Trust is good but verification is better as they say🧐

Either way you may be glad to hear we are done 💪Yes, go on call the CAP app URL and marvel and the privately served data from Cosmos DB as OData stream:

Thoughts on production readiness

Final Words

SAP BTP Destinations in a Nutshell Part 1 - Motivation & NoAuthentication Destinations

Motivation

Prerequisites

Cloud 2 Cloud - NoAuthentication

Cloud SDK

Plain

Disclaimer

SAP BTP Destinations in a Nutshell Part 2 – Basic Authentication

Introduction

Basic Authentication

Cloud 2 Cloud – Basic Authentication

Client Implementation

Cloud SDK

Plain

Server Implementation

Execution

Disclaimer

Why the TypeScript Sheriff has come to clean up your JavaScript (Part 1 of 3)

Why TypeScript?

TypeScript Sheriff: How can I use TypeScript in the SAP ecosystem? (Part 2 of 3)

What is TypeScript?

How does TypeScript work?

Where can we use TypeScript in an SAP context?

Where can I find all the information I need to get started?

TypeScript Sheriff: Tips for newbies (Part 3 of 3)

Use the import prompt

Watch your case

Less is more

Clearing the cache

Taking a break from types

Confgure the TypeScript Compiler

Don't be a cowboy coder....

Lets Deep dive into CAPM and HANA Cloud --> HANACap

Pre-requisite:

Here you go GitHub Repo - https://github.com/shivamshukla12/SAP-CAP/tree/main

Write your first CAP Application - Its a simple one Hello World

Create one entity in your CAP App and Insert / Retrieve some Hard coded Values

Add some CSV Data in your CAP Application

Run and retrieve your CSV Data

Connect your CAP Application to BTP Space

Provision Services for your CAP Application

Enable HANA Cloud Instance and Add HDI Containers

Build and Deploy your CAP Application on CF ( Cloud Foundry )

Run and Debug your CAP Application

Tutorial Highlights:

GET Request :

Highlights

Coming up Next...

Up-level your SAP OData APIs with Azure API Management

API Creation, Design & blueprints

Enable modern GraphQL for your OData APIs.

Spin up your SAP app extension powered by the SAP Cloud SDK on Azure with API Management with one command

Speed up your Azure API Management Policy design with GitHub Copilot and ChatGPT

Reason about and debug complex policies on Azure API Management using breakpoints from Visual Studio Code

Create an Azure API Management service including APIs using Terraform

Authentication & Security

Activate Defender for APIs in Azure API Management to automatically detect threats in your SAP APIs