SAP Community - SAP Cloud SDK

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"

Open Sourcing the SAP Cloud SDK for Java: Part 1 - Preparations

2024-06-05T16:33:41.214000+02:00

The SAP Cloud SDK is a library for developing applications on the SAP Business Technology Platform (BTP). While its version for JavaScript has been open source since 2020, the Java version has been open sourced only recently with the release of version 5.0.0.

This blog post is first in a series where I go over the process of how we moved the SAP Cloud SDK for Java from an internal code base and development ecosystem to an open source project on GitHub. This has been a journey that spun across 10 months and involved a lot of planning, coordination and technical work.

We started planning the process in the beginning of 2023 and finally released version 5.0.0 as the first open source version of the project on December 5th, 2023. Of course, during this time we also worked on other features and improvements for the SDK, but the open source migration was a significant part of our work.

This first blog post covers some of the non-technical planning and preparation that was necessary to open source the project. Parts two and three will cover the technical migration steps of the codebase itself and the development ecosystem around it.

🤔Why Open Source?

Choosing to open source the SAP Cloud SDK for Java was a strategic decision, aiming for multiple long term benefits:

First, open sourcing the project makes it easier for all developers to use the library. It allows users to quickly peek into the source code to better understand some implementation, to ask for help on the issues tab of the repository or to contribute themselves.
Second, it also allowed us to modernize and simplify our tools to build the SDK.
Last, but not least, it allows us to engage more with the developer community and promotes transparency and trust.

These were some of the reasons that ultimately motivated us to take on the challenge of moving the project to open source.

🔎 Finding a Starting Point

At SAP, we have a dedicated team that helps other teams within SAP open-source their projects: The Open Source Program Office of SAP (OSPO). You can read more about them in this blog post from Michael: Managing Open Source Software with an Open Source Program Office.

So, the first step was to get in touch with the OSPO and discuss our plans. They helped us understand the requirements and the necessary steps we'd have to take for going open source.

🤺 Taking the First Steps

We started by evaluating which parts of the productive codebase were (not) eligible for open sourcing. The code base had grown since its inception in 2016 and contained some functionality that was either not central to the product, only used internally or legacy code.

We knew that the core functionality of the SDK (e.g. the destination service integration, the OData APIs, the multi-tenancy and resilience features) could be moved to open source without issues. But there were other parts where it was either not immediately clear, or the functionality was completely SAP-internal and not released to Maven Central.

We had to deal with two main categories of code that we had to either remove or replace:

Code that contained SAP intellectual property (IP) and was not eligible for open sourcing.
Code that used SAP-internal dependencies.

Both categories required an extensive review of the codebase, its dependencies and the functionality provided by the code.

For example, we found that the pre-generated OData clients for SAP S/4HANA were not eligible for open sourcing. In this case we decided that we would deprecate and remove these clients. To make up for this, we instead improved the OData generator which was used to generate these clients, so that users can generate their own version of the clien

In other cases, we decided to remove modules, but ensure the existing modules of version 4 would be compatible with the new version 5 of the SDK. That way existing users could upgrade to the new version while keeping a select few modules of the old version. But since this approach has some challenges (one has to keep maintaining the old modules and continuously ensure compatibility with the new version), we only applied this for a few select cases that were small but important enough to justify the effort.

Overall, we had to evaluate each impacted feature case by case. That meant getting feedback from existing stakeholders, finding and evaluating any potential alternatives and ultimately making a decision.

💡Considering the relatively large code base of version 4 with well over 100 maven modules this was arguably the most challenging part of the open source migration. Overall it took several months until we had a clear picture of what we wanted to open source and what we had to remove or replace.

However, because this naturally is a process that takes time, we worked on other aspects of the migration in parallel to that.

🧹 Code Cleanup

While the future of some parts of the code base where still in discussion, we already prepared the rest of the code base to be moved to an open source repository. For example, this meant removing any internal or personal identifiable information from test code. But also inspecting internal documents and code comments, removing e.g. links to internal tools or documentation, internal IP addresses or other internal information.

While not strictly necessary in all cases, it was important to us that the code is sensible to all developers, not just SAP internal developers. Having inaccessible links or references to internal tools would make it difficult for open source contributors to understand and contribute to the code.

Considering the project contained around 1800 productive classes and equally many test classes together with around 100 other files like Markdown documents, configuration files and scripts, this task also took some time. But after a few weeks and a good bit of search and replace, we were confident that the code base was ready to be open sourced.

🏗Setting up an Open Source Repository

Now it was time to set up the open source repository. That meant creating a new repository within the SAP organization on GitHub. For this process the OSPO team has a repository template prepared from which new repositories are created.

As part of the process we added the necessary documents and links: We set the new license to be Apache-2.0, added the main readme file, drafted our contribution guidelines and linked the code of conduct. The OSPO template navigates you through this process and provides you with a comprehensive checklist as well as any SAP-specific standard texts or references that need to be used.

But, since this repository so far effectively only contained a readme, we kept it internal to the SAP organization until we were ready to open source the actual source code. The actual process of moving over the code base is what I will cover in the next part of this series.

😴 What we didn't have to do

Before wrapping up I think it's worth mentioning that there were also some things we didn't have to do. For example, we didn't have to apply any larger refactorings to deal with functionality we removed or replaced. Most of the code was already structured into maven modules that were independent enough from each other, so that often we could decide on a per-module basis if and how the code should be open-sourced.

In addition, we already had strong tooling support set up to ensure that the code base was in a good state overall. This included a comprehensive test suite, but also code scanning tools (e.g. Fortify, Checksytle, PMD etc.) and tools for analyzing dependencies and licenses (e.g. BlackDuck). This made identifying internal dependencies or finding license issues relatively easy.

And, of course, we had experience from moving the JavaScript variant of the project into open source. We could also refer to other closely related open source projects such as the SAP BTP Security Services Integration Libraries or the SAP BTP Environment Service Binding Access Library. Together with the help and tools provided by the OSPO team this made the process of moving the Java variant into open source significantly easier.

📖Conclusion

Summing up, we had to do quite some planning and preparation to get the SAP Cloud SDK for Java ready for open sourcing. This was mostly due to the size of the code base and the amount of internal functionality and IP it contained

But with the help of the OSPO team, the experience from open-sourcing the JavaScript variant and the support from stakeholders we were able to prepare the code base step by step. In the next part of this series I will cover the actual process of moving the code base to GitHub and the technical challenges we faced during this process.

What are your experiences with open sourcing projects? Do you have any questions on the process we went through? Leave your thoughts in the comments below!

Open Sourcing the SAP Cloud SDK for Java: Part 2 - Moving Code

2024-06-07T09:21:46.497000+02:00

The SAP Cloud SDK is a library for developing applications on the SAP Business Technology Platform (BTP). While its version for JavaScript has been open source since 2020, the Java version has been open sourced only recently with the release of version 5.0.0.

This blog post is the second of a series where I go over the process of how we moved the SAP Cloud SDK for Java from an internal code base and development ecosystem to an open source project on GitHub.

Part one covered the non-technical planning and preparation that was necessary to open source the project. Finally, part three will cover the transformation of the CI/CD pipeline and the surrounding automations.

📈 The Overall Strategy

Right from the get-go it was clear that we would release a new major version of the SDK once the open source migration was complete. The open source version would come with a new license and significant changes to the feature scope, dropping support for some legacy features and platforms. With the current version being 4.X at the time, we set the goal to release version 5.0.0 as the first open source version of the SDK.

Still, we would have to continue developing the current version 4 for some time, at least up until a few weeks before the release of version 5. And even after that, we would have to maintain version 4 and provide bug fixes and security updates for some time.

Next, we had decided to replace our existing (Jenkins) pipelines and related tooling (e.g. for static code checks, dependency updates etc.) in favor of more modern alternatives that are more suitable for open source projects. We decided to completely switch to GitHub Actions for our pipelines and automations, and also use other tools provided by GitHub for code quality and security checks (e.g. CodeQL, Dependabot). This would require some time to set up and test.

Finally, we wanted to have a smooth transition with as little downtime to the development process as possible. Ideally, we copy over the code to the new repository and have all the CI/CD tooling and automations in place and working, guaranteeing the same or even better code quality compared to the internal repository.

🚚 How We Moved the Code Base

With these requirements in mind we came up with a plan to move the code base over to the open source repository. It comprised of three steps:

Copy a representative sample of the code to the open source repository and develop the CI/CD pipelines.
Create a v5 branch in the internal repository and develop the open source version in parallel.
Move the v5 branch over to the open source repository and press the release button.

Copying a sample allowed us to develop the CI/CD pipeline and all related tooling in parallel to the code development. Also, it allowed us to split the code base as late as possible, reducing the time period where we need to maintain two repositories.

🧪 Creating a Representative Sample

Once we had created the empty repository on GitHub we copied around 5-10 modules or roughly 10 % of the code base over to the open source repository. We carefully chose a subset of the code that we knew would change relatively little in the near future and that would be representative of the whole code base. The code sample was representative in the sense that it included various different kinds of Maven modules: Typical modules that would get shipped as JAR, parent and BOM modules that are used for dependency management, modules that would get shipped as a Maven plugin or Maven archetype and test modules that wouldn't get shipped.

This allowed us to implement our CI/CD pipelines on a subset of the code that would be representative of the whole code base. Also, this meant this work can be done in parallel and completely independent of the development on the internal repository. In the end, the sample code allowed us to fully prepare all CI/CD tooling with a high degree of confidence that once we move over the rest of the code base everything would work as expected.

🔀 Creating a Branch for V5

We then created a v5 branch in the internal repository and started removing any code that would not be open sourced. We also set up an automation right away that would merge any changes done to v4 automatically into the v5 branch.

That way we could continue developing the current version 4 without the risk of forgetting to port relevant changes to the v5 branch. Still, maintaining two branches is additional work, so we pushed creating the v5 branch back as far as possible.

↗️Moving to the Open Source Repository

Finally, once all changes required for the open source migration on the v5 branch were complete and the open source repository was set up with all required CI/CD tooling, we moved over the v5 branch to the open source repository. This step almost fully replaced the existing code sample we had copied over earlier. Only the parts relevant to the CI/CD setup were kept and merged with the incoming v5 branch.

On the 2nd of October around 2500 files were copied over from the internal to the open source repository with this pull request. We implemented the necessary adjustments for the CI/CD pipelines to work on the full code base (e.g. adjusting the thresholds for the code scans and test coverage, adjusting the copied over pom.xml files etc.).

Copying over also meant we would lose the commit history of the code. While technically we could have kept it, it would have contained all the internal code and information we had to remove from the code base. Therefore, we decided to start with a clean commit history in the open source repository.

The process finished on the 4th of October where the pull request was merged and the internal v5 branch archived.

📖 Summing Up

Overall, we were quite happy with how the move of the code base went. Having the work on pipelines and tooling done independently and in parallel to the development on the internal repository meant we didn't lose any time or sacrifice code quality in the process. It also made it easier to involve other from colleagues outside our development team who had more experience with GitHub Actions and helped us set up the pipelines.

Here is a timeline of the overall process:

In the third and final part of this series I will cover how we used GitHub Actions to implement our all our CI/CD pipelines and how we automated the release process.

Open Sourcing the SAP Cloud SDK for Java: Part 3 - Re-Building the CI/CD Automations

2024-06-10T14:00:23.734000+02:00

The SAP Cloud SDK is a library for developing applications on the SAP Business Technology Platform (BTP). While its version for JavaScript has been open source since 2020, the Java version has been open sourced only recently with the release of version 5.0.0.

This blog post is the final one of a series where I go over the process of how we moved the SAP Cloud SDK for Java from an internal code base and development ecosystem to an open source project on GitHub.

Part one covered the non-technical preparations and planning that were necessary to open source the project. Part two went into the details of how we moved the code base over from an internal repository to the open source repository on GitHub. Finally, this post will cover the transformation of the CI/CD pipelines and the surrounding automations.

☝️Requirements for our CI/CD Automation

For our internal repository we were using an internal Jenkins server to run most of our automations. The pipelines had grown over the years and were quite complex:

The main Jenkins pipeline for PR and main branch builds alone had grown to over 1k lines of Groovy code.
The release was mostly handled by Python scripts with roughly 1.5k lines of code.
The pipelines were integrated with other internal systems and tools.

It was clear that we had to replace the current setup with a publicly accessible and more modern alternative. We made the decision to completely move to GitHub Actions. Considering the size of the code base and the high degree of automation this was a significant challenge.

To better understand the solution we went for, let's look at some of the requirements we had for the CI/CD automation:

Pull requests should automatically be built, tested and validated against quality checks (e.g. test coverage, static code checks etc.).
Commits on the main branch should automatically be deployed to an internal Maven snapshot repository.
As part of this, commits on the main branch must also pass all requirements that hold for pull requests plus an additional check on licenses and security vulnerabilities on dependencies.
In terms of quality, any commit on the main branch might be released as a productive version.
Releases to Maven Central should be done using a fully automated pipeline, performing several steps:
Release builds must pass all quality checks that hold for commits on the main branch.
The release pipeline should automatically increment the version number, create a release tag and publish the release notes and JavaDocs.
The pipeline must also distinguish between modules intended for public release and internal test modules which are not to be released.
Finally, the release pipeline should automatically deploy all artifacts intended for release to Maven Central.

