0% found this document useful (0 votes)
317 views27 pages

Devops With BTP

Uploaded by

amol
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
317 views27 pages

Devops With BTP

Uploaded by

amol
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

Demystifying DevOps with SAP BTP: Part 1 – What is

DevOps?
3 10 1,831

Introduction
In today’s rapidly evolving technology landscape, where agility and efficiency are paramount, DevOps has emerged as a
game-changer. But what exactly is DevOps, and how does it relate to SAP Business Technology Platform (BTP)? If you’re
new to these terms or seeking to understand how they work together, you’ve come to the right place.

Welcome to this blog series to Demystify DevOps with SAP BTP, where we’ll unravel the mysteries of DevOps in simple
terms and show you how it can supercharge your SAP BTP experience.
Whether you’re a seasoned IT professional or just dipping your toes into the world of technology, this blog is your first step
toward mastering the essentials of DevOps and its powerful synergy with SAP BTP.

So, let’s embark on this journey of discovery, where we’ll break down complex concepts into simple, digestible pieces and
explore how DevOps can transform the way you manage your SAP BTP projects.

For ease of reading, I have split the content into two blogs, which are:

1. Demystifying DevOps with SAP BTP: Part 1 – What is DevOps? [Current Blog]

2. Demystifying DevOps with SAP BTP: Part 2 – Navigating SAP BTP DevOps Portfolio

Targeted Readers
This blog series is targeted for people who are completely new to DevOps and need a guidance on how to start their journey
on DevOps with SAP BTP.

In this blog series, we will learn:

What is DevOps?
Why DevOps is so important for all IT organizations, be it small or big.
What are some of the important concepts around DevOps – e.g. DevOps Lifecycle Model, CI/CD etc.
What are the services, tools and frameworks SAP BTP offers to implement DevOps.
How to implement DevOps in SAP BTP along with best practices and guidelines.

Prerequisite
Before understanding DevOps with SAP BTP, you should have a basic idea what SAP BTP is. If you are new to SAP BTP,
please spend 5 minutes reading this blog – Explaining SAP Business Technology Platform (SAP BTP) to a Beginner

Let’s start!

What is DevOps?
Imagine world’s best musicians are playing an orchestra together. Best guitarist, best pianist, best flute player etc. Would you
like to see their performance? I am sure most of you would say, YES.

Now, let’s imagine there is one problem in this orchestra. There is no Conductor. Due to that, every musician is only
focused on his/her performance. There is no synchronization among them. Everyone thinks that only his/her performance is
important and does not care much about others.

Will you still like to see the performance? Of course NOT, because without proper synchronization, the orchestra will be a
mess.

IT organizations had similar problem. Multiple teams working in silos and focused only on their own goal. No proper
collaboration and communication. Everyone thinking that their job is most important and not caring what others are working.
It resulted into lengthy release cycle, quality issues, operational issues etc.

This led to the birth of DevOps.

So, what exactly is DevOps?


There are several definitions of DevOps available in Internet and different perspective to explain it. If you ask what DevOps
is to people from different organizations and different teams, you will be surprised by the variation in the responses.

Some will emphasize on automation tools, some will talk about best practices, some may focus on CI/CD pipelines. All the
points are correct up to some extents. DevOps is something a mix of all of this. However, more than anything, DevOps is
about culture of bringing the teams together and taking down the wall of separation. This change in culture leads to efficient
development and delivery cycle.

Out of several definitions of DevOps, this one I find quite simple yet effective.

DevOps is:

“A culture where people, regardless of title or background,

work together to imagine, develop, deploy, and operate a system”.

— Ken Mugrage

The Problems in a Non-DevOps Environment


To clearly understand DevOps, it’s important to understand how IT organizations used to work before DevOps and what
problems it used to face which DevOps solved.

In any IT organization be it small or large, there are mainly two types of teams – Development and Operation. In a non-
DevOps environment, although both the teams work for same organization, their goals are very different from each other,
they work in isolation and many a times they see each other with disbelief and disagreement.
As shown in image above, development and operation teams often have conflicting goals. While development is too focused
on developing the solution and releasing new features quickly, they tend to ignore how the application will run in real life for
end users. On the other hand, operation team is focused on keeping the application running and stable. Their primary job is to
make sure that end-users don’t face any problem.

