SAP Community - SAP Continuous Integration and Delivery

Video Learning Map - SAP Cloud ALM for Implementation

2023-03-15T14:20:19+01:00

As you begin your journey in SAP Cloud ALM, yes you can read Expert Portal and loads of Blog Posts but if you are short of time why not just finish a video series.

If you want to quickly understand the End to End Story then just watch this video.

If you want to go deep and use SAP Cloud ALM productivity then follow this sequence

Setup a Project

Setup a Release and Deployment Plan

Deep Dive Project Management

Deep Dive Task Management

Deep Dive Requirement Management

Deep Dive Features

Hope you find this useful.

Next Steps

Bookmark Expert Portal and YouTube Playlist

We Made Our CI/CD Pipelines More Flexible

2023-03-21T21:47:21+01:00

With SAP Continuous Integration and Delivery, we strive for simplicity: Our service on SAP BTP offers ready-made pipelines for various SAP-specific development scenarios. With them, we want to help you implement CI/CD quickly and without having to care about the underlying infrastructure. Simplicity, however, shouldn’t mean inflexibility. That’s why we’ve added additional configuration options to our pipelines to make sure they work for your purposes.

In different stages of your CI/CD pipelines, you can now add additional credentials and variables. This lets you, for example, access a private repository when building your application or set a DEBUG flag when running your tests.

Have a look at the following example to see how our new feature works:

Use Private npm Packages in Your CI/CD Job

Add an access token to the Build stage of your SAP Continuous Integration and Delivery job to access private npm packages during its execution.

Procedure

In your source code repository, create a custom .npmrc file with the following content:
```
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
```
Note:
You specify a literal value of ${NPM_TOKEN}. The npm CLI will replace this value with the contents of the NPM_TOKEN environment variable. Do not put a token in this file.

Check in your .npmrc file.

In SAP Continuous Integration and Delivery, create a new or edit an existing SAP Cloud Application Programming Model job.

In the Build stage, choose + (Add credentials variable) next to Additional Credentials.
As a result, the Add Credentials Variable pop-up window opens.

For Name, enter NPM_TOKEN.

Open the Credentials Name drop-down list and choose Create Credentials.
As a result, the Create Credentials pop-up window opens.

For Credentials Name, enter mynpmtoken.

From the Type drop-down list, choose Secret Text.

In the Secret text field, enter your token.

Choose Create.
As a result, your newly created credential is used for Credentials Name.

Choose OK.

Create and run your job.

Result

You can now use private npm packages with your SAP Continuous Integration and Delivery job.

That’s cool, isn’t it? Have a look at our documentation and try it out yourself: Adding Environment Variables to Stages | SAP Help Portal

We’re also working on adding even more flexibility to our pipelines. Stay tuned!

Upcoming webcast series “The Open Space of Application Operations within SAP BTP”

2023-04-11T17:16:40+02:00

I am sure we do all agree that application operations is a crucial part to provision and run any app on SAP BTP – only when we make sure that we can provide our apps with the right performance and availability, they will bring the expected value to our end users and our business.

To reflect this, we decided to complement the currently running The Universe of SAP BTP in a Nutshell webcast series with an accompanying one, about The Open Space of Application Operations within SAP BTP.

The Open Space of App Operations webcast series

Starting in April, you can expect to get additional information and insights on different aspects around operating your apps on SAP BTP – after an overview session, we plan to focus on a lot of examples and demos that shall allow you to make the next steps:

On April 20^th, we start with an overview session about DevOps with SAP BTP – as more and more development teams strive for a more agile development approach, it is crucial to understand how your ops teams can cope with this demand, by offering a very low entry barrier without ignoring the more strict boundary conditions you normally face in SAP enterprise environments.
If you want to get an overview and latest news + a demo of our Pipeline-as-a-Service offering, this is the right session for you: DevOps with SAP BTP – how you can use SAP BTP to lower the entry barrier for your dev teams to benefit from agile approaches in SAP enterprise environments, while being able to stick to existing operations processes

One week later, on April 27^th, we will continue with details on how you can integrate SAP Cloud Transport Management service into Application Lifecycle Management – so, if you plan to orchestrate your cloud changes from SAP Solution Manager or SAP Cloud ALM or just want to get a detailed demo on what to expect, join this session here: Integration of SAP Cloud Transport Management into Application Lifecycle Management solutions

On May 11^th, get insights on how to implement a more reactive way of working by setting up automated alerts with SAP Alert Notification service of SAP BTP and SAP Automation Pilot service - on the example of a cloud app (developed via SAP Build Apps) using SAP HANA Cloud: Using alerting and technical ops automation for synthetic monitoring

If you use SAP Event Mesh, mark May 25^th in your calendar for this session about how to use SAP Alert Notification service and SAP Automation Pilot for monitoring, alerting and automated remediation: Monitoring, alerting and remediations on failed events in SAP Event Mesh

And if you want to learn how you can reduce your efforts around operating SAP HANA Cloud, join us on June 1^st: SAP HANA Cloud: recurrent monitoring and an automated status report generation

I hope to welcome many of you in our sessions! Register here free-of-charge: The Open Space of Application Operations within SAP BTP.

If you should be unsure which session to join, we will offer a quick teaser of the complete webcast series on April 18^th here: The Universe of SAP Business Technology Platform in a Nutshell series – Application Operations Overview

And if you should have ideas for other operations topics around SAP BTP, please leave a comment!

Extensible Pipelines for SAP Continuous Integration and Delivery

2023-05-30T09:16:38+02:00

The SAP Continuous Integration and Delivery service just reached a new stage of its evolution: Up until now, the available pipelines were made of a fixed set of building blocks, such as: build, test, scan your code and deploy. You could choose which of those blocks you wanted for your pipeline, but you couldn't create your own.

That's about to change. Pipelines now have extension points that allow you to implement your own logic in the form of scripts.

In the next paragraph, I'll give some background on the why and the how. If you're only interested in how to use the new feature, feel free to skip it.

A Bit of History

When we productized the SAP Continuous Integration and Delivery service around 2020, the main quality we aimed for was simplicity, which has two main aspects for the service:

enabling you to implement CI/CD (continuous integration and delivery) without owning any infrastructure, for example, build servers

focusing on SAP development scenarios (for example, CAP, Fiori) to provide ready-made pipelines that you can use without any additional scripting

That made sense, because our target audience were customers at the beginning of their CI/CD journey. On the other end of spectrum were customers who had already invested in CI/CD. They were not our main target because we knew that CI/CD requirements are highly specific within each organization, and our service wouldn't have the flexibility to accommodate that.

Fast forward to the present. The service is well received by its target audience: Customers who only had manual processes before now use automated pipelines.

But we also received feedback that surprised us:

We like the Continuous Integration and Delivery service a lot, so we're going to migrate our complete development landscape (hundreds of projects) to the service. But could you please implement support for our Radar Scans?

As far as this story goes, Radar Scans are clearly a fictional example. However the point stands: for static code checking, we only support Sonar Scans. It's not likely that we'll support other code scanning tools in the near future, because to keep our configuration UIs simple, we decided to support only one mainstream tool for each area of functionality.

Now you can see the dilemma we are facing: How can we meet diverse customer requirements and keep the service simple at the same time?

Making Pipelines Extensible

The only scalable solution is to enable you to help yourself. To do so, we added extension points to the pipelines that allow you to run arbitrary commands and scripts. So it's scripts after all, you say? Yes, true. But the important thing is that you can get started without scripting and continue so as long as you stick to the mainstream stuff we support. Later, when you need that extra bit of functionality, scripts are the way to go.

Freestyle Configuration and Freestyle Steps

Now let's have a look at those extension points. Before adding freestyle steps, we introduced freestyle configuration. With this feature you can add arbitrary environment variables to all processes executed within a stage, and even inject secrets.

You can use freestyle configuration when configuring those stages which are scriptable by nature. The build stage is a typical example, because no matter which build tool you use (be it maven or npm), it's easy to integrate custom scripts into the build process. Freestyle configuration now unlocks lots of options. For an example on how powerful it is, see the blog post Accessing Private Registries.

But what about those stages that are not scriptable by nature? Recall the question: How can I do Radar if the service only provides Sonar?

To cover this, we added two extension points per stage, called runFirst and runLast.

The semantics are as expected:

the runFirst command is executed before everything else in that stage

the runLast command is executed after everything else in that stage

If you decide to enable the preconfigured steps in the stage (for example, Sonar scan), the runFirst and runLast commands can be used for preparation and post-processing.

If you decide to do something else instead, use one of the extension points to execute it.

Sure, a single command is often not enough, but you can just add a more complex script to your source repository and use the command to start it.

If this makes you curious, check out the official documentation.

Container Images

Being able to execute a script sounds great, but you might want to know in which environment it runs and which tools you can use. Like everything else in the Continuous Integration and Delivery service, custom commands are executed in a Linux container.

As the base image for that container, we decided for an image containing the standard Linux shell tooling plus a recent node runtime and npm.

Because JavaScript is the most popular implementation language on SAP Business Technology Platform, we decided to go for node as a scripting language. Using npm, you can easily bootstrap additional dependencies.

Chances are you're not happy with the choice we've made. Because, obviously, lua is the only acceptable scripting language. But don't despair. Just get in contact with us and tell us about your requirements, because the plan is to make the container image configurable. At first, it might be a fixed list of images maintained by us. But eventually, we want to enable you to "bring-your-own-image", despite some challenging compliance aspects that it might bring along.

Conclusion

Now you know how we make pipelines in SAP Continuous Integration and Delivery more flexible and our motivation behind it. If you have remarks or suggestions, please comment or contact me directly.

Next Level of Flexibility: Additional Commands in CI/CD Pipelines

2023-06-22T15:12:15+02:00

With SAP Continuous Integration and Delivery, we like to keep things simple and easy to use. That’s why we’ve created preconfigured CI/CD pipelines for SAP-specific development scenarios. These pipelines consist of several building blocks, so-called stages. Each stage describes a task such as build this app, run these tests, and deploy this to pre-production. When running a pipeline job, each stage performs various smaller tasks - that is, steps - one after the other to meet its purpose.

Our goal was to cover standard scenarios to onboard you as quickly as possible. But sometimes, standard scenarios aren't sufficient. We’ve therefore already implemented the option to add additional credentials and variables to most stages within our CI/CD pipelines (see We Made Our CI/CD Pipelines More Flexible). As a second step in our journey to more flexibility, we’ve now added extension points that let you add your own commands before or after any other step within a stage.

You can extend our pipelines with any kind of additional JavaScript tasks, which will then be executed within a Node.js Docker image. Of course, you also can combine additional commands with additional credentials and variables.

For more information on why and how we want to make our CI/CD pipelines more flexible, see Extensible Pipelines for SAP Continuous Integration and Delivery.

When does it make sense to enhance our standard pipeline functionality? Let’s have a look at an example:

Creating a GitHub Release with an Additional Build Artifact

Add a command for a GitHub release with an attached .mtar file to the Release stage of your job.

Context

In this example, you will add a GitHub release as last step to the Release stage of your SAP Continuous Integration and Delivery job. This GitHub release contains the .mtar file that results from the Build stage. To reuse files in later stages of a job, they must be placed into the so-called cloudcitransfer folder in your project sources. This folder is created automatically at the start of a pipeline run.

Procedure

In your project in your source code repository, create a file called create-release/create-release.js and paste the following content into it:

const { Octokit } = require("@octokit/core");

const fs = require("fs");

const dateFormat = require('date-and-time')



//

// 1.) Retrieve all parameters from the environment.

// The corresponding environment variables are defined

// in the job.



// If the GITHUB_TOKEN is a basic auth credential, the

// user and password are exposed with a trailing

// '_user' and '_password'.

var githubToken = process.env.GITHUB_TOKEN

var releaseNamePrefix = process.env.RELEASE_NAME_PREFIX;

var releaseTagPrefix = process.env.RELEASE_TAG_PREFIX;

var additionalAssetLabel = process.env.ADDITIONAL_ASSET_LABEL



// CLOUDCI_GIT_COMMIT is not defined as additional environment variable

// for the stage. CLOUDCI_GIT_COMMIT is always injected into the environment

// for run-first and run-last commands.

var targetCommitish = process.env.CLOUDCI_GIT_COMMIT;



// We expect the additional asset in the transfer folder one folder level above,

// since the script is launched from a subfolder.