These requirements were largely already in place for our internal repository, and it was crucial for us to have the same or even higher levels of quality and automation for the open source repository. Here is how we did it.

🔖Architecture of our GitHub Workflows

We use several workflows that build on each other to achieve the requirements mentioned above. I'll go through them step by step and explain how we use them to fully automate everything from PR builds to deploying to Maven Central.

✅ The CI Workflow

At the heart of our CI/CD automation is the continuous-integration workflow. It is triggered on every pull request and comprises multiple jobs, from building the code to running tests and quality checks.

Here is a simplified excerpt from the build job:

build:
  name: "Build"
  needs: [ context, check-formatting ]
  runs-on: ubuntu-latest
  steps:
    - name: "Checkout repository"
      uses: actions/checkout@v4
      # ...
    - name: "Setup java"
      uses: actions/setup-java@v4
      # ...
    - name: "Restore Dependencies"
      id: restore-dependencies
      uses: actions/cache/restore@v4
      # ...
    - name: "Build SDK"
      run: |
        MVN_ARGS="${{ env.MVN_MULTI_THREADED_ARGS }} install -DskipTests -DskipFormatting"
        # ...
        echo "[DEBUG] Running Maven with following arguments: $MVN_ARGS"
        mvn $MVN_ARGS
    - name: "Cache Dependencies"
      if: ${{ steps.restore-dependencies.outputs.cache-hit != 'true' }}
      uses: actions/cache/save@v4
    # ...
  # ..

This is how it looks like when triggered on a pull request:

Aside from the typical build and test jobs you can see some of the tools we use to ensure code quality, such as CodeQL, Checkstyle, PMD and SpotBugs. Some other tools such as BlackDuck are shown but disabled for pull request builds. You'll also notice that the workflow is designed to fail fast, having fast running jobs at the beginning and more time-consuming jobs in parallel or at a later stage, wherever possible.

Finally, you'll notice the Collect Context job at the start of the workflow. This becomes relevant later when we look at how we use the CI workflow for builds on the main branch and releases.

The details of the individual jobs such as build and test contain much more than what is shown in the diagram. I'll explain some of the tips and tricks we used to get them to work efficiently and reliably further down in this post. For now, let's move on to how we use the CI workflow for builds on the main branch and releases.

📸 The Main Branch Workflow

The main build is triggered by commits on the main branch. In addition to running the same checks as on pull requests, it should also run a BlackDuck scan and deploy the current snapshot to an internal Maven repository.

This is how it looks like when triggered on the main branch:

As you can see, the main build triggers the CI workflow and runs the deployment afterward. When triggering the CI workflow it passes a parameter to inform the workflow it should also run the BlackDuck scan. Finally, in case the workflow fails it also sends a Slack notification to the development team.

📦 The Release Workflow

We are using a two-step process for releasing to Maven Central, comprised of two workflows: prepare-release and perform-release. Both workflows are triggered manually and are designed to provide as much automation while being as reliable as possible.

The prepare-release workflow first creates a branch for the release and increments the projects version to the desired release version. Then it triggers the CI workflow on the commit with the release version set and with additional parameters to sign the produced artifacts with a GPG key and enable JavaDoc generation.

Once the CI build completes, it creates a release tag, a draft release and pull requests for the release notes and JavaDocs. Finally, if all steps succeeded, it increases the version number again to the next snapshot version and raises a pull request on the code base. If any of the steps failed the workflow will roll back the changes.

If everything looks good we trigger the perform-release workflow which will deploy the artifacts to Maven Central and merge the open pull requests.

This two-step approach allows us to ensure everything is in place and functional before actually deploying the new version. For example, we can tweak the release notes or the GitHub release description while still having the process fully automated. And in case anything goes wrong it is much easier to fix it, compared to having one large release pipeline.

🔎 The Details of GitHub Actions and our Maven Project

Now that you have an idea of how the overall architecture of our GitHub workflows looks like, let's dive into some of the details of the workflows. Please keep in mind that this part is somewhat specific to building larger Java projects using Maven.

📂 Keeping Track of Build Artifacts

We are using several jobs in our workflows that depend on each other. For example, the build job produces the artifacts that are then used in the test job.

Now, for this to work one has to share the artifacts produced in the build job with the test job. This turned out to not be as straightforward as one might think. Some tasks would require the compiled classes (e.g. running tests), others would require the JAR files (e.g. the signing step) and others would require the JARs to be installed in the local Maven repository (e.g. the archetype test stage).

We solved this by using the upload-artifact and download-artifact actions. We configured them to upload all ./**/target/** directories produced by the build job. We also upload the part of the local Maven repository that contains our own artifacts (~/.m2/repository/com/sap/cloud/sdk/**). Subsequent jobs that require these artifacts download them.

To speed up build times we also use a cache for our dependencies. That means dependencies don't have to be re-downloaded for every build, which speeds up the build significantly. However, because our own artifacts are also installed into the local Maven repository, we have to be careful to exclude them from this cache. Otherwise, build results from previous builds would leak into subsequent runs. So we use exclusion patterns when setting up the cache to exclude our own artifacts.

🔁 Dealing with the Maven Build Lifecycle

Maven has a well-defined build lifecycle where each phase builds on the previous phase. This becomes a bit of a challenge if you have a larger project and want to separate out individual build steps.

For example, running mvn compile in one job, uploading the artifacts, then downloading them and running mvn test in another job would internally run the compile phase again. This happens because uploading and downloading the artifacts affects the file timestamps and Maven considers the files to be outdated.

In addition, we are using a lot of Maven plugins to verify various aspects of our code base. We are using multiple formatting plugins, static code analysis plugins, test coverage plugins, dependency analyzers and more. To speed up the build process and to fail fast we want to run these checks as early as possible and in parallel.

To solve this, we are invoking the plugins explicitly in their dedicated jobs (e.g. formatting and code style analysis). For the build job we run mvn install and exclude tests as well as any plugins that run elsewhere via specific properties. Finally, the test stage invokes the Maven surefire plugin and the code coverage plugin directly to avoid recompiling the code.

While saving a few minutes of build time, this also gives us the flexibility to turn individual checks on or off. Last, but not least, splitting the build process into individual jobs makes it much easier to see where a build failed and why.

However, this requires a good understanding of your Maven project and how you have configured your profiles and plugins.

📌 Keeping Track of which Artifacts to Release

The Cloud SDK is a multi-module Maven project with several modules that are not intended for public release. For example, we have modules like testutil or odata-api-sample that are only used for testing. When releasing to Maven Central we want to make sure that only modules that are intended for public release are actually deployed. This can be achieved using Maven profiles, for example by listing the test modules only under a certain profile.

But we found that this solution isn't reliable enough for our purposes. For example, a profile may be forgotten to be (de-) activated within any of the various steps in our build pipeline. Or, if a module is moved or renamed, one has to be extra careful the profile continues to apply after the refactoring.

To solve this, we are using a custom script that builds and verifies the module-inventory.json file. It contains a list of all modules, their intended release scope as well as further information (e.g. if it requires a license and security scan, or if the module is in beta, production ready or deprecated). This information is explicitly declared via properties in each module's pom.xml file and thus immediately visible to anyone working on the project.
Any changes would be detected by the CI pipeline and the build would fail if the module-inventory.json has not been updated accordingly.

Finally, the release pipeline uses the module-inventory.json to determine which modules to release and deploys exactly those artifacts.

💡Challenges and Learnings

One of the challenges we faced was how to develop and test the workflows. GitHub Actions can not be easily re-ran or debugged locally, each change in a workflow file has to be committed and pushed to the repository. But we didn't want to spam our repositories with commits, tags, releases and pull requests during the development phase. Furthermore, we didn't want to publish any artifacts to Maven Central during the development and testing phase. Still, we wanted to test the release pipeline as close to the real process as possible.

To solve the first issue we used forks of the repository for developing and testing the workflows until they were close enough to the final version. Some of the larger changes required 200-300 commits until we got the desired result (for example, see this PR). When merging we squashed everything into a single commit to not clutter the version history.

Also, we limited pipeline steps to only a few lines of shell commands per step. For anything more complex (e.g. generating a JSON file, generating a test report XML file, etc.) we created Python scripts that could be tested independently on a local machine. Finally, we tested our release automation by deploying snapshots to the Sonatype snapshot repository. This also allowed us to give SAP-external developers access to a release candidate for testing.

📖 Conclusion

After several iterations and a lot of testing we now have fully automated CI/CD pipelines that meet our requirements. Using GitHub Actions we were able to replace our complex Jenkins setup with a modern and publicly accessible alternative. That enables also SAP-external developers to contribute to the project and accelerates the development of the SAP Cloud SDK for Java.

That concludes this series on open sourcing the SAP Cloud SDK for Java. Please don't hesitate to share your thoughts on the migration process or what you may have done differently. How do you build your Java projects with GitHub Actions? Do you also use multiple workflows and jobs, do you use re-usable workflows or custom actions? Or do you have one large workflow that does everything? As usual, let me know in the comments below 😉.

Custom Spring Boot application in SAP BTP CF integrates with BTP Document Management Service(DMS

2024-08-17T01:58:19.050000+02:00

Introduction

The SAP BTP Document Management Service(DMS) helps in managing business documents. It's based on the OASIS (Organization for the Advancement of Structured Information Standards) industry standard CMIS (Content Management Interoperability Services) and includes features like versioning, hierarchies, access control, and document management.

In this blog, I am going to explain how to create a custom spring boot application in SAP BTP cloud foundry and integrate it with SAP BTP DMS.

Business Scenario

Let’s say we have a requirement where we need to replicate documents from different SAP SaaS applications(e.g. SAP SuccessFactors) to SAP BTP Document Management Service. In this case, we can create a custom Java Spring Boot application and deploy it to BTP Cloud Foundry as an MTA(multi-target application). Spring Boot application can have scheduled Cron Jobs(if there is any need for automation) or REST APIs(to be triggered from UI and any other application) to interact with DMS rest APIs and SuccessFactors.

Or if you have a custom application, and you want to use SAP BTP DMS for document management then this example will be helpful.

Technical Details

In this blog, I will create a maven-based spring boot application(MTA) and will expose a REST API that will upload a document in the DMS. Spring Boot application will interact with DMS REST API through BTP destinations. The main reason for using BTP destinations is the DMS authentication will be taken care of by BTP destinations. I will be using SAP Cloud SDK to interact with BTP Destinations from Spring Boot.

Architecture

Prerequisite

Access to SAP BTP Cloud Foundry, and org & space are created.
Access to BTP destination.
Access to SAP BTP DMS service and DMS repository is created.
Eclipse(with Spring tool suite and Lombok plugin) and JDK(1.8) are installed in the development system.
Cloud Foundry command line interface (CF CLI) is installed, and the path is set in the environment variable.
Cloud MTA build tool (MBT) is installed, and the path is set in the environment variable.
Make tool is installed, and the path is set in the environment variable.

Create a destination in SAP BTP for DMS service

Please make sure the URL contains the repository ID and folder name(if no folder is created in the repository, then use root)

Steps to create the Application

Create a maven based spring boot project in Eclipse.

Open the pom.xml file and replace it with the below code.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.2.0.RELEASE</version>
		<relativePath/> <!-- lookup parent from repository -->
	</parent>
	<groupId>com.sl</groupId>
	<artifactId>SampleSAPBTPApplication</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>SampleSAPBTPApplication</name>
	<description>Sample SAP BTP App with Spring Boot</description>
	<url/>
	<licenses>
		<license/>
	</licenses>
	<developers>
		<developer/>
	</developers>
	<scm>
		<connection/>
		<developerConnection/>
		<tag/>
		<url/>
	</scm>
	<properties>
		<java.version>1.8</java.version>
		<swagger.version>2.9.2</swagger.version>
	</properties>
	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>com.sap.cloud.sdk.cloudplatform</groupId>
			<artifactId>scp-cf</artifactId>
			<version>3.46.0</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web-services</artifactId>
		</dependency>
		        <dependency>
		    <groupId>org.apache.httpcomponents</groupId>
		    <artifactId>httpclient</artifactId>
		    <version>4.5.10</version>
		</dependency>
		<dependency>
		    <groupId>org.apache.httpcomponents</groupId>
		    <artifactId>httpmime</artifactId>
		    <version>4.5.10</version>
		</dependency>
		<dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger2</artifactId>
            <version>${swagger.version}</version>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-swagger-ui</artifactId>
            <version>${swagger.version}</version>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-bean-validators</artifactId>
            <version>${swagger.version}</version>
        </dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

	<packaging>war</packaging>
</project>

Create a Java class and replace the code with the below code (please check the package and class name).

package com.sl.demo.api;

import java.io.IOException;

import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.client.HttpClient;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.ContentType;
import org.apache.http.entity.mime.MultipartEntityBuilder;
import org.apache.http.util.EntityUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.multipart.MultipartFile;

import com.sap.cloud.sdk.cloudplatform.connectivity.DestinationAccessor;
import com.sap.cloud.sdk.cloudplatform.connectivity.HttpClientAccessor;
import com.sap.cloud.sdk.cloudplatform.connectivity.HttpDestination;

import io.swagger.annotations.ApiOperation;
import io.swagger.annotations.ApiResponse;
import io.swagger.annotations.ApiResponses;

@RestController
public class BTPDMSService {

	private final Logger log = LoggerFactory.getLogger(this.getClass());

	/**
	 * Attaches a generic file to an existing work.
	 */
	@RequestMapping(method = RequestMethod.POST, path = "/uploadFile", produces = "application/json", consumes = "multipart/form-data")
	@ApiOperation(value = "Attaches a generic file to an existing work.")
	@ApiResponses({ @ApiResponse(code = 200, message = "OK", responseContainer = "Map", response = Long.class),
			@ApiResponse(code = 400, message = "Bad request"),
			@ApiResponse(code = 401, message = "Unauthorized, basic auth required"),
			@ApiResponse(code = 403, message = "Forbidden") })
	public String uploadFile(@RequestParam("attachment") MultipartFile file) throws IOException {

		log.info("Upload file started");

		String DESTINATION_NAME = "MyDestinationForDMS";
		byte[] content = file.getBytes();
		String filename = file.getOriginalFilename();
		String contentType = file.getContentType();

		HttpDestination destination = DestinationAccessor.getDestination(DESTINATION_NAME).asHttp();
		HttpClient httpclient = HttpClientAccessor.getHttpClient(destination);

		MultipartEntityBuilder builder = MultipartEntityBuilder.create();

		log.info("Uploading file : {}", filename);
		builder.addTextBody("cmisaction", "createDocument");
		builder.addTextBody("propertyId[0]", "cmis:name");
		builder.addTextBody("propertyValue[0]", "testSudhir01.json");
		builder.addTextBody("propertyId[1]", "cmis:objectTypeId");
		builder.addTextBody("propertyValue[1]", "cmis:document");
		builder.addTextBody("filename", "testSudhir01");
		builder.addTextBody("_charset_", "UTF-8");
		builder.addTextBody("includeAllowableAction", "true");
		builder.addTextBody("succinct", "true");
		builder.addBinaryBody("media", content, ContentType.create(contentType), filename);

		HttpEntity postData = builder.build();
		HttpPost httpPost = new HttpPost();
		httpPost.setEntity(postData);
		HttpResponse response = httpclient.execute(httpPost);
		HttpEntity entity = response.getEntity();
		log.info("Response from post File: {}", response.getStatusLine().getStatusCode());
		log.info("******** Response Body **********: {}", EntityUtils.toString(entity));

		return "Executed with status Code:" + response.getStatusLine().getStatusCode();
	}

}