In non-DevOps environment, we often see a situation such as an application is throwing error while being deployed to
production environment. The team’s response is like:

Development Team: “It’s not my code that’s causing issues. It’s your machine/system.”

Operation Team: “It’s not my machine/system that’s causing issues. It’s your code.”

Here we have taken example of only two teams – development and operations teams. In reality, there could be more teams
working together such as quality assurance, documentation teams, infrastructure support team, user experience experts
(UX), and product managers (PM).

This results into higher communication costs and create silos that prefers not to see anything beyond their atomic works.
Further if the teams are located at different locations this add into more chaos.

How Does DevOps Solve This Problem?


To solve the problem discussed above, we need to throw over the wall behavior and bring both the team together as shown in
image below.

In DevOps culture, we don’t have separate teams working in silos. All the teams are merged in one single team and it’s
everyone’s responsibility to work throughout the application lifecycle from development to test to release to operation.

In DevOps everyone works together which creates a positive environment and everyone’s goal is aligned with each other.

DevOps enables the teams to handle the issues more effectively without wasting enormous amount of time in creating
tickets or waiting for individual’s hand-off documents from a colleague sitting right next to you.

How Does DevOps Work?


DevOps is not a product which we can buy from some vendor. It’s a methodology, a shift in culture, a collection of tools.
DevOps implementation can be visualized as an infinite loop consists of different phases as shown below.
Plan Phase
In the planning phase, all the teams work together to have a crystal-clear understanding of business requirements and decide
how the solution should be built with what features. In this phase, we also decide criteria for completion of each phase.
DevOps tools and frameworks and services are explored, and right options are chosen.

Develop Phase
Develop phase, also known as Code phase, is where development teams do their magic and build the solution. Source code
repository plays a very important role in this phase where all the developers collaborate and finally have a single source of
truth.

Build Phase
Once developers push their code Build phase starts where code is built into artifacts to deploy on various
server/environments.

Test
After the build phase is done, we have the solution deployed to test systems where several types of testing for example
functional testing, performance testing, security testing, user acceptance testing etc. happens.

Release
After the test phase is done, we have the solution ready to be deployed to production server/environments. In this phase we
release the new solution or a new version of an existing solution into productive environment.

Deploy
In this phase, the solution is deployed into one or more production environment.

Operate
After the deploy phase, solution goes live and get started being used by customers. The operate phase is all about managing
the running solution along with the underlying infrastructure and make sure end-users don’t face any issue.
Monitor
This is one of the most important phases of DevOps. In this phase, DevOps teams have all the monitoring and alerting in
place. It’s important to get the alerts not only there is an issue but also when there is a chance to get issue in future. For
example, high CPU usage, bottlenecks scenarios, disk usage should be properly monitored for proactive maintenance. The
aim at this phase is to achieve system reliability, high availability and zero downtime.

The DevOps infinity loop is not a fixed set of steps. Every organization plans their own DevOps infinity loop to suit their
requirement and culture.

Continuous Integration and Continuous Delivery


(CI/CD) – Backbone of a DevOps Methodology
Continuous Integration and Delivery (CI/CD) is part of DevOps which helps us to automate manual intervention required to
move code from development to production.

Continuous Integration (CI) is the practice where:

Developers merge their code changes to a central repository whenever they finish a logical task.
The merged code is automatically built and tested to make sure that it’s ready for production.

The main goal of Continuous Integration is:

Find and fix the bugs quicker.


Improve software quality.
Reduce the overall time taken to release the solution or a feature.

Continuous Delivery (CD) starts at the end of Continuous Integration (CI). In continuous delivery the code changes are
automatically built, tested, and released to production.

The below image shows the CI/CD in conjunction with DevOps lifecycle.
In simple words:

Continuous Integration and Delivery (CI/CD) Continuous Integration and Delivery (CI/CD)is a set of tools, guidelines and
best practices that enable development teams to deliver solutions more frequently and reliably.

By now, you should have got a clear idea on what DevOps is. In the next blog, we will learn about the services, tools and
frameworks SAP BTP offers to implement DevOps.
Demystifying DevOps with SAP BTP: Part 2 –
Navigating SAP BTP DevOps Portfolio
4 10 3,070

Introduction
This blog is part of the series Demystifying DevOps with SAP BTP.

