PUBLIC

2020-07-30

SAP Cloud Platform Planning and Lifecycle-

Management Guide
© 2020 SAP SE or an SAP affiliate company. All rights reserved.

THE BEST RUN

Content

1 SAP Cloud Platform Planning and Lifecycle-Management Guide. . . . . . . . . . . . . . . . . . . . . . . . 4

2 Basic Platform Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Commercial Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Members and Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
2.6 Entitlements and Quotas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Capabilities and Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Shared Responsibility Model Between You and SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Getting Started Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Set Up and Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1 Creating a Governance Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Building Teams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Creating an Onboarding Process for Development Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Creating a Knowledge Transfer Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Extending Existing Solutions Using SAP Cloud Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Setting Up Your Account Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Using Subaccounts to Create a Staged Development Environment . . . . . . . . . . . . . . . . . . . . . . 24
Account Model 1: Create a Staged Development Environment Combining the Cloud Foundry
and the Neo Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Account Model 2: Use a Subaccount as a Base Template for Development Projects in the Neo
Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Account Model 3: Use Separate Subaccounts for Data and API Management. . . . . . . . . . . . . . . 30
Account Model 4: Create a Staged Development Environment Using Continuous Integration /
Continuous Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Account Model 5: Create a Staged Development Environment Per Functional Area. . . . . . . . . . . . 31
When to Use Which Account Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
5.4 Setting Up Your Security and Compliance Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Security Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Setting Up Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting Up Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Setting Up Identity Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Complying with Data Protection and Privacy Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Giving Access Rights to Platform Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

SAP Cloud Platform Planning and Lifecycle-Management Guide

2 PUBLIC Content
5.5 Planning Failover on SAP Cloud Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 Develop and Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1 Tools, Programming Models, and Programming Languages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
6.2 Using Multitarget Applications to Manage Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Establishing a Provider/Subscriber Scenario Using Multitenancy. . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Performing UI, Usability, and Unit Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7 Deploy and Deliver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.1 Deploying Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Deploying Simple Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Deploying Multi-Target Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Delivering Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 Implementing Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Deploy Your Application in Two Data Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Keep the Two Applications in Sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Define How a Failover Is Detected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Decide on the Failback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8 Integrate and Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8.1 Integrating Your Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
8.2 Performing Integration Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

9 Go Live and Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

9.1 Going Live. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.2 Monitoring Applications and Services Natively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
9.3 Monitoring a Hybrid Landscape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

10 Improve and Retire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10.1 Improving and Maintaining Your Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.2 Retiring Your Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

SAP Cloud Platform Planning and Lifecycle-Management Guide

Content PUBLIC 3
1 SAP Cloud Platform Planning and
Lifecycle-Management Guide

This document helps you plan and set up your landscape and your lifecycle management for running
applications on SAP Cloud Platform. 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.

Is This Guide for You?

This guide is the starting point for setting up application lifecycle management for your specific use case,
business, and IT landscape. It contains recommendations and best practices that give you an overview of what
you should consider when planning development projects on SAP Cloud Platform. It does not contain specific
task descriptions, but does include links to step-by-step instructions when required.

If you're an architect or a development project lead, this guide helps you plan your organizational setup and
your account and security model. It has an overview of processes, tools, and services that are available for
developing and operating applications.

If you're an administrator or developer, this guide helps you define the correct methodologies and tools for
your development project on SAP Cloud Platform.

If you're an SAP partner and want to embed SAP Cloud Platform into your product portfolio, this guide helps
you to set up SAP Cloud Platform for developing and running production services for your customers.

 Note

This guide is targeted at SAP Cloud Platform customers who want to run and use applications in a
production environment. If you're a trial user, you might still find that some information in this guide is
useful. Check out the following page for more details about trial accounts: Trial Accounts. Please note that
the services available in the trial version differ from the ones in the enterprise version.

How to Use This Guide

If you're new to SAP Cloud Platform:

● SAP Cloud Platform is an open platform-as-a-service (PaaS) that is a vital part of the transition to the
Intelligent Enterprise. SAP Cloud Platform and the SAP HANA Data Management Suite comprise the digital
platform of this Intelligent Enterprise. SAP Cloud Platform is where you develop new applications, extend
existing ones, and is at the center of integration scenarios. For more information about the Intelligent
Enterprise, see https://www.sap.com/products/intelligent-enterprise.html
● Basic Platform Concepts [page 7] – regions, environments, accounts, members, quotas, capabilities
and links to in-depth explanations.

SAP Cloud Platform Planning and Lifecycle-Management Guide

4 PUBLIC SAP Cloud Platform Planning and Lifecycle-Management Guide
● Shared Responsibility Model Between You and SAP [page 15] – your responsibilities and SAP's
responsibilities when it comes to application lifecycle management.
● Getting Started Checklist [page 17] – prerequisites and steps to help you get started with your
development project.

If you're familiar with SAP Cloud Platform:

Plan and set up your SAP Cloud Platform landscape to manage the lifecycle of your cloud applications.

● Improve and Retire [page 74]

● Set Up and Plan [page 19]
● Develop and Build [page 47]
● Deploy and Deliver [page 54]
● Integrate and Test [page 66]
● Go Live and Monitor [page 69]

1. Set Up and Plan [page 19] – build teams, set up your account and security model, and create an
enrollment process for your development projects.
2. Develop and Build [page 47] – find out about the tools and programming languages that are available on
SAP Cloud Platform, and how to use multi-target applications to efficiently manage dependencies.
3. Deploy and Deliver [page 54] – deploy and deliver simple and multi-target applications.

SAP Cloud Platform Planning and Lifecycle-Management Guide

SAP Cloud Platform Planning and Lifecycle-Management Guide PUBLIC 5
4. Integrate and Test [page 66] – test and integrate your application with other solutions.
5. Go Live and Monitor [page 69] – learn what's important for going live and monitoring applications,
services, and hybrid landscapes.
6. Improve and Retire [page 74] – make improvements to your application, perform housekeeping, and
learn about what's important to consider when you want to retire it.

Related Resources

The Learning Journey for the Lifecycle-Management of SAP Cloud Platform Applications is an extensive, well-
structured collection of links to resources such as videos, blog posts, openSAP courses, and additional
documentation.

Also check out the video tutorial from SAP HANA Academy SAP Cloud Platform, Administrators Overview:
Planning and Lifecycle Management

SAP Cloud Platform Planning and Lifecycle-Management Guide

6 PUBLIC SAP Cloud Platform Planning and Lifecycle-Management Guide
2 Basic Platform Concepts

SAP Cloud Platform provides comprehensive application development services and capabilities that let you
build, extend, and integrate business applications in the cloud. It offers three development environments (Neo,
Cloud Foundry and ABAP), multiple different regions (data centers) and a broad choice of programming
languages.

The central point of entry to the SAP Cloud Platform is the cockpit, where you can access your accounts and
applications and manage all activities associated with them.

The figure below depicts the relationship between a global account, its subaccounts, environments, regions,
entitlements, and quotas. It shows the administrative tasks to be considered at the global acccount level as
well as at the subaccount level.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Basic Platform Concepts PUBLIC 7
 SAP Cloud Platform: Overview of Global Accounts and Subaccounts

SAP Cloud Platform Planning and Lifecycle-Management Guide

8 PUBLIC Basic Platform Concepts
 Level Administrative Tasks

Global Account ● For each commercial model (licence type), you get a separate global account.
● Appoint at least one person as administrator. The administrator is responsible
for adding new subaccounts, adding members to a global account, and manag­
ing the entitlements. We recommend that you also appoint at least one substi­
tute administrator. If the main administrator leaves the company or is unavaila­
ble, it's important that you have someone who's available to take over these
tasks.
● You purchase entitlements for each global account (according to your commer­
cial model). The administrator of the global account distributes quotas to the in­
dividual subaccounts.

Subaccount ● Each subaccount runs in exactly one region (data center) and one environment.
● Appoint at least one person as administrator. The administrator is responsible
for adding new members to the subaccount and assigning their business roles.
We recommend that you also appoint at least one substitute administrator. If the
main administrator leaves the company or is unavailable, it's important that you
have someone who's available to take over these tasks.

Also see Accounts [page 11] below.

 Recommendation

We recommend that you use the SAP Cloud Application Programming Model to build applications on SAP
Cloud Platform. It uses data models and service definitions on a conceptual level that are used as inputs for
the data, service, and UI layers. The SAP Cloud Application Programming Model is compatible with any
development environment, but we recommed that you use SAP Web IDE Full-Stack.

Related Information

What Is SAP Cloud Platform

Developing with the SAP Cloud Application Programming Model
Setting Up Your Account Model [page 24]

2.1 Regions

A region represents a physical location (for example, Europe, US East) where applications, data, or services are
hosted.

SAP Cloud Platform is available in many regions around the globe. Depending on the environment you're using,
you can choose between data centers that are hosted by SAP (Neo environment) and those run by our partner
Infrastructure as a Service (IaaS) providers (Cloud Foundry environment): Microsoft Azure, Amazon Web
Services (AWS), and Google Cloud Platform (GCP). A region is chosen at the subaccount level. For each
subaccount, you select exactly one region (that is one data center) and one environment.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Basic Platform Concepts PUBLIC 9
Selecting a Region

When deciding on the location of your Platform as a Service (PaaS), consider existing Software as a Service
(SaaS) and Infrastructure as a Service (IaaS) and try to locate it close to those or even in the same data center.
You can also optimize application performance (response time, latency) by selecting a region that's
geographically close to your users. However, the selection of a region is also dependent on many other factors:
First, check the availability of specific services in the individual regions. Second, ensure that you comply with
security requirements, such as country- or industry-specific data privacy regulations. And third, consider the
location of other cloud offerings you’re using. You might have to locate your solutions in the same data center.

For example, if you want to build an extension for SAP SuccessFactors, it must run in the same region as SAP
SuccessFactors, which runs only in SAP data centers. For a complete overview of the availability of SAP Cloud
Platform services in the different regions, see SAP Cloud Platform Regions and Service Portfolio.

2.2 Environments

Environments constitute the actual platform-as-a-service offering of SAP Cloud Platform that allows for the
development and administration of business applications.

Each environment comes equipped with the tools, technologies, runtimes, and services that you need to build
applications. The availability of different environments allows for greater flexibility in your development
process. Environments are self-sufficient and integrated into the platform at the subaccount level, which
means that each environment can be used on its own without any other environments. In the Cloud Foundry
environment, the subaccount is divided into one or more spaces, which is where application development,
deployment, and maintenance takes place. However, the availability of services is not the same for all
environments. For more information, see SAP Cloud Platform Service Availability Matrix.

SAP offers the following environments:

● Cloud Foundry
● Neo
● ABAP*

Cloud Foundry is the strategic choice for developing new business applications and business services. All
applications that will be available in new third-party Infrastructure as a Service (Iaas) provider data centers, in
partner data centers, or in a private cloud environment are required to run on Cloud Foundry. Also consider the
migration guide for moving from Neo to Cloud Foundry Best Practices for Adapting SAP Cloud Platform
Applications to the Cloud Foundry Enironment to better understand the implications of your environment
choice.

*Within the Cloud Foundry environment, you can create a new space for ABAP development. This is what we
refer to as the ABAP environment, which we recommend for building extensions to ABAP-based products. The
ABAP environment supports the ABAP RESTful programming model that includes SAP Fiori and Core Data
Services (CDS). For more information, see ABAP RESTful Programming Model.

For developers to be able to fully use the ABAP environment for application services and for creating
application UIs in the SAP Web IDE, an administrator has to do a setup of the ABAP environment, as described
in detail in Setup of the ABAP Environment.

SAP Cloud Platform Planning and Lifecycle-Management Guide

10 PUBLIC Basic Platform Concepts
To plan and set up your landscape and lifecycle management in the ABAP environment, see ABAP Lifecycle
Management.

2.3 Commercial Models

SAP Cloud Platform offers two different commercial models.

● Consumption-based commercial model: Your organization receives access to all current and future SAP
Cloud Platform services that are eligible for this model, but only pays for the actual consumption.
For more information, see What Is the Consumption-Based Commercial Model?.
● Subscription-based commercial model: Your organization subscribes only to the SAP Cloud Platform
services that you plan to use. You can then use these services at a fixed cost, irrespective of consumption.
For more information, see What Is the Subscription-Based Commercial Model?.

For information about service availability, prices, and estimators, see the SAP Cloud Platform website . You
can also view the SAP Cloud Platform service catalog via the Discovery Center .

 Note

If you want to use both commercial models, you need two separate global accounts. Each licensing model
requires a specific contract, so you can't combine those models under one agreement.

 Tip

You can switch an existing SAP Cloud Platform contract between the two commercial models at any time.
Keep in mind that not all SAP Cloud Platform services are available in both commercial models. Contact
your SAP account executive or sales representative to discuss feasibility and the terms of transforming
your contract.

2.4 Accounts

The SAP Cloud Platform cockpit is structured according to global accounts and subaccounts.

Global Accounts

A global account is the realization of a contract you made with SAP. It is region-independent, and it is used to
manage subaccounts, members, and quotas. You receive quotas to use platform resources per global account
and then distribute the quotas to the subaccount for actual consumption. There are two types of global
accounts: enterprise accounts (paid) and trial accounts (free). The type determines pricing, conditions of use,
resources, available services, scope of the functionality that you can use, and the level of support you can
receive.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Basic Platform Concepts PUBLIC 11
A global account can contain one or more subaccounts in which you deploy applications, use services, and
manage your subscriptions.

 Note