Create a Java class for swagger config and replace the code with the below code.

package com.sl.demo.swagger;

import java.util.Collections;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;

import springfox.bean.validators.configuration.BeanValidatorPluginsConfiguration;
import springfox.documentation.builders.PathSelectors;
import springfox.documentation.builders.RequestHandlerSelectors;
import springfox.documentation.service.ApiInfo;
import springfox.documentation.service.Contact;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spring.web.plugins.Docket;
import springfox.documentation.swagger2.annotations.EnableSwagger2;

@Configuration
@EnableSwagger2
@Import(BeanValidatorPluginsConfiguration.class)
public class SpringFoxConfig {

	String appTitle = "DMS Integration";

	@Bean
	public Docket api() {
		return new Docket(DocumentationType.SWAGGER_2).apiInfo(apiInfo()).select()
				.apis(RequestHandlerSelectors.basePackage(parentPackageName())).paths(PathSelectors.ant("/**")).build();
	}

	private String parentPackageName() {
		String thisPackageName = getClass().getPackage().getName();
		int lastDotPos = thisPackageName.lastIndexOf('.');
		String parentPackageName = thisPackageName.substring(0, lastDotPos);
		return parentPackageName;
	}

	private ApiInfo apiInfo() {
		return new ApiInfo(appTitle + " API", "This is the API for the " + appTitle + " application.", "v1", null,
				new Contact("SL", "", "test@sl.com") , null, null,
				Collections.EMPTY_LIST);
	}
}

Create a mta.yaml file in the workspace (where the project is created) and paste the below code into the mta.yaml file.

_schema-version: '3.0.0'
ID: com.sl.sampleApplication
description: Sample Application
version: 1.0.0
modules:
  - name: SampleSAPBTPApplication
    type: java
    path: SampleSAPBTPApplication
    parameters:
        stack: cflinuxfs4
        memory: 2048M
        instances: 1
        buildpacks:
           - java_buildpack
        build-parameters:
             builder: custom
             timeout: 10m
             build-result: target/SampleSAPBTPApplication-*.jar
             commands:
               - mvn clean install -Dcheckstyle.skip -DskipTests=true -Pdev
    requires:
      - name: BTPDestinationResource
# Binding services
resources:
  - name: BTPDestinationResource
    type: org.cloudfoundry.managed-service
    parameters:
      service-name: MyDestinationInstance
      service-plan: lite
      service: destination

Select the project in Eclipse and update(Maven) the project, please make sure there is no compilation error.

Build and Deployment

Open the command prompt from the workspace(where the mta.yaml file is placed) folder.

Build the project to generate the “.tar” file by using the below command in the command prompt.

mbt build -t SampleSAPBTPApplication/generatedTAR --mtar SampleApplication.tar

If the build is successful, then SampleApplication.tat file will be created in the generatedTAR folder.

Use the below commands in the command prompt to log in to the BTP cloud foundry and deploy the project. (It will prompt you to enter the username and password for BTP. it will prompt you to select org and space if there is more than one)

cf login -a https://api.<CF API host>.hana.ondemand.com

cf deploy SampleSAPBTPApplication/generatedTAR/SampleApplication.tar

Once the deployment is successful, it will be shown in the applications under the space.

If everything is fine, then the status will be showing as started and the application can be accessed by using the URL shown under application routes.

Testing

The application can be tested by using the swagger URL from the application as mentioned below.

https://<app URL-dev-samplesapbtpapplication.hana.ondemand.com>/swagger-ui.html

Click on “/uploadFile” API to test the file upload functionality.

Choose any file and click on “Execute”.
If everything is fine, then the file will be uploaded to DMS and can be found in DMS.

Conclusion

This blog is written based on my learning and understnading, please feel free to comment for the improvement. Same thing can be achieved by creating a CAP appllication, in the next blog I will explain how to achieve the same requirement through a CAP (Java) application.

If anybody is interested for the code, please feel free to pull it from git.

https://github.com/sudhirlenkagit/MTASpringBootIntegratesDMS.git

Thanks,

Sudhir Lenka.

SAP Cloud Integration API - Collection of OData Clients using JS/TS and SAP Cloud SDK

2024-09-02T15:20:00.706000+02:00

TL;DR

Hey everyone, I'm a very new developer in the SAP ecosystem and I want to share some stuff.

To consume the SAP Cloud Integration APIs from JS/TS, you must install the SAP Cloud SDK and utilize the generated clients. It is necessary to properly configure tsconfig when using Typescript, which can be challenging as it may not always be compatible with your project.

(Trying to write down a entire client using axios is really painful)

Additionally, these files begin to appear in every project, leading to unnecessary boilerplate in many repositories within SAP projects.

Now you can simply run `npm install ts-sap-cloud-odata-api-v2-client` and start using the generated clients immediately without any stress.

Process followed: https://sap.github.io/cloud-sdk/docs/js/features/odata/generate-client

Features

I've just generated clients for the https://api.sap.com/package/CloudIntegrationAPI/odata

Before moving forward, please pay attention to this: https://github.com/GiuseppeMP/sap-cloud-integration-odata-api-v2-clients?tab=readme-ov-file#-disclaimer- 🙏

Install

npm i ts-sap-cloud-odata-api-v2-client

Dependencies

npm i -cloud-sdk/connectivity #required
npm i -cloud-sdk/odata-v2 #optional

Usage

Now you can simply use the generated clients in your code. The entire interface was kept from the SDK, and you can refer to the https://sap.github.io/cloud-sdk/docs/js/getting-started to learn more.

https://sap.github.io/cloud-sdk/docs/js/features/odata/execute-request

Each client is isolated in a module that can be imported using `'ts-sap-cloud-odata-api-v2-client/{APINAME}'`.
This is necessary to avoid conflicts with other modules as they are all generated separately.

Example that how I'm using

import {messageProcessingLogs, MessageProcessingLogsType } from 'ts-sap-cloud-odata-api-v2-client/MessageProcessingLogs'
import { registerDestination } from '@sap-cloud-sdk/connectivity'

async function example(name: string, url: string) {

await registerDestination(
{
name: name, // choose name
url: url // add url to your tenant
},
);

const basePath = "/api/v1" // change if needed

const requestBuilder = messageProcessingLogs<MessageProcessingLogsType>().messageProcessingLogsApi.requestBuilder().getAll()

const getAll = requestBuilder.setBasePath(basePath).addCustomHeaders({ 'authorization': `Bearer ...` })

return getAll.execute({ destinationName: name })
}

Show your support

Give a ⭐️ if this project helped you!

If you would like to ask about features, other API clients, report bugs, or seek help, please feel free to create an issue in the GitHub repository.

https://github.com/GiuseppeMP/sap-cloud-integration-odata-api-v2-clients/issues/new

It's a very new repository, I really appreciate feedback and collaborations folks!

See you!

Build a Java Spring boot middleware application to consume SAP OData service with SAP Cloud SDK

2024-09-08T01:45:30.799000+02:00

Introduction

We had a requirement to consume a SAP OData service in an existing spring boot application running on SAP BTP Cloud Foundry. There are many ways to consume an OData service in a Java application, but we found an easier way to consume the OData service by using SAP Cloud SDK. There are many business use cases where we need to develop an application to run on SAP BTP or any cloud and consume OData service. In this blog, I will share the steps to consume an OData service in a maven-based Java Spring boot application with the help of SAP Cloud SDK.

Understanding SAP Cloud SDK

SAP provides a software development kit (SDK) called the SAP Cloud SDK to make developers' jobs easier. The SDK contains a set of libraries that simplify interacting with APIs at a higher level by hiding technical communication details.

The SAP Cloud SDK was developed to reduce the effort of building extension applications for SAP S/4HANA Cloud. It provides Java and JavaScript libraries, as well as a set of tools for developers, such as fault tolerance, cache management, tutorials, and project templates.

The SAP Cloud SDK enables partners, customers to easily consume OData services from SAP S/4HANA Cloud, discover existing OData services, and use built-in developer tools such as cache management, API metering, latency, and fault tolerance.

SAP Cloud SDK also allows you to generate the Virtual Data Model (VDM) of custom OData Services as well as standard SAP OData Services. This VDM can then be readily consumed by your application

SAP CAP Model uses SAP Cloud SDK behind the scenes to perform a variety of tasks.

Business use cases

Scenario 1:- If you are planning to build your application using MongoDB, then you will not be able to use the CAP Model (since it only supports HANA for production), so you can create an application(MTA) in Java Spring boot and make use of SAP Cloud SDK for connecting to remote systems, consuming APIs in a type-safe manner, securing your application and providing multi-tenant support, etc.
Scenario 2: - If you already have an existing Java application that was built without using the SAP CAP Model and you want to add more features like consuming an OData service.
Scenario 3: - If you need advanced features in your app (currently, not provided by CAP Model) - for example, Resilience.
Scenario 4: - You Are Extending an SAP Product or Service, building a Middle-Ware, Publishing a Cloud App

Steps at a high level

Create a maven-based Java Spring boot application/project.
Download the metadata of the service and save it as “serviceName.edmx”.
Put the EDMX file in the resource folder of the application/project.
(optional) Create a service naming properties file in the resource folder.
Add the dependencies (SAP Cloud SDK OData generator and others) in the pom.xml file.
Add the OData generator maven plugin in the pom.xml file.
Compile the application to generate the type-safe Java client library from the EDMX of the service, which gives you programmatic access to all the entities, fields, and structures of the OData service
Create the controller class and use the generated classes to interact with the OData service.
Create the destination in the environment variable for local testing and in the BTP for productive use.
Run the application and test it locally.
Deploy the application to BTP Cloud Foundry as an MTA application.

Prerequisite

Eclipse(with Spring tool suite and Lombok plugin)
JDK(1.8).
Access to any OData service (I will be using Business Partner API from SAP Business Accelerator Hub)

(In this blog I will not cover the BTP deployment, I will explain how to test the application locally. Please refer to my other blog for deployment to BTP Cloud Foundry)

Steps

Create a new spring boot project in Eclipse as mentioned below.

The project structure in eclipse will look like below.