This blog series aims to Demystify DevOps with SAP BTP for beginners, where we’ll unravel the mysteries of DevOps in
simple terms and show you how it can supercharge your SAP BTP experience.

Whether you’re a seasoned IT professional or just dipping your toes into the world of technology, this blog is your first step
toward mastering the essentials of DevOps and its powerful synergy with SAP BTP.

For ease of reading, I have split the content into two blogs, which are:

1. Demystifying DevOps with SAP BTP: Part 1 – What is DevOps?

2. Demystifying DevOps with SAP BTP: Part 2 – Navigating SAP BTP DevOps Portfolio [Current Blog]

In the previous blog, we learnt about DevOps and some of the important concepts around DevOps – e.g. DevOps Lifecycle
Model, CI/CD etc. Now, let’s explore various services, tools and frameworks SAP BTP offers to implement DevOps. We will
also get a holistic overview on how to implement DevOps in SAP BTP.

Let’s start!

SAP BTP DevOps Portfolio


The true benefit of SAP BTP lies in the rich set of services, tools and frameworks provided by it. Same goes for DevOps
scenario. SAP BTP provides well-organized portfolio for entire DevOps lifecycle. Below image summarizes the complete
SAP BTP DevOps portfolio.
Note: To view the image clearly, you may click here.

Let’s first have a quick look on what services and tools are offered by SAP BTP in each phase of DevOps lifecycle.

SAP BTP DevOps Portfolio – Plan and Setup


In the planning phase, we identify the business requirement, create a project roadmap, decide on overall approach and setup
the infrastructure and landscape for upcoming development, build and test phase. Here is the list of BTP offerings for this
phase.
SAP BTP Landscape Setup
Once you procure SAP BTP global account, one of the first tasks is to setup SAP BTP landscape. Typically, this includes
creating subaccounts for various teams, assigning roles and authorizations, setting quota and entitlements etc.

A typical BTP accounts setup looks like below.


SAP BTP provides a web-based UI called “SAP BTP Cockpit”, to manage the landscape.

You can access SAP BTP cockpit at https://emea.cockpit.btp.cloud.sap/cockpit.

SAP BTP also provides a very powerful command line tools called “SAP BTP Command Line Interface (btp CLI)” to
manage accounts and perform other administrative tasks.

SAP BTP CLI can be downloaded from https://tools.hana.ondemand.com -> CLOUD.

Best Practices for SAP BTP


SAP provides a comprehensive guide for SAP BTP – Best Practices for SAP BTP . This can help you plan and set up your
landscape and your lifecycle management for running applications on SAP BTP.

It contains best practices and recommendations for planning development projects – from setting up the correct
organizational structure to creating an account and security model, to developing and operating applications.

SAP Discovery Center


Another amazing resource we have is SAP Discovery Center. It provides not only a full list and detail of all SAP BTP
services, but also a list of missions which have designed to cover most of the scenario and use-cases.
In Discovery Center mission, we can find all the pieces of puzzles solved together, for example list of all the services
required to integrate SAP S/4HANA with SAP BTP, complete bill of materials for customer, sample architecture diagrams,
step-by-step guide on how to implement the solution etc.

SAP Discovery Center can be accessed at https://discovery-center.cloud.sap

Continuous Integration and Delivery (CI/CD) in SAP


BTP
To simplify the Continuous Integration and Continuous Delivery (CI/CD) setup, SAP BTP provides 3 major offerings.

SAP Continuous Integration and Delivery – An SAP BTP Service, mainly suited for SAP-centric use case, does not
require lots of skills to build a pipeline.

Project “Piper” – An open-source project and libraries that provides templates for pipelines, best suited when you want to
use predefined template and have some flexibility.

Continuous Integration and Delivery Best Practices Guide – Best practices guide if you want to completely own CI/CD
pipeline with full flexibility.

The main difference between these 3 options is in terms of skills required and level of flexibility as shown below.
Let’s have a close look into each of these 3 options.

SAP Continuous Integration and Delivery


SAP Continuous Integration and Delivery is an SAP BTP Service which enables us to configure and run predefined CI/CD
pipelines without need of having individual infrastructure and in-depth knowledge.

It comes with interactive user interface and helps us configure and run an out-of-the-box CI/CD pipeline without much
hassle.