If you use SaaS (Software as a Service), this is usually displayed in a separate global account.

Subaccounts

Subaccounts let you structure a global account according to your organization’s and project’s requirements
with regard to members, authorizations, and quotas. Subaccounts in a global account are independent from
each other. This is important to consider with respect to security, member management, data management,
data migration, integration, and so on, when you plan your landscape and overall architecture.

Each subaccount is associated with a region, which is the physical location where applications, data, or
services are hosted. It is also associated with one environment. The specific region and environment are
relevant when you deploy applications and access the SAP Cloud Platform cockpit. The region assigned to your
subaccount doesn't have to be directly related to your location. You could be located in the United States, for
example, but operate your subaccount in Europe.

 Note

SAP Cloud Platform accounts are completely independent of user accounts. The global account and its
subacounts in SAP Cloud Platform are the way in which all of your organization's activities in SAP Cloud
Platform are structured in the cockpit.

When you configure your subaccounts, you'll see that the Cloud Foundry environment includes an additional
hierarchical level. In the Neo environment, you perform member, role, and quota management at the
subaccount level; however, in the Cloud Foundry environment, you create spaces within a subaccount. A
subaccount can contain multiple spaces, and member, role, and quota management can be performed at both
the subaccount and the space level.

User Accounts

A user account corresponds to a particular user in the SAP ID service and consists, for example, of a user ID
and a password. User accounts enable users to log on to SAP Cloud Platform and access subaccounts and use
services according to the permissions given to them. A user account can be assigned to one or more global
accounts, subaccounts, and Cloud Foundry spaces.

There are two types of users on SAP Cloud Platform: platform users and business users. Platform users are
usually developers, administrators, or operators who deploy, administer, and troubleshoot applications and
services. They work in the SAP Cloud Platform cockpit or with the command line tools. Business users are
those who use the applications that are deployed to SAP Cloud Platform. For example, a developer who's using
the SAP Web IDE to develop apps, is a business user of SAP Web IDE.

For platform users, the default identity provider is SAP ID Service, but if you want to have subaccount members
from your own user base, you can use your own identity authentication tenant with SAP Cloud Identity

SAP Cloud Platform Planning and Lifecycle-Management Guide

12 PUBLIC Basic Platform Concepts
Authentication Service. For business users, the identity provider can be, for example, SAP Cloud Identity
Authentication Service or your own, such as Active Directory.

For more conceptual information, see Account Model. To learn how to set up your account model, see Setting
Up Your Account Model [page 24].

Related Information

Managing Global Accounts and Subaccounts Using the Cockpit

2.5 Members and Roles

A member is a user who is assigned to an SAP Cloud Platform global account or subaccount. An account
member automatically has the permissions required to use the SAP Cloud Platform functionality within the
scope of the respective accounts and as permitted by their account member roles.

A member of a global account is always an admin of that global account. Adminstrators can add users to global
accounts and subaccounts and assign roles to them as needed. SAP Cloud Platform offers predefined roles, for
example the administrator role for managing subaccount members. Member management is slightly different
in Cloud Foundry and Neo environments. For more information, see User and Member Management.

Related Information

2.6 Entitlements and Quotas

Entitlements represent a specific set of resources that can be used within a global account.

A quota represents the numeric quantity that defines the maximum allowed consumption of that resource.
Entitlements and quotas are managed at the global account level, distributed to subaccounts, and consumed
by the subaccounts. When quota is freed at the subaccount level, it becomes available again at the global
account level.

Related Information

Managing Entitlements and Quotas Using the Cockpit

Configure Entitlements and Quotas for Subaccounts

SAP Cloud Platform Planning and Lifecycle-Management Guide

Basic Platform Concepts PUBLIC 13
2.7 Capabilities and Services

SAP Cloud Platform provides a set of capabilities that group together different technical components, like
services, tools, and runtimes. For example, the Analytics capability includes three services that allow you to
embed advanced analytics into your solutions to gain real-time insights. Or the DevOps capability, which
includes about a dozen services that help increase developer productivity by simplifying development and
operations of your solution and the interplay of involved teams. For a complete overview of capabilities, see
SAP Cloud Platform Capabilities .

Services enable, facilitate, or accelerate the development of business applications and other platform services
on SAP Cloud Platform. For a detailed list of services and information about their regional availability, see
Availability of SAP Cloud Platform Services.

Related Information

What Is SAP Cloud Platform

Glossary
Shared Responsibility Model Between You and SAP [page 15]
Getting Started Checklist [page 17]

SAP Cloud Platform Planning and Lifecycle-Management Guide

14 PUBLIC Basic Platform Concepts
3 Shared Responsibility Model Between You
and SAP

A shared responsibility model applies to SAP Cloud Platform: SAP manages the platform, whereas you develop
and manage applications.

Shared Responsibilities Between You and SAP

SAP's Responsibilities

SAP is responsible for operating the overall infrastructure of SAP Cloud Platform, including monitoring,
patching, applying software updates, and maintaining the infrastructure and underlying operating systems.
SAP is also responsible for technical operations such as monitoring SAP Cloud Platform services, providing
health check services, managing capacity, performing troubleshooting and housekeeping, implementing
regular updates, and managing incidents.

SAP creates your global account and provides you with the resources and services you've purchased.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Shared Responsibility Model Between You and SAP PUBLIC 15
Finally, SAP is responsible for SAP HANA database platform operations, including hardware configuration
management, backup and recovery, space management, security management, and providing SAP HANA data
center service point revisions as self-service update options.

Your Responsibilities

As an SAP Cloud Platform customer, you must manage your global account and any subaccounts; that is, you
are responsible for coming up with an account concept, creating and configuring your subaccounts based on
the requirements of your development projects, and for distributing resources and services accordingly.

In addition, it's up to you to develop and operate applications. You are responsible for creating and deploying
applications, managing application-specifc role assignments, integrating with existing systems and
applications, monitoring and implementing health checks, and performing housekeeping, troubleshooting, and
regular updates for your applications that are running on SAP Cloud Platform.

If you're using the SAP HANA service, you're required to trigger updates of SAP HANA revisions when
applicable, using a self-service from SAP Cloud Platform.

For a more granular overview of the responsibilities for operating SAP Cloud Platform, see Operating Model in
the Cloud Foundry Environment.

Related Information

Getting Started Checklist [page 17]

SAP Cloud Platform Planning and Lifecycle-Management Guide

16 PUBLIC Shared Responsibility Model Between You and SAP
4 Getting Started Checklist

If you're new to SAP Cloud Platform, this checklist helps you ensure the implementation readiness of your
development projects.

More Information and Troubleshoot­

Task Step ing

Fulfill prerequisites 1. Get familiar with the use cases SAP Cloud Platform SAP Cloud Platform - Learning Journey
covers with its service portfolio, understand basic plat­
Basic Platform Concepts [page 7]
form concepts and your responsibilities throughout
the implementation project. Developing with the SAP Cloud Applica­
tion Programming Model

Shared Responsibility Model Between

You and SAP [page 15]

2. Identify one or more initial development projects or SAP Cloud Platform Scenarios
a pilot project.

3. Decide which commercial model (subscription- or SAP Cloud Platform Pricing

consumption-based) best suits your needs and sign
SAP Cloud Platform Learning Journey
contracts for SAP Cloud Platform.

4. Review Service Level Agreement. SAP Cloud Platform Service Descrip­

tion Guide

SAP Cloud Trust Center

5. Receive onboarding e-mail with a link to the cockpit. If you don't receive this email, for some
reason, or have inadvertently deleted it,
simply access your SAP Cloud Platform
cockpit using the region-specific link
Regions. SAP has activated your ac­
count prior to sending you this e-mail.

6. Obtain a customer number (required for support Check with your system administrator if
tickets). you do not know your customer num­
ber.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Getting Started Checklist PUBLIC 17
 More Information and Troubleshoot­
Task Step ing

7. If you use SAP ID Service, create SAP user IDs (S- Contact a user administrator in your
users) for all technical users who need access to your company. If you don't want to use SAP
SAP Cloud Platform accounts. ID Service, configure your subaccounts
to use a different identity provider.

 Note
SAP cannot assign additional S- or
P-user IDs on your company's be­
half.

8. Build a Cloud Administration and a Cloud Develop­ Building Teams [page 19]
ment Team (and optionally, a Cloud Center of Excel­
lence).

Get started 9. Set up your account model. Setting Up Your Account Model [page
24]

10. Set up your security model. Setting Up Your Security and Compli­
ance Model [page 36]

11. Create an enrollment process for development Creating an Onboarding Process for De­
projects. velopment Projects [page 21]

Implement 12. Develop, integrate, deploy, and transport your ap­ Develop and Build [page 47]

plication. Deploy and Deliver [page 54]

13. Test and evaluate your application. Integrate and Test [page 66]

14. Go live with your application. Go Live and Monitor [page 69]

15. Make improvements to your application, or retire it Improve and Retire [page 74]
if it's no longer needed.

SAP Cloud Platform Planning and Lifecycle-Management Guide

18 PUBLIC Getting Started Checklist
5 Set Up and Plan

Before you begin developing your applications, make sure your organizational and landscape setup is
appropriate for managing their lifecycles, and consider failover to prevent breakdowns.

● Creating a Governance Model [page 19]

● Setting Up Your Account Model [page 24]
● Setting Up Your Security and Compliance Model [page 36]
● Planning Failover on SAP Cloud Platform [page 44]

5.1 Creating a Governance Model

One of the first and most important steps of your journey to the cloud is to establish an appropriate
organizational setup and corresponding governance model. A clear and well-thought-out organizational setup
makes it easier for your employees to adopt agile processes.

We also recommend that, before you begin your development project, you create an onboarding process and a
knowledge transfer process.

For example:

● Define team setups (including IT support roles and responsibilities)

● Create an onboarding process for development projects
● Create a knowledge transfer process for the involved teams
● Define support processes, operations documentation and involved tools
● Define activities to ramp up resources and implement changes (support processes, tools, documentation)
● Clarify help desk processes and incident and change management

Related Information

Building Teams [page 19]

Creating an Onboarding Process for Development Projects [page 21]
Creating a Knowledge Transfer Process [page 22]

5.1.1 Building Teams

We recommend that you set up two teams: A Cloud Development Team, which builds applications, and a
Cloud Administration Team, which is responsible for any account operations and the build infrastructure. In

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 19
addition, you may want to consider implementing a Center of Excellence to drive cloud adoption throughout
your organization.

5.1.1.1 Cloud Administration Team / Center of Excellence

The Cloud Administration Team defines, sets up, and maintains your cloud landscape.

The responsibility of this team is to operate and ensure a stable and secure cloud landscape, and to enable
other developers to build cloud applications. The members of this team are highly qualified experts who have
development experience and experience with setting up and running a build infrastructure for continuous
deployments and integration scenarios.

This team can support your development teams by providing knowledge and defining guidelines that match
your company’s quality and security requirements. The Cloud Administration Team should generally not be
responsible for the lifecycle management of specific applications; the Cloud Development Team should take
responsibility for this task.

The Cloud Administration Team can also operate as a Center of Excellence (CoE), driving cloud adoption,
migration, and operation throughout your organization by providing thought leadership and guidance for
resolving roadblocks. The CoE is also responsible for identifying, evaluating, and implementing use cases for
the SAP Cloud Platform.

We recommend that the Cloud Administration Team / Center of Excellence (CoE) create the following
documents:

● Onboarding Document [page 21]

● Security Document [page 21]
● Services Catalog [page 22]

5.1.1.2 Cloud Development Team

The Cloud Development Team is responsible for developing and operating the applications that run on SAP
Cloud Platform.

Teams that develop on-premise applications often follow a Build-Run setup. The Build team develops the
application, then passes it to the Run team, which operates and maintains it. However, this setup is not optimal
in a cloud application development environment.

We recommend that Cloud Development Teams follow a DevOps approach, which means that the team both
develops and operates applications. The team should maintain applications regularly after Go Live, and fix any
issues. For example, if the team develops an SAPUI5 front end, they should verify at least every six months that
the UI controls used are still supported by the latest SAPUI5 version. This doesn't require much effort, but does
need to be checked to ensure the application continues running properly.

SAP Cloud Platform Planning and Lifecycle-Management Guide

20 PUBLIC Set Up and Plan
5.1.2 Creating an Onboarding Process for Development
Projects

If you're planning on starting multiple development projects on SAP Cloud Platform, we recommend that you
set up an onboarding process to ensure that new projects are tracked and documented properly, compliant
with the security standards and guidelines you define.

Every new application that is managed and tracked by a Cloud Administration Team should have an onboarding
process. Owners of new applications should fill out an onboarding document and a security template.
Maintaining administrative information about all applications in one central place helps the Cloud
Administration Team to keep an overview about all projects, applications, and responsibilities. It also allows the
team to inform all project managers and developers about changes and updates to the cloud landscape.

Onboarding Document

An onboarding document ensures that a new application is properly onboarded and documented. Onboarding
can happen via e-mail, a ticketing system, or any other tool used in your company that you find suitable. The
following provides an example of the information you might want to include:

