Abstract

The infrastructure costs to run applications with SAP Cloud Platform ABAP Environment (Steampunk) are mainly driven by the costs per ABAP system. In order to run several customers on the same ABAP system, multitenancy is required. Multitenancy support comprises two aspects. First, Steampunk needs to provide the required capabilities which are planned for the next releases. Second, the application must be developed according to dedicated rules in order to, for example, ensure a content separation between different customers.

This document describes these rules as a development guideline to build tenant-aware applications on top of Steampunk. These rules can be applied immediately, even before the Steampunk infrastructure capabilities are available.

Architecture Overview and Basic Concept

Multitenancy defines the capability to host different customers (tenants) on a single, shared computing infrastructure in order to optimize administration and significantly reduce TCO. A tenant is an organizationally independent unit whose IT business (or parts of it) is operated together with the businesses of other tenants by a hosting provider. Multitenancy is especially relevant in a “software as a service” (SaaS) business model where customers subscribe to hosted software solutions rather than buying and installing them. From the perspective of a hosting provider, the operation costs per user per tenant are a decisive factor. This applies even more in the SME market, where typically each tenant will only have a small number of users (10 – 50) accessing the hosted solution. It is obvious, that the hosting provider can only operate profitably, if he succeeds in keeping the administration and maintenance costs for the hosted solution as small as possible. Of course, this cost pressure also limits the degree of individualization and customization a hosting provider is willing to accept for a hosted solution for many tenants.

To achieve a breakthrough in TCO reduction, a way needs to be offered to host multiple tenants in one ABAP system. Therefore, we provide guidance how you can build a multitenant enabled solution. In this document we will use the term multitenancy. More specifically, we will only use multiple clients in the ABAP environment as a technical means to implement multitenancy.

There are two basic principles with regards to multitenancy. The first one reflects the expectation of a tenant:

Strict data isolation is guaranteed between tenants on all levels of the system. A tenant must be sure that his data (and its tenant-specific application extensions) are under no circumstances mingled with the data or applications of any other tenant being operated in the same system.

The second one is from the hosting provider’s point of view:

The costs for operating multiple tenants in the same system must be significantly lower compared to single tenant systems. Multitenant systems must reduce the TCO of a hosted solution in such a way that the business case is met. Please note: Multitenancy is only one means to reduce the marginal costs of operations addressing system and hardware costs.

To some extent, these two principles are contradictory. The first one could be most easily fulfilled by single tenant systems, whereas the second one imposes the need for sharing resources on each system level, for example, hardware, database, application server. So, multitenancy can be described as a sharing of as much system resources as possible without violating the principle of tenant data isolation. This document describes the design principles how multitenancy can be achieved in Steampunk by an evolution of the present multi-client capability of an ABAP system.

Tenant isolation is not completely ensured by the Steampunk infrastructure, but the infrastructure allows to develop multitenant-aware applications by following certain design principles.

Terminology

Steampunk is a Platform as a Service (PaaS) offering for ABAP. In a typical scenario for Steampunk, an independent software vendor (ISV) develops and runs a Software as a Service (SaaS) application on Steampunk and sells this application to their end-customers. In order to avoid confusion with the term “customer”, as the ISV is also a customer of Steampunk, the following terminology is used in this document:

The service provider of the SaaS application is responsible to develop, maintain and operate the application on top of Steampunk. It is typically an ISV or development partner.

The provider system is a Steampunk ABAP system to run the SaaS application operated by the service provider offering multitenancy capabilities.

The service consumer of the SaaS application is an end-customer of the service provider who has subscribed a tenant in a provider system.

Assumptions and Limitations

The following items are the foundation of the multitenancy support in Steampunk:

• Multitenancy is only supported in provider systems operated by the same services provider to run a single SaaS application.
• Multitenancy is not supported for the development scenario using the ABAP Development Tools (ADT). It means, neither several service providers can share the same system for development, nor a consumer can further develop or extend the provider’s SaaS application using ADT.
• You as a service provider can build a multitenancy application following the respective guidelines.
• There is no system-controlled process to ensure that you as a service provider really build your application in a multitenancy compliant way. If a strict data isolation is a legal requirement, we propose an external audit to ensure that your code does not break the data isolation.
• There are options to share data between tenants. Furthermore, native SAP HANA database access via ABAP-managed database procedures (AMDP) requires special considerations. It is only documented which functionality does have which impact on client isolation. There is no check ensuring that you as a service provider use these features in a multitenancy compliant way.
• To ensure tenant lifecycle procedures, it is essential that the applications are built in a way that the procedures for tenant copy, tenant move, and tenant delete can deal with it. It is crucial to comply with these aspects of the guideline as this would create issues where SAP, you as a provider and the consumer are involved.
• There is no system-controlled process to ensure that you as a provider really build your application in a tenant lifecycle management compliant way.
• Security and system logs store data in a cross-client persistence together.
• Any multitenancy-specific certifications from SAP in addition to the already existing SAP Cloud Platform ABAP Environment product certifications are out of scope.
• A dedicated support for Key User extensibility of the SaaS application is on our roadmap.
• Inbound RFC communication is currently not supported for multitenancy (calling an RFC in Steampunk from an on-premise system).

Guidelines for Multitenancy Applications in Steampunk

The following sections list the relevant guidelines for content separation in multi-client systems. We use the multi-client architecture of the ABAP system for multitenancy enablement and list here the design principles to reach multitenancy.

Overview About the Must-Haves

The following list provides a comprehensive overview for the readers who are experienced with the multi-client approach of on-premise systems. Most of the rules are well-known and well-established for on-premise ABAP systems. You can find more information in the subsequent sections.