var additionalAssetName = `../${process.env.ADDITIONAL_ASSET_PATH}`;



//

// 2.) Use a suitable stategy for release suffixes

// to ensure that the same release does not already exist. A simple and

// straight-forward approach is to use a time stamp.

var releaseSuffix = dateFormat.format(new Date(), 'YYYY-MM-DD-HH-mm-ss')



// 1: protocol

// 2: host

// 3: owner

// 4: repo

var gitRepoUrlParts = process.env.GIT_URL.match(/(.*):\/\/(.*)\/(.*)\/(.*).git/)



var githubApiUrl=`${gitRepoUrlParts[1]}://${gitRepoUrlParts[2]}/api/v3/`

var owner=gitRepoUrlParts[3]

var repo=gitRepoUrlParts[4]



//

// 3.) Define the client for communicating with the GitHub-API.

const octokit = new Octokit({

  auth: githubToken,

  baseUrl: githubApiUrl,

});





//

// 4.) Create the GitHub release.

octokit

  .request("POST repos/{owner}/{repo}/releases", {

    owner: owner,

    repo: repo,

    target_commitish: targetCommitish,

    tag_name: `${releaseTagPrefix}-${releaseSuffix}`,

    name: `${releaseNamePrefix}-${releaseSuffix}`,

    draft: false,

    prerelease: false,

    generate_release_notes: false,

  })

  .then((res) => {

    // response status code check not required. In case of an issue octokit throws an error

    console.log(`Release created: status: '${res.status}', url: '${res.data.html_url}'`)



    //

    // 5.) ... and we attach the additional asset

    octokit.request(`POST ${res.data.upload_url}`, {

      name: additionalAssetName,

      label: additionalAssetLabel,

      data: fs.readFileSync(additionalAssetName),

    });



    console.log(`additional asset "${additionalAssetName}" uploaded`)

  })

Create another file called create-release/package.json with the following content:
```
{

  "dependencies": {

    "@octokit/core": "^4.2.0",

    "date-and-time": "^3.0.0",

    "fs": "^0.0.1-security"

  }

}
```
As a result, a GitHub release with an additional asset, namely an .mtar file that results from the build, is created.

In SAP Continuous Integration and Delivery, create a new or edit an existing SAP Cloud Application Programming Model job.

In the Build stage, choose + (Add command step) next to Additional Commands and then Run Last in Stage.

As Command, enter: cp <PATH_TO_MTAR_FILE> cloudcitransfer

In the Release stage, choose + (Add command step) next to Additional Commands and then Run Last in Stage.

As Command, enter: cd create-release && npm install && node create-release.js

Choose + (Add credentials variable) next to Additional Credentials.

Enter a name for your credentials variable.

From the Credentials Name drop-down list, choose Create Credentials.

Enter the necessary information for your GitHub token and choose Create.

Choose OK.

Choose + (Add variable) next to Additional Variables.

Add the following variables:

Name	Value
RELEASE_NAME_PREFIX	A prefix for the name of the release. A timestamp will be appended.
RELEASE_TAG_PREFIX	A prefix for the tag used for the release. A timestamp will be appended.
ADDITIONAL_ASSET_LABEL	The label for the additional asset
ADDITIONAL_ASSET_PATH	The path to the file, in which the additional asset is located. Provide the file which was copied into the cloudcitransfer folder in run-last of the build stage.

Create and run your job.

Configuration as Code

The configuration for this example looks as follows:

---

general:

  buildTool: "mta"

service:

  buildToolVersion: "MBTJ11N16"

  stages:

    Build:

      runLast:

        command: "cp BAS_Sample_App.mtar cloudcitransfer"

    Release:

      credentialVariables:

      - name: "GITHUB_TOKEN"

        credentialId: "<YOUR_GITHUB_TOKEN>"

      stringVariables:

      - name: "RELEASE_NAME_PREFIX"

        value: "experimental"

      - name: "RELEASE_TAG_PREFIX"

        value: "v0.0.1"

      - name: "ADDITIONAL_ASSET_PATH"

        value: "cloudcitransfer/BAS_Sample_App.mtar"

      - name: "ADDITIONAL_ASSET_LABEL"

        value: "BAS_Sample_App.mtar"

      runLast:

        command: "cd create-release && npm install && node create-release.js"

stages:

  Build:

    npmExecuteLint: false

  Additional Unit Tests:

    npmExecuteScripts: false

  Malware Scan:

    malwareExecuteScan: true

  Acceptance:

    cloudFoundryDeploy: false

    npmExecuteEndToEndTests: fals

  Compliance:

    sonarExecuteScan: false

  Release:

    cloudFoundryDeploy: true

    cfApiEndpoint: "<YOUR_CF_ENDPOINT>"

    cfOrg: "<YOUR_CF_ORG>"

    cfSpace: "<YOUR_CF_SPACE>"

    cfCredentialsId: "<YOUR_CF_CREDENTIAL_ID>"

    deployType: "standard"

    tmsUpload: false

steps:

  artifactPrepareVersion:

    versioningType: "cloud_noTag"

  cloudFoundryDeploy:

    mtaDeployParameters: "-f --version-rule ALL"

Result

You have now extended our preconfigured pipeline for SAP Cloud Application Programming Model projects by a GitHub release with an additional asset.

How do you extend your SAP Continuous Integration and Delivery jobs? Try it out and let us know!

SAP BTP Innobytes – July 2023

2023-07-27T08:09:28+02:00

SAP Business Technology Platform brings together application development, automation, data and analytics, integration, and AI capabilities into one unified environment optimized for SAP applications. Learn more: sap.com/btp

It’s hard to believe that we are more than half-way through the year. Seasons change, temperatures rise (or decline, depending on where you are located), plans change, vacations end; but something you can always count on, is the SAP BTP Innobytes monthly video! 😊 This month, we are diving into the world of flexibility, automation, and data semantics. Our experts, share the recent innovations for the SAP Continuous Integration and Delivery service, the new Graph capability in SAP Integration Suite and how you can automate the setup of your SAP BTP account. Curious? Check out the video to learn more!

Application Development Innovations on SAP BTP

SAP Continuous Integration and Delivery – Pipeline Flexibility

The SAP Continuous Integration and Delivery service on SAP Business Technology platform was already easy to use, but in some cases, customers mentioned it was not a perfect fit for their use case. And, to be fairly honest, we can’t match 100% of all use cases for all our customers. That’s just not realistic. But what’s even better than trying to provide standard solutions to fit every and any situation? You guessed it… FLEXIBILITY!

We've integrated even more flexibility to our pipelines especially for you. It's now possible to add your own commands and scripts to the pre-defined pipelines. We don’t want you to miss out on SAP's CI/CD tool because it's missing one of your business requirements.

With this new feature you could have the release stage create a git release for you, use a different tool to check code quality, or even print your name as ascii art to the build log, like Linda did 😉. No judgement here!

What are you waiting for? It's available on SAP BTP and you can try it out today. Check out the links below to learn more:

Related Documentation: Additional Commands

Related Blog Post: Extensible Pipelines for SAP Continuous Integration and Delivery

SAP Help Portal

SAP Discovery Center

Terraform Provider for SAP BTP

If you’ve used SAP Business Technology Platform, or any platform to be honest, you know that before you can even start developing, you need to have the right setup in place. This means the right project structure (subaccount and spaces, for example), the needed service entitlements, your runtime, etc. All these steps, when done manually, can be time-consuming. And I know, we’d all love to be doing something more productive with our time.

Based on Terraform, the de-facto industry standard for infrastructure-as-code, we’ve released the Terraform provider for SAP BTP for non-productive. It’s available in the central Terraform registry and we will be delivering new releases every month!

To learn more, check out this blog post and the sample code provided on GitHub so you can get started today!

And as Rui said in the video: happy Terraforming on SAP Business Technology Platform!

Integration Innovations on SAP BTP

Graph in SAP Integration Suite

Building applications that extend SAP business systems requires developers to know many complex details about the underlying system landscape. The new Graph capability in SAP Integration Suite, part of SAP Business Technology Platform, addresses this complexity.

How? Graph extends traditional API Management by providing the ability to create a business data graph of semantically connected business data across multiple systems, accessible by one single unified API.

Integration experts decide which data they want to expose developers when they create the business data graph. Out-of-the-box, the data graph automatically contains:

all the data objects (or entities) in the underlying business systems.

unified entities – which are simplified and abstracted entities connecting similar data across multiple systems.

You can also create custom entities. Custom entities include attributes from multiple source entities and can hide the complexity of those source entities from developers.

Once the business data graph has been created, developers can explore it using the Graph Navigator tool in SAP API Business Hub Enterprise. They can see which entities are included in the business data graph, how those entities are connected, which CRUD operations are available for each entity, and they can also try out OData v4 queries or GraphQL queries using a GraphQL client.

Want to learn more? Check out these links:

SAP Community topic page

Graph New in SAP Integration Suite - Blog Post

SAP Help Portal

SAP Discovery Center

Share your thoughts

These videos are for YOU. We would love to hear your impressions. How do you like the video? How can we improve the upcoming videos? Please share your feedback by liking this post or leaving a comment below.

Thank you for your support and happy viewing, sharing, and enjoying!

New free DevOps with SAP BTP Learning Journey

2023-08-04T15:53:18+02:00

DevOps enables your development teams to achieve high-level agility and quality - also for SAP cloud projects. Here, SAP does provide a recommended approach that makes it easy for you to apply it efficiently for your development projects on SAP BTP.

Learn all about this topic for free with our new learning journey Discovering DevOps with SAP BTP and optionally earn your record of achievement.

With this offering from SAP Learning, you first get everyone on the same page and make your teams understand basic principles of DevOps and of Continuous Integration and Continuous Delivery (CI/CD).

Then, get an introduction to the basic approach of DevOps especially with SAP BTP, as recommended by SAP - explaining key differentiators of the SAP-specific procedure, as being provided by the portfolio of DevOps cloud services from SAP BTP.

As baseline for applying this SAP-specific approach for own development projects, learn about required activities to set up a corresponding DevOps toolchain (such as your CI/CD pipeline) with a very low entry barrier – and with the right integration into existing operation processes, if required.

In addition, get insights on how to then use this setup for your agile development processes and for running your developed applications on SAP BTP reliably and in an agile way.

Fill the gap through upskilling and enjoy SAP’s learning offerings on the SAP Learning site. This article is created and brought to you by SAP Product Learning CoE experts!

CICD for SAP On-Premise and UI5 applications

2023-09-07T22:41:23+02:00

Introduction

As a Fiori developer, I have encountered the following issue on several occasions: "Where is the source code of the application located?" Previously, when using SAP WebIDE, it was possible to retrieve the complete code of an application already deployed in SAP Gateway. However, with the latest innovations in Fiori development, this technique no longer works as effectively, and the reference source code is now located in Git. SAP Fiori Tools or UI5 Tooling are NodeJS-based tools that add files to our Fiori application, and these files are not stored in the backend. On the other hand, the Git server will store all this data for us.

For developers coming from the pure SAP/ABAP world, using Git can indeed be unclear or even seem like a daunting task to grasp. I will write a blog post on how to use Git in an SAP On-Premise context.

How to secure the source code?

I've had an experience in my career where, during the development of a Fiori application, a developer would occasionally push without realizing the importance of this action. The application went into production, and a few months later, we were asked to make a modification. Following this change, a regression appeared. My colleague had relied on the incorrect code because I had forgotten to do the push!

When starting to develop Fiori applications with Git, it's common to primarily use the "master/main" branch and misuse commit and push practices. In such cases, the developer deploys the application directly from their own workstation.

Then comes the fundamental question:

How can you ensure that the Git source code matches the version deployed on the SAP system?

The answer lies in the organization of development. Whether you are a single developer or part of a team, it's essential to establish a "software factory" to secure the source code and apply the following rule:

No developer is allowed to deploy into the SAP system! Only the software factory has that privilege.

This rule emphasizes a strict separation of concerns between development and deployment, ensuring that only authorized processes or individuals (in this case, the software factory) have the authority to deploy code to the SAP system. This practice helps maintain control, security, and consistency in the deployment process.

The software factory I mentioned is what we commonly refer to as CI/CD (Continuous Integration Continuous Deployment). I won't go into the details of this tool, as there are websites that can explain it better than I can. However, please keep in mind that this tool automates deployment as soon as an action (such as a Pull Request) is performed on the main branch of the Git repository.