Open the pom.xml file and replace the below code.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.2.0.RELEASE</version>
		<relativePath /> <!-- lookup parent from repository -->
	</parent>
	<groupId>com.sl</groupId>
	<artifactId>SpringBootToConsumeODataThroughCloudSDK</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>SpringBootToConsumeODataThroughCloudSDK</name>
	<description>Sample Spring Boot App to consume OData through Cloud SDK</description>
	<url />
	<licenses>
		<license />
	</licenses>
	<developers>
		<developer />
	</developers>
	<scm>
		<connection />
		<developerConnection />
		<tag />
		<url />
	</scm>
	<properties>
		<java.version>1.8</java.version>
	</properties>
	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web-services</artifactId>
		</dependency>



		<dependency>
			<groupId>com.sap.cloud.sdk.datamodel</groupId>
			<artifactId>odata-core</artifactId>
			<version>4.15.0</version>
		</dependency>
		<dependency>
			<groupId>org.projectlombok</groupId>
			<artifactId>lombok</artifactId>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>javax.inject</groupId>
			<artifactId>javax.inject</artifactId>
			<version>1</version>
			<scope>provided</scope>
		</dependency>

	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>

			<plugin>
				<groupId>com.sap.cloud.sdk.datamodel</groupId>
				<artifactId>odata-generator-maven-plugin</artifactId>
				<!-- Please use the latest version here -->
				<version>4.15.0</version>
				<executions>
					<execution>
						<id>generate-consumption</id>
						<phase>generate-sources</phase>
						<goals>
							<goal>generate</goal>
						</goals>
						<configuration>
							<inputDirectory>${project.basedir}/src/main/resources/edmx</inputDirectory>
							<outputDirectory>${project.build.sourceDirectory}</outputDirectory>
							<serviceNameMappingFile>${project.basedir}/src/main/resources/serviceNameMappings.properties</serviceNameMappingFile>
							<deleteOutputDirectory>false</deleteOutputDirectory>
							<packageName>com.sl.vdm</packageName>
							<defaultBasePath>odata/v2/</defaultBasePath>
							<compileScope>COMPILE</compileScope>
							<serviceMethodsPerEntitySet>true</serviceMethodsPerEntitySet>
							<overwriteFiles>true</overwriteFiles>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

</project>

(In this blog we will be using OData V2 and SAP Cloud SDK version 4, if you want to consume OData V4 then the dependency version needs to be changed in the pom.xml file)

Go to SAP Business Accelerator Hub to download the metadata of the OData service.
Search for “business” in the search box for business partner OData service (In this blog we will be using OData V2).

(Please login with your personal(trial) SAP user account)

Click on “Business Partner (A2X)” to navigate to business partner API.
Click on “API Specification” and download the EDMX (service metadata).

(If you want to consume an OData service that is not available in the Business Accelerator Hub like On-promise ECC/S4HANA OData service then you can fetch the metadata of the service by using $metadata and save the content in a .edmx file{any name})

Create a folder called “edmx” in the resource folder of the project and copy the downloaded/created edmx file.
Also create a properties file “serviceNameMappings.properties” in the resource folder.

# API BUSINESS PARTNER
API_BUSINESS_PARTNER.className = APIBusinessPartner
API_BUSINESS_PARTNER.packageName = businesspartner

Now the folder structure in Eclipse should look like below.

Now compile the project by using the “maven install” command.

Once the project is compiled successfully it will generate the classes for the OData service which will be used in our business logic for integration with the OData service.
Now the folder structure should look like below in Eclipse.

(Sometimes it doesn’t create the correct URL in the generated service interface (APIBusinessPartnerService,java), so please verify and replace it with the correct URL as mentioned below. You can find the correct URL when you click “Code Snippet” in the “Try Out” tab in Business Accelerator Hub)

String DEFAULT_SERVICE_PATH = "odata/sap/API_BUSINESS_PARTNER";

Now create a controller class (BusinessPartnerController.java) to fetch business partners.
Replace the below code in the BusinessPartnerController class.

package com.sl.api;

import java.util.List;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import com.google.gson.Gson;
import com.sap.cloud.sdk.cloudplatform.connectivity.Destination;
import com.sap.cloud.sdk.cloudplatform.connectivity.DestinationAccessor;
import com.sap.cloud.sdk.cloudplatform.connectivity.HttpDestination;
import com.sl.vdm.namespaces.businesspartner.BusinessPartner;
import com.sl.vdm.services.DefaultAPIBusinessPartnerService;

@RestController
public class BusinessPartnerController {

	private final Logger log = LoggerFactory.getLogger(this.getClass());
	private static final String APIKEY_HEADER = "apikey";
	private static final String SANDBOX_APIKEY = "---Generated API Key---";

	@GetMapping("/GetBusinessPartners")
	public ResponseEntity<?> getBusinessPartners() {
		String DESTINATION_NAME = "MyDestination"; // in productive code, use constants file to
													// retrieve destination name
		 HttpDestination destination =
                 DestinationAccessor.getDestination(DESTINATION_NAME).asHttp();
		

		final List<BusinessPartner> businessPartners = new DefaultAPIBusinessPartnerService()
				.getAllBusinessPartner().select(BusinessPartner.BUSINESS_PARTNER, BusinessPartner.LAST_NAME,
						BusinessPartner.FIRST_NAME, BusinessPartner.CREATED_ON)
				.filter(BusinessPartner.MALE.eq(true))
				.top(200)
                .withHeader(APIKEY_HEADER, SANDBOX_APIKEY)
				.executeRequest(destination);

		return ResponseEntity.ok( new Gson().toJson(businessPartners));
	}
}

Generate the API key from Business Accelerator Hub and copy it in the variable SANDBOX_APIKEY in BusinessPartnerController class.

(If the OData service is from other system like ECC or S4HANA then this step is not required, and the authentication will be set in the destination which will be automatically picked up by the SAP Cloud SDK library)

Now we need to create a destination in the environment variable to configure the OData service URL and authentication details (in this case authentication is not required).
Right-click on the project and select the run configuration, select the “Environment” tab in the dialogue box.
Click on “Add” to create an environment variable for the destination. Keep the name as “destinations” and value as mentioned below.

[{"name": "MyDestination", "url": "https://sandbox.api.sap.com/s4hanacloud/sap/opu/"}]

<<sample destination with basic authentication>>

[{"name": "MyDestination", "url": "--OData service base URL--", "user": "---user name---", "password": "--password for the given user--" }]

(You can add multiple destinations to connect to different systems)

Click on apply and run.
If everything is fine, then it will be a success and show the port number for the App.
Now you can test it from your browser by using the application URL

Note :- This blog is written based on my personal learning and experience, please feel free to commnet for improvement.

Happy learning!!

Best Regards,

Sudhir.

Integrating with SAP Datasphere API through BTP Destination Using OAuth SAML Bearer Assertion

2024-09-30T10:39:53.533000+02:00

For our proof of concept, we aimed to access the SAP Datasphere API via SAP BTP, utilizing the OAuth2 SAML Bearer authentication flow. Ideally, we wanted to connect directly to this destination through a route in our Approuter.

We found this blog post helpful as a starting point: Integrating with SAP Datasphere Consumption APIs Using SAML Bearer. Thanks to @gustavokath

However, the solution required an additional (NodeJS) middleware. Our goal was to achieve this both with and without a Node.js middleware, leveraging the destination service and default approuter.

We encountered some issues that I would like to document. If our experience can help anyone facing similar challenges along the way, that would be wonderful! 🙂

Prerequisite: Make sure to check out the blog I mentioned earlier, as I won’t be going over all the steps again. I’ll just point out the differences we made.

With NodeJS middleware:

In the scenario where we used a Node.js middleware, we opted for the SAP Cloud SDK instead of handling HTTP requests with Axios. The SAP Cloud SDK simplifies integration with SAP services, providing built-in tools for handling authentication and API interactions. You can find more details in the SAP Cloud SDK documentation.

The following code does the trick:

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

//Simple example method to call datasphere destination via Cloud SDK
//Assuming req is a Request object coming from ExpressJS
const callDatasphere = (req, path, params) => {

const jwt = connectivity.retrieveJwt(req);
const destination = await connectivity.getDestination({ destinationName: "datasphere_destination", jwt: jwt });

 let url = `${dest.url}${path}`;
    let result = await httpclient.executeHttpRequest(dest, {
      url: url,
      method: "get",
      headers: { "Content-Type": "application/xml" },
      params: params
    });

return result.data;
}

Without NodeJS middleware

The above example worked perfectly for us. However, we also wanted to explore an implementation without using a Node.js middleware. In this case, only a managed or custom approuter would be utilized.

For this we added a router to the approuter xs-ap.json file:

While testing this setup, we encountered an unexpected "unauthorized" error. This was puzzling because the destination worked flawlessly when used with the Cloud SDK. To investigate further, we fetched the destination data using Postman. The response confirmed that the tokens were generated correctly, indicating that the OAuth2 SAML Bearer flow was functioning as expected.

While debugging the Approuter, we discovered that it was adding additional headers to the request being sent to the Datasphere API.

One of these headers was "x-forwarded-host", which contained the source domain. By adding an additional property to the destination configuration, we were able to overwrite this header successfully:

uRL.headers.x-forwarded-host: "your-datasphere-domain.com"

From this point on, we were able to make calls to Datasphere through the Approuter without needing an additional Node.js middleware. This approach also works with a managed Approuter, allowing you to achieve the integration without requiring a Cloud Foundry runtime.

Ideally, Datasphere would offer the ability to allowlist our source domains in a way, eliminating the need for the above change in the destination configuration. If you have any ideas on how to achieve this, feel free to share! For now, we will go forward with this work around :-).

SAP Datasphere SAP Business Technology Platform

Introducing the SAP Cloud SDK for AI (JavaScript/TypeScript) 🎉

2024-10-28T17:57:54.632000+01:00

We are excited to announce the initial release of the SAP Cloud SDK for AI.

Integrate generative AI capabilities into your SAP Business Technology Platform (BTP) applications and leverage the Generative AI Hub in SAP AI Core.

If you’re developing on SAP BTP, the SAP Cloud SDK for AI is designed to make AI integration more accessible and impactful in your applications. With features that streamline deployment management, enhance content safety, and simplify model orchestration, this SDK allows you to quickly incorporate advanced AI capabilities without extensive setup. Whether you need flexible workflows, secure data handling, or seamless integration with generative models, this SDK offers powerful tools to bring AI-driven functionality to your SAP BTP solutions.

In this blog post, we will introduce you to the key packages and their features.

AI Orchestration with @sap-ai-sdk/orchestration

Leverage the generative AI Hub orchestration service and configure templating, content filtering, and data masking for your applications with the @sap-ai-sdk/orchestration package.

With the orchestration service, you can streamline AI interactions and ensure compliance with content safety guidelines.

Templating: Create dynamic prompts with placeholders to customize AI interactions based on user inputs.
Content Filtering: Apply filters to ensure input and output adhere to content safety guidelines.
Data Masking: Anonymize and pseudonymize sensitive information.
Grounding: Integrate external data sources to provide contextually relevant information (planned for Q4 2024).

AI Management with @sap-ai-sdk/ai-api

Automate processes such as creating artifacts, configurations, and deployments, executing batch inference jobs, as well as managing Docker registries and object storage for training data.

The @sap-ai-sdk/ai-api package provides comprehensive tools for managing scenarios and workflows in SAP AI Core.

Artifact Management: Register and manage datasets and other model artifacts.
Configuration Management: Set up configurations for different models and use cases.
Deployment Management: Deploy AI models and manage their lifecycle within SAP AI Core.

LangChain Integration with @sap-ai-sdk/langchai

The @sap-ai-sdk/langchain package provides LangChain-compatible clients for Azure OpenAI models deployed in SAP AI Core, enabling sophisticated AI pipelines within your SAP BTP applications.

Seamless Integration: Built on SAP Cloud SDK for AI's foundation model clients, ensuring compatibility with SAP AI Core and LangChain's ecosystem.
Flexible Clients: Easily initialize chat and embedding clients with support for advanced features like templating and output parsing.
RAG Support: Implement Retrieval-Augmented Generation workflows by combining embedding capabilities with LangChain's text splitters and vector stores.

Generative AI with @sap-ai-sdk/foundation-models

The @sap-ai-sdk/foundation-models package offers streamlined access to specific generative AI models accessible via Generative AI Hub.

It provides a more focused interface compared to the full orchestration capabilities, concentrating on direct model interactions.

This package is ideal for developers who need direct access to foundation models for inference and embedding requests without the additional layers of templating, content filtering, or data masking provided by the orchestration service.

Getting Started

You will need Node v20 or higher and an ESM (ECMAScript Modules) compatible application to use the packages.
To explore these packages further, check out our sample code, which shows the usage of the various SDK packages.

Support and Feedback

We value your feedback on this initial release!

If you need support or want to share your thoughts and ideas, go ahead and open an issue on GitHub.

Latest News

Visit sap.com/ai and explore our portfolio
Explore the available AI capabilities on SAP Discovery Center.
Discover the latest announcements in the SAP TechEd Press Release and the SAP TechEd News Guide.
Review the SAP Road Map Explorer for a detailed view of upcoming product innovations.
Join the SAP Community page to connect with experts and share knowledge.