• Store tenant-related data in client-dependent tables of type A, C or L.
• Store system-related data in client-independent tables of type S.
• Always add the selection of the current client to ABAP database procedures (AMDPs).
• Do not generate development objects or other client-independent data system-locally in the provider system.
• Do not evaluate the actual value of the 3-digit client field (IF sy-mandt = ‘nnn’. …. ENDIF.)

Database Table Design

Database tables must be classified according to their content. We differentiate the following types:

Tenant Content (client-dependent)

• Tenant configuration data – tables with delivery class “C”
• Tenant application data – tables with delivery class “A”
• Tenant temporary data – tables with delivery class “L”

Database tables for tenant content must be client-dependent. That means, that the first field of the table must be of datatype “CLNT”. We recommend using the inline declaration „abap.clnt“.

Only the content of client-dependent “C” and “A” tables is considered during tenant copy and tenant move. Content of client-independent tables which is not delivered from the development system and “L” tables will be lost during tenant lifecycle processes like tenant move.

During tenant delete, the content of all client-dependent tables is removed.

The delivery class must be “C”, “A”, or “L”.

The delivery classes “E”, “G” and “W” are not supported in Steampunk at all.

System Content (client-independent)

• System configuration data – tables with delivery class “S”

Data which is defined by the service provider and not specific for any tenant shall be stored in a client-independent “S” table. The content shall be defined in the respective development system and exported as TABU entries via a development transport request. The content is considered as code and imported like other development artefacts into subsequent systems like the provider system.

Database Table Access

Read Access Using ABAP SQL

Whenever you access table content you must ensure that tenant isolation is not violated. ABAP SQL does not support additions like CLIENT SPECIFIED or USING CLIENT in Steampunk. As a result, access to another client than SY-MANDT is technically not possible. But it is required to define client-dependent tables properly that the ABAP runtime applies this role accordingly.

Write Access Using ABAP SQL

“S” tables must not be written in the provider system. Otherwise, this content is not considered during tenant lifecycle management events like tenant move and content gets lost. In addition, tenant isolation is violated since every tenant will immediately have access to the changes.

Access Using AMDP

Access to SAP HANA database using AMDP is not controlled via the ABAP database interface. The actual client is just handed over as a parameter. This can easily violate the content separation and access a table data for another client. Make sure that the client is always passed via SY-MANDT.

Code Generation

Development artefacts (Data dictionary objects, classes, interfaces etc.) which are typically created via ABAP Development Tools (ADT) are always client-independent. Changes are always recorded in transport requests.

Generation of such development artefacts must not take place in a non-development system like a provider system. It violates the content separation and will not be considered during tenant move and copy procedures. Generation of development artefacts in Steampunk is only allowed in development systems. The XCO library can be used for that purpose. In case of generation, it is the responsibility of the service provider to ensure, that the generated artefacts are transported into all required provider systems. Standard life-cycle events like tenant move will not consider such client-independent artefacts.

Multitenant Aware Programming

Cross-Client Locking (Enqueue)

Lock Objects are associated to database tables or structures. The runtime API in Steampunk is CL_ABAP_LOCK_OBJECT_FACTORY and the returned instance of type IF_ABAP_LOCK_OBJECT.

You need to make sure to lock only client-dependent database tables or structure having a CLIENT field.

CL_ABAP_CONTEXT_INFO=> GET_SYSTEM_DATE and TIME

The system date/time (methods CL_ABAP_CONTEXT_INFO=>GET_SYSTEM_DATE, CL_ABAP_CONTEXT_INFO=>GET_SYSTEM_TIME) is always based on UTC time zone. The system time zone cannot be changed tenant-specifically. As a usual approach in cloud environments, it needs to be considered in your code, as it gives the same date and time for all tenants.

Usage of System Information (sy-sysid and sy-mandt)

Storing SY-SYSID and SY-MANDT explicitly in database tables is not allowed. This would lead to issues after tenant copy or tenant move, because both values are not unique and not stable in the whole system landscape. A dedicated API will be provided to get a unique and stable identifier for the tenant.

Connectivity

Outbound communication management in Steampunk differs from the on-premise usage of SM59 destinations. See Consuming External Services for details. Destinations are configured in a Cloud Foundry destination service and the ABAP consumer API references these destinations.

Please take into consideration, that Steampunk supports only one communication configuration layer which is intended for the consumer. It is currently not possible to enforce a communication configuration exclusively managed by the service provider within the consumer tenant.

There is a limitation in the area of inbound communication: Inbound RFC is not supported.

Exceptions

There might be some use cases where the guidelines provided are not applicable, for example, sharing of data across tenants or sharing of aggregated customer data.

For such use cases, the operations concept needs to be documented and an alignment with SAP is required. It is recommended to check the operational impact on tenant move and tenant copy procedures. In addition, a review for multi-client content separation is recommended.

Usage of SAP-Delivered SAP Fiori Apps

SAP has delivered several SAP Fiori apps for the administration of a Steampunk system. These SAP Fiori apps are targeting different roles like administrator, project manager, developer. Regarding multitenancy, several of these apps are covering client-independent objects and configuration according to their purpose. For example, SAP Fiori app “Manage Software Components” is intended to import software component which has an immediate impact on all tenants. Therefore, you need to include SAP-delivered business catalogs carefully into the business roles of your SaaS application.

Conclusion

Following the described guidelines is a prerequisite to run an application developed on top of Steampunk in a multitenancy mode. Although multitenancy is not supported in the current Steampunk release, the explained guiding principals can be applied immediately.

Original Article:
https://blogs.sap.com/2020/06/02/development-guideline-to-enable-multitenancy-for-applications-built-on-sap-cloud-platform-abap-environment/