Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

This article is ideal for those starting out with SAP Datasphere and wishing to understand, at least at a high level, how life-cycle management works, and what ‘Spaces’ are all about. For example, can Spaces be used for life-cycle purposes (dev, test, prod), what are the limitations that Spaces have for life-cycling management and what are the best practices? These and other commonly asked questions are answered in this article, which is also available as a video.

In this article, I refer to another presentation on Datasphere Security. I'm currently working on this presentation and hope to make it available soon. Please stay tuned for updates.

Feel free to post a comment, but if you'd like a reply please instead post a question. (Since only 'questions' enable replies and keep the context of the question)

Matthew Shaw



Download or Preview presentation.pptx, Version 1.0, February 2024
Watch this presentation (37 minutes).mp4, Version 1.0, February 2024


Tenants and Spaces

1 SAC and DSp relationship.jpg


SAP Datasphere Services (Tenants):

  • Subscription-Based Tenant
    • Provisioning is performed by SAP, only 1 per subscription
  • Consumption-Based Tenant (Standard Plan or Free Plan*)
    • * limitations - SAP Note 3227267
    • Provisioning is performed by the customer in SAP BTP (doc), so can easily create more

Relationships with SAP Analytics Cloud Services (tenants):

  • No real limitations, each SAP Analytics Cloud Service can connect to multiple Datasphere Services
  • However, the ‘Product Switch’ in Datasphere can only point to a single Analytics Cloud Service. It’s just a ‘button’, not a limitation per see

4 Spaces and Users.jpgWithin each Datasphere Service (tenant):

  • System Owner, and other ‘DW Administrator’ users, can:
    • create 1 or multiple Spaces
    • perform other tasks, such as creating users, and roles, and assigning users to Spaces

Each Space

  • Is a secured container
    • Users need access to a Space to access the resources held within it
    • Content can be shared with other Spaces allowing additional access
  • Holds all content:
    • Tables, views, models, data flows, replication flows, task chains, etc.
  • Grants resources:
    • CPU, memory, disk
    • Priority, statement limits
  • Space Administrators can also grant users access to their Spaces

5 Space configuration.jpg

Forethought is required when creating Spaces

  • Need maximum reusability, for example:
    • Avoid the need to replicate data into more than 1 Space
  • Enforce security with minimum effort
    • It is possible for a single user to have different access rights in different Spaces
    • (see the next presentation on ‘scoped roles’ for more)
  • Only 1 Space can have SAP HANA Cloud data lake access
    • Though read access can be shared with other Spaces
    • Only the original Space can write to data lake
      • Even when using Open SQL Schema, the Space grants access
      • Blog provides an example of data lake access by multiple Spaces

Spaces – boundary conditions

6 Content within Spaces not across Spaces.jpg


Content within Spaces:

  • No means to ‘move’ or ‘copy’ content across Spaces
    • Can only move or copy within a Space
  • Most content can be shared across Spaces within the same Service (tenant)
    • Enables segregation and security controls (see later)
    • For example, tables, views and models can be shared across Spaces
  • Some things cannot be shared across Spaces within the same Service (tenant) including:
    • Connections, Data flows, Replication Flows etc.
  • Service-wide (tenant) configuration settings including:
    • Authentication Configuration (SAML SSO) setup
    • OAuth Clients (API) access
    • BTP Sub Account for use with the SAP Cloud Connector
    • SAP Data Provisioning (DP) Agent
  • Import and Export of content is possible and needed for lifecycle management (see next)

Tenants and Spaces, Sub Accounts


7 manual export and import via CSN json files.jpg



  • Best to avoid using different Spaces within the same Datasphere Service (tenant) for different lifecycle use
    • All objects (models, tables, connections etc.) relate to each other by ‘ID’. It means any manual export/import is technically possible, but prone to error and somewhat complex to ensure IDs are consistent
    • Some customers have used Spaces for lifecycle use in this way, knowing this limitation, but it can be challenging to do so

8 one or multiple BTP sub accounts.jpg



  • For BTP ‘Consumption-Based Tenants’:
    • Single BTP Sub Account has no significant advantage compared to multiple Sub Accounts
      • However it is best practice for ‘dev’ and ‘prod’ to have their own BTP Sub Account, so this is often the preferred choice
    • We recommended a SAP Cloud Connector per environment (dev, test, prod) regardless of which option you pick