Introducing the SAP Cloud SDK for AI (Java) 🎉

2024-12-06T18:26:11.077000+01:00

We’re excited to announce the initial release of the SAP Cloud SDK for AI for Java! Only a few weeks ago we already announced the release of the JavaScript/TypeScript variant. Similarly, this SDK for Java enables convenient integration of generative AI capabilities within your SAP Business Technology Platform (BTP) applications and allows you to utilize the Generative AI Hub in SAP AI Core.

For SAP BTP developers, the AI SDK is crafted to simplify AI integration and enhance application impact. With features that optimize deployment, improve content safety, and facilitate model orchestration, the SDK lets you bring advanced AI functionality to your applications swiftly and with minimal setup. Whether you need adaptable workflows, secure data handling, or smooth generative model integration, the SDK equips you with robust tools to embed AI-powered features in your SAP BTP solutions.

This post introduces the main modules and their features.

AI Core - Setup and Usage

<dependency>
  <groupId>com.sap.ai.sdk</groupId>
  <artifactId>core</artifactId>
  <version>1.0.0</version>
</dependency>

Automate tasks such as creating AI Core artifacts, configurations, and deployments, executing batch inference jobs, as well as managing Docker registries and object storage for training data. The core module provides tools for workflow and scenario management within SAP AI Core.

Artifact management: register and organize datasets and model artifacts.
Configuration management: set up configurations for various models and use cases.
Deployment management: deploy AI models and manage their lifecycle within SAP AI Core.

Example SDK code: Create a deployment in SAP AI Core.

var api = new DeploymentApi();
var resourceGroupId = "default";
var request = AiDeploymentCreationRequest.create().configurationId("12345-123-123-123-123456abcdefg");

AiDeploymentCreationResponse deployment = api.create(resourceGroupId, request);
String id = deployment.getId();
AiExecutionStatus status = deployment.getStatus();

You can learn more about the SDK's capabilities for SAP AI Core in the public repository guide.

AI Core - Orchestration

<dependency>
  <groupId>com.sap.ai.sdk</groupId>
  <artifactId>orchestration</artifactId>
  <version>1.0.0</version>
</dependency>

This orchestration module lets you use the Generative AI Hub Orchestration Service with templating, content filtering, and data masking from within your applications. The Orchestration Service streamlines AI interactions while ensuring adherence to content safety guidelines.

Templating: Build dynamic prompts with placeholders to tailor AI interactions to user inputs.
Content Filtering: Apply filters to maintain compliance with content safety guidelines.
Data Masking: Anonymize and pseudonymize sensitive data.
Grounding: Add external data sources for contextually relevant information (planned for Q1 2025).

Example SDK code: Write a simple chat completion.

var client = new OrchestrationClient();
var config = new OrchestrationModuleConfig().withLlmConfig(OrchestrationAiModel.GPT_4O);
var prompt = new OrchestrationPrompt("Hello world! Why is this phrase so famous?");
var result = client.chatCompletion(prompt, config);

String messageResult = result.getContent();

You can learn more about the SDK's capabilities for Orchestration Service in the public repository guide.

AI Core - Foundation Models

<dependency>
  <groupId>com.sap.ai.sdk.foundationmodels</groupId>
  <artifactId>openai</artifactId>
  <version>1.0.0</version>
</dependency>

The openai module, along with other modules in the com.sap.ai.sdk.foundationmodels group, enables streamlined access to specific generative AI models available through the Generative AI Hub. The module provides a simplified interface focused on direct model interactions, ideal for developers who require direct access to foundation models for inference and embedding requests without additional orchestration features.

Currently only openai is supported. Please open a feature request, if you need direct LLM access for other foundation models.

Example SDK code: Write a simple chat completion.

var result = 
  OpenAiClient.forModel(GPT_35_TURBO)
    .withSystemPrompt("You are a helpful AI")
    .chatCompletion("Hello World! Why is this phrase so famous?");

String resultMessage = result.getContent();

You can learn more about the SDK's capabilities for foundation models and OpenAI specific features in the public repository guide.

Getting Started

You will need Java 17 or higher. Spring Boot or SAP Cloud Application Programming Model (CAP) as a framework is recommended, but not required. To explore these packages further, check out our sample project, which shows the usage of the various SDK packages.

Support and Feedback

We’d love your feedback on this first release! For support or to share your ideas, feel free to open an issue on GitHub.

Latest News

SAP Cloud SDK for AI for JavaScript released in October 2024.
Visit sap.com/ai and explore our portfolio
Explore the available AI capabilities on SAP Discovery Center.
Discover the latest announcements in the SAP TechEd Press Release and the SAP TechEd News Guide.
Review the SAP Road Map Explorer for a detailed view of upcoming product innovations.
Join the SAP Community page to connect with experts and share knowledge.

Sending Custom Emails in Digital Manufacturing Using SAP Cloud SDK

2025-01-10T14:22:58.291000+01:00

Introduction

In SAP DM, email notifications can be sent to one or multiple users using the Create & Update Alert Services. To do this, it is sufficient to provide our data to the AlertNotification field, apart from 'IN_APP'. With a recent update to DM, our existing mail destination was automatically brought into the Destinations section inside our BTP account.

When creating custom emails, this destination can be utilized via the Cloud SDK. The reason for leveraging the Cloud SDK for sending custom emails is that the styles and content of emails sent through alert services within DM cannot be customized. If there is a need to send information beyond the fixed email text, an alternative method outside of alert services is required.

Sending Mails with Create Alert Service

In standard DM developments, when using the Create Alert service, we can send the alert to the specified email by setting the ActionType value to SAP_MAIL in the AlertNotification body parameter.

["Figure 1- Alert Notification Body Parameter"]

Additionally, to utilize the mail service, it is necessary to verify that a destination of type 'Mail' is configured in the 'Destinations' section of SAP BTP.

["Figure 2- Destination Configuration of the Mail Server"]

Once the necessary connections are established and the Create Alert service is triggered with the provided parameters, the email notification is received as shown below.["Figure 3-Example Alert Mail"]

However, as can be seen, these template email notifications offer limited capabilities in terms of both content and scenario diversity.

This blog will provide examples of integrating a custom email service into DM as a third party using the mail client feature in Cloud SDK, and utilizing the existing MAIL destination for our processes.

["Figure 4- Basic Send Mail Service"]

["Figure 5- Receiced Basic Mail"]

In addition to the simple email shown in the image, the main additional features that can be added and used are as follows: cc, replyTo, html (the message to be sent can be designed and shared in HTML format), attachments, and priority.

["Figure 6- Mail Attachment Examples"]

Images can be embedded within the page, and they can also be sent as attachments. The key point here is that the name of the image used must match the provided CID correctly.

["Figure 7- Received Mail with Attachments and Images"]

Usage of the Mail Service as a Third Party in DM Processes

By triggering our service via Postman, we are now ready to integrate it as a third party within DM for future process designs. To achieve this, we navigate to 'Manage Service Registry' in DM and create a new service under 'API Services,' assigning our defined path to the URL path.

After configuring our method and defining the request and response structures, we save the service and proceed to 'Design Production Process' for testing.

["Figure 8- Service API Template of Mail Service"]

After opening our design, we navigate to 'Services and Process' and select our mail service from the group where it was added under 'Select Services.' Once selected, we save the configuration. This setup allows us to tailor our setups and introduce variety to our developments based on customer requirements.

["Figure 9a- Custom Service Selection in Process Designer"]["Figure 9b- Basic Process Template with Third Party Service"]

Future Directions & Possibilities

"Examples of scenario customizations and the variety of responses to customer requests enabled by the added email service include:

Automatically sending data via email: Instead of downloading filtered tables from report pages as Excel files, the data can be automatically sent to predetermined or input-specified email accounts after being retrieved.
Sending critical information with CCs: Critical information can be sent to necessary groups, including CCs, to ensure the information reaches all relevant recipients.
Creating internal email handling pages: Developing pages within DM for internal email receipt and response, facilitating better internal communication.

If you like this post or have any questions, please let us know in the comments.
All questions are highly appreciated.

Ege Aksöyek

Reference Documents

Configure Email Notifications | SAP Help Portal

SAP Developer News, January 23rd, 2025

2025-01-23T21:10:00.156000+01:00

DESCRIPTION

Podcast: https://podcast.opensap.info/sap-developers/2025/01/23/sap-developer-news-january-23rd-2025/

Developer Insight Survey

New Release of the SAP Cloud SDK for AI

SDK Release Notes https://github.com/SAP/ai-sdk-js/releases/tag/v1.6.0

Code Connect 2025

Conference website https://code-connect.dev/
Storm Éowyn https://www.bbc.co.uk/weather/articles/cr46z2dv606o
My post-news-item run route https://www.strava.com/activities/13430153502

“Wait for an API Call” Step in SAP Build Process Automation

Daniel’s blog post on the new process step: https://community.sap.com/t5/technology-blogs-by-sap/new-quot-wait-for-api-call-quot-integrates-processes-with-external-systems/ba-p/13992848

New SAP Community interest group - Integration

Integration interest group: https://community.sap.com/t5/integration/gh-p/integration

New Certification Prerequisite for SAP Build Low-Code Certification

Description: https://www.linkedin.com/posts/sabrina-brueck_sapcertification-sapbuild-lowcodenocode-activity-7287391385630982145-4G-c

CHAPTER TITLES

0:00 Intro

0:10 2025 Developer Insight Survey

1:14 Code Connect 2025

2:32 New Release of the SAP Cloud SDK for AI

3:17 “Wait for an API Call” Step in SAP Build Process Automation

4:23 New SAP Community interest group - Integration

4:47 New Certification Prerequisite for SAP Build Low-Code Certification

Transcription

[Intro] This is the SAP Developer News for January 23rd, 2025.

[Riley] The annual SAP Developer Insight Survey is live now. This is the sixth annual running of the survey for us. If you've taken it before, you'll see many familiar questions, things that we use to track trends over time. There's also a deeper exploration this year of topics like generative AI for developers and also developer enablement. In the description section below, you're going to do that. to find two links. The first is actually a link to last year's report. If you haven't looked at that yet, I think you'll find the results interesting. The second link, of course, is to this year's survey. It will take about 12 to 15 minutes of your time to complete. The survey is going to be open for about six weeks. At the end of that time, we'll go off and analyze the data and produce a report that we'll share with you. So I look forward to seeing your comments at the point that we do that. In the meantime, dive into the links, explore it, and we appreciate your feedback. It's important because it helps us shape the programs that we use within the community for 2025. Thank you.

[DJ] Good morning. Storm Éowyn is on its way. It's already bitterly cold. It's starting to rain and the winds are gathering. But I've just got time before I got on my run to tell you about the grassroots annual SAP Tech Conference of the year. That is, of course, Code Connect. Happy way again this year, in the usual place, certainly unruped, in Germany, near Walldorf. In the usual time of year, it's the first full week in July, and we have two usual suspect one-day conferences, the awesome recap and the amazing UI5con, and Code Connect is joined this by a new conference HANA TechCon. So we're also planning to run a couple of CodeJams on the Monday, the first day of the Code Connect week. So let us know if you're interested in those too. For those traveling from afar, there's also an early bird ticket application process. Anyway, all the links are in the description. I'm going to be there and I hope to see you there too.

[Thomas] Hey, I wanted to tell you about the new release of the SAP Cloud SDK for AI. This is a great tool for JavaScript developers to be able to build your own custom AI orchestration services and interactive applications. In this new 1.6 release, we see the inclusion of image recognition in the orchestration service, as well as screaming. capabilities in the orchestration client. So if your JavaScript developer looking to get started with SAP AI capabilities, be sure to check out this new release of the SAP Cloud SDK for AI. AI.

[Daniel] SAP Build Process Automation is introducing a new type of process step. Wait for an API call. The step lets you pause a process automation. and then let an external system call an API to resume it. When you add this type of step to your process, you are creating a new trigger. But instead of this trigger creating a new process instance, it merely resumes an existing instance that had already been paused by the step. The idea is to allow process automation to integrate with external systems and let those systems take over part of the process and then signal back to the process instance that it has finished. It seems like it'll open up a world of possible integration scenarios with process automation. I've written a blog on how to use it, step by step, and I will leave a link to the blog post in the description.

[Antonio] Holla, SAP developers. Did you know that there is a new interest group in SAP community which focuses completely on the integration topic? This is our place to share and connect with a collaborative community of integration developers. Now, what are you waiting for? Go and join a new group. I'm including the link in the description.

[Thomas] I'd like to tell you about a new edition into the certification experience, particularly for SAP build low code no code certification. SAP is adding a new hands-on practical portion of the certification experience. This is a free learning course that comes with system access to allow you to execute exercises to get hands-on practical experience. This is part of a new effort by SAP to bring more practical capabilities and testing as part of the certification experience. So check out the links in the show notes for the addition to the certification, the particular certification that's involved, as well as the free experience learning journey that you can take to get ready for that certification.

SAP BTP Accessing Feature Flag using ClientCredentials Destination. Part - 1

2025-02-05T13:14:44.184000+01:00

Introduction to SAP Feature Flags