● Organization or department the application is being developed in

● Application name
● Technical application name (only alphabetic characters, no spaces)
● Business case and application description
● Planned Go-Live date
● Application owners
● Colleagues who need access to the development subaccount (if you've set up a staged development
environment)
● Whether the application will be accessible by external users
● End-to-end data flow description, including connections to back-end systems
● Programming languages and technologies that will be used
● URL of the Git repository, if applicable
● Test strategy

After the document is verified, application owners and developers should get access to the development
subaccount to start developing. Make sure that all developers understand that on the development
subaccount, all applications can be stopped, and code can be deleted by users at any time without notice. We
recommend that the Cloud Development Team keeps the relevant code and files in a repository outside of SAP
Cloud Platform to avoid that applications and artifacts like git repositories (containing code) are deleted in the
subaccount by accident.

Security Document

We recommend you provide a template for the security document that is filled out for every new application,
which is then approved by security experts in your company before you start developing. The template should
ask for detailed information, such as:

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 21
● Name of the application owners
● Scenario description and business need
● User groups, data classification, and confidentiality and integrity requirements
● Compliance with any applicable security policies
● End-to-end data flow
● Data storage
● Overview of all connected cloud and on-premise systems, used protocols, and ports
● Authentication and high-level authorization concept
● Auditing concept, logging, traceability

Services Catalog

If you're going to onboard multiple development projects, we recommend that you set up a services catalog
that summarizes all services offered by the Cloud Administration Team, especially when access to the testing
and production subaccounts are restricted for developers. This facilitates and speeds up the collaboration
between the Cloud Administration and the Cloud Development Teams. Examples of such services include the
following:

● Adding or managing destinations

● Creating build plans
● Restarting applications
● Providing read access to the testing or production subaccounts
● Creating database schemas and giving access to a specific schema

All services should be offered as templates in a service catalog that developers can fill out, for example, in a
ticketing system.

We recommend that the Cloud Administration Team makes the consumption of services as easy as possible, or
even automates it using SAP Cloud Platform APIs. The team may want to, for example, write scripts for
database schema creation and access management. The Lifecycle Management API lets the Cloud
Development Team restart an application in the production subaccount without having access to it and without
affecting any other application. For more information, see the Lifecycle Management API .

Related Information

API Documentation

5.1.3 Creating a Knowledge Transfer Process

Carefully plan for sufficient enablement of all stakeholders, and ensure that the knowledge gained throughout
your application lifecycle is shared with others.

Before you start your development project, we recommend that you do the following:

SAP Cloud Platform Planning and Lifecycle-Management Guide

22 PUBLIC Set Up and Plan
 ● Ensure that the Cloud Administration Team, which should consist of skilled and experienced technology
experts, documents and shares their knowledge with existing and new colleagues.
● Set up training and enablement sessions to get everyone on board.
● Create and promote a dedicated communication channel, such as SAP Jam Collaboration, to share lessons
learned or provide other developers with guidance and recommendations. For more information, see SAP
Jam Collaboration .

5.2 Extending Existing Solutions Using SAP Cloud Platform

SAP Cloud Platform offers services, tools, and capabilities to develop, extend, or integrate business
applications in the cloud. You can implement additional workflows or modules on top of existing solutions,
which lets you benefit from out-of-the-box security, inherited data access governance, user interface
embedding, and so on.

The following resources are available for your extension scenarios. The links to various documents guide you
through the configuration tasks that you need to perform to enable the SAP Cloud Platform for developing
extension applications for your existing SAP solutions, and the learning journeys are collections of links to
additional resources.

● SAP S/4HANA Cloud

○ Extending SAP S/4HANA Cloud
○ Integration of SAP Cloud Platform ABAP Environment with SAP S/4HANA Cloud: Introduction
○ Learning Journey: SAP S/4HANA Cloud Extensions on SAP Cloud Platform
● SAP S/4HANA
○ SAP S/4HANA Cloud Extensions on SAP Cloud Platform
● SAP Cloud for Customer
○ Extending SAP Cloud for Customer
○ Learning Journey: SAP Cloud for Customer Extensions on SAP Cloud Platform
● SAP SuccessFactors
○ Extending SAP SuccessFactors
○ Learning Journey: SAP SuccessFactors Extensions on SAP Cloud Platform
● SAP Ariba
○ Extending SAP Ariba

Related Information

Extensions

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 23
5.3 Setting Up Your Account Model

The hierarchical structure between global accounts and subaccounts lets you define an account model that
accurately fits your business and development needs.

Once you've signed your commercial contract with SAP, you'll receive access information and credentials for
your global account. Use this account to manage the resources and entitlements for your development
projects; it's the realization of your commercial contract with SAP. You'll also receive a bill for all resources used
in your global account. If you require multiple global accounts for compliance or other reasons, you'll need to
sign a dedicated contract for each one.

To develop and deploy applications, to use services, and to subscribe to business applications provided by SAP,
a global account member must create subaccounts and distribute the resources that are assigned to your
global account across these subaccounts. Subaccounts let you structure a global account according to the
requirements of your organization and projects with regards to members, authorizations, and quotas.

 Tip

Check out the video tutorial from SAP HANA Academy about setting up the account model: SAP Cloud
Platform, Administrators Overview: Account Model .

As you've seen in the Basic Platform Concepts [page 7] section, within your (region-independent) global
account, you can create any number of subaccounts in any environment and region, depending on your
contract. For example, if you're located in the US, you can create subaccounts in different regions, such as
Europe (Rot) or Japan (Tokyo), to support the customers who are using your applications. Subaccounts are
independent from each other, which means that each subaccount allows for dedicated quota and member
management. You can configure a dedicated identity provider for business users in each subaccount. Each
subaccount is associated with exactly one environment, Cloud Foundry or Neo, for example.

Related Information

Account Model
Managing Global Accounts and Subaccounts Using the Cockpit
Create a Subaccount [Feature Set A]

5.3.1 Using Subaccounts to Create a Staged Development

Environment

The number of subaccounts you create, and for which purpose, depends on your organizational setup and your
use case.

 Recommendation

In general, we recommend that you create at least three subaccounts to set up a staged development
environment, including one subaccount each for development, testing, and production.

SAP Cloud Platform Planning and Lifecycle-Management Guide

24 PUBLIC Set Up and Plan
 ● Development – for development purposes and for testing individual increments in the cloud.
● Testing – for integration testing and testing in production-like environment prior to making it publicly
available, to ensure quality delivery. In highly DevOps-driven companies, this subaccount is also used for
production applications, as testing occurs in the development subaccount.
● Production – for production applications.

Considerations For Creating Your Account Model

Although we recommend that you use subaccounts to create a staged development environment, you can also
create subaccounts to do the following:

● Separate development scenarios and projects to allow for easier configuration, for example, with regard to
access restrictions.
● Separate the work of different development teams.
● Set up different trust configurations between your subaccounts and your identity providers; for example,
using the SAP Cloud Platform Identity Authentication service as a user store in one subaccount and an
internal identity provider in another one.
● Restrict access to applications and their administration, for example, by setting up "high-security"
subaccounts with restricted access, or creating separate subaccounts to connect with your different back-
end systems.
● Share an SAP HANA database in one subaccount with similar projects managed in other subaccounts. You
can currently do this only in the Neo environment.

 Recommendation

Depending on the degree of centralization of your IT department, we recommend the following:

● If you're a highly DevOps-driven company and if your IT department is decentralized, create a separate
subaccount per development project and application so that your developers and teams can work
more independently and effectively.
● If your IT department is highly centralized, start with only one subaccount for each of the three stages
and ensure your IT team can provide sufficient support to all the developers who work in the three
subaccounts. You can consider creating separate subaccounts for development projects with special
needs or larger projects.

Keep in mind the following considerations when creating different subaccounts:

● You can monitor the consumption of resources in your global account only per subaccount, not per
application. To monitor the resources consumed by a specific project, department, or application, create a
dedicated subaccount for it.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 25
● When creating a new subaccount, you can clone the configuration settings from an existing subaccount in
the Neo environment, but you'll still need to manually adjust some settings, which means more work for
your Cloud Administration Team.
● Connections to on-premise systems must be made separately for each subaccount, which also means
more work for your Cloud Administration Team. However, it might be easier for you to shut down all
integration paths for a project if you've maintained them all in one subaccount. This also lets you control
which application uses which on-premise connections.
● When choosing a region for your subaccount, consider that the region should be close to your customers'
geographic location to reduce network latency. In extension scenarios, choose a region that's close to the
systems involved. Also, consider any legal requirements and the load distribution when choosing a region.

For information about creating subaccounts in the SAP Cloud Platform cockpit, see Create a Subaccount
[Feature Set A].

Special Considerations for the Cloud Foundry Environment

When you enable the Cloud Foundry environment in one of your subaccounts, the system automatically
creates a Cloud Foundry org for you. The subaccount and the org have a 1:1 relationship and the same
navigation level in the cockpit (even though they may have different names). You can create spaces within that
Cloud Foundry org. Spaces let you further break down your account model and use services and functions in
the Cloud Foundry environment. For more information about Cloud Foundry orgs and spaces, see the Cloud
Foundry documentation at https://docs.cloudfoundry.org/concepts/roles.html

You can use both subaccounts and spaces to develop applications and to use services. You must therefore
decide, for example, whether to create different subaccounts or spaces within one subaccount to set up a
staged development environment.

In general, we recommend that you create different subaccounts for a staged development environment, as
shown below. This allows for dedicated user management between the different stages, as well as for dedicated
data management in elastic services like Internet of Things Application Enablement. You can then create
dedicated spaces for applications or projects within these subaccounts if you don't need a dedicated user
management for these applications and projects.

To decide whether to create separate subaccounts or separate spaces within the same subaccount, consider
the different configuration possibilities, available for subaccounts and spaces:

SAP Cloud Platform Planning and Lifecycle-Management Guide

26 PUBLIC Set Up and Plan
 Configuration Subaccount Space

Configure your own group of business Yes No

users

Configure a Cloud Connector tunnel Yes No

Configure roles and trust Yes No

Assign quotas Yes (mandatory) Yes

Cross-consume SAP HANA tenant da­ No Possible to share SAP HANA tenant da­
tabases tabases with other spaces

See Create Spaces.

Example Account Models

Consider the following account scenarios for creating your own account model:

● Account Model 1: Create a Staged Development Environment Combining the Cloud Foundry and the Neo
Environment [page 27]
● Account Model 2: Use a Subaccount as a Base Template for Development Projects in the Neo Environment
[page 29]
● Account Model 3: Use Separate Subaccounts for Data and API Management [page 30]
● Account Model 4: Create a Staged Development Environment Using Continuous Integration / Continuous
Delivery [page 31]

5.3.2 Account Model 1: Create a Staged Development

Environment Combining the Cloud Foundry and the
Neo Environment

In this scenario, the IT department of an organization creates a staged development environment by creating
three subaccounts in both the Cloud Foundry and the Neo environment.

Dedicated spaces for specific applications or projects are created in each of the subaccounts in the Cloud
Foundry environment.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 27
If you need to deploy an application to a space within the Cloud Foundry environment, you can use SAP Web
IDE Full-Stack, which runs in a subaccount in the Neo environment. In this case, we recommend that you create
three subaccounts in the Cloud Foundry environment to separate the three different development stages. In
addition, create one subaccount in the Neo environment that you use for developing using the SAP Web IDE
Full-Stack. You can connect that subaccount with your Development and Testing subaccounts in the Cloud
Foundry environment by configuring trust and destinations.

 Note

This setup works only if you use the same identity provider for the subaccounts in the Cloud Foundry and in
the Neo environments. For more information, see Principal Propagation from Cloud Foundry to Neo

 Tip

Check out the Business Application Studio, which is runs in the Cloud Foundry environment and this makes
a Neo subaccount unnecessary: .

Related Information

Principal Propagation
Configure Trust
Configure Destinations from the Cockpit
When to Use Which Account Model [page 32]

SAP Cloud Platform Planning and Lifecycle-Management Guide

28 PUBLIC Set Up and Plan
5.3.3 Account Model 2: Use a Subaccount as a Base Template
for Development Projects in the Neo Environment

In this scenario, the IT department creates one subaccount that serves as a base template. If new subaccounts
for a development project are required, the IT department clones the base template, thereby copying its
configuration settings to the new subaccounts.

The owners of the development projects are responsible for application lifecycle management. As shown
below, all new subaccounts are cloned from the base template, regardless of whether a project requires three
subaccounts for each development stage, or whether only one DEV subaccount is needed (for example, for a
proof of concept).

This account setup is especially well suited for organizations that rely heavily on a DevOps methodology with
independent development projects.

 Note

This account setup might require a high level of maintenance and governance efforts. For instance, it is
important that the responsible teams of each project landscape stay tightly aligned. Since each team has
full access to their subaccounts, it is important to define and follow guidelines for all projects, such as
security requirements, access guidelines, governance processes, and so on.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 29
5.3.4 Account Model 3: Use Separate Subaccounts for Data
and API Management

In this scenario, the IT department of an organization manages separate subaccounts for data isolation and for
reuse of API management and connectivity. The department also creates dedicated (staged) subaccounts for
development projects.