CI/CD is an essential part of modern development workflows, enabling automatic testing and deployment processes, ensuring code quality and consistency, and reducing the risk of deployment issues. If you'd like to discuss CI/CD in more detail or explore any specific aspects of it for your blog post, feel free to provide further information or questions, and I'll be happy to assist.

CI/CD listens to the activities on the "main" branch of the Git repository and initiates a development pipeline as soon as a Pull Request is triggered. The pipeline comprises several steps, but in our scenario, only one step is required, which is the deployment to an SAP On-Premise system.

Which tool choose?

There are indeed many tools available for CI/CD, and SAP offers its tool based on SAP BTP SAP Continuous Integration and Delivery (CI/CD).When I began my research on CI/CD, this service did not initially offer the capability to deploy to an On-Premise server. However, this has since been addressed. Nevertheless, due to the limited documentation on how to configure it, I explored other tools.

I conducted various tests with Azure DevOps, GitLab, GitHub, and CircleCI. One of the reasons I chose these platforms is that, typically, the expertise already exists within the company. Setting up these environments often requires just a single configuration file in the project, making it extremely simple!

Architecture

Once you've mastered the concept, it's essential to focus on the architecture to implement, as security is the key consideration in this type of software factory. There are two possible scenarios: either the CI/CD tool is entirely cloud-based, or it resides within the company's network.

On-Premise setup

This configuration is the simplest to implement. In the diagram below, I could have placed the Git servers On-Premise as well, but the critical point of concern is the CI/CD server, which must have visibility of the SAP DEV server. Typically, this requires firewall rules or network configuration.

Cloud setup

Configurations with cloud-based tools require particular attention to who has access to deploy on the server and thus visibility of the SAP server. While it's possible to create firewall rules to allow requests from various cloud services (e.g., CircleCI or GitHub), this introduces a security vulnerability that can be challenging to manage.

The solution to address this concern is to use a Self-Hosted runner, a server that periodically connects to the cloud CI/CD service to check if there are tasks to perform. If affirmative, it retrieves the commands to execute and the Git clone URL, and it's this server alone that initiates the deployment. As you can see, this server is located on the On-Premise network and can communicate with the SAP server.

This setup enhances security by limiting access to the deployment server and maintaining control over the deployment process.

Indeed, CI/CD providers typically offer a Docker image for the Self-Hosted runner, which simplifies the installation process.

How to deploy?

Now that we have a good understanding of the concepts and architecture, let's discuss how to deploy automatically. With UI5 Tooling, the npm run deploy command requires specific information, such as:

User and password.

Transport order.

Server URL.

Application-specific details.

All this information is typically stored in the ui5-deploy.yaml file at the root of the UI5 project. However, for CI/CD usage, we'll need to create a new file and use environment variables to replace some parameters.

The advantage of using environment variables is that CI/CD tools can configure them. As a result, the authentication part will be stored in the CI/CD configuration, while the transport order (TR) will be handled for the application in the .env file.

Here's an example of a deployment file (ui5-deploy-cicd.yaml):

# yaml-language-server: $schema=https://sap.github.io/ui5-tooling/schema/ui5.yaml.json



specVersion: "2.5"

metadata:

  name: <namespace>.<appname>

type: application