The SAP Feature Flags service is designed to help developers manage feature toggles efficiently. By using feature flags, you can control the availability of new features in your application dynamically. This blog post will walk you through a simple application that accesses a feature flag from the Feature Flag dashboard and uses its return value to control application behavior based on different requirements.

Let's not discuss more about it, rather jump into the action. You can find the more details in sap documentation - link

Pre-Requisites

Before diving into the implementation, ensure you have the following:

SAP BTP Feature Flag subscription
Feature Flag Instance
Flag created in the Feature Flag Dashboard
Destination instance

For this demo, we have set up the SAP BTP Feature Flag service, created an instance of the feature flag service, and a destination named featureflagdest.

Setting Up the Environment

Creating the Certificate

First, create the necessary certificates for OAuth2ClientCredentials authentication.

Use the following commands in the BTP command prompt:

cf service-key feature-flag flag-key | sed '/Getting key/d' | jq --raw-output .credentials.x509.certificate > mtls-certificate.pem
cf service-key feature-flag flag-key | sed '/Getting key/d' | jq --raw-output .credentials.x509.key > mtls-private-key.pem

Both of these commands will extract certificate details and store in .pem files.

Combine the contents of mtls-certificate.pem and mtls-private-key.pem into a single certificate.pem file and upload it to the certificates section inside the destination service featureflagdest.

Creating the Destination

Create a destination named FeatureDest with the following details:

Name: FeatureDest
Type: HTTP
URL: https://feature-flags.cfapps.<region>.hana.ondemand.com
Proxy Type: Internet
Authentication: OAuth2ClientCredentials
Use mTLS for token retrieval: Checked
Client ID: <Service Key Credential-> x509-> client_id >
Token Service Key Store Location: certificate.pem
Token Service Key Store Password: Auto-generated from certificate.pem
Token Service URL Type: Dedicated
Token Service URL: https://trial-<subdomain>.authentication.cert.<region>.hana.ondemand.com/oauth/token

Most of the inputs we will get from the flag-key credentials –

We are done creating our destination. We could use Basic Authentication method but thought to use certificate-based ClientCredentials authentication and how to create the .pem file out of the service key.

In the next part we will develop a small application to access the Feature Flag.

--> SAP BTP Accessing Feature Flag using ClientCredentials Destination. Part - 2

SAP BTP Accessing Feature Flag using ClientCredentials Destination. Part - 2

2025-02-05T13:39:46.438000+01:00

In Previous Part-1 we configured the destination through which we will access feature flags. Now we will develop an application. We could use a Simple NodeJs application to access BTP instance, but again thought of developing using sap cloud sdk as described by SAP.

How to develop a simple nodeJS application, you can follow one of my existing blog posts or any other out there in internet.

Run NodeJs in SAP BTP and Locally, Part - 1

(** Note: The blog was written earlier, you may have to adjust the npm packages and little modifications in the code.)

Let’s Start with some command to install packages –

Setting Up the Project

1. Install NestJS: (documentation on NestJS - link )

npm i -g @nestjs/cli

2. Scaffold an Application:

nest new featureflagsapcloudsdk
cd featureflagsapcloudsdk

3. Install OpenAPI Generator:

npm install -D -cloud-sdk/openapi-generator

4. Download and Set Up FeatureFlagsAPI.yaml:

Download from SAP Business Accelerator Hub.
Create folders resources/service-specs and upload FeatureFlagsAPI.yaml. https://api.sap.com/api/FeatureFlagsAPI/overview

5. Create a file options-per-service.json and store in the same folder ‘resources/service-specs’.

{
  "resources/service-specs/FeatureFlagsAPI.yaml": {}
}

6. Install SAP Cloud SDK OpenAPI Package:

npm i -cloud-sdk/openapi

7. Generate Typed Client:

npx openapi-generator --input resources/service-specs --outputDir src/generated

This will generate the below like folders and files –

All the calls or routing will be navigating from app.controller.ts file. These files will be generated by-default.

8. Implementing the Application

Modify app.controller.ts and app.service.ts to include methods for accessing the feature flag.

These applications are based on typescript which generated by sap cloud sdk, but for the demo purposes we are avoiding the types. Mostly we are providing <any> as assigning and return type.

app.controller.ts:

app.service.ts:

Add “import { EvaluateV2Api } from './generated/FeatureFlagsAPI';”

9. Deploying the Application

Now let’s create a manifest file to deploy and bind with other resources –

Destination Featureflagdest already

** I am not very much worried about the authentication here now. So only using the Destination service.

manifest.yaml will look like below –

Before deploying use the below Command, which is must each time you make any changes to any files.

nest build

Now deploy manifest file to BTP Cloud foundry using Command

cf push

10. Run the Application

In BTP, Application is in running state and started.

Execute the module with the path /feature-flag

Here is the output when flag is set to true

When the flag is false

Code Snippet –

app.controller.ts

import { Controller, Get, HttpException } from '@nestjs/common';
import { AppService } from './app.service';
@Controller()
export class AppController {
  constructor(private readonly appService: AppService) { }
  @Get('/feature-flag')
  getFeatureFlag(): any {    
    return this.appService.getFlag()
    .then(response => {
      return response;
    })
    .catch(error => {
      throw new HttpException(
        `Failed to get Feature Flags - ${error.message}`,
        500
      )
    })
  }
}

app.service.ts

import { Injectable, Get ,HttpException } from '@nestjs/common';
import { EvaluateV2Api } from './generated/FeatureFlagsAPI';
@Injectable()
export class AppService {
  async getFlag(): Promise<any> {
    return EvaluateV2Api
          .getV2EvaluateById('<feature_flag_name>', { identifier: '<tenant_id>'})
          .setBasePath('https://feature-flags.cfapps.<region>.hana.ondemand.com/api')
          .execute({ destinationName: '<destination_name>' });
  }
}

manifest.yaml

applications:
  - name: featureflagsdk  
    path: .
    buildpacks:
      - nodejs_buildpack
    memory: 256M
    command: npm run start:prod
    random-route: true
    services:
      - featureflagdest

Conclusion:

By following this posts, you will get the guidance of how to access the BTP Feature flags and use in your different scenarios.

If you have any questions or faced challenges, feel free to drop a comment below.

References –

SAP BTP: Cloud Application Programming Model

2025-03-04T07:09:41.141000+01:00

SAP Cloud Application Programming (CAP) Model exposes the ability to extend standard Cloud, on-premises and hybrid application functionality with flexible custom business logic scripted using the developer’s choice of programing language (SQL, SQL Script, Python, Node.js and JavaScript) and exposing the functionality to various user interfaces (UIs) e.g. Microsoft Power Bi, SAP Fiori, Dataiku and Google Big Query using various integration frameworks e.g. OData v4,JDBC/ODBC depending on the case study.

The developer takes pride in delivering a scalable extended functionality, embedding robust real-time monitoring capabilities to ensure a health life cycle and protecting the functionality with secure authentication protocols e.g. OAuth 2.0, JWT Bearer, SAML version 2.0 and RFC Specification.

Furthermore, the developer ensures a reliable and robust solutions by implementing continuous integration and continuous delivery CI/CD pipelines that automates testing, building and deployment of code changes this strategy ensures a speedy development and delivery cycle.

Traditionally developers extended business logic directly on-premises on the ABAP application server. With the ever-changing world of technology, digital transformation has become essential for organization to say afloat of competitors and therefore the programming model paradigms and capabilities of extending SAP solutions have evolved drastically and provides a seamless experience into the cloud.

Figure 1:

Architectural Paradigm Shift from Classic ABAP App server to CAP App server

Source: Thomas Jung, SAP HANA Extended Application Services blog, URL: https://community.sap.com/t5/technology-blogs-by-sap/sap-hana-extended-application-services/ba-p/12963426/page/4

The SAP Cloud Application model comes with a rich set of languages, libraries, and tools for building enterprise-grade services and applications. It guides developers along a 'golden path' of proven best practices and a great wealth of out-of-the-box solutions to recurring tasks:

Figure 2:

SAP Cloud Application Model Architecture

Source HTTPS://Cap.cloud.sap , URL: https://cap.cloud.sap/docs/about/

The below diagram categories the skill set of SAP Cloud Developer based on the scope of the development either being ABAP or Non-ABAP. Each with its unique set of tools and methodologies:

Figure 3:

SAP Cloud Developer skill set

Source: Building side-by-side extensions on SAP BTP, URL: https://learning.sap.com/learning-journeys/build-side-by-side-extensions-on-sap-btp/identifying-the-need-for-side-by-side-extensibility_f1e838f0-f02a-43b4-8896-cedc25a7d5d0

The Cloud Application Programming model enables a collaboration of agile cross functional teams inclusive of but not limited, depending on the scope of the development: citizen developers (low-code/no-code), Professional developers (Scripting, OOP), business analysts, data engineers and application specialists to model robust data models:

Figure 4:

Agile cross functional team

Source: Investigating the Impact of Cross-Functional Teams on Business Success

URL: https://www.iienstitu.com/en/blog/cross-functional-teams

SAP Cloud Application Programming (CAP) Model enables a culture where people regardless of their title or background, work together to imagine, develop, deploy, and operate a solution. This strengthens the trust between employees and authentic healthy work relationships.

Thank you all for taking a glimpse into the above Content. Please don’t for get to like, comment and share.

Abbreviations:

APP: Application

CAP: Cloud Application Programing

CDS: Core Data Services

CI/CD: Continuous Integration and Continuous Delivery

JWT: JSON Web token

OData: Open Data Protocol

RFC: Remote Function Call

SAML: Security Assertion Markup Language

SQL: Structured Query Language

UIs: User Interfaces

Autoloading Data in SAP Fiori Apps Using SAP CAPM Backend

2025-04-10T16:54:38.645000+02:00

Step-1 : Locate the Manifest.json in your application.

Step-2 : State the changes as shown below in the code.

      "targets": {
        "RecordList": {
          "type": "Component",
          "id": "RecordList",
          "name": "sap.fe.templates.ListReport",
          "options": {
            "settings": {
              "contextPath": "/Record",
              "variantManagement": "Page",
              "initialLoad":true, //Make the intial-load to true
              "navigation": {
                "Record": {
                  "detail": {
                    "route": "RecordObjectPage"
                  }
                }
              },

Step-3 : Make the intialLoad : true,

contextPath: Refers to the entity set exposed by your CAP service (e.g., /Record).

Step-4 : Run your your sap fiori-application & See the magic that happens.

Final Verdict:

Enabling initialLoad: true is a subtle but impactful enhancement that can significantly improve user experience in SAP Fiori List Report applications. However, like any performance-related tweak, it should be applied thoughtfully based on the app’s business purpose, dataset size, and user expectations.

Spoiler

📣I will give only the conditions when the initial-load is not to be used & consider using in other conditions 😊

I will give only the conditions when the initial-load is not to be used & consider using in other conditions

❌ When Not to Use initialLoad: true?

1)Your app handles large datasets or complex queries without filtering.
2) Real-time, always-fresh data is mandatory (e.g., live inventory counts).
3) You rely heavily on dynamic filters that users apply manually before loading.
4) There's a risk of backend performance bottlenecks on auto-load.
5) You're building an app with heavy personalization or variant management that changes frequently.

Using the SAP Cloud Javascript SDK for AI

2025-07-02T14:15:32.107000+02:00

Using the SAP Cloud Javascript SDK for AI

Introduction

In this blog, We will build a Node.js Service with authenticaton that Talks to SAP Generative AI Hub. We’ll spin up a tiny Express server, protect it with XSUAA, call an OpenAI model (gpt-4o-mini) deployed in the Generative AI Hub, and push the whole thing to Cloud Foundry.

Source code is ~70 lines; everything else is service wiring.

Prerequisites

Step 1 — Destination services

Step 2 — Create the XSUAA instance

Step 3 — Scaffold the Node project

Step 4 — Deploy to BTP

Step 5 — Test with Postman

Useful Links

1 · Prerequisites

BTP sub-account (any region)

Generative AI Hub enabled in BTP Cockpit

Node.js ≥ 18 & cf CLI v8 - https://nodejs.org

Postman - https://www.postman.com/

VSCode - https://code.visualstudio.com/

AI Core Instance & Service Key created from BTP

2 · Step 1 — Create Destination Service

Creation of a Destination Service is needed as we will be using it to connect to our GenAI hub instance. There is a way to define custom destination programatically mentioned here.

https://sap.github.io/cloud-sdk/docs/js/features/connectivity/destinations#register-destination

However from my testing I just couldn’t got it to connect to my genai instance. So I will be creating a destination following the documentation

https://sap.github.io/ai-sdk/docs/js/connecting-to-ai-core

Create the Destination Service
Go to the Instances and Subscriptions and click the create button to the right

Select the Destination Service and name it whatever you like

Click on the newly created Destination Service Instance and create a Service Key for it

And then click the 3 dots up on the right corner and go to option View Dashboard here we will be creating a destination. Create a HTTP destination and select Authentication type as “OAuth2ClientCredentials” paste-in the values you have beforehand from the AI Core Service service key.