Access to back-end systems is managed centrally by the IT department via API management in three
dedicated subaccounts. Every new development project uses a separate subaccount that consumes the APIs
that are managed in these subaccounts via destinations. In addition, SAP HANA databases are deployed in two
dedicated subaccounts – Development/Testing and Production – and shared across different subaccounts.

The advantages of this model are that it allows you to scale quickly while ensuring that connections to your
back-end systems are always established via APIs; it also keeps costs low (due to the sharing of the SAP HANA
databases across subaccounts).

In the Cloud Foundry environment, you can either create three dedicated spaces (one each for Development,
Testing, and Production) within one subaccount that includes the API configurations, or you can create one
subaccount each for Development, Testing, and Production. For more information on special considerations in
the Cloud Foundry environment, see Using Subaccounts to Create a Staged Development Environment [page
24].

SAP Cloud Platform Planning and Lifecycle-Management Guide

30 PUBLIC Set Up and Plan
5.3.5 Account Model 4: Create a Staged Development
Environment Using Continuous Integration /
Continuous Delivery

In this account model, a dedicated Development subaccount is created for each development project.
Applications that are developed in these subaccounts are consolidated, tested, and published in one single
Testing and Production subaccount.

This account model is especially well suited for companies with a focus on continuous integration and
continuous delivery, as it lets every development project decide separately about their environment. A central
Testing and Production subaccount ensures a high degree of governance, data security, and compliance.

In the Cloud Foundry environment, consider creating separate Development spaces in one subaccount and a
dedicated Testing and Production space in a Testing and Production subaccount, respectively.

5.3.6 Account Model 5: Create a Staged Development

Environment Per Functional Area

In this scenario, the IT department creates separate Dev, Test, and Prod subaccounts for each functional area:
In our example, HR, IT, and Sales each get their own subaccounts for development, test, and production.

With a separate account landscape per functional area, you can use multiple instances of the same SaaS
subscription (e.g. in case you need to keep data or user access separated). For example, HR subaccounts
would use an internal identity provider, whereas for public or external scenarios, an external identity provider
could be used.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 31
Using this account model, you can distribute the subaccount administration to several teams, which allows for
easy scaling as the number of cloud projects grows while still having a manageable amount of maintenance
and governance efforts (unlike with account model 2). If possible, consider assigning responsible colleagues to
each group of three subaccounts, i.e. to each account landscape.

A SaaS application can only be used once within a subaccount, so if each functional area has their own
subaccounts (for dev, test, and prod), you won't encounter limitations as to using the same SaaS offering in
different projects.

This account model can also be combined with the structuring approach of account model 2. In addition to the
structuring according to functional areas, you can create separate dev, test, and prod subaccounts for large
projects that use different components or services and have a completely separated support process and
operations model than your other projects.

Related Information

When to Use Which Account Model [page 32]

5.3.7 When to Use Which Account Model

Determine which account model is the most appropriate for your needs.

The tables below provide requirements with regards to project and team setup as well as the services and
resources involved. You can compare them against your own requirements and see which account model most
closely matches. Please remember that the four account models are a result of a best-practice approach. They

SAP Cloud Platform Planning and Lifecycle-Management Guide

32 PUBLIC Set Up and Plan
are not mutually exclusive and you may want to use a combination of approaches, if, for example, you have
different projects with different requirements.

Project Setup

Your Require­
ments ... Account Model 1 Account Model 2 Account Model 3 Account Model 4 Account Model 5

You follow the De­ X (X) (X)

vOps methodology
and have many au­
tonomous
projects.

You need different X (X) (X) (X) X

stages for your

project or sce­
nario.

You have a highly X X

centralized project
landscape with
many projects us­
ing the same tech­
nologies (for ex­
ample, Fiori devel­
opment for a Fiori
launchpad).

You want to share X X (X) (X)

more expensive re­

sources (HANA
databases, Inte­
gration service
tenants) with mul­
tiple projects.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 33
Team Setup

Your Require­ Account Account Account Account Model

ments ... Model 1 Model 2 Model 3 4 Account Model 5

You have a large X X (X)

number of develop­
ers, with several dif­
ferent project ad­
mins responsible
for them.

You have many dif­ X

ferent development
teams, but only one
single production
environment for
which the teams de­
velop applications.

You have different X X X X

development
teams, each of
which works inde­
pendently, meaning
they should not be
able to, for example,
accidentally break
the other team's
developments.

Your development X X X X

teams on SAP
Cloud Platform are
coming from differ-
ent organizational
units in different
geographic loca­
tions and you want
to track them sepa­
rately.

You want to ensure X X X

that no developer or
project admin can
assign privileges to
themselves for
services or applica­
tions.

SAP Cloud Platform Planning and Lifecycle-Management Guide

34 PUBLIC Set Up and Plan
 Your Require­ Account Account Account Account Model
ments ... Model 1 Model 2 Model 3 4 Account Model 5

You have stringent X X (X) (X)

security require­
ments. For example,
you don't want all
developers to have
access to all Git re­
positories.

You want to allow X (X) (X)

access to on-prem­
ise systems via
Cloud Connector
only for selected
projects, while re­
stricting it for the
applications of
other projects.

Services and Resources

Your Require­
ments ... Account Model 1 Account Model 2 Account Model 3 Account Model 4 Account Model 5

You want to assign X X (X)

quotas to different
projects and
tightly control that
the projects don't
exceed their re­
sources.

You want to allow X (X) (X)

the usage of a par­

ticular service only
for selected
projects.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 35
Your Require­
ments ... Account Model 1 Account Model 2 Account Model 3 Account Model 4 Account Model 5

You want to easily X X (X) X

monitor which
services are con­
sumed by which
projects. For ex­
ample, you might
want to do internal
billing based on
the resource con­
sumption of the in­
dividual projects.

You want to re­ X

strict the exposure

of on-premise sys­
tems through cen­
tral middleware
(Integration serv­
ice) or an API layer
(API Manage­
ment).

● X: Account model meets this requirement.

● (X): Account model meets this requirement with restrictions.

5.4 Setting Up Your Security and Compliance Model

Applications on SAP Cloud Platform are exposed to the Internet and should therefore fulfill the highest possible
security requirements to prevent unauthorized access.

5.4.1 Security Concepts

The level of security you implement may vary depending on your use case and your company's general security
requirements. However, there are a few best practices that we recommend, regardless of your implementation.

General SAP Cloud Platform and Network Security Aspects

The SAP Cloud Platform landscape runs in an isolated network that is protected from the outside by firewalls, a
DMZ, and communication proxies for all inbound and outbound communication. All user access is protected

SAP Cloud Platform Planning and Lifecycle-Management Guide

36 PUBLIC Set Up and Plan
with transport layer security (TLS). Use SAP Cloud Platform Connectivity to enable your SAP Cloud Platform
applications to securely access remote services on the Internet or in your on-premise systems. For connecting
to Internet services, we recommend that you use APIs with destinations, and for cloud-to-on-premise
scenarios, we recommend that you use destinations and the Cloud Connector. If you use destinations, you
achieve a separation between the application and the configuration, which means it's easier to make
configuration changes. And you can use the destinations to store credentials and certificates.

The Cloud Connector is a lightweight on-premise agent that establishes a secure tunnel for connecting your
cloud applications to on-premise systems. The Cloud Connector acts as a reverse invoke between the on-
premise network and SAP Cloud Platform. That means you don't need to open in-bound ports in the firewall for
external access from the cloud. The Cloud Connector provides a fine-granular access control mechanism,
supports multiple protocols, such as RFC and HTTP, and can forward the cloud user identity using principal
propagation. It enables users to log on to on-premise systems without logging in again by securely forwarding
their logged-on identity from the cloud. You can configure the Cloud Connector directly from the subaccount in
the SAP Cloud Platform cockpit.

For more information, see:

● Principal Propagation
● Connectivity
● Cloud Connector

Identity Management and Authorization Management

Access to any endpoint of your applications should be secured by enforcing authentication and authorization.
This ensures that only the intended target group, such as your company's employees, can access your
application. We recommend that you use the SAP Cloud Platform's default SAML single sign-on authentication
mechanism for user acccess and principal propagation for back-end access. Once a user is authenticated,
single sign-on securely propagates the credentials to the back-end system without requiring the user to
reauthenticate.

SAP Cloud Platform subaccounts get their users from identity providers. Administrators ensure that users can
access only their dedicated subaccount by establishing a dedicated trust relationship only between the identity
providers and the respective subaccounts. The preconfigured default identity provider for SAP Cloud Platform
is SAP ID Service. SAP ID Service is managed by SAP. You can also connect your own identity provider, which
means you have full control over your user base. For developing and administrating your own applications on
SAP Cloud Platform, we recommend that you use SAP Cloud Platform Identity Authentication in your own
tenant. SAP Cloud Platform Identity Authentication is SAP's cloud solution for identity lifecycle management
for SAP Cloud Platform applications, and optionally for on-premise applications.

See the following for more information about security best practices:

● Setting Up Authentication [page 38]

● Setting Up Authorization [page 41]
● Setting Up Identity Propagation [page 42]

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 37
Security Considerations for Applications

When building applications, your developers should use the security features of SAP Cloud Platform, such as
protection from web attacks. We recommend that your developers configure and deploy application-based
security artifacts containing authorizations, and administrators assign these authorizations using the cockpit.
SAP Cloud Platform offers platform roles that help you ensure a separation of duties, such as between app
development and administration.

It's likely that data protection and privacy influence your architecture and the functions of your application, and
you should consider any implications as early as possible in your development process. Security monitoring is
done via audit logging. SAP Cloud Platform writes logs for security-relevant events and the written log files are
digitally signed to ensure their integrity.

See the following for more information about security best practices:

● Protection from Web Attacks

● Giving Access Rights to Platform Users [page 44]
● Data Protection and Privacy

5.4.2 Setting Up Authentication

SAP Cloud Platform provides various options for implementing user authentication.

Use the decision tree below to determine how to set up authentication. Once you've implemented
authentication, you can start implementing user authorization.

 Remember

There are two types of users on SAP Cloud Platform: platform and business. Platform users are usually
developers, administrators, or operators who deploy, administer, and troubleshoot applications and
services. Business users are those who use the applications that are deployed to SAP Cloud Platform.

SAP Cloud Platform Planning and Lifecycle-Management Guide

38 PUBLIC Set Up and Plan
 Setting Up Authentication

Business users can be authenticated by SAP ID Service (default), by the SAP Cloud Platform Identity
Authentication service, or by your own identity provider. Platform users can be authenticated by SAP ID
Service (default), or by the SAP Cloud Platform Identity Authentication service. The SAP Cloud Platform
Identity Authentication service (IAS) can authenticate users stored in the IAS user store, your own corporate
user store, or by forwarding to your own corporate identity provider. Because command-line tools don't
support the SAML browser flow, you can't use them to forward authentication of platform users from IAS to
your own corporate identity provider. Only logging in to SAP Cloud Platform cockpit is supported.

 Recommendation

We recommend that you use SAP Cloud Platform Identity Authentication service for business users.

Related Information

Set up Platform Identity Provider

Set up Identity Authentication Service for Existing Corporate Users
Access Management in the Cloud Foundry Environment
Trust and Federation with Identity Providers or SAP ID Service
SAP Cloud Platform Identity Authentication
SAP Cloud Platform Authentication: Corporate Identity Provider

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 39
5.4.2.1 Authentication Methods

You can implement the authentication methods that are available on SAP Cloud Platform on the frontend of
applications.

Authentication Methods on SAP Cloud Platform Neo Environment

Authentication Method Default Options Description

FORM or SAML2 Trusted SAML 2.0 identity provider with FORM authentication implemented
application-to-application SSO through the Security Assertion Markup
Language (SAML) 2.0 protocol. Authen­
tication is delegated to the SAP ID serv­
ice or a custom identity provider.

BASIC User name and password HTTP basic authentication delegated to

the SAP ID service or to an on-premise
SAP NetWeaver AS Java system. Web
browsers prompt users to enter a user
name and password. By default, the
SAP ID service is used.

CERT Client certificate Used for authentication only with client

certificate.

BASICCERT User name and password client certifi- Used for authentication either with a cli­
cate ent certificate or with user name and
password.

OAUTH OAuth 2.0 token Authentication according to the OAuth

2.0 protocol with an OAuth access to­
ken.

Authentication methods depend on buildpacks, and the cloud Foundry environment offers more than just Java.
Please refer to the Cloud Foundry documentation for more information: Cloud Foundry Security .

5.4.2.2 Destination Authentication Methods

Destinations are part of SAP Cloud Platform Connectivity and are used for communication between a cloud
application and a remote system.

Destinations are required to consume a target remote service from an application. They are resolved at runtime
based on their symbolic names, resulting in an object that contains customer-specific configuration details,
such as the URL of the remote system or service, the authentication type, and the respective credentials.

SAP Cloud Platform Planning and Lifecycle-Management Guide

40 PUBLIC Set Up and Plan
Destination Authentication Methods on SAP Cloud Platform

Authentication Method Description Internet Proxy On-Premise Proxy

AppToAppSSO Used for application-to-appli­ Yes No

cation communication if the
caller needs to propagate its
logged-in user. Both applica­
tions must be deployed on
SAP Cloud Platform.