SAP Continuous Integration and Delivery is mainly suited for SAP-centric use cases and supports SAP Fiori, SAP Cloud
Application Programming Model, SAP Integration Suite artifacts and container-based applications. Below image shows a
high-level view of SAP Continuous Integration and Delivery.
Project “Piper”
Project “Piper” is an open-source project which provides a more flexible option than SAP Continuous Integration and
Delivery and yet is not too difficult.

The vision behind Project “Piper” is to enable SAP customers and partners to ease up CI/CD implementation and help them
choose best SAP and non-SAP solutions for it along with predefined templates and libraries. Piper is based on Jenkins.

Below image shows a high-level view of Project “Piper”.

CI/CD Best Practices in SAP BTP


In the Continuous Integration and Delivery Best Practices Guide, we will find instructions on how to easily implement
CI/CD pipelines on any infrastructure.

Unlike SAP Continuous Integration and Delivery or Project “Piper”, we don’t get any ready-made pipelines in this case
rather we get best practices, guidelines, and steps on how to apply principles of CI/CD on SAP specific technologies.

Below image shows a high-level view of CI/CD Best Practices in SAP BTP.
SAP BTP DevOps Portfolio – Develop & Test
Once the planning phase is completed, the blueprint of the development is ready, SAP BTP accounts is configured, landscape
is setup, approach to configure a CI/CD pipeline has been chosen and an initial pipeline has been configured.

Now is the time to Develop the solution. SAP BTP provides a rich set of tools, frameworks and services for this phase, some
of them are:

SAP Business Application studio


SAP Cloud Application Programming Model
Multitarget Application

Let’s have a close look into these.

SAP Business Application Studio