Important!

Make sure to add /oauht/token to the end of your Token Service URL if there is none.

Click Check Connection. It will give a message;

✅Connection to "my-aicore" established. Response returned: "404: Not Found”.

This is fine as we are not sending a request to the destination yet.

3 · Step 2 — Create XSUAA Service and Service Key

Just like the steps we did when creating our Destination Service create an Authorization and Trust Management (XSUAA) service instance and then create a service key for it.

Only thing to pay attention is to select plan “broker” when creating the service

Then just create the service keys for this service aswell.

4 · Step 3 — Scaffold the Node project

mkdir genai-node && cd genai-node
npm init -y
npm i express -ai-sdk/foundation-models
npm i cfenv /xssec
npm i -D typescript rimraf
npm i -D @types/express @types/cfenv to the
npx tsc --init --outDir dist --rootDir src \
 --target es2022 --module es2022 \
 --moduleResolution node --esModuleInterop tru
mkdir src
touch .cfignore #here put the paths of the files you don't want to deploy to BTP

⚠️TypeScript typings & Express version
This tutorial uses express@5.1 (bundles its own .d.ts files).
Do not install @types/express with Express 5 – VS Code will show

“Duplicate identifier / Cannot redeclare …” errors because two sets of
typings clash.
If you decide to downgrade to express@4.x, then you must add
npm i -D @types/express so the compiler can find the declarations.
In both cases you can safely install the helpers below:

# always safe
npm i -D @types/node @types/cfenv

They silence any remaining red squiggles without affecting runtime.

Complete tsconfig.json

{
 "compilerOptions": {
 "target": "es2022",
 "module": "es2022",
 "moduleResolution": "node",
 "rootDir": "src",
 "outDir": "dist",
 "esModuleInterop": true,
 "allowSyntheticDefaultImports": true,
 "skipLibCheck": true // turns off deep type-checking in node_modules
 },
 "include": ["src/**/*.ts", "*.ts"]
}

Complete package.json

{
 "name": "genai-node",
 "version": "1.0.0",
 "type": "module",
 "scripts": {
 "build": "rimraf dist && tsc",
 "start": "npm run build && node dist/server.js"
 },
 "dependencies": {
 "@sap-ai-sdk/ai-api": "^1.15.0",
 "@sap-ai-sdk/foundation-models": "^1.15.0",
 "@sap-ai-sdk/langchain": "^1.15.0",
 "@sap-ai-sdk/orchestration": "^1.15.0",
 "@sap-cloud-sdk/connectivity": "^4.0.2",
 "@sap/xssec": "^4.8.0",
 "cfenv": "^1.2.4",
 "dotenv": "^16.5.0",
 "express": "^5.1.0"
 },
 "devDependencies": {
 "rimraf": "^6.0.1",
 "ts-node": "^10.9.2",
 "tsx": "^4.20.3",
 "typescript": "^5.8.3"
 }
}

We compile on CF during npm start; the buildpack installs devDeps by default, so no extra steps required.

Create src/server.ts:

import express, { Request, Response, NextFunction } from 'express';
import { AzureOpenAiChatClient } from '@sap-ai-sdk/foundation-models';
import xssec from '@sap/xssec';
import cfenv from 'cfenv';
const app = express();
const port = process.env.PORT || 3000;
const XSUAA_SERVICE_NAME = process.env.XSUAA_SERVICE_NAME;
const appEnv = cfenv.getAppEnv();
const xsuaaService = appEnv.getService(XSUAA_SERVICE_NAME as any);
if (!xsuaaService) {
 throw new Error(`XSUAA service "${XSUAA_SERVICE_NAME}" not bound!`);
}
const uaaCreds = xsuaaService.credentials;
function verifyJwt(req: Request, _res: Response, next: NextFunction) {
 const auth = req.headers.authorization;
 if (!auth?.startsWith('Bearer ')) {
 return _res.status(403).send('Missing bearer token');
 }
 const token = auth.slice(7);
 xssec.createSecurityContext(token, uaaCreds)
 .then(() => next())
.catch((e: any) => {
 console.error('JWT rejected →', e.innerError ?? e.message ?? e);
 _res.status(403).send(String(e.innerError?.message ?? e.message));
});
}
const chat = new AzureOpenAiChatClient(
 {
 modelName: 'gpt-4o-mini' ,
 resourceGroup: 'your-resource-group'
 },
 {
 destinationName: 'my-aicore'
 }
);
app.post('/chat', verifyJwt express.json(), async (req, res) => {
 const userMsg = String(req.body.message ?? '');
 try {
 const resp = await chat.run({
 messages: [{ role: 'user', content: userMsg }]
 });
 res.json({ answer: resp.getContent() });
 } catch (e: any) {
 console.error(e);
 res.status(500).json({ error: e?.message ?? 'server error' });
 }
});
app.listen(port, () => console.log('⇢ listening on', port));

5 · Step 4 — Deploy to BTP

manifest.yaml

---
applications:
 - name: genai-node
 buildpack: nodejs_buildpack
 command: npm start
 memory: 256M
 env:
 XSUAA_SERVICE_NAME: xsuaa-blog #Name of your service
 services:
 - destination-service
 - xsuaa-blog

Push the codebase to the CloudFoundry and check if it is running

cf push
cf logs genai-node --recent

5 · Step 6—Test with Postman

After you deploy the application click on it to get the custom link to the app.

Open up Postman and write your request with your endpoint

Go to the Authorization tab → Select OAuth 2.0

Enter credentials

Scroll down to the “Get New Access Token” and then “Use Token”.

Now you are good to send the request and get a result

{
 "answer": "Hello! How can I assist you today?"
}

7 · Useful Links

https://www.sap.com/events/teched/virtual/flow/sap/te24/catalog/page/catalog/session/1722557682293001fTqe

https://github.com/SAP-samples/teched2024-AI180

https://sap.github.io/ai-sdk/docs/js/connecting-to-ai-core

https://sap.github.io/cloud-sdk/docs/js/tutorials/getting-started/introduction

How to use Cloud SDK for AI in an existing CAP NodeJS Project in CommonJS

2025-08-01T10:03:01.242000+02:00

I have an existing SAP Cloud Application Program Project in CommonJs. I want to add custom AI function in it . So need to use SAP Cloud SDK for AI in my project. But SAP Cloud SDK for AI only support native ESM. Convert my existing project into ESM? I think it is too risky. I need to use the ESM module in the CommonJs project. At last, it works. Let me share the steps which maybe be helpful for you.

Steps:

1, Install esbuild in the root path of my project:

npm i esbuild

2. Create folder named esm under srv, then create a file named index.js under folder esm with the following code .

import { OrchestrationClient, buildAzureContentSafetyFilter } from '@sap-ai-sdk/orchestration';
import { AzureOpenAiEmbeddingClient } from '@sap-ai-sdk/langchain'

export { OrchestrationClient, buildAzureContentSafetyFilter, AzureOpenAiEmbeddingClient };

3. Add following script in my package.json file in project root path.

 "deps": "esbuild --platform=node srv/esm/index.js --bundle --outfile=srv/esm/bundle.js"

4. Run the following command in the project root path in terminal.

npm run deps

5. Adjust the code of importing the module of SAP Cloud SDK for AI as the following.

// const { OrchestrationClient, buildAzureContentSafetyFilter } = require('@sap-ai-sdk/orchestration');
const { OrchestrationClient, buildAzureContentSafetyFilter } = require('../esm/bundle');
// const { AzureOpenAiEmbeddingClient } = require('@sap-ai-sdk/langchain');
const { AzureOpenAiEmbeddingClient } = require('../esm/bundle');

The ends!

Thanks for your time!

Jacky Liu

Build a Code-based Agent using SAP AI Core with Next.js and the Vercel AI SDK

2025-09-29T16:43:22.762000+02:00

Build a Code-based Agent using SAP AI Core with Next.JS and the Vercel AI SDK

TL;DR

If you need to create a code-based agent and want to use Next.js with the Vercel AI SDK, you can connect to SAP AI Core through the LangChain compatibility layer.

Use Case

I was recently looking into building an application which gives users access to a highly specialized AI agent. To make this application, I chose Next.js and created a code-based agent which will be handled by the Next.js server runtime through the Vercel AI SDK. Even though this is not the traditional way to create web applications at SAP, it was a very efficient way to create this application for me.

Why Next.js?

Modern web applications have come a long way since the times of single-page apps (SPA) which brought dynamic and reactive applications to the web. React is the most popular web UI library, but "Create React App" is deprecated. Instead the React team recommends the meta-framework Next.js. Both React and Next.js dominate the popularity charts as you can see in the annual State of JS survey. While popularity is not the only consideration when picking a framework, it often suggests good documentation and widespread support.

Meta-frameworks focus on rendering and serving the application in an efficient way, using static-site generation (SSG), server-side rendering (SSR) and other techniques to improve load times and responsiveness. To fully utilize these advantages, Next.js runs its own server and introduces server routes and server components, breaking down the traditional frontend-backend split.

If you are interested in learning about Next.js, feel free to check out one of the many available tutorials:

Why a Code-based Agent?

SAP offers different options to create a custom agent based on your needs. Many cases are already covered by existing agents integrated with Joule or can be created without writing code in Joule Studio. These are the recommended ways to consume AI services in a safe and compliant way, but highly specialized agents may need additional capabilities only available through code-based agents.

Code-based agents can use SAP AI Core services to provide streamlined access to a large number of frontier models through SAP Business Technology Platform. This allows you to create a bespoke agent using popular open-source tools together with SAP integrations. But beware: Creating a code-based agent requires additional development capacity, specialized skills and significant ongoing maintenance.

Connect Vercel AI SDK with SAP Cloud SDK for AI

The best way to connect your application to SAP AI Core is the SAP Cloud SDK for AI (often called SAP AI SDK). It supports Python, Java and JavaScript. To use it with Next.js, the JavaScript version is the correct choice.

Unless you want to build your code-based agent from the ground up, you'll need to choose one of the many available frameworks. The common choices in JavaScript are LangChain, Mastra and Vercel AI SDK. I chose the Vercel AI SDK as it makes the integration with Next.js super easy. While the Vercel AI SDK supports many model providers out-of-the-box, the SAP AI Core is not included. Luckily, both the SAP AI SDK and the Vercel AI SDK have LangChain compatibility layers.

I started by generating a new Next.js application with npx create-next-app@latest and installed the required dependencies. Please excuse the image for the instructions, SAP Community makes it really hard to post this command without linking to a user when using the @ symbol.

The SAP AI SDK needs an environment variable called AICORE_SERVICE_KEY which contains the service key from your SAP AI Core instance on SAP Business Technology Platform. It should look something like this (but as a string):

{
    "clientid": "...",
    "clientsecret": "...",
    "url": "https://...sap.hana.ondemand.com",
    "identityzone": "...",
    "identityzoneid": "...",
    "appname": "...",
    "credential-type": "binding-secret",
    "serviceurls": {
        "AI_API_URL": "https://...ml.hana.ondemand.com"
    }
}

There seems to be an issue in how Next.js parses the .env file, so I recommend you load the environment variable manually before starting the Next.js server or with direnv.

Now you need to create the route which calls the model (e.g. src/app/api/chat/route.ts).

import { OrchestrationClient } from "@sap-ai-sdk/langchain";
import { toUIMessageStream } from "@ai-sdk/langchain";
import { UIMessage, createUIMessageStreamResponse } from "ai";

export async function POST(req: Request) {
  const { messages }: { messages: UIMessage[] } = await req.json();

  const model = new OrchestrationClient({
    promptTemplating: {
      model: {
        name: "gpt-4o-mini",
      },
    },
  });
  const stream = await model.stream(
    messages.map((m) => ({
      role: m.role ?? "user",
      content: m.parts.map((p) => (p.type === "text" ? p.text : "")).join(""),
    }))
  );

  return createUIMessageStreamResponse({ stream: toUIMessageStream(stream) });
}

Next, add the page which displays the chat (e.g. src/app/page.tsx).

"use client";

import { useChat } from "@ai-sdk/react";
import { useState } from "react";

export default function Chat() {
  const [input, setInput] = useState("");
  const { messages, sendMessage } = useChat();
  return (
    <div className="flex flex-col w-full max-w-md py-24 mx-auto stretch">
      {messages.map((message) => (
        <div key={message.id} className="whitespace-pre-wrap">
          {message.role === "user" ? "User: " : "AI: "}
          {message.parts.map((part, i) => {
            switch (part.type) {
              case "text":
                return <div key={`${message.id}-${i}`}>{part.text}</div>;
            }
          })}
        </div>
      ))}

      <form
        onSubmit={(e) => {
          e.preventDefault();
          sendMessage({ text: input });
          setInput("");
        }}
      >
        <input
          className="fixed dark:bg-zinc-900 bottom-0 w-full max-w-md p-2 mb-8 border border-zinc-300 dark:border-zinc-800 rounded shadow-xl"
          value={input}
          placeholder="Say something..."
          onChange={(e) => setInput(e.currentTarget.value)}
        />
      </form>
    </div>
  );
}