builder:

  resources:

    excludes:

      - /test/**

      - /localService/**

  customTasks:

    - name: deploy-to-abap

      afterTask: generateCachebusterInfo

      configuration:

        ignoreCertError: true

        target:

            url: https://<server_uri>:<port>;

            client: "500"

        credentials:

          username: env:DEPLOY_USER

          password: env:DEPLOY_PASSWORD

        app:

          name: <application_name>

          description: <application_description>

          package: <package>

          transport: env:TRANSPORT_NO

It's evident that we're utilizing three environment variables:

env:DEPLOY_USER	Stored into CICD server
env:DEPLOY_PASSWORD	Stored into CICD server
env:TRANSPORT_NO	Stored into .env file at the root project

Example of an environment file:

TRANSPORT_NO = DEVK######

Next, you need to add a script for CI/CD in the `package.json` file:

"scripts": {

    ...

    "deploy:cicd": "npm run build && fiori deploy -f -- -y --config ui5-deploy-cicd.yaml && rimraf archive.zip",

   ...

  },

Compared to the configuration of a standard deployment, the following parameters have been added:

-- -y: Disable user interaction

--failfast, -f: - Throw an error if something goes wrong and exit with a return code != 0.

Conclusion

Through this blog post, I wanted to share my experience in securing SAP Fiori developments. I have often witnessed code losses due to a lack of knowledge about the tools. The real-world scenario shows us that ABAP developers transitioning into web development often apply improper practices, and the software industry is not immune to these mistakes. The CI/CD software factory is the solution to this problem, marking the entrance into the era of continuous development.

I intentionally left out discussing automated testing, a topic closely related to CI/CD, as my primary focus was on promoting a good development practice.

I would be delighted to hear your feedback on your projects related to the implementation of such a system or any other options you have explored to secure your source code.

Enjoy 😉

Wishes come true - Cloud Native Buildpack Support in SAP Continuous Integration and Delivery!

2023-11-07T14:07:31+01:00

Hello, SAP community! 👋

We're always on a mission to keep our Sustainable SaaS Sample Application scenario up-to-the-minute. Therefore, we're eager to share 🎉 the latest enhancement to our sample use-case related to our exceptional Kyma Runtime (kyma-project.io) - the Kyma Runtime Pipeline (click here) in SAP Continuous Integration and Delivery (click here). Feels like early Christmas 🎄🎁

CAP + Kyma + CI/CD = 😍 🥰 ❤️

Our fantastic engineering teams (you guys rock 🎸🤘) have worked hard to provide another crucial component to improve your SAP BTP end-to-end developer experience! Check out Discovery Center (click here) to learn more about the service offering in general and the availability in your preferred SAP BTP region.

This new feature of our beloved SAP CI/CD service offering, supports SAP's recommended Cloud Native Buildpack (https://buildpacks.io/) approach to craft your Container Images when deploying CAP applications to the SAP BTP, Kyma Runtime! Pretty impressive, right? 🚀 Let's break it down from the top so you're fully up to speed with this remarkable pipeline - available for free validation using our SAP BTP, Free Tier or Trial plans!

Kyma + CAP + CI/CD

The SAP Cloud Application Programming Model (CAP) (cap.cloud.sap) sets the gold standard 🏆 for future SAP BTP developer generations, offering a clear set of recommendations, guardrails and best-practices for creating solutions on the SAP Business Technology Platform. When you're using SAP's managed Kubernetes offering Kyma, SAP's guidance includes the use of Cloud Native Buildpacks (click here) to build the necessary Container Images. Paired with paketo (paketo.io), developers can create standardized and reliable Container Images without the hassle of writing and maintaining separate Dockerfiles.

SAP's Project Piper (project-piper.io) - the advanced CI/CD stuff 😀 - has been supporting the required cnbBuild step (click here) for a while now, and the SAP Continuous Integration and Delivery Service has just launched a new pipeline 🎁, custom-made for application developers in the SAP BTP, Kyma Runtime context. This new Kyma Runtime Pipeline (click here) supports the complete process of building Container Images using Cloud Native Buildpacks, pushing them to your chosen Container Registry like DockerHub, Google Artifact Registry or even your own Container Registry, and an industry-standard Helm-based (helm.sh) deployment to your Kyma Cluster. This will greatly simplify your life as a DevOps engineer, as you can now concentrate on tackling the more intricate DevOps scenarios. 🚀 Meanwhile, SAP's managed CI/CD offering running on SAP BTP, will take care of handling the majority of your SAP BTP developments or extensions. 🎉 No more complex Jenkins setups required for each and every new development project.

From SAP Business Application Studio to GitHub to SAP CI/CD to SAP Kyma

As always, you can choose a code-based configuration (click here) of your pipeline or use the Job Editor (click here) to set up your job. You'll find a wealth of configuration options related to the Cloud Native Buildpack approach, and you can continue using the familiar stages that encompass steps like Unit Tests, Acceptance, or Compliance requirements. Be sure to explore the latest documentation 📚 (click here) to learn all about this new pipeline before giving it a go in your own SAP BTP landscape. For the Free Tier and Trial plan users amongst you - please be aware that your Jobs are deactivated after remaining unchanged for one week, but you can easily switch them on again.

For a practical example, we've included a simple end-to-end pipeline configuration (click here) in our popular Sustainable SaaS GitHub repository. As the new pipeline and its features might seem overwhelming initially, we've also prepared a step-by-step guide (click here) 🗺️ to ensure a smooth setup experience. The sample pipeline (click here) might not cover all available steps (e.g., Unit Tests or wdi5 Tests), but it's a great starting point for setting up all relevant credentials, like the kubeconfig details of a required service account (click here) or your container registry authentication (click here) details. Once you've got the sample scenario up and running, adding additional testing or deployment steps should be a breeze! 🌬️

Build Process

Build Results

Kyma Deployment

For the K8s (Kubernetes) enthusiasts in our community who've been following the recent SAP Blog Posts in the DevOps context, you've likely caught the great update on GitOps with Argo CD & Kyma (click here). Using Argo CD (argo-cd.readthedocs.io) to manage Helm installations in one or more Kyma clusters can be a game-changer. The best part? Consider combining Argo CD with the SAP Continuous Integration and Delivery Service, using the new Kyma Runtime Pipeline to build, test, and finally distribute your Container Images to your Kyma Cluster(s)!

That's all for now, folks! Please give it a try in your own landscape, and reach out for any question or in case you face any issue!

Happy DevOps deep diving! 🏊‍♂️👩‍💻👨‍💻

Martin

Don’t implement a CI/CD (Continuous Integration and Continuous Deployment) process unless you...read this

2023-12-16T22:01:24+01:00

Introduction

Implementing a CI/CD (Continuous Integration and Continuous Deployment) process for SAP developments is a significant undertaking that requires careful planning and consideration. Think how many companies using SAP you know that have successfully implemented it before your organization and try to understand why they managed to do it before you embark on the journey. Below you will find a few questions one might try to answer before saying out loud: "We’re planning to introduce an CI/CD process to our SAP developments".

"When I stop asking questions, something's wrong - Rene Marie"

What are the business goals and objectives?

Start by understanding the overarching business goals and objectives that the CI/CD process should support. What are you trying to achieve with this initiative, and how will it benefit your organization? Something that will always keep you moving forward even if you are faced with a big blocker (no understanding of some parts of your organization, lack of processes, etc.). This will also help you get executive support (more on this later).

What SAP systems and landscapes are involved?

Identify the specific SAP systems (SAP S/4HANA or maybe some parts of SAP BTP only) and landscapes (e.g., development, quality assurance, production) that will be part of the CI/CD process. Are there any third-party integrations or dependencies (if yes – openSAP).

What are the current development and deployment processes?

Validate the existing development and deployment processes for SAP. Do they exist? This will help you identify pain points and areas for improvement. What SAP development technologies and tools are in use? Will they support all CI/CD processes in all parts of SAP development or only in certain? Maybe you plan to use a general-purpose CI/CD solutions (which can work with SAP and non SAP technologies).

What is the size and skillset of your development team?

Assess the size and skillset of your development team. How much do you use Service Integrators or freelancers? Are they familiar with CI/CD practices (my best guess would be no) so they will additional training be required. How much of this training will be required?

Are there compliance and regulatory requirements?

Do you work in a regulated industry where some special practice needs to be validated (GxP for pharmaceutical industries)? Are there any other requirements that need to be considered in your CI/CD process, such as GDPR, SOX, or industry-specific standards.

What is the current testing and quality assurance process?

Here we start with a simple one: how mature are you with automated testing of your SAP developments? Are you aware that continuous deployment and continuous delivery includes continuous testing being run first on all of the parts of the process which you want to include in the CI/CD pipeline? Develop a comprehensive testing and validation plan to ensure that changes introduced through CI/CD do not negatively impact SAP functionality and data integrity.

What are the risks and challenges associated with a CI/CD process for SAP?

Identify potential risks and challenges that may arise during the implementation of CI/CD for SAP developments. This could include system refreshes, system downtime, or data migration issues.

What CI/CD tools and technologies will you use?

Select the CI/CD tools and technologies that are best suited for SAP development. Consider tools for version control, automated testing (like Int4 Suite for SAP BTP Integration Suite), and deployment automation.

What is the deployment strategy?

Define your deployment strategy, including how and when new SAP developments will be deployed to different environments (e.g., dev, test, production).

What is the timeline and budget for implementation?

Develop a timeline and budget for implementing CI/CD for SAP developments. Consider both the initial setup costs and ongoing maintenance expenses.

What is the rollback and disaster recovery plan?

Have a plan in place for rolling back changes in case of issues and a disaster recovery plan to mitigate risks associated with CI/CD.

Do you have executive support and sponsorship?

Ensure that there is executive support and sponsorship for the CI/CD initiative, as it may require changes in processes and investments in technology and someone needs to have your back when others will ask "do we really need it, old process was working just fine".

Final thoughts

If you don’t know any SAP companies using a full blown CI/CD process don’t worry – you don’t need to change the whole world, there’s plenty you can still do:

You can find out companies who at least try – SAP User Groups, SAP Events (like SAP Teched)

You don’t need to implemented this for the whole SAP landscape at one, maybe start with something small (SAP BTP might be good frontrunner)

Don’t give up – CI/CD process is a very well-known practice outside so it’s nothing new

Good luck!

Instant alerting for failed builds on SAP Continuous Integration and Delivery via SAP Alert Notification service

2024-01-09T15:22:17+01:00

Hello SAP community! I would like to share with you insights on how easy is to configure SAP Alert Notification service on SAP BTP in a way so that you can get instant notifications for potential disruptions in your system and more specifically – failed builds on SAP Continuous Integration and Delivery.

This blog-post is also an extension to What’s going on in your CI/CD pipeline? created by christoph.szymanski so also credits to Christoph for the initial setup.

Context

To be frank, I was inspired to write also this blog-post as the integration between Alert Notification service and SAP Continuous Integration and Delivery indeed is quite intuitive. All you need to do is to create the needed credentials, enable a toggle button available in SAP Continuous Integration and D and configure the needed alerts! If you are interested to learn more about it - all details are provided underneath.

Alerting for failed builds on SAP Continuous Integration and Delivery via SAP Alert Notification service

Solution diagram

The main concept for this use case is setting up a reliable and instant alerting in SAP Business Technology Platform (SAP BTP) for sending instant notifications in case a build in SAP Continuous Integration and Delivery has been failed. To meet these expectations I have implemented SAP Alert Notification service in a way so that in case there is a failed job - an instant notification is sent out to the responsible DevOps / SRE team.

Implementation

Create a Service Key credentials in Alert Notification service

As a first step you need to authenticate your SAP Continuous Integration and Delivery pipeline to the SAP Alert Notification service. To do so, you need to create a Service Key credentials for the

Alert Notification service as shown below:

1. Go Alert Notification service instance in your SAP BTP account, navigate the to the "Service Keys" section and click on the "Create" button.

2. Specify the "Service Key Name" (free text) and click on the "Create" button.

3. You will see that the service key creation has been started.

4. Once the service key has been created, please view and copied it over as a JSON format:

Create credentials in SAP Continuous Integration and Delivery

1. Navigate to SAP Continuous Integration and Delivery and access the "Credentials" section. Once that's done, please click on the "+" button to provided the needed credentials details:

specify the name and the description (free text);

specify the credential type - pick up "Service Key" from the drop-down;

paste the JSON service key from the Alert Notification service you had already created in the previous step;

click on the "Create" button to save the credentials

Enablement of Build Notifications for SAP Continuous Integration and Delivery

Now, after you have created all the needed credentials, you need to enable the notifications so that SAP Continuous Integration and Delivery can start ingesting notifications to SAP Alert Notification service for the relevant pipeline events . To do so, please follow these steps:

1. Access to the pipeline you want to start monitoring and click on the “Edit” button.

2. Click on the Build Notifications to access the relevant section and enable the notifications for the given pipeline:

click on the toggle button to turn it into ON.

click on the "Service Key" and pick up the credentials for the Alert Notification service you already have created in the previous step:

Click on the "Save" button to save the changes made:

Your pipeline is configured to send notifications to the Alert Notification service.

Configuring the Alert Notification service

Now it is time to configure the Alert Notification service itself and see it in actions.

In order to be able filter and act on the events ingested into the Alert Notification service it is needed to create:

Conditions: needed to filter out the events which are important for you;

Actions: specify actions to be triggered by the Alert Notification service, e.g. send email, send instant notifications (via Microsoft Teams Slack, etc), trigger HTTPS webhooks, trigger automation flow, etc;

Subscription – that is the entity that binds one or more conditions to one or more actions that have been already set. Note that without an active subscription no action will be triggered by Alert Notification service.

Setting "Conditions" in Alert Notification service

The configuration of Alert Notification service in this use case is to notify our DevOps team in case of failed CID jobs. There are various of available parameters to be considered when the condition within the Alert Notification service is to be set – you can check out the available event properties here.

Nevertheless, I have decided to go with two conditions:

```
eventType = end
```

body CONTAINS Build has finished with 'FAILURE'

NOTE: Mandatory conditions are those that must always be met within the subscriptions where they are used. For the second condition I have enabled the mandatory condition so that I will receive notification only the ended builds that have been failed.

Setting "Actions" in Alert Notification service

As an action I have created two actions that will be triggered in parallel:

send an email

send an instant message over Microsoft Teams

Setting "Subscription" in Alert Notification service

Of course, as already mentioned, it is needed to setup the relevant subscription where I have picked up both conditions and both actions already configured.

End-to-end test and output

As an end result, as expected, in case my pipeline fails, I get an instant notification delivered by the Alert Notification service over email and also in the relevant Microsoft Teams channel. The details included in these notifications are ingested directly from SAP Continuous Integration and Delivery (see below).

Email received

Instant message over Microsoft Teams

Other considerations

SAP Automation Pilot

In addition the described use case (as also shown in the solution diagram) it is also possible Alert Notification service to trigger automatically a remediation action executed by SAP Automation Pilot. This is not covered in the current blog-post but in case you are interested in, please feel free to check out these resources:

[help documentation] Integrating with SAP Automation Pilot

a webinar from 05/2023: "The Open Space of Application Operations within SAP BTP - SAP Alert Notification service & SAP Automation Pilot" (see the video below)

SAP Cloud ALM for Operations

Another aspect of this use case is that the Alert Notification service can be integrated further into the SAP Cloud ALM for Operations that provides a central entry point to operate your complete SAP landscape running on different technologies (including SAP BTP).

Feedback / Questions

I hope this blog-post is useful and in case of any questions / comments, please do not hesitate add a comment and / or reach out to me.

SAP Kyma deployments easy with ArgoCD multiple-sources apps

2024-01-10T22:06:58+01:00

Continuous integration and delivery is at the heart of any cloud native environment.

SAP Continuous Integration and Delivery service provides a way of configuring your development pipelines including access to your in-house corporate git repositories: Connect SAP Continuous Integration and Delivery with Your Corporate Git

However, when it comes to Kubernetes-based environments, including Kyma, Argo CD - a declarative, GitOps continuous delivery tool for Kubernetes - is a likely frontrunner.

Why ArgoCD is that popular with the Kubernetes environments ?

Simply because it enforces their declarative and contractual nature, as described here: https://argo-cd.readthedocs.io/en/stable/#why-argo-cd

Long story short. For this brief, I wanted to repurpose my custom helm pipelines into ArgoCD.

The main hurdle I had to overcome was the fact that my original helm chart based pipeline is composed of several independent helm charts (sources).

Luckily, ArgoCD supports both single and multiple source deployments. (Please note, the multi-source deployments are still a beta feature, thus subject to change.)

That saved my day. Let me share how it went.

Putting it all together

Here goes a high level architecture of a SAP solution deployed to a kyma cluster.

As of such, it is a pretty standard SAP business solution that leverages the SAP BTP multi-tenancy model with the approuter, frontend and backend services deployed to a kyma cluster (as described in way more details here: Developing multi-tenant SaaS applications easy with SAP BTP, Kyma runtime.)

The fronted is a React-Native build-app developed with SAP Build Apps as described here: Deploy SAP Build Apps web applications easy to SAP BTP, Kyma runtime.

Here goes the helm charts tree of the above solution:

📦helm

 ┣ 📂faas-app

 ┃ ┣ 📂templates

 ┃ ┃ ┣ 📜NOTES.txt

 ┃ ┃ ┣ 📜_helpers.tpl

 ┃ ┃ ┣ 📜apirule.yaml

 ┃ ┃ ┣ 📜binding-ias.yaml

 ┃ ┃ ┣ 📜configmap.yaml

 ┃ ┃ ┣ 📜deployment.yaml

 ┃ ┃ ┣ 📜destination-rule.yaml

 ┃ ┃ ┣ 📜resources.yaml

 ┃ ┃ ┣ 📜service-ias.yaml

 ┃ ┃ ┣ 📜service.yaml

 ┃ ┃ ┗ 📜xs-app.yaml

 ┃ ┣ 📜.helmignore

 ┃ ┣ 📜Chart.yaml

 ┃ ┣ 📜SAP_Best_scrn_R_gry_neg.png

 ┃ ┣ 📜kyma-logo.png

 ┃ ┣ 📜spark.jpeg

 ┃ ┗ 📜values.yaml

 ┣ 📂faas-saas

 ┃ ┣ 📂templates

 ┃ ┃ ┣ 📜NOTES.txt

 ┃ ┃ ┣ 📜_helpers.tpl

 ┃ ┃ ┣ 📜binding-registry.yaml

 ┃ ┃ ┣ 📜binding-role.yaml

 ┃ ┃ ┣ 📜configmap.yaml

 ┃ ┃ ┣ 📜function.yaml

 ┃ ┃ ┣ 📜role.yaml

 ┃ ┃ ┣ 📜sa-secret.yaml

 ┃ ┃ ┣ 📜sa.yaml

 ┃ ┃ ┣ 📜saas-apirule.yaml

 ┃ ┃ ┗ 📜service-registry.yaml

 ┃ ┣ 📜Chart.yaml

 ┃ ┗ 📜values.yaml

 ┗ 📂faas-srv

 ┃ ┣ 📂templates

 ┃ ┃ ┣ 📜NOTES.txt

 ┃ ┃ ┣ 📜_helpers.tpl

 ┃ ┃ ┣ 📜binding-dest-x509.yaml

 ┃ ┃ ┣ 📜binding-dest.yaml

 ┃ ┃ ┣ 📜binding-quovadis-sap.yaml

 ┃ ┃ ┣ 📜binding-uaa.yaml

 ┃ ┃ ┣ 📜function.yaml

 ┃ ┃ ┣ 📜service-dest.yaml

 ┃ ┃ ┣ 📜service-quovadis-sap.yaml

 ┃ ┃ ┗ 📜service-uaa.yaml

 ┃ ┣ 📜.helmignore

 ┃ ┣ 📜Chart.yaml

 ┃ ┗ 📜values.yaml

That translates into the following argocd project manifest:

project: default

source:

  repoURL: 'https://github.com/quovadis.git'

  path: kyma-btp/kyma/helm/

  targetRevision: HEAD

destination:

  namespace: anywhere

  name: shoot--kyma-stage--*****

syncPolicy:

  syncOptions:

    - ServerSideApply=true

    - RespectIgnoreDifferences=true

ignoreDifferences:

  - group: apps

    kind: Deployment

    jsonPointers:

      - /spec/replicas

  - group: services.cloud.sap.com

    kind: ServiceBinding

    jsonPointers:

      - /spec/parametersFrom

  - group: serverless.kyma-project.io

    kind: Function

    jsonPointers:

      - /spec/labels

      - /spec/runtimeImageOverride

  - group: batch

    kind: Job

    jsonPointers:

      - /*



sources:

  - repoURL: 'https://github.com/quovadis.git'

    path: kyma-btp/kyma/helm/faas-srv/

    targetRevision: HEAD

    helm:

      valueFiles:

        - values.yaml

      parameters:

        - name: services.app.service.port

          value: <port>

        - name: clusterDomain

          value: <custom domain>

        - name: gateway

          value: <istio gateway>

  - repoURL: 'https://github.com/quovadis.git'

    path: kyma-btp/kyma/helm/faas-saas/

    targetRevision: HEAD

    helm:

      valueFiles:

        - values.yaml

      parameters:

        - name: services.app.service.port

          value: <port>

        - name: clusterDomain

          value: <custom domain>

        - name: gateway

          value: <istio gateway>

  - repoURL: 'https://github.com/quovadis.git'

    path: kyma-btp/kyma/helm/faas-app/

    targetRevision: HEAD

    helm:

      valueFiles:

        - values.yaml

      parameters:

        - name: services.app.service.port

          value: <port>

        - name: clusterDomain

          value: <custom domain>

        - name: gateway

          value: <istio gateway>

Good to know:

There is at least one default argoCD project and a number of argoCD applications as well.

ArgoCD applications may be pointing to different target kyma clusters and/or namespaces.

For instance, here goes a top level application view of resources deployed to a kyma cluster

After the deployment to a kyma cluster the business users (aka consumers) gain access to the kyma app by subscribing to it from the Service Marketplace in their respective BTP tenants (sub-accounts).

Eventually, in order to acquire permissions to access the app, business users must be assigned suitable role collections available to them in their respective BTP sub-accounts.

ArgoCD APIs

Last but not least, another great feature of ArgoCD is the REST APIs package and its swagger definition.

Eventually, I used SAP API Management to implement the whole ArgCD API package as an API proxy.

For instance, one can manage argoCD applications programmatically:

Appendix

Prepare your kyma cluster for ArgoCD operations

Assuming you have a service account token-based kubeconfig to access your kyma cluster.

The below Makefile summerizes the steps required to add a shoot kyma cluster to an ArgoCD instance:

create a dedicated namespace for argocd related configurations

Create a service account to be used by argocd

create a cluster rolebinding for argocd service account

create a target namespace in your cluster to deploy argocd applications to

log into your argocd service

add your cluster by its shoot name to your argocd service

.DEFAULT_GOAL := help



LOCAL_DIR = $(dir $(abspath $(lastword $(MAKEFILE_LIST))))





ARGOCD_NAMESPACE=argocd

ARGOCD_SERVICEACCOUNT=demo-argocd-manager

KUBECONFIG=~/.kube/kubeconfig--c-***.yaml

NAMESPACE=quovadis

ARGOCD=<argocd server>



CUSTOM_DOMAIN= $(shell kubectl get cm -n kube-system shoot-info --kubeconfig $(KUBECONFIG) -ojsonpath='{.data.domain}' )

SHOOT_NAME= $(shell kubectl config current-context --kubeconfig $(KUBECONFIG) )



help: ## Display this help.

	@awk 'BEGIN {FS = ":.*##"; printf "\nUsage:\n  make \033[36m<target>\033[0m\n"} /^[a-zA-Z_0-9-]+:.*?##/ { printf "  \033[36m%-15s\033[0m %s\n", $$1, $$2 } /^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) } ' $(MAKEFILE_LIST)

		echo $(KUBECONFIG) $(NAMESPACE) $(SHOOT_NAME)





.PHONY: argocd-bootstrap-cluster

argocd-bootstrap-cluster: ## bootstrap argocd on your kyma cluster

   # create a dedicated namespace for argocd related configurations

	kubectl create ns $(ARGOCD_NAMESPACE) --kubeconfig $(KUBECONFIG) --dry-run=client -o yaml | kubectl apply --kubeconfig $(KUBECONFIG) -f -

	# Create a service account to be used by argocd

	kubectl -n $(ARGOCD_NAMESPACE) create serviceaccount $(ARGOCD_SERVICEACCOUNT) --kubeconfig $(KUBECONFIG) --dry-run=client -o yaml | kubectl apply --kubeconfig $(KUBECONFIG) -f -

	# create a cluster rolebinding for argocd service account

	kubectl create clusterrolebinding $(ARGOCD_SERVICEACCOUNT) --serviceaccount $(ARGOCD_NAMESPACE):$(ARGOCD_SERVICEACCOUNT) --clusterrole cluster-admin --kubeconfig $(KUBECONFIG) --dry-run=client -o yaml | kubectl apply --kubeconfig $(KUBECONFIG) -f -



	kubectl create ns $(NAMESPACE) --kubeconfig $(KUBECONFIG) --dry-run=client -o yaml | kubectl apply --kubeconfig $(KUBECONFIG) -f -

	kubectl label namespace $(NAMESPACE) istio-injection=enabled --kubeconfig $(KUBECONFIG)



	argocd login $(ARGOCD) --sso

	argocd cluster add $(SHOOT_NAME) --service-account $(ARGOCD_SERVICEACCOUNT) --system-namespace $(ARGOCD_NAMESPACE) --namespace $(NAMESPACE) --kubeconfig $(KUBECONFIG)

ArgoCD application(s)

As aforementioned, any argoCD application must be part of a project. And anyone can use the default argoCD project to start with...

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

  name: quovadis-rwx

spec:

  destination:

    name: ''

    namespace: quovadis

    server: 'https://api.*****.stage.kyma.ondemand.com'

  source:

    path: kyma-btp/kyma/helm

    repoURL: 'https://github.tools.sap/<repo>/quovadis.git'

    targetRevision: HEAD

  sources: []

  project: default

  syncPolicy:

    syncOptions:

      - ServerSideApply=true

      - RespectIgnoreDifferences=true

Additional reading

ArgoCD blogposts:

Getting Started with ArgoCD

https://blogs.sap.com/2023/11/05/gitops-with-argo-cd-kyma-multi-cluster-management/

How to create ArgoCD Applications Automatically using ApplicationSet? “Automation of GitOps”

Getting Started with ArgoCD for GitOps Kubernetes Deployments

Test Automation Tool for SAP S/4HANA Cloud Public Edition 2402 Release Overview

2024-01-30T10:12:22.850000+01:00

Embedding intelligence into our products has been the main focus topic for this release. The 2402 Cloud Release introduces new features around AI/ML for advanced error analysis and functions which build on the tool being an integrated part of the SAP S/4HANA Cloud solution.

Intelligent Test Scoper(i-TS)

The new Intelligent Test Scoper(i-TS) app leverages the embedded nature of the test automation tool to provide an optimized scope based on the code changes done as part of a major release or SAP Continuous Integration and Delivery . The app currently suggests Post Upgrade Tests(PUT) Standard Scripts which cover the changes done in the particular software update. The consolidated list of automates provide a more efficient and optimized scope for running PUT.

Intelligent Test Scoper(i-TS) Application

The i-TS app is integrated with the Manage Upgrade Tests(MUT) solution and provides a one click option of moving the optimized scope to a new execution variant. The execution variant created is marked as “optimized” scope and will be then available for PUT in the Test Your Process(TYP) application.

You can read more about the evolution of the i-TS tool here.

ABAP Units as part of Post Upgrade Tests(PUT)

Embedded Steampunk allows customers and partners to create cloud-ready and upgrade-stable ABAP extensions. There is a need to ensure these extensions work well release on release. With the feature of ABAP Units as part of the PUT process we enable customers to test their custom ABAP Units as part of the release regression suite. MUT application has been enhanced with an additional tab “ABAP Units” where users can add ABAP Units to an execution variant and utilize it in the PUT run. Results will be shown on the PUT track results page, the information can be downloaded as an excel file and further actions can be taken up in ABAP Development Tool(ADT).

ABAP Units in Post Upgrade Tests(PUT)

Automation Failure Classification(AFC)

While the feature of AFC has been available in the Analyse Automated Test Results(AATR) application for some time, from this release you would be able to see if the classification has happened via “ML Text Classification” or “Regular Expressions”. AFC is now able to categorize close to 70% of the automate failures. This features also provides Recommendations to solve the automate error based on the error message and classification.

Error Classification

Additional Innovations

Some additional features which increase the overall user experience are as follows:

The ”Execution Variant” tab is now deprecated and all relevant PUT scope grouped into an execution variant called Default PUT Scope
Restriction on deleting execution variants that has been executed before or the one currently being executed

SAP Delivered Standard Automates

The total list of SAP delivered automated test scripts are 414 for 2402 and can be accessed via link – Automated Test Scripts Index”. This includes 8 new scope items which were added this release.

Further detailed change information about the standard automate is available in the “Automated Test Script Change History” and “Test Script Release Change Information”.

Important Links and Updates

You can also access the replay from the SAP S/4HANA Cloud 2402 Early Release Series which highlights the key new features. Details on how to login and access the content is available here.

As part of our PUT 2.0 Enablement also we have created a set of short videos which cover the most important aspects of the process. The video playlist can be accessed here.

Also continuing our trend of highlighting important blogs written on test automation topic below are some blogs we definitely recommend:

Please bookmark the test automation community page to keep up with the latest updates happening in the test automation space.

For more details on the functionality please refer the links below:

Intelligent Test Scoper (i-TS)
Manage Upgrade Tests
Manage Your Test Processes
Test Your Processes
Test Data Container
Analyze Automated Test Results
Configure Conditional Authentication
Also refer FAQs

--------------------------------------------------------------------------------------------------------------------------------------------------

Don’t hesitate to leave a comment and check out our new community page to ask your questions and engage with the experts. Follow the PSCC_Enablement tag to stay up to date with our latest blog posts.

📽️ Watch Our Live Sessions

In January 2024, we hosted a series of 19 compelling live sessions to highlight the exciting innovations shipped with the SAP S/4HANA Cloud Public Edition 2402 release. Missed the live sessions? No problem! Take advantage of the entire series or pick and choose the sessions most relevant to you on demand.

🎙️ Inside SAP S/4HANA Cloud

There is no customer success without project success and product success! Leverage the unique knowledge and expertise of SAP S/4HANA Cloud experts, partners, and customers, sharing their SAP S/4HANA Cloud implementation project best practices and lessons learned – anywhere, anytime. In this podcast, we give you all ingredients to get to the next level and make your SAP S/4HANA Cloud project a success. Subscribe now and benefit from the shared knowledge!

💻openSAP Microlearnings for SAP S/4HANA Cloud

Our openSAP microlearnings for SAP S/4HANA Cloud offer an exciting new learning opportunity. What began with a small batch of 20 videos, has now become a channel with more than 50 microlearnings that have generated over 20,000 views. Today, we cover multiple lines of business such as finance, manufacturing, and supply chain management, and key technology topics like Master Data Management, extensibility, SAP User Experience, and upgrade management. We are continuously adding new microlearnings to our channel, so make sure you check them out.

🗣️ Your Voice Matters

You want to learn more and actively engage with SAP subject matter experts on SAP S/4HANA Cloud topics? We have just the right place for you! Join our interactive community where we bring together customers, partners, and SAP experts with a clear mission: To engage with one another about best practices and product solutions. We invite you to explore the ‘one-stop shop’ as the central place for all resources, tools, content questions, answers and to connect with experts who will guide you through your journey to the intelligent, sustainable enterprise.

🔎Find All of Our Assets

SAP S/4HANA Cloud is the foundation of the intelligent, sustainable enterprise and is an innovative, robust, and scalable ERP. We at Cloud ERP Product Success and Cloud Co-Innovation offer a service as versatile as our product itself. Check out the numerous offerings our team has created for you below:

🎯Where to Find More Information:

Read up on the highlights of the SAP S/4HANA Cloud Public Edition 2402 release here: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/highlights-of-the-sap-s-4hana-cloud-public-edition-2402-release/ba-p/13587480
Interested in an SAP S/4HANA Cloud Public Edition 2402 update on the intelligent ERP? Read all about it here: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/sap-s-4hana-cloud-public-edition-2402-intelligent-erp-update/ba-p/13584760
Watch the replays of our exclusive SAP S/4HANA Cloud Public Edition 2402 Early Release Series here: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/watch-the-replays-of-our-exclusive-sap-s-4hana-cloud-public-edition-2402/ba-p/13587019
Explore the ready-to-run cloud ERP here: https://www.sap.com/products/erp/s4hana.html
Watch our SAP S/4HANA Cloud product update videos on YouTube: https://www.youtube.com/playlist?list=PLWV533hWWvDnnyN2j-CcUheNN-GaNCb3H
Check out our digital enablement wheel here: https://chart-bdmaicr0au.dispatcher.eu2.hana.ondemand.com/index.html?hc_reset
Find out how to switch from groups to spaces and pages here: https://blogs.sap.com/2023/11/06/deactivation-of-groups-in-the-sap-fiori-launchpad-in-sap-s-4hana-cloud-public-edition-2402-switching-to-spaces-and-pages-mandatory/
Become an early adopter for Joule in SAP S/4HANA Cloud Public Edition here: https://influence.sap.com/sap/ino/#campaign/3612
Check out the SAP Activate Roadmap for early adopters here: https://go.support.sap.com/roadmapviewer/#/group/658F507A-D6F5-4B78-9EE1-0300C5F1E40F/roadmapOverviewPage/0894b61141a74a65b8da92db32685da5
Review the PPL content here: https://go.support.sap.com/roadmapviewer/#/group/658F507A-D6F5-4B78-9EE1-0300C5F1E40F/roadmapContentPage/0894b61141a74a65b8da92db32685da5:t8
Listen to our podcast here: https://podcast.opensap.info/inside-sap/
Watch our openSAP microlearnings to learn about SAP S/4HANA Cloud topics at your own pace here: https://microlearning.opensap.com/
Find best practices on SAP S/4HANA Cloud Public Edition here: https://me.sap.com/processnavigator/SolS/EARL_SolS-013/latest?region=DE
Check out what’s new here: https://help.sap.com/doc/ce01d82756b947a1a043a5d5a3204226
Find help here: https://help.sap.com/docs/SAP_S4HANA_CLOUD
Read the feature scope description here: https://help.sap.com/doc/7c9e0bbbd1664c2581b2038a1c7ae4b3

Using Integration Suite Piper commands in GitHub Actions (CI/CD) platform

2024-02-12T04:00:36.795000+01:00

Github Actions provides a way to Automate, customize, and execute your software development workflows right in your Github repository.

Github Actions is a continuous integration and continuous delivery (CI/CD) platform that automates build, test, and deployment pipelines. It also allows you to execute code in the repository when certain events occur, making it easy to extend and customize.

In this Blog we will showcase how to build GitHub Actions Workflow for deploying the integration flow using Integration Suite Piper Commands.

A workflow is a series of actions initiated once a triggering event occurs. For example, the triggering event can be some commit pushed to a GitHub repository, the creation of a pull request etc.

The set of instructions for a workflow is kept in a workflow file and written in YAML. The workflow file specifies what commands or scripts to run, the default settings, the environment for the commands, etc.

The workflow is divided into jobs, and each job performs a set of steps. Each step runs one or more commands and can also call self-contained units of commands called actions. Each step runs on computational resources called runners, and the default settings can specify it to be Windows or Linux.

Lets build a workflow which deploy the integration flow in to the SAP Cloud integration Tenant

Create a Workflow

1. Create a repository and name it .github/workflows inside the GitHub repository GithubActionsDemo.

2. Create a yml file and name it iflowDeploy.yml.

3. Paste the following code inside the iflowDeploy.yml file.

name: SAP Cloud Integration deploy IFlow Test
on:
  push:
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: integrationArtifactDeploy
        uses: SAP/project-piper-action@main
        with:
          step-name: integrationArtifactDeploy
          flags: --apiServiceKey ${{ secrets.CPIAPISERVICEKEYCREDENTIALSID }} --integrationFlowId PurchaseOrderHandlerDemo

4. Copy the SAP Cloud Integration Service Key for API Plan from SAP BTP Cockpit

5. Copy the JSON Content to the Text Editor and remove line breaks and spaces. make complete JSON appear in single line without any such line breaks or spaces.

For example: {"oauth":{"createdate":"2022-11-02T09:48:13.398Z","clientid":"sb-47bbf5d2-d764-45d7-ba46-d6bd540cc4c6!b17976|it!b2455","url":"https://XXX.it-cpi999.cfapps.us10.hana.ondemand.com","clientsecret":"c52bbcff-ca23-4f90-b01f-73b0f552ebb6$fXqdreVaI13WTn8cdgXNW5Tt83RfvFg9pyVYBAVz8WI=","tokenurl":"https://XXX.authentication.usXX.hana.ondemand.com/oauth/token"}}

6. Create repository secret and save above content by name CPIAPISERVICEKEYCREDENTIALSID

Test Workflow

To test the workflow in the committed workflow file:

Since our workflow’s trigger is a push event, push a commit on this repository branch via directly editing report content or from Git tool.
Go to the repository’s page on GitHub and click the Actions tab under the repository’s name.
At the top, the commit message for the push that triggered the workflow will be visible.
Once the workflow is complete, click on the tab with the commit message. In this case, click on "Update Readme.txt".
The job name and status will appear on right side
Clicking on the job will show the output from each step in the workflow.

From the results you can see that integrationArtifactDeploy piper command successfully executed.

7. Verify the integration flow deployment in to SAP Cloud integration Tenant

As you see below integration flow PurchaseOrderHandlerDemo deployed in to SAP Cloud integration tenant runtime.

In this way you can use any of the Integration Suite piper commands referred in my earlier blog in the GitHub Actions project and implement you own CI/CD pipelines.

Integrate CI/CD with cTMS as part of SAP Cloud ALM

2024-03-29T07:59:53.217000+01:00

Introduction

As Tom Cenens already explained very well, we have not only Cloud Transport Management Service (cTMS) in BTP but also cTMS a part of SAP Cloud ALM: https://community.sap.com/t5/technology-blogs-by-members/integration-of-ctms-as-part-of-sap-cloud-alm-and-charm/ba-p/13651994

They are both identical, the only difference is the pricing. The one in ALM comes with free GB’s of bandwidth.

Now, if you haver BTP applications (Fiori apps, CAP apps, … ) developed in Business Application Studio (BAS) that needs to be transported from DEV to ACC and PRD later on, cTMS can be used. The cTMS used for this should be the same that’s being connected to CHARM so you can combine ABAP transports with BTP transports in the same change document. When Tom connects cTMS of ALM to CHARM, we need to connect CI/CD to that same cTMS of ALM. Unfortunately, just like the integration with CHARM, this is not document and most of the blog posts about this topic refer to cTMS on BTP.

(Transporting could also be done using CI/CD only using the GitFlow strategy but this does not connect BTP transports with ABAP transports like CHARM allows us to do. In the SAP world, we want to keep CHARM for transporting and integrate BTP transports into it.)

Cloud ALM API Instance

If not already done, create an ALM API instance in the ALM Sub Account as described here with the additional points of Tom:

https://help.sap.com/docs/cloud-alm/setup-administration/enabling-sap-cloud-alm-api

Once you have created the instance, also create service keys and copy them. You’ll need them in a later step.

Connect SAP CI/CD to ALM cTMS:

Copy the service keys from ALM API instance you have created in the previous step
Open the BTP CI/CD service
Go to the job of an app that you want to transport using cTMS of ALM

Switch to edit in the job and scroll down to the step “Cloud Transport Management”:

Open the valuehelp for the field “Service Key” and click on “Create Credentials”
Paste the service keys of the ALM API instance

Remove the part of “endpoints”

Add the property “uri” and provide it the value: “https://<region>.alm.cloud.sap/api/imp-cdm-transport-management-api/v1” eg.: https://eu20.alm.cloud.sap/api/imp-cdm-transport-management-api/v1 or https://eu10.alm.cloud.sap/api/imp-cdm-transport-management-api/v1

As transport operation I use “Export from” and name of the DEV node. The export from will add it to the queue of ACC and not deploy it to DEV. The deployment to DEV will be done by the CI/CD service in my example.

Save and run your Job, the release step will be green and you’ll find the MTA in the queue of your ACC node in cTMS of ALM:

Connect any other CI/CD tool to ALM cTMS

Besides the SAP CI/CD service, some companies prefer to use the same CI/CD tooling they already have and use for other frameworks. There are already some examples on how to integrate your own CI/CD setup with cTMS but none of them cover cTMS on ALM. As a starting point I will use the setup described in this blog post:

https://community.sap.com/t5/technology-blogs-by-sap/integrate-a-ci-cd-pipeline-on-azure-devops-with-devops-related-services/ba-p/13528858

The only thing we need to change for cTMS in ALM is the upload to cTMS step, line 70, 71 and 72:

I’ve changed it to the following:

TOKEN=$(curl -s -X POST -u "<ALM Service Key uaa.clientid>:<ALM Service Key uaa.clientsecret>" -d "grant_type=client_credentials&response_type=token" <ALM Service Key uaa.url>/oauth/token | sed -n '/ *"access_token": *"/ {s///; s/{//g ;s/".*//; p; }')

