The SAP HANA Cloud 2022 QRC3 release is happening. You can read about the major enhancements in Thomas Hammer’s blog post here. This post describes one of the features: the abstract-sounding “multi-environment” support. Part 2 describes how to get started with the multi-environment SAP HANA Cloud tools.

With the 2022 QRC3 release in October 2022, SAP HANA Cloud is going to be “multi-environment”, where “environment” refers to the Cloud Foundry or Kyma runtime environments available within SAP BTP subaccounts. For many, this will not be the easiest statement to untangle, so this blog post is about what it means and what benefits it brings to users.

The new features are entirely optional at this point, and will appear in public data centers over the next couple of weeks (writing on September 21).

What doesn’t change

But first, some things don’t change.

• Since its release HANA Cloud has run on a separate landscape in each data center where it is available. That landscape has always been a set of Kubernetes clusters managed by Gardener. This is not changing. All existing and new HANA Database or Data Lake instances are created in the same landscapes that currently run HANA Cloud. All your existing databases remain available in exactly the way they are now.
• There is also no change to SQL endpoints (host names and port 443 for client/server connectivity).
• Access to these HANA Cloud landscapes for management purposes has been carried out through BTP Cockpit and the SAP HANA Cloud tools (HANA Cloud Central, HANA Cockpit, Database Explorer) or through the “cf” command-line utility. These have always run in a Cloud Foundry landscape in the same region as the HANA Cloud landscape, but separate from that landscape. While the new multi-environment tools run differently, the existing Cloud Foundry-based HANA Cloud tools will continue to be available for some time. There is no immediate need to change over.
• Even if you do move to the multi-environment HANA Cloud tools, you will not see a big difference in user experience initially. The multi-environment tools themselves are essentially the same as the Cloud Foundry tools, but they are running in a different environment. Over time, most new features will be added only to the multi-environment tools.

It’s not obvious to many of us using BTP where Cloud Foundry-specific concepts start and SAP BTP concepts take over, but Cloud Foundry concepts have been central to the HANA Cloud experience since its launch. All HTTP access to HANA Cloud for database provisioning, management, and development work has gone through the Cloud Foundry user authentication and authorization framework, as you can see in this diagram.

SAP HANA Cloud runs in its own landscape, but most access to it is through Cloud Foundry

As a result, HANA Cloud database instances “belong to” a specific Cloud Foundry “org” and space. To get access to them (for development, management or tooling purposes, not for the SQL endpoint, which is simply a host name and port number) you need the Space Developer role in the Cloud Foundry space where you want to work.

Behind the scenes

So what has changed? Behind the scenes, there are several changes:

• The new multi-environment SAP HANA Cloud tools will run in the HANA Cloud landscape, rather than in Cloud Foundry. As a result they will be available even in subaccounts that do not have the Cloud Foundry runtime environment enabled. This closer coupling between tools and HANA Cloud database instances will enable new innovations and capabilities over time, such as customer-facing management APIs and better integration with other BTP services,
• Just as the Cloud Foundry tools have a command-line interface equivalent using the “cf” CLI, so the multi-environment tools have a command-line interface. It is provided through the “btp” command-line tool used by other SAP BTP services. The btp command-line tool is available from the SAP Cloud Tools page and is documented in the BTP documentation here. The CLI requires your global account to have moved to Feature Set B, Most accounts have already moved: if in doubt you can check as described here.
• Access to the tools and authentication for use of btp is provided through users and role collections defined at the level of the subaccount, rather than the Cloud Foundry space. (In BTP you will sometimes see this authentication framework called XSUAA). The overall authentication and authorization scheme is described in the BTP documentation here. This move to subaccount-based authorization has some benefits which I’ll explain below.

Some benefits

The most immediate benefits are around authentication and authorization, and follow from using the XSUAA BTP subaccount model.

• You can establish trust between a BTP subaccount and SAP Identity Authentication Service (IAS) which provides secure authentication and single sign-on for users in the cloud. As a BTP subaccount administrator, go to Security > Trust Configuration in BTP Cockpit, from your subaccount.
• Once established, you can use IAS as a proxy to your organization’s own identity provider (IdP). This means you can govern access to HANA Cloud by assigning users to groups in your own IdP. You no longer have to maintain separate credentials and authorizations in SAP BTP.
• You can use BTP role collections to bundle HANA Cloud permissions together with other roles (for example, Business Application Studio access) in a way that matches the needs of your projects or operations. Then you can assign your role collection to a group of users in your IdP, and when you add users to that group they will get all the permissions they need (and no more).
• Over time the multi-environment and Cloud Foundry tools will diverge. New features will be added primarily to the multi-environment tools, and not to the Cloud Foundry tools. Moving to the multi-environment tools is the best way to get these enhancements as they are released.
• SAP BTP users who make use of the Kyma environment to run their applications will be better supported with the multi-environment tools. Mapping HANA Cloud databases into Kyma namespaces will come over time.

For developers (Kyma coming soon)

If you are using SAP Business Application Studio to develop calculation views (“native HANA development”) or Cloud Foundry applications, you can still do so with the new model. While HANA Cloud instances are no longer “created in” a Cloud Foundry space, you can still use a feature called “instance mapping” to make them available in one or more Cloud Foundry spaces. This feature is available from SAP HANA Cloud Central: click on the three dots by your instance and choose Manage Configuration, then go to Instance Mapping, where you can map your instance to a Cloud Foundry organization and space to be able to create HDI containers.

Mapping a HANA database instance into a Cloud Foundry org and space

If you are developing applications in the Kyma runtime, you will have to wait a short time for a similar instance mapping feature. We hope to roll instance mapping into Kyma in the near future.

What next?

This post describes the “what” of SAP HANA Cloud multi-environment support. If you want to read about the “how” – instructions for how to get started – then head to Part 2 of this pair of posts.