This creates a new SAP AI SDK OrchestrationClient using the SAP AI SDK LangChain compatibility package, creates a new stream and wraps it with the toUIMessageStream compatibility function and createUIMessageStreamResponse function. This way it can be consumed with the useChat hook from the Vercel AI SDK React package.

There is still a long way from this demo to the finished application. But I hope you can see how easy it is to connect open-source tools with your SAP AI Core instance and get started.

Consuming DPI NextGen Services using Client Certificate Authentication

2025-11-20T11:01:31.311000+01:00

This blog provides a step-by-step walk-through of using client-certificate authentication to connect to DPI Next Gen (Data Privacy Integration - NextGen) services via destination certificates. You’ll also find practical guidance for testing your setup ensuring secure communication between services via MTLS. Even if you're new to certificate authentication, or just looking for a quick reference, this guide offers an approach to getting it right.

Introduction

Client Certificate Authentication is a secure method to verify the identity of an application making a request to a service. Instead of relying on passwords or OAuth2 tokens, the calling client presents a certificate during the TLS handshake. The service then validates this certificate against trusted authorities before allowing access.

In the SAP BTP landscape, this authentication mechanism is used when applications communicate with either a platform service (such as Destination Service), or custom apps deployed on Cloud Foundry. By configuring a certificate as a service key, SAP BTP ensures that only verified clients can call endpoints.

This method offers stronger security for communication because certificates are harder to compromise, can be automatically rotated, and can be scoped strictly to the required service.

Accessing Data Privacy Integration (DPI Next Gen) Service

DPI Services provides unified data privacy capabilities for applications on SAP BTP. You can explore more about it in the help guide. It also provide API endpoints that you need to implement in your application.

To consume the services, create a service instance of data-privacy-integration-service with the data-privacy-internal plan. Depending on the use-case (for example, archiving, retention, etc.) a set of configurations parameters are expected during service instance creation, which are documented here.

Generating Client Certificates

The Destination Certificates UI on the BTP Cockpit provides a way to create and maintain X.509 Certificates, either self-signed or generated via external services.

Create a new certificate. Make sure to choose the file-extension as P12 extension, which allows retrieve both the certificate and the corresponding private key. Choose the validity based on your requirement. Password can be left empty.
(Note: whatever you input in the "name" field will end up being the Common Name in the certificate, once generated.)Certificate Creation on BTP
Once submitted, the UI shows the certificate subject and the issuer details. They are needed during the creation of a service-key.

Destination Certificate Details

Creating a Service Key for DPI NextGen Service

Creating a service key without additional parameters typically indicates that the service uses the Client-Credentials flow, where authentication is handled through the client ID and client secret.

To consume the DPI NextGen service via client-certificates, we'll need to specify our intent via a few parameters when creating a service-key:

{
  "credentials": {
    "certSubject": ".....",
    "certIssuer": "....."
  }
}

The values for certSubject and certIssuer fields are strings, and can be obtained from the certificate details page as shown previously. For example:

Service Key Configuration Parameters

Click on Create to start the service-key creation. Once the service key is successfully created, you can fetch the callback URL. We will create a destination by providing this URL.

Creating a Destination to access DPI NextGen Services

Now, we create a destination to the DPI NextGen service.

Create a new destination via the BTP Cockpit. For authentication, choose the option ClientCertificateAuthentication from the drop-down. In the Key Store Location select the certificate that you created in the previous step. The URL can be obtained from the service-key itself.

Creation of a new Destination
Click on Save to create the destination. Verify the authentication parameters and the URL.

Destination Details

Once this is done, the connectivity setup is complete for any application to consume the DPI NextGen services. In the next few sections, we'll show how to test the connectivity via a REST Client, and also via a deployed application.

Getting Client Certificate and Key via Destination Service API

To test connectivity via a REST client, we'll need access to both the certificate and the private key. Currently, the "Export" button on the Destination Certificates UI provides only the public certificate. Private keys are only accessible via the Destination Service API.

All destination certificates and private keys can be obtained by sending a GET request to the following endpoint:

https://<domain>/destination-configuration/v1/subaccountCertificates

The response body will have the following format:

{
    "Name": "trial.p12",
    "Type": "CERTIFICATE",
    "Content": "<base64-encoded content>"
}

The certificate and private-key are packed together into a binary, and then encoded via base64, which is what the API response carries. In the next set of steps, we'll be decoding this base64-encoded content and extract the certificate and private-key as two separate files.

Copy the value for the "Content" attribute and save it in a file, for example Trial.txt. Since the content is base64-encoded, use the following command to decode it and save it in a proper format:

cat Trial.txt | base64 -d > Trial.p12

For the subsequent operations, the openssl binary is needed. For macOS, you can install it via homebrew.

Next, we'll use this command to display the certificate chain and the private key. This is to verify if the response was properly decoded or not.

openssl pkcs12 -in Trial.p12 -nodes

There will be prompt to enter a password. It would be the same as the one chosen while creating the certificate. In case you didn't enter a password, just press the enter key to continue.

Next, we need to save certificate and key into two separate files.

To save the certificate to a file TrialCert.crt:

openssl pkcs12 -in Trial.p12 -nodes -out TrialCert.crt -nokeys

To save the private key as TrialKey.key

openssl pkcs12 -in Trial.p12 -nodes -out TrialKey.key -nocerts

There may be some sections with “Bag Attributes”. We can manually correct both the certificate and key files by removing these sections.

Example: Use DRM Service via REST Client

In this section, we'll test by sending calls to the Data Retention Manager (DRM) API which is a part of the DPI NextGen service, by using client-certificate we obtained in the previous step. Any REST client can be used, Bruno is used in these examples.

In Bruno, create a new collection. On the collection settings page, choose the certificate and key that was created, For domain, specify the root URL for the DPI service.Add Certificate in Bruno
Now, within the collection, any request that is created to an endpoint which matches the domain selected above, Bruno will perform authentication via the chosen client-certificate:

Send Request to DRM Endpoint

Example: Use DRM Service via SAP Cloud SDK

For a backend application to consume any external service, SAP recommends using the SAP Cloud SDK for both Java and JavaScript applications. This blog post assumes you're using a CAP application. Follow these steps here to setup Cloud SDK integration: https://cap.cloud.sap/docs/java/cqn-services/remote-services#cloud-sdk-integration

Also, this blog post uses code-snippets written in Java, but Cloud SDK for JavaScript has equivalent methods and interfaces for everything used here.

Setup a Destination Instance

SAP Cloud SDK provides the DestinationService and DestinationOptions interfaces. This is an example to connect to a destination via name:

var service = new DestinationService();
DestinationOptions options;
Try<Destination> destination = service.tryGetDestination("destination-name", options);

By default, in case of a multi-tenant setup, the Cloud SDK will look-up the destination in a consumer subaccount first. Since, the “TRIAL_AUTH” destination is maintained in the provider subaccount, the destination lookup (a.k.a "retrieval") strategy needs to be changed.

Here, we explicitly specify the retrieval strategy ALWAYS_PROVIDER to make sure the destination is fetched directly from the provider subaccount:

DestinationService service = new DestinationService();

DestinationOptions options = DestinationOptions.builder()
      .augmentBuilder(DestinationServiceOptionsAugmenter
      .augmenter()     
      .retrievalStrategy(DestinationServiceRetrievalStrategy.ALWAYS_PROVIDER))
      .build();

Try<Destination> destinationTry = service.tryGetDestination(“TRIAL_AUTH”, options);
Destination destination = destinationTry.get();

Setup an HTTP Client using the resolved Destination

Once the destination has been resolved, the next step is to create an instance of HTTPClient. This instance already has the authentication credentials, headers, etc. defined as set in the destination, which it will be apply for every request:

// Convert the destination to an HTTP destination
 HttpDestination httpDestination = destination.asHttp();
 
 // Obtain an HTTP client instance
 HttpClient client = HttpClientAccessor.getHttpClient(destination);
 
 // Create a generic HTTP request (e.g., HttpPut / HttpPost / HttpGet / tec)
 HttpRequestBase request = new HttpPut(httpDestination.getUri().toString());
 // Example: Replace with new HttpPost(...) or new HttpGet(...)or others as needed
 
 // --- Set headers (example) ---
 request.setHeader("Content-Type", "application/json");
 request.setHeader("Accept", "application/json");
 // Add any additional headers here...
 
 // --- Set payload (only applies to entity-enclosing requests like PUT/POST/others) ---
 StringEntity requestBody = new StringEntity(payload, "UTF-8");
 if (request instanceof HttpEntityEnclosingRequestBase) {
     ((HttpEntityEnclosingRequestBase) request).setEntity(requestBody);
 }
 
 // Execute the HTTP request
 HttpResponse response = client.execute(request);

To verify this, we setup a dummy backend application with this code, along with an endpoint to trigger it. Again, we setup Bruno to send a request to this custom endpoint and validate the destination-based connectivity. This time, the client-certificates need not be added, since the destination service will provide those:

Send Request to DRM via Bruno

Conclusion

This post walked through configuring client-certificate (mTLS) authentication for DPI Next Gen: from creating destination certificates and service keys to wiring a destination for testing both using a REST client and the SAP Cloud SDK. The following is the summary of what we've covered:

Generate a P12 certificate in the Destination Certificates UI.
Create the DPI-NextGen service-instance and configure a service-key for client-certificate authentication.
Create a destination using ClientCertificateAuthentication.
Retrieve and decode the certificate-key pair via the Destination Service API endpoint.
Test with a REST client to call DRM/DPI endpoints.
Integrate and test from an application using the SAP Cloud SDK.

SAP Community - SAP Cloud SDK

Configuration as code (CaC) with destinations.

Configuration as code (CaC) with destinations.

Configuration as code with SAP BTP destination service

Open Sourcing the SAP Cloud SDK for Java: Part 1 - Preparations

🤔Why Open Source?

🔎 Finding a Starting Point

🤺 Taking the First Steps

🧹 Code Cleanup

🏗Setting up an Open Source Repository

😴 What we didn't have to do

📖Conclusion

Open Sourcing the SAP Cloud SDK for Java: Part 2 - Moving Code

📈 The Overall Strategy

🚚 How We Moved the Code Base

🧪 Creating a Representative Sample

🔀 Creating a Branch for V5

↗️Moving to the Open Source Repository

📖 Summing Up

Open Sourcing the SAP Cloud SDK for Java: Part 3 - Re-Building the CI/CD Automations

☝️Requirements for our CI/CD Automation

🔖Architecture of our GitHub Workflows

✅ The CI Workflow

📸 The Main Branch Workflow

📦 The Release Workflow

🔎 The Details of GitHub Actions and our Maven Project

📂 Keeping Track of Build Artifacts

🔁 Dealing with the Maven Build Lifecycle

📌 Keeping Track of which Artifacts to Release

💡Challenges and Learnings

📖 Conclusion

Custom Spring Boot application in SAP BTP CF integrates with BTP Document Management Service(DMS

SAP Cloud Integration API - Collection of OData Clients using JS/TS and SAP Cloud SDK

TL;DR

Features

Install

Dependencies

Usage

Show your support

Build a Java Spring boot middleware application to consume SAP OData service with SAP Cloud SDK

Integrating with SAP Datasphere API through BTP Destination Using OAuth SAML Bearer Assertion

Introducing the SAP Cloud SDK for AI (JavaScript/TypeScript) 🎉

AI Orchestration with @​​​​​sap-ai-sdk/orchestration

AI Management with @​​​​​​​​sap-ai-sdk/ai-api

LangChain Integration with @​​​​sap-ai-sdk/langchai

Generative AI with @​​​​​​​​​​​​sap-ai-sdk/foundation-models

Getting Started

Support and Feedback

Latest News

Introducing the SAP Cloud SDK for AI (Java) 🎉

AI Core - Setup and Usage

AI Core - Orchestration

AI Core - Foundation Models

Getting Started

Support and Feedback

Latest News

Sending Custom Emails in Digital Manufacturing Using SAP Cloud SDK

Introduction

Sending Mails with Create Alert Service

Usage of the Mail Service as a Third Party in DM Processes

Future Directions & Possibilities

Reference Documents

SAP Developer News, January 23rd, 2025

DESCRIPTION

CHAPTER TITLES

Transcription

SAP BTP Accessing Feature Flag using ClientCredentials Destination. Part - 1

SAP BTP Accessing Feature Flag using ClientCredentials Destination. Part - 2

Conclusion:

SAP BTP: Cloud Application Programming Model

Autoloading Data in SAP Fiori Apps Using SAP CAPM Backend

❌ When Not to Use initialLoad: true?

Using the SAP Cloud Javascript SDK for AI

Using the SAP Cloud Javascript SDK for AI

Introduction

Table of Contents

1 · Prerequisites

2 · Step 1 — Create Destination Service

Important!

3 · Step 2 — Create XSUAA Service and Service Key

AI Orchestration with @sap-ai-sdk/orchestration

AI Management with @sap-ai-sdk/ai-api

LangChain Integration with @sap-ai-sdk/langchai

Generative AI with @sap-ai-sdk/foundation-models