Lifecycle management

9 Content Network.jpg

 Best practices


  • Use a Datasphere Service (tenant) per environment (dev, test, prod)
  • Use the Content Network to transport content, a cloud-based file system
    • Some content can also be exported/imported via CSN* JSON files
    • (* Core Data Services Schema Notation) either manually or via command line
  • Do not name content by its lifecycle phase
    • instead, keep all names generic such as ‘Sales’ avoiding ‘SalesDEV’
  • Do not name content by its version
    • Instead, avoid the version number, add that to the description or use ‘Packages’ (see later)
  • Not all content can be transported (export/imported)
    • Need to manually recreate some content ensuring it matches by ‘ID’
    • Includes Spaces and connections*. Spaces must be recreated manually in each Service before any content can be imported into it
      • * Roadmap item for wave 2024.03 subject to change
    • Where possible create content once, then transport it to ensure IDs are consistent across the landscape
  • Exportable/Importable content:
Definition ofPackage via Content NetworkCSN/ JSON fileNotes
Local tablesYesYes 
Remote tablesYesYesEnsure connection in source and target match
Flows (data, replication, transformation)YesYesIncludes source and target tables
Intelligent LookupsYesYesIncludes inputs and lookup entities
Analytic ModelsYesYes 
E/R ModelsYesYesDoes not include dependencies, requires manual selection
Data Access ControlsYes Includes permissions entity
Task ChainsYes Includes all objects it automates
Business Entities / Business Entity VersionsYes Includes all its versions, source and authorisation entities
Fact ModelsYes Includes all its versions and business entities
Consumption ModelsYes Includes all its perspectives, source fact models and business entities
Authorization ScenariosYes Includes data access control

Lifecycle management - Content Network best practices

10 Content Network Best Practices.jpg

 Best Practices when using Content Network


  • Avoid sharing individual export packages
  • Instead
    • Create folders and share the folder with the other Services (tenants)
  • Store the export packages in pre-shared folders
  • Naming convention is important to help understand dependencies and responsibilities
    • See guidance on a naming convention. Consider including Space name, data source

Useful insights

11 Modify Content in a package.jpg


  • To re-capture any changed content:
    1. Edit the existing export package
    2. Enable ‘Modify content’
    3. Re-export the export package
  • This loses the previous delivery package unless manually downloaded beforehand
    Dependencies are typically identified

12 Content Network download package.jpg

  • An export package can be downloaded and re-uploaded
    • Whilst not intended and not ideal, it enables a form of version control or backup
    • Manual download/upload is required when transporting across Data Centres

Lifecycle management – 2 types of Packages

13 Delivery Package.jpgDelivery Packages

  • The transport mechanism transports these types of packages
  • Export process creates an export package based on a delivery package
  • Can contain content from multiple Spaces
  • Whilst dependencies are automatically detected, it could become complex or confusing when mixing multiple shared contents from a ‘matrix’ of dependencies

13 Repository Package.jpgRepository Package

  • Means to package content within 1 Space only
    • a kind of ‘sub-Space’ idea
  • Has a version concept which should be used
  • Modellers can add certain objects to packages without the need to be a Space administrator
    • Space administrator still needed to export/import
  • Modeller mandates all dependencies within a single package
    • Not across packages, as that’s done automatically
  • These Packages can be added to Delivery Packages as a single object
    • thus, removing some complexity for other users
    • helps to reduce unnecessary redundancy for complex use cases
  • More about Package dependencies next…

Lifecycle management – Packages and dependencies

14 Required Packages.jpg



  • Can contain many objects from a single Space
  • A single object can only exist in 1 Package
  • Packages can contain other Packages, they are identified as ‘Required Packages’
    • Required Packages can be from other Spaces

15 Package Dependancies.jpg


  • Requires Packages example (doc)
    • Package A1 is a required Package of B1
      • An example of a shared object from a Package in a different Space
    • Package B1 is a required Package of B2

Lifecycle Management Summary

16 initial setup.jpg

  • Most customers start with a single Datasphere Service, even if they have multiple Analytics Cloud Services
  • Avoid naming Spaces that you expect to last with any lifecycle naming reference
    • Avoid ‘ProdSalesSpace’ for example

9 Content Network.jpg


  • As adoption increases, multiple Datasphere tenants become increasingly needed to manage lifecycle content