BODY=$(curl -s --location --request POST '<ALM TMS Service Key uri>/v2/files/upload' --header "Authorization: Bearer $TOKEN" --form 'file=@"$(Pipeline.Workspace)/MySampleApp.mtar"' | awk -F ":" '{print $2}' | grep -Po "\\d+")

curl --location --request POST '<ALM TMS Service Key uri>/v2/nodes/export' --header 'Content-Type: application/json' --header "Authorization: Bearer $TOKEN"  --data-raw '{ "nodeName": "<Name of your ALM TMS DEV node>", "contentType": "MTA", "storageType": "FILE", "entries": [ { "uri": '"$BODY"' } ], "description": "<Description optional>", "namedUser": "<User name optional>" }'

ALM Service Key uaa.clientid: clientid property in the ALM service keys (eg.: sb-calm-api-inst-2!b..... )

ALM Service Key uaa.clientsecret: clientsecret property in the ALM service keys

ALM Service Key uaa.url: authentication url for ALM (eg.: https://<alm-instance-name>authentication.<region>.hana.ondemand.com/oauth/token )

ALM TMS Service Key uri: will become the url of ALM followed by the path to cTMS, something like this: https://eu20.alm.cloud.sap/api/imp-cdm-transport-management-api/v1 . In the end it will have a full uri that looks like this https://eu20.alm.cloud.sap/api/imp-cdm-transport-management-api/v1/v2/files/upload , strange to have /v1/v2 but it works!

Name of your ALM TMS DEV node: Name of ALM cTMS DEV node. You might have noticed that I’m using /export instead of upload. This is the same as the Transport Operation in the BTP CI/CD service “Export from”, it will upload it to the next node after DEV. Same reason as before, the deployment to DEV will be done by the CI/CD tool.

Integrate other services with cTMS of ALM

Any other service that requires you to create a destination can be configured the same way. Take for example BTP BUILD WorkZone, std edition , transporting the content (catalogs, groups, roles, ... ) requires a destination “ctms_destination”. In this destination you need to provide the credentials to cTMS. Now in case of cTMS in ALM, you have to use clientid, client secret and uaa url from the ALM API service keys. The url of the destination should be the following: “https://<region>.alm.cloud.sap/api/imp-cdm-transport-management-api/v1” eg.: https://eu20.alm.cloud.sap/api/imp-cdm-transport-management-api/v1 or https://eu10.alm.cloud.sap/api/imp-cdm-transport-management-api/v1

Conclusion

In short, when switching to ALM, you need to use the service keys from the ALM API service and the uri “https://eu20.alm.cloud.sap/api/imp-cdm-transport-management-api/v1” instead of this one from cTMS (standalone) “https://transport-service-app-backend.ts.cfapps.eu10.hana.ondemand.com”

Special thanks for investigating this with me to @TomCenens , @matthiaskiekens and @FrederikJ !

How to Create Outbound Delivery With order reference in SAP VL01N

2024-04-05T16:27:49.370000+02:00

Outbound Delivery Replication in SAP - TCODE- VL01N

1. Introduction

Outbound Delivery in SAP (Systems, Applications, and Products in Data Processing) refers to the process of fulfilling customer orders by shipping goods or products from a company's warehouse or production facility to the customer's specified location. This documentation provides a comprehensive guide to understanding and executing Outbound Delivery processes within SAP.

2. Purpose

The purpose of Outbound Delivery in SAP is to streamline the logistics and shipping operations of a company, ensuring accurate and timely delivery of products to customers. By efficiently managing outbound deliveries, businesses can enhance customer satisfaction, optimize inventory management, and improve overall operational efficiency.

3. Key Features

Creation of Outbound Delivery Orders (ODOs) based on sales orders or stock transport orders.
Packing of goods into delivery packages or handling units.
Generation of delivery documents such as delivery notes and shipping labels.
Integration with transportation management systems for route optimization and carrier selection.
Confirmation of goods issue to update inventory levels.
Monitoring and tracking of delivery status in real-time.

4. Process Flow

The typical process flow for Outbound Delivery in SAP involves the following steps:

Sales Order Creation: Customer orders are received and entered into the SAP system as sales orders.
Outbound Delivery Order Creation: Based on the sales orders, Outbound Delivery Orders (ODOs) are created in SAP. These ODOs contain information such as the items to be shipped, quantities, delivery dates, and customer shipping details.
Packing: Goods are picked from the warehouse shelves or production lines and packed into delivery packages or handling units. The packing process involves assigning materials to specific delivery units and determining packaging materials.
Goods Issue: Once the goods are packed and ready for shipment, a goods issue is posted in SAP to signify the removal of goods from inventory. This updates inventory levels and triggers the billing process.
Delivery Document Printing: Delivery documents such as delivery notes and shipping labels are generated in SAP and printed for inclusion with the shipment.
Shipment Execution: The goods are physically transported to the customer's location using selected carriers or transportation methods.
Delivery Confirmation: Upon successful delivery, the delivery is confirmed in SAP to update the delivery status and trigger subsequent processes such as billing and customer invoicing.

T.code:-

VL01N – With / Without Reference to Sales Order.
VL02N – Single Document Change.
Vl03N – Display Delivery Document.

In the initial Screen of Create Outbound Delivery Need to provide below information.
Shipping Point: Get the shipping point from the shipping tab of sales order line item.
Selection Date : It should be either the material availability date or the system copies the item into the delivery.
Sales Order Number: The sales order number against which the delivery document needs to be created.
From and to Item Number: Line item number of sales order against which needs to be created delivery, if a user does not specify any line item then the system will consider all line items of sales order for delivery creation.

Create outbound delivery without order reference

Then the system will land to the user on Create Delivery Overview screen like the below screenshot.

Picking Tab display

Plant code: Delivery plant
Storage location
Delivery Quantity
UoM
Picked Quantity

The picked quantity is grey out mode that means we have to transfer the order to pick the material.

Transport tab provide information

Transportation Planning date
Transportation Planning status.
Route
Gross weight
Volume

The goods movement tab provides information that which movement type is used for this delivery document.

Select any one line item of the delivery document and click on the item Details button. It will display item data of that line item.

The predecessor data tab provides information about

Reference Document number e.g. Sales order number.
Reference Item: line item number of Sales order number.
Reference Type: Document category.

Click on SAVE button.

Now, the delivery document has been saved with the delivery number.

5. Benefits

Improved order fulfilment accuracy and speed.
Enhanced visibility and traceability of outbound shipments.
Reduction in shipping errors and delays.
Optimal utilization of warehouse resources.
Better customer service and satisfaction.

6. Conclusion

Outbound Delivery in SAP plays a critical role in ensuring the smooth and efficient execution of logistics and shipping operations. By leveraging SAP's robust functionality and integration capabilities, businesses can effectively manage outbound deliveries, meet customer expectations, and drive operational excellence.

New webcast series on “SAP BTP DevOps and Observability in Action”

2024-04-10T08:13:46.597000+02:00

If you run applications on SAP Business Technology Platform (SAP BTP), join our huge webcast series on DevOps and observability - featuring over ten absolute content experts from different SAP teams and areas! The new series is a continuation of last year’s webcasts and offers the latest news and many additional topics and insights!

Overview

Consisting of interactive lectures and demos, you can learn how you can enable your teams to benefit from a more agile way of developing – while preserving the right level of control when it comes to delivering their changes to your production environment. Also, we will cover how you can integrate SAP BTP operation and delivery with SAP Cloud ALM, SAP’s strategic operations platform also for SAP BTP. All following SAP's recommended approach depicted below:

SAP's recommended approach for DevOps on SAP BTP

Topics will be the interplay of DevOps with SAP Cloud ALM, the integration of Continuous Integration pipelines with transport and change management, and SAP BTP operations with SAP Cloud ALM and local expert tools. Learn more about:

Creating CI/CD pipelines with SAP Continuous Integration and Delivery service in minutes and how to adapt them, if required
Transporting the latest SAP BTP content types with SAP Cloud Transport Management service, optionally orchestrated by SAP Cloud ALM
Managing further content types with SAP Content Agent service
Logging your applications on SAP BTP with SAP Cloud Logging service
Establishing a more reactive way of working by benefiting from our unified alerting approach with SAP Alert Notification service and SAP Cloud ALM
Instrumenting your own applications built on SAP BTP with the help of OpenTelemetry
Reducing operation efforts with SAP Cloud ALM and SAP Automation Pilot service – and how you can benefit from the upcoming GenAI capabilities to automate your technical operation tasks and easily create automated recommended actions
Managing your infrastructure with the Terraform provider for SAP BTP

Sessions of the Webcast series

As part of the series, we will start with two overview lectures, offered as live sessions on YouTube:

April-23, 2024: Unlock the potential of DevOps on SAP BTP with SAP Cloud ALM
April-24, 2024: SAP Cloud ALM for SAP BTP operations

After that, you can deep dive into the three topic areas, always covered with a longer presentation (consisting of three related topics, held by three different experts in an interactive Zoom session) – followed by a holistic demo session on all the three topics covered before. This way, you can get detailed insights and can benefit from a jumpstart to establish the presented best practices also in your landscape! Both deep dive formats will grant enough time to raise your questions and to get direct guidance from the corresponding experts!

Here is what you can expect in detail for the interactive deep dive sessions on Zoom:

For logging and alerting:

May-14, 2024: Logging and Alerting with SAP Cloud ALM for your apps on SAP BTP (lecture)
- Unified Approach Towards Alerting in SAP BTP with SAP Alert Notification Service and SAP Cloud ALM
- OpenTelemetry-Based Instrumentation for your Custom-Built Apps on SAP BTP
- Introduction to SAP Cloud Logging Service
May-15, 2024: Get a Demo on the Unified Alerting and Logging Approach on SAP BTP (demo session)

For technical ops automation:

May-21, 2024: Reduce your operation efforts with SAP Cloud ALM, SAP Automation Pilot and the Terraform Provider for SAP BTP (lecture):
- Reduce your Operation Efforts with SAP Cloud ALM and SAP Automation Pilot Service
- Benefit from Latest GenAI Capabilities for Automating your Technical Operation Tasks with SAP Automation Pilot Service
- Manage your Infrastructure with the Terraform Provider for SAP BTP
May-22, 2024: Get a demo on how to automate technical operation tasks for running your application on SAP BTP (demo session)

And finally on delivery:

May-28, 2024: Deliver content on SAP BTP (lecture):
- Enhanced Flexibility for your Pipelines in SAP Continuous Integration and Delivery service
- Transport of Further Content Types with SAP Cloud Transport Management Service
- Enablement of new Content Management Use Cases with SAP Content Agent Service
May-29, 2024: Get a Demo on How to Combine CI/CD with Transports for Speedy and Controlled Delivery (demo session)

Sign up today!

Benefit from this offering and the guidance provided by our over ten topic experts, from different areas and teams at SAP! Share the event with your colleagues, to get everyone up to speed and on the same page! And feel free to bring your questions around these topics!

Learn more and sign up here free-of-charge.

And as always: if you should have ideas for other operations topics around SAP BTP, please leave a comment!

Configure cTMS in combination with CHARM and CI/CD

2024-04-28T22:47:32.487000+02:00

Introduction

The BTP Cloud Transport Management Service (cTMS) is mostly used in combination with the CI/CD service (or any other non-SAP CI/CD tool) when you need to transport applications from one Sub Account to another Sub Account. This combination is well documented in the SAP help documentation. CI/CD deploys to your DEV Sub Account and uploads the MTAR of your application to cTMS. From here, cTMS taks over to deploy to ACC and PRD Sub Accounts. You can find the details in the documentation here:

https://help.sap.com/docs/continuous-integration-and-delivery/sap-continuous-integration-and-delivery/configure-sap-fiori-in-cloud-foundry-environment-job-in-your-repository#(optional)-integrate-sap-cloud-transport-management-into-your-pipeline

Besides integration with CI/CD, you want to integrate cTMS with your existing transporting system, which is for most customers Charm. This setup allows you to transport ABAP objects and BTP applications together. You could also consider using ALM as transporting system but at the moment this has not all the functionalities that you have in Charm today.

Connecting cTMS nodes to Charm require enabling the configuration “Controlled By SAP Solution Manager”:

When you enable this, you might face some of the problems listed below and the solution might might be helping you to have a clean cTMS landscape integrated with Charm.

Problems

DEV node in cTMS without destination cannot be saved

Setting a destination doesn’t make sense as the CI/CD service already deploys to the DEV Sub Account but it allows you to continue with the configuration.
The flow described for Cloud ALM cannot be applied exactly the same way when using Charm as it does not require to enable “Controlled by SAP Solution Manager”, see documentation.
- https://help.sap.com/docs/cloud-alm/setup-administration/cloud-transport-management

All cTMS Nodes after DEV need to be controller by SAP Solution Manager if you want to integrate it with Charm BUT import to cTMS Nodes “Controlled By SAP Solution Manager” is not possible. This will cause an error in the logs of cTMS

Uploading to the DEV Node in cTMS only forwards to ACC after successful import. Importing/Deploying to DEV via cTMS is not needed as this is already done by the CI/CD service
- This is only causing overhead which is not needed

This means that you need to upload to cTMS Node for ACC BTP Sub Account BUT this is not possible because it is controlled by SAP Solution Manager

Solution

Make the DEV nodea Virtual Node
In SAP CI/CD, use export from “DEV-NODE” instead of "Upload to":
- This will upload the mtar to cTMS and immediately forward it from DEV to ACC so it ends up in the queue of ACC.

In any other CI/CD tool, use the export api: “/v2/nodes/export”
- https://api.sap.com/api/TMS_v2/path/NODE_EXPORT_BY_NAME_V2
- See blog post with an example: https://community.sap.com/t5/technology-blogs-by-members/integrate-ci-cd-with-ctms-as-part-of-sap-cloud-alm/ba-p/13653010

In the end, DEV is a virtual node and all others are controlled by Solution Manager

Configuration of the DEV Node:

Upload to Node is allowed
Node is flagged as a virtual node

Configuration of all nodes after DEV:

“Conntrolled By SAP Solution Manager” enabled

Overview

In the end, your transport landscape with CI/CD, cTMS and Charm will look like this:

Developers will push their code from BAS or VSCode to GIT
GIT will trigger CI/CD through a webhook
CI/CD will
- deploy to the DEV Sub Account
- export to cTMS dev node
cTMS will move the transport to the queue of ACC
From here it can be transported using Charm

I used a separate Sub Account for the CI/CD service but this could be as well in the DEV Sub Account.

For the integration with Charm I recommend following this blog post: https://community.sap.com/t5/technology-blogs-by-sap/how-to-use-the-integration-of-sap-cloud-platform-transport-management-into/ba-p/13443259

DevOps with SAP BTP

2024-05-06T14:26:48.640000+02:00

As my initial blog post series around DevOps with SAP BTP is already some years old, I thought it would be about time to come up with a new article - to reflect latest changes about how you can enable your teams to benefit from it for developing and running their apps on the platform.

DevOps is a key enabler for achieving high-level agility and quality in development projects – also in SAP enterprise environments. If you should be new to DevOps, the DevOps | SAP Community topic page does offer a lot of information.

Although DevOps is mainly a cultural approach, tools can help to foster agile development principles along the lifecycle of applications. In this article, I will sketch the setup recommended by SAP for agile development projects on SAP BTP, using corresponding SAP BTP cloud services and offerings. The platform does offer several different development approaches and runtime environments, so details of this setup might slightly differ per use case, but the goal is to offer a similar concept fitting for the most important ones.

The following figure outlines the recommended approach on the example of SAP BTP, Cloud Foundry environment:

Recommended approach to apply DevOps on SAP BTP

As most of the depicted SAP BTP cloud services are also part of SAP Build Code, this does also reflect the recommended approach around this offering.

Let's go through those four phases in the remainder of this article.

1. Set Up Continuous Integration

One driver of the agility and built-in quality that DevOps brings is the automation of large parts of the deployment pipeline. For this, a Continuous Integration / Continuous Delivery (CI/CD) pipeline is involved that automatically gets executed whenever your development teams do submit changes to their source code management system, to qualify them. The pipeline automatically performs certain actions along different stages, such as to build your changes and to test them on different levels. With this, it provides feedback to the developer on the quality of his/her changes:

Using Continuous Integration and Delivery to automate large parts of the deployment process

So, the first challenge is to set up CI/CD for your SAP BTP development use cases. Here, SAP BTP does offer a two-fold approach:

Option 1: Pipeline as a Service with SAP Continuous Integration and Delivery
- Opinionated, highly integrated setup that allows to benefit from agile methods without having to bring expertise
- Brings pipeline templates for typical SAP BTP development use cases, such as to develop a side-by-side extension using Cloud Application Programming model (CAP) or a compelling UI using SAP Fiori on Neo/Cloud Foundry/ABAP Front-End Servers; with this, it allows to come up with a running build, test and deploy pipeline for those SAP BTP specific use cases in minutes – where the pipeline can be configured completely via UI (configuration as code is optionally also possible)
- No need to build up and especially operate an own CI/CD infrastructure – only prerequisite: bring your own Git as source code management system
- SAP product, with direct support from SAP
- With this, addressing also those partners and customers that do not bring experience or that are looking for a CI/CD setup recommended and provided by SAP, reducing the overhead and cognitive load of their developers

Easy process to set up pipeline in SAP Continuous Integration and Delivery service

Option 2: Toolbox with open source offering project ‘Piper’
- Building blocks that allow you to build an own pipeline for SAP-specific use cases easier: pipeline templates (for Jenkins only), a library of pipeline steps (in Golang, which allows you to use them also for non-Jenkins CI/CD infrastructures), scenarios (end-to-end descriptions with sample code snippets), and Docker images you can easily add to your pipeline (example for usage with Azure DevOps)
- As it is an open source offering, there is no direct support provided by SAP – only community support, you have to create and then own your pipeline
- With this, the offering is addressing those partners and customers that need full flexibility and already bring expertise or infrastructure (or are willing to build it up and operate it) and now want to know how to best expand it also for SAP-specific use cases

2. Develop

This CI pipeline is then used by your development teams to qualify their changes – here, changes get pushed to a central source code repository based on Git, which then can automatically triggers a run of the corresponding pipeline via webhook. This pipeline run performs a build and executes automated test cases. The developer then gets informed about issues with the performed changes and can react on those directly. Also, compliance checks, such as for security flaws with used third-party libraries, can be tested as part of the pipeline run.

Example of agile development process

Of course, there are many frameworks available for automated testing – SAP Continuous Integration and Delivery service does provide an opinionated proposal for corresponding frameworks, which then have to be set up accordingly. If you want to use alternative frameworks, SAP Continuous Integration and Delivery allows to extend the predefined pipelines with scripting (for more information, see this blog post).

For the creation of the actual test cases, a step-wise approach is recommended, where you start with first test cases and then evolve by time, by adding additional cases, also based on the issues that come up later and on the latest compliance requirements you might face.

As implied above, the actual development process will slightly differ per development environment. For example, on Cloud Foundry, you might use SAP Business Application Studio (where you would benefit from a direct integration of SAP Continuous Integration and Delivery, allowing to set up and monitor corresponding pipelines directly from the IDE), on Neo SAP Web IDE Full-Stack and on SAP BTP ABAP development tools in Eclipse. Still, the general approach for these environments could be similar, as depicted above.

3. Deliver

When your teams come up with a qualified release candidate, they can either perform a direct deployment out of the pipeline (when all tests are “green”, a direct deployment can be triggered) – or you benefit from a standardized central transport and change management approach, using SAP Cloud Transport Management. The later is our recommended approach for most enterprise environments, where you normally want to have additional control of your production subaccounts.

The actual transport concept is quite similar to what you might be used to from development in on-premise and private cloud environments, with a centrally defined delivery landscape:

With the option to control who is allowed to handle changes where (that is, on which SAP BTP subaccount),
With a central log file for auditing,
With the option to synchronize the propagation of changes from different environments (such as from private cloud/on-premise together with related cloud changes), where change and deployment management capabilities of SAP Cloud ALM or Change Request Management (ChaRM) of SAP Solution Manager could orchestrate SAP Cloud Transport Management service, in addition to orchestrating then also private cloud/on-premise transport mechanisms.

Still, here with the option to combine it on SAP BTP with CI principles, so that your development teams can benefit from tight feedback loops enabled by an automated pipeline, to verify single developer changes - while you still have full control for the propagation of those changes towards your production environment, with the automated hand-over from the pipeline into a controlled, centrally managed and pre-defined delivery landscape. Then to verify the release candidate, potentially consisting of changes from different environments and typically done with a manual confirmation.

Hybrid change management

SAP Cloud Transport Management service can cover more and more content types, such as:

SAP Fiori content (in Neo and Cloud Foundry)
CAP applications (in the form of MTA archives),
Objects from SAP BTP ABAP environment,
Content from SAP Build (SAP Build Process Automation, SAP Build Work Zone, …),
App-specific content types, such as iFlows from SAP Integration Suite and Network Package content from SAP Analytics Cloud
See the full list here

With this, you can establish a standardized transport management process for more and more development use cases around SAP BTP - with the option to integrate all those content types into your central change and delivery management process, such as provided by SAP Cloud ALM.

SAP Cloud Transport Management service is out-of-the-box integrated with SAP Continuous Integration and Delivery - just switch on the corresponding option of the Release stage:

Screenshot from 'Release' stage of SAP Continuous Integration and Delivery

It can also be integrated into other CI stacks via a step of the library from project Piper into third-party pipelines or open APIs (for example, see this blog post on using Azure DevOps with transports).

4. Operate

With SAP Cloud ALM, SAP is providing a central observability platform for all SAP products, including SAP BTP (in interplay with several local SAP-BTP-specific observability capabilities). To operate your apps on SAP BTP, you can therefore use its unified monitoring, alerting and analytics offering based on telemetry data exposed by SAP BTP (and other SAP solutions), to reduce the meantime to detect any issues. SAP is using OpenTelemetry as unified and open instrumentation approach for SAP BTP use cases, allowing you for example to instrument your custom apps for central observability.

Functional overview of SAP Cloud ALM for Operations

For more information, see SAP Cloud ALM for Operations.

To resolve issues, you can then navigate from SAP Cloud ALM to the local expert tools on SAP BTP, to perform a use-case-specific root cause analysis. For example, from an error message in Exception Monitoring of SAP Cloud ALM, you could directly jump to SAP Cloud Logging service to perform a detailed analysis, for which the service stores and visualizes log files, metrics, and traces from your apps running in different SAP BTP environments.

For the execution of corrective actions on SAP BTP, events in SAP Cloud ALM could automatically trigger the execution of corresponding commands on SAP Automation Pilot. This service offers a low-code and no-code automation engine and brings catalogs of automated actions that you can use to compile the best-fitting command for automating your recurring DevOps-related tasks and for remediation of alerts from your individual SAP BTP applications.

Automate recurring ops tasks with SAP Automation Pilot

This way, you can optimize your operation efforts and increase the resilience of your business scenarios.

Summary

SAP BTP offers a low-entry approach to verify the value a more agile development process can bring - also for your SAP applications. It does comprise highly-integrated DevOps services along the complete lifecycle - from CI/CD to development, delivery and operations, with a smooth integration option into SAP Cloud ALM, as SAP's strategic operations and central observability platform. SAP Cloud ALM allows the central operation of your holistic business scenarios spanning several environments. If you should have special needs or third-party frameworks already in use around DevOps, benefit from open APIs of the DevOps services of SAP BTP and of SAP Cloud ALM.

If you want to learn more, check out the information from the DevOps | SAP Community topic page and consider to take the learning journey Discovering DevOps with SAP BTP. If you want to try it out, all DevOps services are part of SAP BTP free tier, so the above setup can be experienced without charge. Otherwise, SAP Build Code is a good starting point as well, as it does comprise most of the DevOps-related SAP BTP services.

Configuring SAP CI/CD pipeline for Deploying ReactJS application in Cloud Foundry

2024-05-07T09:59:07.961000+02:00

In this blog, we will discuss how to integrate SAP CI/CD pipeline for deploying ReactJS application on SAP Cloud Foundry environment.

You will learn,

How to create and build a ReactJS application.
How to configure and run SAP CI/CD Pipeline service.
How to create GitHub Webhook for automatically build, test and deploying the code changes.

Prerequisites

You have an SAP BTP Global or trial account.
Node installed in your system.
You have a GitHub account.

Setting up React Application

step 1: Create your react application using the create-react-app. The create-react-app is an excellent tool which allows you to create and run React project very quickly by wrapping all the required dependencies.

npx create-react-app reactcicd

step 2: To ensure that the application is running as expected, open the terminal and navigate to the application folder and type the below command. The application gets automatically hosted in the default server localhost:3000 and you’ll get the following screen.

npm start

step 3: Now create manifest.yml file for determining the Cloud Foundry app configurations and paste the below contents.

 ---
applications:
- name: your-app-name
path: build/
instances: 1
buildpack: https://github.com/cloudfoundry/staticfile-buildpack.git
memory: 256M

step 4: Build the application using the below command, you will see the build folder getting added to your project.

npm run build

Also create a Staticfile with the following content in the build folder as shown below

step 5: Now create a repository in your GitHub and push the changes. Make sure to remove build folder from the gitignore file since it is added default while creating the react project, we require it for deployment. For more details on how to deploy react application refer this link react-CF-deploy

Enable SAP Continuous integration and Delivery Service

step 1: Login into SAP BTP Cockpit and choose the subaccount to which you want to deploy your application.

step 2: Select Service Marketplace from the side pane and search for Continuous Integration and Delivery service. Click the create button.

step 3: Create popup will appear then choose the plan you want to and click create button at the bottom. Choose View Subscription and wait until the status changes to Subscribed.

step 4: Once the status is changed to subscribed navigate to Security → Role Collections from the left-hand pane. Choose role collection CICD Service Administrator and click edit.

step 5: Navigate to users section click edit then Add a new row in the Users section table, enter your user id, Keep the identity provider as default and click save.

Configure your credentials

step 1: Go to Services → Instances and Subscriptions from the pane. Choose the application icon located next to the Continuous Integration & Delivery subscription. Now we need to add credentials for GitHub, CF and Webhook.

step 2: Let’s first go with GitHub credentials. If your GitHub repository is private, you will need to provide with the necessary credentials to access it. You can skip this in case of public repository.

step 3: In Create Credentials popup make sure you give unique name within the subaccount. Select the type as basic authentication and provide your git credentials. Use personal access token as a password. Then choose create.

step 4: Now repeat the same steps for adding CF credentials. Here you have to provide your SAP BTP cockpit username and password.

step 5: For configuring webhook credentials change the type from Basic Authentication to Webhook Secret. Then generate the webhook secret copy it somewhere safe and finally choose Create.

Add a CI/CD job

step 1: Navigate to the Jobs tab and choose the icon to add a new job. Provide unique name for the job.

step 2: Click on the icon inside the Repository input field. You will get a popup then choose add repository., Enter your git repository clone URL. You can add any name of your choice. It need not to be matched with your repo. Choose your saved credentials for git and webhook.

step 3: For Branch, enter the GitHub branch of your repository from which you want to receive push events. In this example, master. Select Cloud Foundry Environment from the dropdown in the Pipeline field.

step 4: In the BUILD section choose npm as your build tool. For Build Tool Version, select the latest node version.

step 5: Under the Release section, switch on the execution of the Deploy to Cloud Foundry Space. Since we have already given name in the manifest file, we can skip the name field.

Replace the placeholders API Endpoint, Org Name and Space with the values in the Cloud Foundry environment to which you want to deploy. You can get the values from your subaccount overview in the SAP BTP cockpit.

step 6: For Deploy Type, choose standard and select your previously created CF credentials. Leave remaining fields default then finally choose create.

Create a GitHub Webhook

GitHub webhooks allow you to automate CI/CD builds. Whenever you push changes to your GitHub repository, a webhook push event is sent to the service to trigger a build of the connected job.

step 1: To create a webhook in GitHub, you need payload URL. Select your repository and choose Webhook Data from the right pane. You will see a below popup:

step 2: Now sign in into your GitHub account. In your project, go to the Settings tab.

step 3: From the left pane, choose Webhooks then Add webhook. Enter the Payload URL, Content type from the popup and the Secret that you had saved previously. For all other settings, leave the default values and add.

Verify your Build

You have to trigger your job manually the first time after creation.

step 1: In Jobs tab, select your job and choose Run. Verify that a new tile appears in the Builds view. This tile should be marked as running.

step 2: Wait until the job has finished and verify that the build tile is marked as successful.

step 3: Navigate to your space in the SAP BTP cockpit and check the list of installed applications. Now you can see your application got added.

step 4: Select your application and launch it with the application route. You can see the react application deployed.

You have now successfully created a CI/CD pipeline and deployed your ReactJS application to SAP BTP. From now on for every commit you can see the job getting triggered with commit id displayed under builds section.