BasicAuthentication Used for destinations that re­ Yes Yes

fer to a service on the Inter­
net or an on-premise system
that requires basic authenti­
cation.

ClientCertificateAuthentica- Uses a technical user certifi- Yes No

tion cate to perform mutual
transport layer security
(TLS) authentication.

NoAuthentication Used for destinations that re­ Yes Yes

fer to a service on the Inter­
net or an on-premise system
that does not require authen­
tication.

OAuth2SAMLBearerAsser­ Enables applications to use Yes Yes

tion SAML assertions to access
OAuth-protected resources.

PrincipalPropagation Forwards the identity of an No Yes

on-demand user to the Cloud
Connector, and from there to
the back end of the relevant
on-premise system.

SAPAssertionSSO Generates an assertion ticket Yes Yes

to propagate the currently
logged-in SAP Cloud
Platform user to an SAP
back-end system.

5.4.3 Setting Up Authorization

SAP Cloud Platform provides various options for implementing user authorization.

Use the decision tree below to determine how to set up authorization.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 41
  Remember

There are two types of users on SAP Cloud Platform: platform and business. Platform users are usually
developers, administrators, or operators who deploy, administer, and troubleshoot applications and
services. Business users are those who use the applications that are deployed to SAP Cloud Platform.

Setting Up Authorization

In general, you can use static or federated authorization configuration in development accounts. In production
accounts, you'd would usually use identity federation or provisioning.

Related Information

Setup SAML 2.0 for Identity Federation

Setup and Manage Roles for Authorization
Authorizations in SAP Cloud Platform
Security Administration: Managing Authentication and Authorization
SAP Cloud Platform Identity Provisioning Service

5.4.4 Setting Up Identity Propagation

SAP Cloud Platform provides various options for identity propagation.

The decision tree below might help you identify an appropriate setup, however, these are recommendations
only. Your specific setup highly depends on your use case. In general, we recommend using principal
propagation with SAP systems and OAuth2SAMLBearer Assertion with third-party systems to make use of
mapping. Also, OAuth2SAMLBearer lets you send more infos as SAML attributes.

SAP Cloud Platform Planning and Lifecycle-Management Guide

42 PUBLIC Set Up and Plan
 Setting Up Identity Propagation

Related Information

Principal Propagation
Principal Propagation via the Cloud Connector
Configure Principal Propagation to an ABAP System for RFC
Application-to-Application SSO Authentication

5.4.5 Complying with Data Protection and Privacy

Requirements

All companies must respect data protection and privacy rights of individuals. Data protection and privacy most
likely influences your architecture and the functionalities of your application and should be considered as early
as possible in your development process.

It's important you understand that simply using SAP software, such as SAP Cloud Platform, does not make
your company compliant. However, SAP software can help you achieve compliance. You should consult legal
experts to determine the requirements for your company and specific use cases.

 Note

SAP does not provide legal advice in any form. SAP software supports data protection compliance by
providing security features and data protection-relevant functions, such as blocking and deletion of
personal data. In many cases, compliance with applicable data protection and privacy laws is not covered
by a product feature. Furthermore, this information should not be taken as advice or a recommendation

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 43
 regarding additional features that would be required in specific IT environments. Decisions related to data
protection must be made on a case-by-case basis, taking into consideration the given system landscape
and the applicable legal requirements.

Related Information

SAP Cloud Platform Data Protection and Privacy

5.4.6 Giving Access Rights to Platform Users

If you've set up a staged development environment using different subaccounts or spaces, such as for
development, testing, and production, we recommend that you grant the Cloud Development Team access to
development subaccounts and spaces, but that you grant only the Cloud Administration Team access to the
testing and production subaccounts or spaces.

All developers and stakeholders for a particular development project or application should get access to the
Development subaccount or space, if the project or application has been properly enrolled. See Creating an
Onboarding Process for Development Projects [page 21]. We recommend that you assign all developers the
Developer and Application User Admin roles, to enable them to develop, assign roles, and test the
application's functionalities. You can also configure custom platform roles. See Manage Custom Platform
Roles.

As every small change that's made in a single application (for example, changing a destination) might affect all
other applications, only the Cloud Administration Team should have access to the test and prod subaccounts
or spaces, and should manage them centrally. If required, developers may be assigned to the Support User
role to get read access. For all changes required in subaccounts or spaces, the Cloud Development Team
should reach out to the Cloud Administration Team.

 Note

To avoid overwhelming the Cloud Administration Team with inquiries, consider automating of tasks and
providing a build infrastructure for continuous deployment.

5.5 Planning Failover on SAP Cloud Platform

Use a multi-data center setup and implement automatic failover to ensure the high availability of your
applications in case of a data center outage.

Together with Implementing Failover [page 58], this chapter helps you implement a basic automated failover
for SAPUI5 and HTML5 applications in a multi-data center setup. The failover approach ensures that your
business-critical applications continue working in case of an unexpected downtime in an SAP Cloud Platform
data center or SAP Cloud Platform Portal.

SAP Cloud Platform Planning and Lifecycle-Management Guide

44 PUBLIC Set Up and Plan
  Restriction

At the moment, these chapters are only valid for SAPUI5 and HTML5 applications without data persistence
or any kind of in-memory caching, whose data is stored in on-premise back-end systems.

What is Failover

Failover is an approach to ensure the high availability of your applications.

Generally, the term denotes the automated process of switching from one server, network, or system to
another redundant one in case of an either unexpected or planned downtime. If the primary server, network, or
system is unavailable, the traffic is redirected to the secondary one, which takes over the tasks. Therefore, both
functionality and availability of your application is maintained.

The following figure illustrates this concept for a mutli-data center setup, as described in this guide:

Failover in Multi-DC Setup

The SAP Cloud Platform Failover Guide focuses on four principles to consider when planning a failover:

Deploy Your Application in Two Data Centers

Our guide focuses on a multi-data center setup in which you deploy your application in two different data
centers in parallel. The described setup is active/passive, which means that the traffic is generally directed to
the application in the primary (active) data center. Only if the active data center experiences a downtime, the
traffic is redirected to the application in the secondary (passive) one.

For more information, see Deploy Your Application in Two Data Centers [page 58].

Keep the Two Applications in Sync

To maintain the functionality of your application, make sure that both applications in the primary and the
secondary data center are kept in sync. In this guide, we consider three different ways to orchestrate your
applications:

● Orchestrate your applications manually. See Synchronize Your Applications Manually [page 60].
● Orchestrate your applications with the help of a continuous integration and delivery pipeline. See Use a
Continuous Integration and Delivery Pipeline [page 60].

SAP Cloud Platform Planning and Lifecycle-Management Guide

Set Up and Plan PUBLIC 45
● Orchestrate your applications through a combination of the Solution Export Wizard and the SAP Cloud
Platform Transport Management service. See Use the Solution Export Wizard and SAP Cloud Platform
Transport Management [page 61].

For more information, see Keep the Two Applications in Sync [page 59].

Define How a Failover Is Detected

To implement an automated failover from one data center to another, you must specify the cases in which the
automatic switch has to be performed. You can choose from several options that vary in both their setup effort
and flexibility, and use, for example, arbiters and different monitoring tools. In this guide, we describe a basic
scenario, in which a user request triggers checks for both error codes and inappropriate response times.

For more information, see Define How a Failover Is Detected [page 63].

Decide on the Failback

Depending on your failover setup, a failback to the primary data center is either required or optional. In our
active/passive scenario, the failback is mandatory and performed by the user himself. Additionally, we
recommend to visually differentiate between the applications in the primary and the secondary data center so
that the user is constantly reminded of the necessity to switch back as soon as the primary data center is
available again.

For more information, see Decide on the Failback [page 64].

SAP Cloud Platform Planning and Lifecycle-Management Guide

46 PUBLIC Set Up and Plan
6 Develop and Build

SAP Cloud Platform offers various tools and programming languages for application development. You might
also want to consider to integrate your application with other solutions.

We recommend that you use the SAP Cloud Application Programming Model for your development project. For
more information, see Tools, Programming Models, and Programming Languages [page 47].

Development Guide

For best practices, guidelines and step-by-step instructions, see Development.

We recommend that you create multitarget applications for managing dependencies more easily. For more
information, see Using Multitarget Applications to Manage Dependencies [page 50].

Defining Development Guidelines

To ensure consistency and foster collaboration between developers, we recommend that you define guidelines
that include standards for programming principles, code styles, and naming conventions.

SAP provides the following official guidelines:

● SAPUI5 Guidelines
● SAP Fiori Design Guidelines

Related Information

Tools, Programming Models, and Programming Languages [page 47]

Using Multitarget Applications to Manage Dependencies [page 50]
Integrating Your Application [page 66]
Performing UI, Usability, and Unit Tests [page 52]

6.1 Tools, Programming Models, and Programming

Languages

SAP Cloud Platform provides various programming languages and tools for your development project.

For an overview about how to develop applications on SAP Cloud Platform, seeDevelopment.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Develop and Build PUBLIC 47
The Cloud Application Programming Model

The approach we recommend for developing full-stack applications is the SAP Cloud Application Programming
Model. The Cloud Application Programming Model offers a consistent end-to-end programming model that
includes languages, libraries, and APIs that are tailored for full-stack development on SAP Cloud Platform. It
simplifies the development process by enabling you to create concise and comprehensive data and service
models at a conceptual level, which are then used as input for the data, service, and UI layers. The SAP Cloud
Application Programming Model is compatible with any development environment, but we recommend SAP
Business Application Studio.

For more information, see Developing with the SAP Cloud Application Programming Model and SAP Business
Application Studio.

Programming Languages

SAP Cloud Platform supports many different programming languages; the availability of each depends on the
development environment you're using.

Continuous Integration and Continuous Delivery

If you want to run in a DevOps mode, which means a collaborative culture between development and operation
of your cloud applications, we recommend that you also implement a highly automated agile development
process, which ensures speed and increases the quality of your deliveries. Continuous integration (CI) is a key
agile software engineering practice where development changes are integrated frequently. Each change is
verified automatically (by automated builds and tests) and results are made transparent to all developers. As
issues are identified faster, CI is an enabler for agile software development.

Continuous delivery (CD) aims at releasing changes quickly and sustainably. You set up a delivery pipeline that
breaks up the build and deployment process into single stages in order to identify and filter out issues that
might affect the production usage of a change with regard to, for example, performance, stability, security, or
usability.

For detailed information, see What Are Continuous Integration and Continuous Delivery?

We provide the following offerings to ease applying CI/CD practices with SAP Cloud Platform:

● Project "Piper" provides pre-configured Jenkins pipelines, which you can use in your own Jenkins master
infrastructure and adapt according to your needs, if necessary.
● The Continuous Integration and Delivery Best Practices Guide provides simple procedures to implement
continuous delivery pipelines on any CI/CD stack and demonstrates how to apply the principles of CI/CD
to SAP-specific technologies.

See Continuous Integration and Delivery by SAP

SAP Cloud Platform Planning and Lifecycle-Management Guide

48 PUBLIC Develop and Build
Tools

SAP Cloud Platform includes many tools to help you develop and manage applications, and connect them to
your on-premise systems.

Tool Description

SAP Web IDE A powerful, extensible, cloud-based integrated development

tool that simplifies end-to-end (prototype, develop, build, de­
ploy, and extend) SAP Fiori, SAPUI5 and full-stack business
application development. With no installation required, rapid
development tools, and seamless integration with SAP tech­
nologies and services, this IDE increases developer produc­
tivity and reduces development cost and complexity.

SAP Cloud Platform cockpit The central point for managing all activities that are associ­
ated with your subaccount, and for accessing key informa­
tion about your applications.

Cloud Connector The link between on-demand applications in SAP Cloud

Platform and existing on-premise systems. Control the re­
sources that are available for the cloud applications in those
systems.

Cloud Foundry Command Line Interface Work with the Cloud Foundry environment to deploy and
manage your applications.

Console Client for the Neo Environment Develop, deploy, and configure an application outside the
Eclipse IDE as well as perform continuous integration and
automation tasks.

Maven Plugin Use Maven to develop Java applications for SAP Cloud
Platform. Call the console client and its commands from the
Maven environment.

SAP Cloud Platform SDK for iOS Based on the Apple Swift programming language for devel­
oping apps in the Xcode IDE. Includes well-defined layers
(SDK frameworks, components, and platform services) that
simplify development of enterprise-ready mobile native iOS
apps. The SDK is tightly integrated with SAP Cloud Platform
Mobile Services.

SAP Cloud Platform SDK for Neo Environment Everything you need to work with SAP Cloud Platform, in­
cluding a local server runtime and a set of command-line
tools.

SAP Cloud SDK Libraries and tools that make it easy to develop cloud appli­
cations that extend SAP S/4HANA Cloud and other SAP
cloud solutions, improving the application development ex­
perience by providing out-of-the-box capabilities, such as an
abstraction of the underlying SAP Cloud Platform environ­
ment, access to SAP cloud services, fault-tolerance, cache
management, tutorials, and project templates.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Develop and Build PUBLIC 49
6.2 Using Multitarget Applications to Manage
Dependencies

One challenge of moving into the cloud is deploying applications that consist of multiple interconnected
components. We recommend that you develop multitarget applications that let you package those
components into one bundle, and deploy and manage them all at once.