One of the major goals at in any DevOps phase is to minimize the manual effort and reduce the overall time. Setting up the
IDE to onboard a new developer (or in case you change your local system (laptop/desktop) has always been a time-taking
effort. To solve this problem, SAP BTP provides a cloud-ready, browser-based editor, called SAP Business Application
Studio, which gives a desktop-like experience to developers and comes integrated with all the tools and plugins we need for
development and DevOps tasks.

What is SAP Business Application Studio?


SAP Business Application Studio is a service in SAP BTP, which offers a browser-based, integrated development
environment to efficiently build a full-stack cloud solution for SAP BTP.
It is built on an open-source platform called Code-OSS, which is also used by Microsoft VS Code. Hence, it gives a desktop-
like experience and if you have worked with Microsoft VS Code or Eclipse, Business Application Studio seems super
familiar.

SAP Business Application Studio comes integrated with a command line tool, an optimized editor and all the major plugins
we need for SAP BTP development.

How does SAP Business Application Studio play a major role in Develop, Build and Test
Phase

SAP Business Application provides an excellent experience for developing a solution for SAP ecosystem. It extremely
simplifies the developer experience, improves development as well as DevOps operations, and offers better time to market.

Below image illustrates a high-level overview of different components and features of it. Dev Space is like an isolated
development environment containing tailor-made tools and extensions and pre-installed runtimes as per the development
scenario, for example, SAP Fiori, SAP Cloud Application Programming Model, SAP HANA etc.

SAP Cloud Application Programming Model


SAP Cloud Application Programming Model is:

A set of tools, frameworks, languages, and libraries


which provide a golden path for developers
by bringing together SAP technologies like SAP HANA Cloud, Core Data Services, SAP Business Application Studio,
SAP Fiori, and open-source languages/technologies like Java, Node.js or SQLite.

As shown in image below, SAP Cloud Application Programming Model includes a mix of SAP and open-source
technologies.

SAP CAP empowers developers to minimize the overall development effort by helping them to focus on their business logic
and relieving them from tedious repetitive tasks which are common across application e.g., user and security management.

Multitarget Application
A cloud solution usually composed of multiple software modules representing database entities, business logic, backend
services, UI layer etc. For example, a typical solution on SAP BTP usually have a HANA module which contains database
related artifacts (e.g., calculation views), a backend service (e.g., a CAP or Java or Node.js module), an SAP Fiori
Launchpad module and an SAPUI5 module as shown in image below.
There are couple of challenges that we face with such applications having multiple modules.

Maintain dependencies during deployment

One of the main challenges we face with such application is deployment. If all the modules are built separately and have
their corresponding deployment archive file, then we will have to make sure that the dependency is properly maintained
during deployment. For example, if Java module is deployed before SAP HANA module, then it will fail because
dependencies will not be found.

SAP BTP Service Instance Creation

Another challenge is related to the SAP BTP configurations and service instance creation. For example, if the application is
using any SAP BTP services (e.g., Destination service or XSUAA service), then we need to make sure that the service
instances are created before deploying the application. Even if service instances are created, the deployment might fail if the
service instances are not properly mapped to the application.

Lifecycle maintenance

Lifecycle maintenance of individual modules separately is another big issue. If a module has been upgraded, we need to
make sure that in all deployment other modules are using the updated version of each other.

Multitarget application (MTA) helps us to tackle these challenges.

How does Multitarget Application Solve these Problems?


A Multitarget Application (MTA) includes multiple modules of an application together as one single project. These
individual modules although serves as building block of ONE application and share the same development lifecycle.
However, the individual modules of MTA may be written in different languages. For example, an MTA project may contain:

A HANA module where we use HANA dependent language to create calculation views
A backend module implemented using SAP Cloud Programming Model
Business logics implemented in Java or Node.js or other language
SAPUI5 module to implement the UI

These modules can be deployed to different target platforms. For example, HANA module of MTA project may be deployed
to SAP HANA Cloud while the other modules are deployed to SAP BTP, Cloud Foundry.

An MTA project has a file called MTA Descriptor (mta.yaml) that contains a list of all the modules and resources (e.g., SAP
BTP Services or Environment Variables) and their dependency details. The complete metadata of all the modules and
resources are maintained in this mta.yaml file. At the time of deployment, this file is used to automatically create the SAP
BTP service instances, and interdependencies of all the modules and resources are maintained without any manual effort.

As shown in image above, an MTA project contains multiple modules and an MTA descriptor. MTA provides a tool
called Cloud MTA Build Tool which can be used to build the MTA project and generate an MTA archive file called MTAR
(similar to JAR file in case of Java). This MTAR file all the modules, MTA descriptor, resource binaries and configuration
files and can be used to deploy everything in one go.

Continuous Integration (CI)


As we talked about before, using CI/CD makes development faster and better. It automatically tests the new stuff developers
create, so they can fix issues quickly and make improvements, helping the software get better step by step. We can any of the
3 CI/CD option for develop and test phase – SAP Continuous Integration and Delivery, Project “Piper” or Continuous
Integration and Delivery Best Practices Guide.
SAP BTP DevOps Portfolio – Release & Deploy
After the completion of develop, build, and test phase, we have a new or updated solution deployment artifacts which is
ready to be released. SAP Business Technology Platform provides some amazing services for Release and Deploy phase.
Let’s explore them.

Continuous Delivery (CD)


As discussed earlier, Continuous Delivery (CD) is the extension of Continuous Integration (CI) which helps us automatically
build, test, and release the code to production.

Based on CI/CD approach you have taken (discussed earlier), you can add the configuration to deploy code to production
once all previous stages are successfully executed.

For example, in case of SAP Continuous Integration and Delivery service, you can add a release stage for SAP Fiori pipeline
or SAP Cloud Application programming Model pipeline and provide the SAP BTP account details for deployment as shown
below.

SAP Cloud Transport Management


In case of real-life enterprise scenario or complex environments (e.g., a heterogenous landscape including Cloud and On-
Premise), it’s difficult to use CI/CD pipeline for deployment. Rather we need a more standardized change management
service which does not only enable us to deploy the solution to different environment but also provide features like
audit trail of changes, provide reports on who performed the deployment in which productive account etc.

SAP Cloud Transport Management is one stop solution for all deployment and transport related requirement.

So, what exactly is SAP Cloud Transport Management?


SAP Cloud Transport Management is a service in SAP Business Technology Platform that allows us transport solution
deliverables across SAP BTP environments. The service allows us to deploy the solution artifacts (e.g., MTA Archives) along
with its content (e.g., SAP Integration Suite content) and manage the deployment and operation.

SAP Cloud Transport Management service adds transparency to the audit trail of changes so that you get information about
who performed which changes in your production environment, and when they did it.

At the same time, the service enables a separation of concerns: For example, a developer of an application or of SAP Cloud
content artifacts can trigger the transport of changes from within the development environment, while the resulting import
into the test, and production environment is handled by a central operations team.

How does SAP Cloud Transport Management work?


Let’s take an example of an SAP Cloud Application Programming Model based application. The application needs to be
deployed to different subaccounts, for example DEV, TEST, and PROD accounts.
SAP Cloud Transport Management service uses SAP BTP destinations to connect with target end points for deployment.
These destinations have the subaccount details and credentials incorporated within it to connect with a particular subaccount
and deploy the application.

Further, we create something called Transport Nodes which represents source and target subaccounts for deployment.
Transport occurs between these transport nodes. Next, we need a Transport Route to connect transport nodes.

Above image shows a high-level overview of the entire process.

SAP Cloud Transport Management service is also integrated into change and deployment management capabilities of SAP
Cloud ALM.

Integration of CI/CD & SAP Cloud Transport Management


If you aim to harness the advantages of both CI/CD and SAP Cloud Transport Management, you may also explore the
possibility of using both together.

One of the approaches could be as below:

Have a development landscape, based on CI/CD pipeline which is used to verify, build and deploy the solution during
development phase.
Have another delivery landscape, using SAP Cloud Transport Management and use to verify release candidate versions
and deploy to productive environment.
For example, if you are using SAP Continuous Integration and Delivery service, you can let the pipeline directly trigger an
automated upload of your qualified changes to SAP Cloud Transport Management service, as part of the Release stage.

With this combined approach, development teams can start easily, by using an automated pipeline, and come up with results
quickly. However, as soon as they come up with a release candidate, you can regain control of the changes especially
towards the production environment with the then set up hand-over into transport and potentially also change management.

SAP BTP DevOps Portfolio – Operate and Monitor


Operate and Monitor is probably the most important phase of DevOps. The solution has already been released and deployed
to productive landscape and customers are using it. It is utmost important that the solution is available 24/7*365 without any
hiccups.

However, in any cloud infrastructure, there are many components which may cause a downtime for the solution, be it the
platform itself where solution is running, or the database server of the solution, or the underlying technology stack or the
solution itself.

In Operate and Monitor phase, we make sure that we properly monitor the entire landscape and solution stack and get
notification when things go wrong or are about to go wrong. For example, get a notification when solution crashed, get
notification when memory is 80% full because it may crash soon etc.

Let’s check the BTP services and tools which helps us in this phase.

SAP BTP Native Monitoring


SAP BTP offers various native tools for monitoring and operating your application, optionally complemented by third-party
offerings, in case you need deep monitoring of cloud-native applications.

For example, in the Cloud Foundry environment, you can either use SAP BTP Cockpit to access the logs. Alternatively, you
can also use the SAP Application Logging service to access logs from your applications. This service allows to access and
analyze log files stored in the Elastic stack, such as via predefined Kibana dashboards. You may also run the Cloud Foundry
CLI command cf logs to show the recent logs for an application.

To have a full-stack monitoring of BTP apps, you may also use third-party application performance monitoring solutions,
such as Dynatrace.

SAP Alert Notification Service for SAP BTP


The SAP Alert Notification service in SAP BTP allows us to send alerts consistently, whether they come from SAP BTP
runtimes, services, custom solutions, or outside sources. This service uses a single event format for all alerts in BTP, so
there’s no need to deal with different event structures or formats.
How does SAP Alert Notification Service work?
Let’s take an example of an SAP BTP solution which consists of a CAP module, a HANA module, a Fiori module. The
solution is also consuming few BTP services for example, SAP HANA Cloud, SAP Build as shown in image below.

After deploying the solution in a live environment, it’s crucial to monitor all the modules and services closely. Various types
of problems can arise that impact the experience of the end-users. For example:

Performance issue of the application due to high CPU usage


Availability issue of the application due to crash
Functionality issue due to crash of individual application modules
Connectivity issue with SAP HANA Cloud
Technical issue in SAP HANA Cloud, e.g., HANA server goes down.

We must establish a reliable alert system for all situations. This is where the SAP Alert Notification Service becomes
important. It enables us to set up and customize alerts for both the solution itself and the services it relies on, ensuring a
standardized approach. We can configure the SAP Alert Notification service for any of these SAP BTP services or
applications and get the notification to various target system as shown in above image.

SAP Alert Notification service also can be easily integrated with other SAP BTP services. For example, while create a CI/CD
pipeline in SAP Continuous Integration and Delivery, we can configure to get all pipeline notification using SAP Alert
Notification Service.

SAP Automation Pilot


In DevOps, a big part is about making things automatic. Even if we have tools that watch over our systems and send
warnings, we can’t always rely on people to watch and fix things right away. That’s where automation comes in. It helps the
DevOps team by doing some tasks automatically, so they don’t have to. SAP Automation Pilot is like the superhero of
automation for SAP BTP.
SAP Automation Pilot is a service in SAP BTP which enables us to simplify and automate manual tasks so that we minimize
the operational effort to operate and monitor a cloud solution in SAP BTP.

How does SAP Automation Pilot work?

SAP Automation Pilot service can be configured with other SAP BTP services to automate the DevOps tasks. Let’s take an
example scenario. Say, we need to monitor SAP HANA Cloud service. In case the database server is down, DevOps team
needs to restart the database and send the log for further analysis.

To automate this, we may integrate SAP Automation Pilot with SAP Alert Notification Service as shown below.

In case SAP HANA Cloud has an issue, it sends the alert via SAP Alert Notification Service. Upon receiving an alert from
SAP Alert Notification Service, a set of tasks or commands configured in SAP Automation Pilot gets automatically executed.
In this case, a set of commands can be configured to restart the database and send the logs.

Integration of SAP BTP DevOps Services with SAP’s


strategic Operations Platforms
Although, SAP BTP is an important part of SAP ecosystem, there are other solutions as well in SAP ecosystem. SAP
customers may also have hybrid scenarios, for example an application running on SAP BTP may accesses data from SAP
S/4HANA back-end and maybe additional SAP cloud solutions.

Across its complete ecosystem, SAP offers several strategic operations platforms. As many customers have invested in
corresponding processes on these platforms, it’s important that also the SAP BTP tools and cloud services that drive DevOps
can smoothly integrate there, so that you can stick to existing, known processes.

This also allows us to handle hybrid solutions that span beyond SAP BTP.

Let’s take a close look into it.


What are Strategic Operations Platforms from SAP?
SAP offers several strategic operations platforms for Application Life-cycle Management (ALM). They ensure accelerated
implementation and smooth operations of end-to-end business solutions throughout their entire life-cycle.

Major Application Life-cycle Management offerings are:

SAP Cloud ALM


SAP Cloud ALM is an application lifecycle management offering for cloud-centric customers.

It’s intended for customers who use solutions provided by SAP, and who do not want to use their own ALM on-premise
platform to manage those solutions.

SAP Focused Run


SAP Focused Run is designed for businesses that need high-volume system and application monitoring, alerting, and
analytics. It is a powerful solution for service providers who want to host their customers in one central, scalable, safe, and
automated environment.

This ALM product addresses customers with advanced needs in system management, user and integration monitoring, and
configuration and security analytics.

SAP Solution Manager


SAP Solution Manager covers the complete application lifecycle of a customer’s IT solution running on premise, hybrid or in
the cloud. The modern and intelligent IT management platform empowers customer’s IT organizations for the future of
business.

With this highly integrated solution you can implement, maintain, run, and adopt all enterprise solutions – SAP and non-SAP
software – while supporting business innovation, business continuity, and efficient operations.

Integration of BTP DevOps Services into SAP’s Strategic Operations


Platforms
SAP BTP DevOps services can be integrated with SAP’s Strategic Operations Platforms easily.

For example, in SAP Cloud ALM, we can receive alerts sent by SAP Alert Notification.

Or SAP Automation Pilot can be integrated with SAP Cloud ALM to trigger customized or predefined commands on SAP
BTP via SAP Cloud ALM Operation Flows.

SAP Alert Notification service also allows an out-of-the-box integration into SAP Solution Manager and SAP Focused Run.
By now, you should have got a clear idea on DevOps with SAP BTP. If you have any queries, let me know in comment or get
in touch with me at LinkedIn!

To know more about applying DevOps principles efficiently on SAP BTP, you may also refer to:

Efficient DevOps with SAP BTP by Boris Zarske

Discovering DevOps with SAP BTP

You may also have a look into my book “DevOps with SAP”

You might also like