Cloud applications often come with a lot of heterogeneity, which is one of the key strengths of cloud
development, allowing for agility, resilience, and the rapid development of new features. However, it also
increases the complexity of cloud applications, which:

● Usually consist of multiple interdependent software modules

● Are written in different programming languages using multiple development tools
● Might involve different products
● May be deployed to multiple target runtimes

A combined lifecycle lets you deploy all parts together, automatically, and in the right order, and manage the
configuration of the complete solution. You can achieve such a combined lifecycle by developing multitarget
applications. Each multitarget application has the following characteristics:

● One archive file that includes all modules and a description of the dependencies
● Can be delivered, transported, linked to SAP software components, and deployed
● The process can be automated in a continuous integration pipeline

The multitarget application archive contains all required application types and configurations, as well as a
deployment descriptor file. It is intended to be used as a generic artifact that can be deployed and managed on
several SAP Cloud Platform subaccounts. For example, you can use one multitarget application archive in your
development subaccount and reuse it in your production subaccounts.

As all interdependencies are part of the archive file, it's easy to pass multitarget applications from development
to operations. All required information for deployment is provided during the development process. Due to the
benefits provided by applying the multitarget application approach, it is also part of the SAP Cloud Application
Programming Model.

 Recommendation

The approach isn't mandatory for applications that are running on SAP Cloud Platform – you can also
develop without applying it. Without the multitarget application approach, you'll need to manually deploy
your application artifacts, for example by triggering the deployment from SAP Web IDE or manually
uploading artifacts via SAP Cloud Platform cockpit.

We recommend that you use multitarget applications in the following cases:

SAP Cloud Platform Planning and Lifecycle-Management Guide

50 PUBLIC Develop and Build
 ● You're developing a business application composed of several different parts – apps, services, content,
and others – that you want to manage as a single unit.
● Your business application has dependencies to external resources, such as backing services (database,
messaging, and so on), APIs, and configurations from other applications.
● Your business application has a certain default configuration, for example memory, disk, number of
individual app instances, environment variables, service plans, and others.

For more conceptual information about multitarget applications and detailed step-by-step instructions, see
Multitarget Applications in the Cloud Foundry Environment.

There are several options to create multitarget application archives:

● If you use SAP Web IDE Full-Stack, you can use multitarget application templates for Cloud Foundry
applications, where the descriptor file is maintained automatically, for example, whenever you add a new
module in the SAP Web IDE.
● If you have development modules from other sources, you can use the multitarget application archive
builder, a Java-based command-line tool that builds modules and packages them into a deployable
multitarget application archive, together with a deployment descriptor. It is available for download from
SAP Development Tools (see https://tools.hana.ondemand.com/#cloud).
● If you have solutions already deployed in the Neo environment, you can use the solution export wizard, as
offered in the Solutions view of the SAP Cloud Platform cockpit. The wizard lets you select existing
components (considering interdependencies automatically) and offers to download the multitarget
application archive (not supported for archives comprising Java modules) or descriptor files, or to
integrate the changes into transport management processes (see Deploy and Deliver [page 54]).
Applications, configuration content, such as destinations, roles, and security groups are supported. For
more information, see Exporting Solutions on SAP Help Portal.

6.2.1 Establishing a Provider/Subscriber Scenario Using

Multitenancy

The provider/subscriber approach is one of the important scenarios that that are supported with multitarget
application.

SAP Cloud Platform allows you to develop and run multitenant (tenant-aware) applications. These applications,
which must apply the mulittarget application approach, run on a shared compute unit that can be used by
multiple consumers (tenants). Each consumer accesses the application through a dedicated URL.

For example, SAP partners or central IT organizations can build and run multitenant apps in their provider
accounts, deploy them using the multitarget application concept as providers, then deliver them as services to
their customers or line of business subsidiaries in corresponding subscriber accounts via subscriptions.

One of the advantages of this approach is that the application lifecycle and resource management is centrally
managed. A single deployment can serve several subscribing subaccounts, which eases onboarding of new
customers and decreases the number of code versions to manage. This also eases the consumption, as the
actual customers of the applications do not have to deploy solutions and manage corresponding resources.

For more information, see the following:

● Multitenancy Roles
● Developing Multitenant Applications in the Neo Environment

SAP Cloud Platform Planning and Lifecycle-Management Guide

Develop and Build PUBLIC 51
● Developing Multitenant Applications in the Cloud Foundry Environment

6.3 Performing UI, Usability, and Unit Tests

You should always conduct careful testing to ensure that your application is of high quality. Create a release
candidate to propagate throughout your landscape.

For example, consider testing the user interface, usability, and performance, as well as running general unit
tests. Developers should use unit tests to ensure that software modules behave as expected. Unit tests are the
smallest tests, and they detect issues fast. Taking good care of unit tests usually leads to better maintainable
and understandable code. If you use the Continuous Integration process, you should consider automated tests
as part of the pipeline.

SAPUI5

SAPUI5 supports QUnit testing. We recommend that you write unit tests as small as possible, ensuring that you
only test one single thing at a time. This will not only make debugging easier, but also maintaining the tests in
the long run. See Unit Testing with QUnit.

For an overview of available testing options for SAPUI5 developments, see Testing and Performance
Measurement.

For SAPUI5 and SAP Fiori testing, please see the demokit for SAP UI5: https://sapui5.hana.ondemand.com/.

SAP Cloud SDK

We recommend that you write JUnit tests for the modules of your backend services. They should be very
granular in that they only test individual modules, such as a class. See Step 13 with SAP Cloud SDK: Automated
Testing .

As part of the Continuous Integration and Delivery Process, we recommend that you run performance tests in
SAP Cloud SDK Pipeline to determine the behavior of the software system and change in responsiveness under
simulated load conditions. SAP Cloud SDK Pipeline has integrated support for performance tests using JMeter
and Gatling. See Step 23 with SAP Cloud SDK: Performance Tests .

Testing in SAP Web IDE

SAP Web IDE empowers developers to test and evaluate the functionality and performance of their apps:

● Use the application preview to test functionality, design and performance before deploying it. There are
different configuration options available, such as SAP UI5 runtime version, URL parameters. SeeRunning
Applications in Development Mode.

SAP Cloud Platform Planning and Lifecycle-Management Guide

52 PUBLIC Develop and Build
 ● Run your application using a client mock server. See Run Applications with Mock Data.
● Execute unit tests for SAPUI5 (Qunit) and Java (JUnit). See Developing Application Tests and Test a Java
Module.
● Execute SAPUI5 integration tests based on OPA5. See Performing Integration Tests [page 67].

SAP Cloud Platform Planning and Lifecycle-Management Guide

Develop and Build PUBLIC 53
7 Deploy and Deliver

After you've developed your application, you need to deploy it and deliver it to your TEST and PROD
environments. By deploying it to two different data centers in parallel, you can implement failover.

● Deploying Applications [page 54]

● Delivering Applications [page 56]
● Implementing Failover [page 58]

7.1 Deploying Applications

You can leverage different deployment tools and methods, depending on the application type and your
requirements.

7.1.1 Deploying Simple Applications

If your application consists of only one module, there are different native options for deploying it, depending on
the programming language you're using.

Java

You can use the SAP Cloud Platform cockpit, the console client (Neo), or the command-line tool (Cloud
Foundry) to deploy a Java application. You have several options to choose from with regards to runtimes, Java
Virtual Machine versions, and more.

For large-scale development setups, we recommend that you connect your own development infrastructure.

HTML5

You can deploy HTML5 applications from within the SAP Web IDE. In addition:

● In the Neo environment, you can export and import your application via the SAP Cloud Platform cockpit.
● In the Cloud Foundry environment, you can deploy your application using the Cloud Foundry command-line
interface.

SAP Cloud Platform Planning and Lifecycle-Management Guide

54 PUBLIC Deploy and Deliver
Node.js

In the Cloud Foundry environment, you can deploy Node.js applications from within SAP Web IDE, or use the
Cloud Foundry command-line interface.

SAP HANA Extended Application Services, Classic Model (SAP HANA XS)

In the Neo environment, you can create a delivery unit as a .tgz file that contains all the artifacts for
applications that are based on SAP HANA XS. You can import and export the application using SAP HANA
administration tools, and open the application using the SAP Cloud Platform cockpit.

Please be aware that SAP HANA Extended Application Services, Classic Model has been deprecated – for more
information, see 0002465027 .

SAP HANA Extended Application Services, Advanced Model (SAP HANA

XSA)

In the Cloud Foundry environment, you can deploy applications based on SAP HANA XSA using the SAP HANA
Deployment Infrastructure (HDI) from within SAP Web IDE. You can also deploy your application using the
Cloud Foundry command-line interface.

Bring Your Own Buildpack

In the Cloud Foundry environment, you can use your own buildpack to create applications. The deployment of
such an application depends on the buildpack-specific development and deployment infrastructure.

7.1.2 Deploying Multi-Target Applications

There are two options for deploying MTAs: Manually or managed.

● Manually: You can archive all components of your application into one package that includes the
deployment descriptor. You can then manually trigger the deployment of the solution using the SAP Cloud
Platform cockpit or the Console Client. The actual deployment of the MTA files is then performed
automatically by the SAP Cloud Platform deployment infrastructure, considering all interdependencies
specified in the MTA deployment descriptor that is part of the MTA archive. By assigning roles and
encapsulating the Console Client in a script, you can achieve a somewhat controlled release mechanism.
● Managed: If you prefer a managed approach, you can deploy MTAs as part of a CI/CD approach or
implement transport or change management processes for your SAP Cloud Platform apps, using
enhanced Change and Transport (CTS+) for example. For more information, see Transporting Multitarget
Applications with CTS+.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Deploy and Deliver PUBLIC 55
7.2 Delivering Applications
There are several options for propagating developed applications from one subaccount to another, for example,
from your Development to your Testing and Production subaccounts.

Delivery Option
(Tool Support and Development con­
Automation De­ tent (such as SAP Cloud Plat­
creasing from Top Java, HTML5, SAP form Integration Other app-spe­
to Bottom) HANA XSA) packages cific content SAP HANA XS Portal Site

CI/CD recommended n/a n/a recommendedfor partly possible

SAP HANA XSA

Transport Manage­ recommended, recommended, recommended recommended recommended,

but only possible but only possible but only possible
ment service with
as MTA as MTA as MTA
the option to inte­
grate into Change
Management
(ChaRM or QGM of
SAP Solution Man­
ager)

CTS+ with the op­ recommended, recommended, n/a recommended recommended,

but only possible but only possible but only possible
tion to integrate
as MTA as MTA as MTA
into Change Man­
agement (ChaRM
or QGM of SAP
Solution Manager)

SAP HANA Appli­ n/a n/a n/a recommended for n/a

cation Lifecycle SAP HANA XSC
Management

Manually possible possible recommended, possible possible

but with app-spe­
cific procedures

● Set up a continuous integration and continuous delivery (CI/CD) infrastructure: Have a look at Getting
Started with Project "Piper" to learn how to use our Cx server and Jenkins for it. For an overview of all
solutions we provide for continuous integration and delivery, see SAP Solutions for Continuous Integration
and Delivery.
For information and best practices on how to apply CI/CD for development projects on SAP Cloud
Platform, such as using pipeline templates and containerized images, see the Continuous Integration and
Delivery by SAP.
● If you're building an extension to SAP S/4HANA, consider using the continuous delivery toolkit that's
provided with the SAP Cloud SDK. The toolkit helps you manage the infrastructure and provides a ready-
to-use continuous delivery pipeline out-of-the-box. It includes the following freely available components:
○ Maven project archetypes for rapidly creating a new SAP S/4HANA extension application along best
practices
○ A preconfigured Jenkins CI and CD server that is managed via easy-to-use lifecycle scripts and Docker
images

SAP Cloud Platform Planning and Lifecycle-Management Guide

56 PUBLIC Deploy and Deliver
 ○ A ready-to-use pipeline for building, testing, quality checking, and deploying applications that have
been created from the SAP Cloud SDK archetypes without writing any pipeline code
For more information, see SAP Cloud SDK .
● If you want to have more control, especially when propagating changes towards your production
environment, consider the following transport management options:
○ For cloud transports, also in hybrid landscapes: the SAP Cloud Platform Transport Management
service, which allows you to transport content archives, delivery units of SAP HANA XS classic model,
and application-specific content, such as SAP Cloud Platform Integration content, between different
subaccounts, which might also reside in different global accounts, spread across different regions. This
service might be especially suitable if you don't have an ABAP-based landscape, don't want to involve
on-premise ABAP systems in your scenario, or have to handle SAP Cloud Platform application-specific
content, independent of whether it is provided as multitarget application files or in other formats.
For more information, see SAP Cloud Platform Transport Management Service .
○ For ABAP-centric or hybrid scenarios, the enhanced Change and Transport System (CTS+), running
in an on-premise ABAP system. Besides handling the transport of on-premise systems (such as of
ABAP and Java artifacts), CTS+ also lets you transport SAP Cloud Platform artifacts from one
subaccount to another. However, this is only supported if the artifacts are packaged as multitarget
application archives. Please note that no other SAP Cloud Platform content format is planned to be
supported by CTS+.
For more information, see Transporting Multitarget Applications with CTS+.
○ Both CTS+ and SAP Cloud Platform Transport Management allow an integration into change
management approaches around SAP Solution Manager. You can either run CTS+ centrally on SAP
Solution Manager and integrate it with change management tools, such as Change Request
Management (ChaRM) or Quality Gate Management – or you can integrate SAP Cloud Platform
Transport Management service into these tools running on SAP Solution Manager (minimum version:
SAP Solution Manager 7.2 SP10). It is even possible to use CTS+ and SAP Cloud Platform Transport
Management service in parallel within ChaRM or QGM.
With this approach, you can set up synchronized transports in hybrid scenarios (involving both on-
premise ABAP content and SAP Cloud Platform content). For more information, see Interplay of SAP
Cloud Platform Transport Management, CTS+ and ChaRM in hybrid landscapes .
Combine CI/CD with transport management (either in the form of SAP Cloud Platform Transport
Management service or CTS+), to gain more control over the delivery of release candidates towards
your production environment and at the same time benefit from the agility CI/CD brings to your
development. For more information, see How to integrate SAP Cloud Platform Transport Management
into your CI/CD pipeline . It is also possible to combine CI/CD, CTS+, Transport Management and
SAP Solution Manager Change Management.
● Deploy applications manually from your IDE to different subaccounts. Import or export your application
using the SAP Cloud Platform cockpit, or use the Console Client for the Neo environment or the Cloud
Foundry command line interface to deploy your application.

 Note

You can transport portal settings and configurations only by manually redeploying your application in
each subaccount.

● In the Neo environment, consider to use the Solution Export Wizard that you can start in SAP Cloud
Platform cockpit to model solutions by selecting comprised components (with an automated resolution of
interdependencies) and to either export the outcome (as multitarget application file) or to directly handle
the modeled solution via the change management options outlined above. For more information, see
Solution Export Wizard - Ease Modeling and Export of Solutions as MTA .

SAP Cloud Platform Planning and Lifecycle-Management Guide

Deploy and Deliver PUBLIC 57
● (HTML5 applications only) Synchronize Git repositories and create build scripts that let you transfer
commits from the repository of the source subaccount to the repository of the target subaccount. After the
synchronization, you must still deploy the application manually using the SAP Cloud Platform cockpit.
● (SAP HANA XS applications only) Use the SAP HANA XS Application Lifecycle Management (HALM) to
create transport routes between two SAP HANA systems, then transport delivery units between those
systems. For more information, see SAP HANA Application Lifecycle Management.

Related Information

Blog on Transport Approaches in SAP Cloud Platform

7.3 Implementing Failover

Execute the following tasks to implement a basic failover setup:

1. Deploy Your Application in Two Data Centers [page 58]

Deploy your application in two data centers in parallel so that in case of an issue, you can switch from
one to the other.
2. Keep the Two Applications in Sync [page 59]
Synchronize your applications in both data centers to maintain their functionality in case of a
downtime.
3. Define How a Failover Is Detected [page 63]
Define in which cases the automatic failover from one data center to the other is triggered.
4. Decide on the Failback [page 64]
In the setup of your failover scenario, define whether a failback is needed and how it is performed.

7.3.1 Deploy Your Application in Two Data Centers

Deploy your application in two data centers in parallel so that in case of an issue, you can switch from one to
the other.

To implement failover in an active/passive setup, deploy your application in two data centers in parallel. Among
these two data centers, define the primary (active) one to which the traffic is generally directed and the
secondary (passive) data center that takes over in case of a downtime.

Depending on your type of global account on SAP Cloud Platform and the environment you're using, you can
choose from different regions to deploy your applications. To deploy an application in subaccounts of multiple
regions, execute the deployment separately for each subaccount. For more information about regions and a
complete list of data centers from which you can choose, see Regions.

SAP Cloud Platform Planning and Lifecycle-Management Guide

58 PUBLIC Deploy and Deliver
  Recommendation

To optimize the performance of your application, which is, for example, response time and latency, we
recommend that you deploy it in two data centers of the region your target audience and your back-end
system are located in. If you are located in Europe, choose, for example, the data centers in Frankfurt and
Amsterdam.

 Note

If you want to deploy your application in two data centers that are not located in the same region, keep in
mind that there might be issues concerning legal data processing restrictions. For more information, see
Data Protection and Privacy.

Parent topic: Implementing Failover [page 58]

Next: Keep the Two Applications in Sync [page 59]

7.3.2 Keep the Two Applications in Sync

Synchronize your applications in both data centers to maintain their functionality in case of a downtime.

Make sure that you transfer changes on one of your applications to the one in the other data center, as well, so
that its functionality is not interrupted in case of a failover.

 Recommendation

Keeping your two applications in sync does not necessarily mean that both applications need to be
identical. If you want to offer only a reduced set of functions in your secondary application, we recommend
to visually mark it as your backup. In this way, your users are constantly reminded that they are using the
backup version and should switch back to the primary one once it is available again.

There are three different ways to synchronize your applications in the primary and the secondary data center:

● Orchestrate your applications manually. See Synchronize Your Applications Manually [page 60].
● Orchestrate your applications with the help of a continuous integration and delivery pipeline. See Use a
Continuous Integration and Delivery Pipeline [page 60].
● Orchestrate your applications through a combination of the Solution Export Wizard and the SAP Cloud
Platform Transport Management service. See Use the Solution Export Wizard and SAP Cloud Platform
Transport Management [page 61].

Parent topic: Implementing Failover [page 58]

Previous: Deploy Your Application in Two Data Centers [page 58]

Next: Define How a Failover Is Detected [page 63]

SAP Cloud Platform Planning and Lifecycle-Management Guide

Deploy and Deliver PUBLIC 59
7.3.2.1 Synchronize Your Applications Manually

You can orchestrate your applications manually by duplicating your modifications in both data centers, for
example, by mirroring from Git repositories.

The following figure illustrates this process:

Manual Synchronization

With this approach, you can decide yourself which of your changes to transport from one data center to the
other. Therefore, synchronizing your applications manually allows you to maintain two non-identical
applications, for example, if you want to visually differentiate between the UIs in your primary and the backup
version.

 Recommendation

With regard to the relatively high effort needed for this approach, we recommend it only if you do not plan
regular updates or changes to your application.

7.3.2.2 Use a Continuous Integration and Delivery Pipeline

You can synchronize the deployment of your applications in two different data centers by using a continuous
integration and delivery (CI/CD) pipeline. Configure it for multi-deployment so that in the final stage of your
CI/CD pipeline, your changes are automatically deployed to two SAP Cloud Platform subaccounts in parallel. In
our case, these subaccounts are hosted in different data centers. For more information about subaccounts on
SAP Cloud Platform, see Managing Subaccounts.

SAP Cloud Platform Planning and Lifecycle-Management Guide

60 PUBLIC Deploy and Deliver
The following figure illustrates this procedure:

Synchronized Deployment Through a CI/CD Pipeline

 Recommendation

Use a pre-configured pipeline of project "Piper" and adapt it for multi-deployment to your two SAP Cloud
Platform subaccounts in different data centers. For more information, see project "Piper" .

Related Information

Continuous Integration (CI) and Delivery (CD) Overview

Overview of SAP Offerings for CI and CD
Blog - Continuous Delivery with Jenkins Pipelines

7.3.2.3 Use the Solution Export Wizard and SAP Cloud

Platform Transport Management

You can orchestrate your applications through a combination of the solution export wizard and the SAP Cloud
Platform Transport Management service.

Prerequisites

● You have deployed the applications you want to synchronize in two different subaccounts in the Neo
environment. See Create Subaccounts Using the Cockpit.
● You have a subaccount in the Cloud Foundry environment. See Create Subaccounts Using the Cockpit.
● You are subscribed and have access to the SAP Cloud Platform Transport Management service. See SAP
Cloud Platform Transport Management and Initial Setup.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Deploy and Deliver PUBLIC 61
● In SAP Cloud Platform Transport Management, you have defined a transport route from your development
system to your failover system. See Configuring the Landscape.

Context

In your subaccount in the Neo environment hosted in your primary data center, use the solution export wizard
to export the changes you have made to your application to the SAP Cloud Platform Transport Management
service. From the Transport Management service, which is hosted in your subaccount in the Cloud Foundry
environment, transport your changes to the backup application in your subaccount in the Neo environment in
the secondary data center.

The following figure illustrates this procedure:

Synchronization Through Solution Export Wizard and Transport Management

 Note

You can also use the solution export wizard independently from SAP Cloud Platform Transport
Management by manually uploading your exported changes to the target account.

Procedure

1. In the SAP Cloud Platform cockpit, navigate to your subaccount in the Neo environment, in which your
HTML5 application is deployed. See Navigate to Global Accounts and Subaccounts in the Cockpit.
2. From the navigation pane, choose  Solutions.
3. To access the solution export wizard, choose  Export. For more information, see Exporting Solutions.
4. In the Select Components section of the Solution Export Wizard dialog, select the components of your
HTML5 application you have changed.

 Note

The solution export wizard can automatically resolve dependencies, for example, by selecting
corresponding roles.

5. In the Export options section, select Transport Management Service to hand over your MTA archive to SAP
Cloud Platform Transport Management. For more information about MTA archives, see Multi-Target
Applications.

SAP Cloud Platform Planning and Lifecycle-Management Guide

62 PUBLIC Deploy and Deliver
 6. In the SAP Cloud Platform cockpit, navigate to your subaccount in the Cloud Foundry environment. See
Navigate to Global Accounts and Subaccounts in the Cockpit.
7. From the navigation pane, choose  Subscriptions.
8. On the  Transport Management Service tile, choose Go to Application.
9. From the navigation pane, choose  Transport Nodes and select the target node.
10. In the IMPORT QUEUE tab, select the MTA archive you have exported with the help of the solution export
wizard.
11. Choose Import.

Related Information

Blog - Solution Export Wizard – ease modeling and export of solutions as MTA
Blog - The new cloud-based Transport Management Service
Blog - SAP Cloud Platform Transport Management service generally available

7.3.3 Define How a Failover Is Detected

Define in which cases the automatic failover from one data center to the other is triggered.

You can choose from different test categories to decide when the automatic switch from your primary to the
backup application is triggered. Either define these test categories manually in your code or use rule-based
performance solutions such as Akamai ION . At each user request, you could, for example, check for a
combination of a predefined maximum read timeout and set HTTP status codes. If one of these two checks
responds an unwanted behavior of your application, the failover is triggered.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Deploy and Deliver PUBLIC 63
The following figure illustrates this procedure:

Failover Detection

 Example

As an example, you could define 25 seconds as maximum read timeout and set a number of server error
codes (5xx) to be checked. At each first HTTP request towards the URL of your application, both checks
are triggered. All following HTTP requests are ignored to avoid an unnecessary failover if, for example, only
an image resource is missing. If one of the two checks fails, the user is automatically redirected to an HTML
down page, which must not be cached. This down page provides the link to your failover application. Strictly
speaking, the failover itself is therefore manually performed by the user of your application.

Parent topic: Implementing Failover [page 58]

Previous: Keep the Two Applications in Sync [page 59]

Next: Decide on the Failback [page 64]

7.3.4 Decide on the Failback

In the setup of your failover scenario, define whether a failback is needed and how it is performed.

Depending on the setup of your failover scenario, a failback is either optional or mandatory:

● If you use an active/active setup, your applications in both data centers must be identical and provide the
exact same functionality. In this setup, both data centers are of equal value. Therefore, a failback to the
primary data center is not needed but performed automatically the next time a failover is triggered.

SAP Cloud Platform Planning and Lifecycle-Management Guide

64 PUBLIC Deploy and Deliver
 ● If you use an active/passive setup and your applications in both data centers slightly differ from each
other, a failback to the primary data center is mandatory to provide the full functionality of your
application.

 Recommendation

In a basic scenario, you can hand over the failback to the users of your application, who perform the
failback automatically when later trying to access the primary version of your application again. In this
scenario, visually differentiate between your primary and secondary application so that they are constantly
reminded to switch back to the primary one once they have completed their transaction. Unlike an
automatic failback as soon as the primary data center is available again, this approach ensures that your
users are not interrupted while completing a transaction. Instead, they can decide on their own when to
switch back to the primary application.

Parent topic: Implementing Failover [page 58]

Previous: Define How a Failover Is Detected [page 63]

SAP Cloud Platform Planning and Lifecycle-Management Guide

Deploy and Deliver PUBLIC 65
8 Integrate and Test

Test and integrate your application with other solutions.

8.1 Integrating Your Application

SAP Cloud Platform offers various options for integrating your cloud application with other cloud and on-
premise solutions.

Cloud Connector

If you want an application running on SAP Cloud Platform to access data from your on-premise back-end
system, we recommend that you use the Cloud Connector. It's an on-premise piece of software that you'll need
to install in your on-premise landscape, within the firewall. Once it's configured and paired with your SAP Cloud
Platform subaccount, a secure tunnel is established between SAP Cloud Platform (and all the services and
applications that run on it) and the Cloud Connector. Communication between SAP Cloud Platform and the
back-end system is routed via the Cloud Connector through a secure SSL tunnel.

We recommend that you use the Cloud Connector if your use case requires any of the following:

● Point-to-point connectivity and programmatic integration

● Connectivity with cloud applications from on-premise systems, without mediation, such as for mapping,
routing, or security
● Data replication from on-premise databases or Business Intelligence tools to SAP HANA databases
running in the cloud
● On-premise system integration using SAP Cloud Platform Integration

For more information, see Cloud Connector.

SAP Cloud Platform Integration

SAP Cloud Platform Integration (Cloud Integration) supports end-to-end process integration across cloud and
on-premise applications (cloud to cloud and cloud to on-premise integration). It provides the following
features:

● Core runtime for processing, transforming, and routing of messages to be exchanged between your
systems
● Out-of-the-box connectivity support (IDoc, SFTP, SOAP/HTTPS, SAP SuccessFactors, OData, HTTPS)
● Security features such as content encryption and certificate-based communication

SAP Cloud Platform Planning and Lifecycle-Management Guide

66 PUBLIC Integrate and Test
Cloud Integration offers full flexibility for the manner in which messages are exchanged between your systems.
We recommend that you use the Cloud Connector if you require any of the following (or if you don't require on-
premise-based middleware, such as SAP Process Orchestration):

● Compliance scenarios, such as e-invoicing and payroll

● Graphical model of integration flow
● More than a few systems to be integrated, and you'd like to managed integrations centrally, rather than
having to manually code applications when connections change
● Individual messages to be processed during integration
● Integration with third-party solutions

For more information, see SAP Cloud Platform Integration.

Cloud Integration Automation Service

If you're planning on integrating your SAP Cloud Platform application into a hybrid landscape, you can also
leverage the Cloud Integration Automation Service that is offered for selected integration scenarios. This
service provides a guided workflow that uses customer-specific system information, reusable configuration
settings between tasks, and automated execution capabilities, thereby reducing the manual work for your
scenario integration. For more information, see Cloud Integration Automation Service.

Related Information

Blog Post: SAP Cloud Platform Integration: When to use which tool
Blog Post: Using SAP Cloud Platform Cloud Connector with SAP Cloud Platform Integration
Blog Post: Cloud Integration Automation Service - What is it?
Blog Post: Cloud Integration Automation Service: Step-by-Step

8.2 Performing Integration Tests

In contrast to unit tests that are performed locally on your development subaccount without any external
dependencies in the develop and build phase, integration tests target the interplay of a complete system,
spanning several single components and units potentially spread throughout a hybrid landscape. Integration
tests verify that all building blocks work together, meet specified requirements, and fulfill the targeted business
case. They should therefore then be executed on your test infrastructure or in your test subaccount after the
integration into an existing landscape has taken place. This ensures that the interplay with backend
functionalities is verified. In a CI/CD setup, note that such integration tests are part of the pipeline.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Integrate and Test PUBLIC 67
Integration Tests for SAPUI5

One Page Acceptance Tests (OPA5) is an API for SAPUI5 controls. It hides asynchronicity and eases access to
SAPUI5 elements. This makes OPA especially helpful for testing user interactions, integration with SAPUI5,
navigation, and data binding. See Integration Testing with One Page Acceptance Tests (OPA5).

Integration Tests for Apps Written Using SAP Cloud SDK

Integration tests work directly on the defined backend APIs, mainly testing the integration between backend
services and the integration between SAP Cloud Platform to SAP S/4HANA systems. For integration tests of
your backend services, we recommend that you use Arquillian to spawn a server that contains only the
resources for the specific backend services that you want to test. See Step 13 with SAP Cloud SDK: Automated
Testing .

SAP Cloud Platform Planning and Lifecycle-Management Guide

68 PUBLIC Integrate and Test
9 Go Live and Monitor

Once you've deployed, transported, tested, and integrated your application, you can go live.

After you've released an application, you have to ensure that it's provided with the right performance and
availability by monitoring its various parts – such as platform services, application parts, and databases. SAP
Cloud Platform 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 hybrid scenarios across the SAP portfolio, or if you already have an operations process in place, you can
also integrate monitoring of SAP Cloud Platform applications into SAP Solution Manager and Focused Run of
SAP Solution Manager.

● Going Live [page 69]

● Monitoring Applications and Services Natively [page 70]
● Monitoring a Hybrid Landscape [page 72]

9.1 Going Live

Once you've tested your application successfully and ensured that you are compliant with any applicable
security guidelines and compliance regulations, you can go live with your application.

If you've set up a staged development environment, we recommend that your Cloud Administration Team
defines specific timeframes during which the Cloud Development Team is allowed to go live with an application.
You can forbid go-live activities during times that a stable landscape is particularly crucial (for example, at the
end of each quarter), and allow deployments to your production subaccount only in case of emergencies.

Consider embedding applications with internal end users in the SAP Fiori launchpad using SAP Cloud Platform
Portal before you go live. This enables your internal target audience to access all applications in one central
place and thus improves the app's usability. For more information, see SAP Cloud Platform Portal.

Web Acceleration

If your application's end users are widely spread across different countries or even continents, you can improve
your application's load performance by using a Content Delivery Network (CDN). For example, you can use
common CDN providers such as Akami or Cloudflare.

If you include SAP’s SAPUI5 library directly from *.hana.ondemand.com, the SAPUI5 resources are
automatically delivered via a CDN. See Variant for Bootstrapping from Content Delivery Network.

Consider the following when using a CDN:

● Secure transport: Make sure any access via HTTP will get redirected to a HTTPS connection before loading
any content.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Go Live and Monitor PUBLIC 69
● Block access based on location: If blocking access from a certain country is required, the client’s location
data can be used. Keep in mind that this does not guarantee a full blocking, since the client’s location data
can be changed, or the client could access from another country via a virtual private network (VPN).
● Content compression: You can compress your content with gzip before it gets delivered to the client. This
improves the performance, especially for clients with a slow connection.
● Content caching: In addition to client caching, you can make the CDN provider cache your server’s content,
so that following requests of the same resources by other clients will be delivered faster. While this can
additionally improve the performance, you need to keep in mind the following:
○ Make sure that you only cache static content. We recommend that you exclude certain files (for
example, for UI5 apps, exclude the neo-app.json file) or paths (for example, a route to OData services),
to make sure dynamic content is never cached.
○ You should configure your CDN provider so that it respects the Cache-Control and Expires header
of your server.
○ You should not cache any dynamic header, such as the X-CSRF-Token header, that is used against
cross-site request forgery (CSRF).

Related Information

Updating Applications

9.2 Monitoring Applications and Services Natively

There are various options you can use to monitor applications and services on SAP Cloud Platform, provided
natively by the platform itself. Which of them you might use depends on the SAP Cloud Platform environments
you work in.

Monitoring Applications in the Neo Environment

In the Neo environment, you can use the SAP Cloud Platform cockpit to monitor applications:

Monitoring Applications Using the Cockpit in the Neo Environment

Application Type Monitoring Options More Information

Java applications ● Application monitoring Managing Deployed Applications

● Application performance statistics
(Beta)
● Custom JMX checks
● Monitoring APIs

SAP Cloud Platform Planning and Lifecycle-Management Guide

70 PUBLIC Go Live and Monitor
 Application Type Monitoring Options More Information

SAP HANA XS applications ● Health statistics for SAP HANA da­ SAP HANA: Application Operations
tabase instances
● Application availability checks
● Email notifications

HTML5 applications Log viewer collecting error messages Log HTML5 Applications

You can also connect your Java applications to a Dynatrace SaaS monitoring environment. For more
information, see Agent Activation for Dynatrace.

Monitoring Applications in the Cloud Foundry Environment

In the Cloud Foundry environment, you can use the ELK stack to monitor applications. You can also run the cf
logs command to show the recent logs for an application. For more information, see the Cloud Foundry
documentation at https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html .

 Note

Container metrics in syslog drains are not currently logged by SAP Cloud Platform.

You can also configure health checks that continually monitor the status of a running application. For more
information, see https://docs.cloudfoundry.org/devguide/deploy-apps/healthchecks.html .

Monitoring Services and Service Availability

You can follow the availability of the platform at SAP Trust Center . You can check:

● the availability by service on the SAP Cloud Platform tile of the Cloud Status tab page;
● the availability by region on the Data Center tab page.

To get notifications for updates and downtimes, subscribe at the Cloud System Notification Subscriptions
application. Create a subscription by specifying Cloud Product, Cloud Service, and Notification Type. For more
information, see Cloud System Notification Subscriptions User Guide .

In addition, you can get a personalized, at-a-glance view of additional SAP Cloud Platform offerings with SAP
Cloud Availability Center , such as SAP Cloud Platform Integration.

There are additional monitoring tools and options available for certain SAP Cloud Platform services, such as
the SAP Cloud Platform Identity Authentication service. Please refer to the respective service documentation
for more details: Capabilities and Services.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Go Live and Monitor PUBLIC 71
Alerting

In addition to the general notifications mentioned above, SAP Cloud Platform Alert Notification lets you know
instantly whenever there's an issue with your specific cloud application or its dependencies, no matter if your
apps are running in the Neo or Cloud Foundry environment. You can subscribe to events coming from used SAP
Cloud Platform services, from hyperscalers, from third-party tools such as Dynatrace, or you can create
custom alerts for your apps. Furthermore, the notifications arrive via any channel of alert management you
select, for example, email, some sort of corporate chat, a ticketing system, or even SAP Solution Manager or
Focused Run for SAP Solution Manager . For more information, see SAP Cloud Platform Alert Notification.

9.3 Monitoring a Hybrid Landscape

If you've integrated SAP Cloud Platform with your on-premise SAP landscape, you can use SAP Solution
Manager, Focused Run for SAP Solution Manager, and, for more and more options and scenarios also SAP
Cloud ALM to monitor and operate that hybrid landscape.

For more information about SAP Cloud ALM, see SAP Cloud ALM https://support.sap.com/en/alm/sap-
cloud-alm.html .

Monitoring Option Description More Information

Integration Monitoring Ensure reliable data exchange between Integration Monitoring

your SAP on-premise system and SAP
Cloud Platform. Includes process inte­
gration monitoring, interface and con­
nection monitoring, and message flow
monitoring.

User Experience Monitoring Simulate the behavior of users who ac­ User Experience Monitoring
cess central servers at different loca­
tions to run business processes. Lets
you monitor the availability of the sys­
tems, and connection performance,
from the end-user perspective, in real
time.

SAP Cloud Platform Planning and Lifecycle-Management Guide

72 PUBLIC Go Live and Monitor
 Monitoring Option Description More Information

Trace Analysis Trace the performance of SAP Cloud Trace Analysis

Platform applications. You can:
End-to-End Trace Analysis
● Trace requests to applications that
are deployed on SAP Cloud
Platform or running on your on-
premise system
● Trace application performance
data, such as application and UI re­
sponse times, and database calls
● Trace request paths through in­
bound and outbound request
points

Exception Management Forward business-critical exceptions Exception Management

from SAP Cloud Platform to on-premise
operations and:

● Centrally retrieve and handle all

single, cross-components, process
flow-driven, and multistep excep­
tions.
● Correlate, analyze, and process ex­
ceptions, and use predefined
guided procedures to quickly han­
dle errors.

Related Information

Blog: Brief Overview of Hybrid Supportability Options for SAP Cloud Platform

SAP Cloud Platform Planning and Lifecycle-Management Guide

Go Live and Monitor PUBLIC 73
10 Improve and Retire

Once your application has gone live, we recommend that you continually ensure its quality. If you determine
that you no longer need it, you should retire it.

10.1 Improving and Maintaining Your Application

Once an application has gone live, the Cloud Development Team is responsible for housekeeping and ongoing
improvements.

The team should:

● Regularly verify and test the application to avoid issues caused by library and platform updates, such as a
new SAPUI5 version
● Ensure that the application remains compliant with all applicable standards and guidelines
● Fix bugs in a timely manner, and ensure that the user experience remains of high quality and is improved
and adapted over time
● Listen to user feedback
● Set up alerting that informs you automatically about issues with your application, for example by using
SAP Cloud Platform Alert Notification
● Adapt/extend your application, as required:
○ For deploying new application versions in the Cloud Foundry environment, consider using a blue-green
deployment, in which you deploy a new application version in parallel to the previous version to test it
and to route to the new version only after successful testing and without downtime – for more
information, see Multi-Target Application Commands for the CloudFoundryEnvironment on SAP Help
Portal.
○ In the Cloud Foundry environment, consider using the Feature Flag service that lets you enable or
disable specific features in a production solution, for testing purposes, without having to redeploy or
restart the solution.

 Recommendation

To stay up to date, we recommend that you regularly check the SAP Cloud Platform Release Notes and the
SAP Community .

10.2 Retiring Your Application

If your application is no longer needed, the Cloud Administration and the Cloud Development Teams should
ensure that it is properly retired, and that all data retention requirements are met.

SAP Cloud Platform Planning and Lifecycle-Management Guide

74 PUBLIC Improve and Retire
Important Disclaimers and Legal Information

Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:

● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:

● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.

Videos Hosted on External Platforms

Some videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any
advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within
the control or responsibility of SAP.

Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

SAP Cloud Platform Planning and Lifecycle-Management Guide

Important Disclaimers and Legal Information PUBLIC 75
www.sap.com/contactsap

© 2020 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.

Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.

SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.

Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.

THE BEST RUN