Skip to Content

This is part 1 of my blog series about cloud architecture with SAP Cloud Platform. Find the series overview here.

I chose to start this blog series with an explanation about SAP CP Global Accounts and Sub-Accounts. To me, it’s one of the first things you should think about when introducing SAP CP at a customer. This task corresponds to the landscape planning that you typically do for an on-premise landscape so the architectural design decisions you make here are quite fundamental. I also observed that not many people know about these concepts because many only have experience with the SAP CP Trial Accounts, which do not make the underlying SAP CP account structure visible to the user. At real customers, of course you must not use Trial Accounts productively, especially for legal and support reasons! 🙂

So let’s get started. When I first approached the account topic I was quite confused, but the following figure that was created by my colleagues from product management (I don’t know who it was, but thanks to you, good job!) really helped me in understanding and explaining the concept:

You see that in this picture, three sub-accounts are structured in one Global Account. So what’s a Global Account then?

Basically, when a customer decides to purchase a productive SAP CP “account” (and in this case, “account” is technically not the correct term, one could better say “when a customer decides to sign a SAP CP contract” (which is of course in the productive landscape)), then the customer receives a Global Account.

All metrics like quota and resources, or amount of Java Compute Units, even billing, is done for this Global Account. A Global Account is always associated with one datacenter. You cannot have a Global Account that has machines from multiple datacenters or geographies. This is the first thing you have to consider: Where do I actually need my Global Account to run? Compliance reasons, for example, might quickly answer this question for you.

Moving on, a Global Account is more or less just an empty shell. You cannot do much with it apart from looking at your overall resource consumption. You cannot run applications or services directly in a Global Account. For these tasks, you’ll actually need Sub-Accounts. (Just as a remark: when you sign up for a trial account, what you receive a dedicated Sub-Account. You have no direct control over the trial landscapes’ Global Accounts).

As you can also guess from the above picture, a Global Account can host many Sub-Accounts. This is what a typical Global Account at a customer could look like (here we have six Sub-Accounts):

You can create new Sub-Accounts in the Cockpit easily with the “New Account” button on the top of the screen:

In order to understand and be able to plan how many Sub-Accounts you might need for your SAP CP project(s), first we have to understand what a Sub-Account actually is.

When I explain the concept of a Sub-Account to a customer, I typically compare the Sub-Account with an on-premise NetWeaver system that is now in the cloud (this is not a perfect definition as such but in my experience, many customers understand the similarities and concepts when I explained it like this).

A Sub-Account

  • Can host different applications simultaneously (Java, HTML5, and XS)
  • Can have zero to many database systems connected to it (you could even share database systems between Sub-Accounts to some extent, please consider the documentation for this)
  • Has at least one trust configuration (the configuration where you maintain users, groups, roles, … (there will be another blog in the future for this)
  • Has one or more SAP Cloud Connector(s) connected to it
  • Has a set of destinations (to on-prem or internet systems) that you can maintain and that all applications in that Sub-Account can consume and share
  • Has ONE dedicated area where you maintain the administrators and developers for this Sub-Account (these users are called “Members” on HCP)
  • Has zero to many Java Compute Units to host Java applications
  • Has a git repository service where you can host many repositories for different projects
  • Has other HCP Services assigned to it that can be configured and used differently for each Sub-Account

This is what the configuration start page for a Sub-Account in SAP Cloud Platform looks like (“Cockpit”):

This page should look familiar to everyone who has experience with the SAP CP Trial Account. In productive environments however, you’ll notice that you can switch between different Global Accounts and Sub-Accounts in the upper center area of the screen.

From an architectural perspective and in order to plan the “Cloud Landscape”, I would at least consider the following questions:

  • Do I need more than one Global Account?
  • In which landscape should I host my Global Account(s)?
  • How many Sub-Accounts do I need? When does it make sense to have more than one Sub-Account?
  • Should I host multiple projects in one Sub-Account? To what extent do I want to share configurations and services between projects/development teams in my Sub-Accounts?

Of course, all these questions can be answered differently for each customer. So my recommendations are just my experience which you might not agree to. Also, these recommendations could also change if certain features of SAP CP are changed in the future (which is definitely possible in the rapidly changing cloud world today).

  • If you want to transport an application between DEV, QA, and PRD for staged application development, it might make sense to have three Sub-Accounts so you can transport between the Accounts (I will release another blog that deals with transporting)
  • If you have completely different scenarios, it might make sense to distribute the scenarios/projects across different Sub-Accounts because it will make your configuration a lot easier (side-effects, access restrictions, …)
  • If you have different development teams working on your projects, I would assign different Sub-Accounts to the teams so that they do not influence each other
  • If you need different trust configurations for each Sub-Account (one for example using SAP Cloud Identity Service as a user store and another only an internal Active Directory), it might make sense to create individual Sub-Accounts with different configurations
  • If your applications and the administrative access to these applications (developers, administrators, and support users) have to be restricted, it might make sense to have separate “high-security” accounts. You assign the “Members” of each account (like developers, administrators, and support users) individually to each Sub-Account. Also the backend systems that are available to your cloud applications are exposed separately per Sub-Account. With separate Sub-Accounts, you have more control over the access to your backend systems.
  • Data security requirements and compliance rules will tell you whether you need more than one Global Account and also where to host your Global Account(s). Also network latency reasons might influence your decision concerning the datacenter.

You see that there are many reasons to introduce many Sub-Accounts in your cloud landscape. But there are also reasons to not always have separate Sub-Accounts for each project/application:

  • HANA Database systems are assigned to one Sub-Account and sharing them, although technically possible to some extent, might cause confusion and unwanted complexity in the landscape. Although you can consume the DB services (e.g. xsjs OData services) from other accounts in HTML5 web-applications (with Java applications it’s a different story), the maintenance and database administration is accessible from one Sub-Account. So if you have multiple similar projects sharing the same developers, same application architecture, and same database, why not gather them in one Sub-Account?
  • Configurations have to be made individually for each Sub-Accounts. If you have many Sub-Accounts, this means more configuration work for your administrators (or less, if it makes your life easier when separating multiple projects on one Sub-Account)
  • Connections to on-premise systems have to be made separately for each Sub-Account. Although you can copy the settings, still, you’ll have to maintain them separately. On the other hand, it’s easier to just shut-down all integration paths for one project when you just have to delete all integrations to one Sub-Account on the Cloud Connector.

In general, I would argue that there are many good arguments to make frequent use of the feature of creating new accounts. You can even create new accounts via the command line so you could automatize the creation (which could be a really cool feature if one of your customers orders a development environment for a new project in the customer’s internal shop system and automatically, a new account was created for that project team… 🙂 ).

An additional topic that I do not want to cover in all detail but that nevertheless should be considered is the structure of your HANA databases in the cloud. Since there is the concept of Multitenant Database Containers (MDC), you can basically use a database system to host multiple independent HANA databases. Independent in that case means that although the databases share the same “physical” machine (= resources) and also the same HANA revision (important restriction!!), they have completely independent configurations, user management, and database content. Since not that long ago, you can also share database systems between accounts, so that you potentially can use the same HANA database system in multiple Sub-Accounts where each Sub-Account has an independent HANA database connected to it. With this, SAP is adding a lot more possibilities to landscape design and SAP CP subscription cost (distribution between projects), but I really want to cover this later as I think for now, you’ll probably have enough information already to digest.

Summing up what we covered already, I just would argue that it really makes sense to put some effort in proper Global Account / Sub-Account planning. Involve also management in those discussions and find out how they plan to extend the SAP CP landscape in the future. This might give you good guidance of how you have to plan your landscapes because your decision may significantly influence subscription costs and extensibility of your future SAP CP landscape.

Feel free to contact my SAP colleagues or me if you need advice for your projects! Let me know whether you have learned something in this blog or if you have questions!

Cheers, Jakob

For further information, please consult the official documentation. I recommend the following pages:
https://help.hana.ondemand.com/help/frameset.htm?8ed4a705efa0431b910056c0acdbf377.html
https://help.hana.ondemand.com/help/frameset.htm?c4c25cc63ac845779f76202360f98694.html

To report this post you need to login first.

18 Comments

You must be Logged on to comment or reply to a post.

  1. Mike Doyle

    Thanks Jakob, nice blog. Most customers will probably go for 1 sub-account for each back-end environment, but they should consider the options carefully. I’m a big fan of having a ‘pre-prod’ environment but it only really makes sense if you have a back-end pre-prod too.

    The new option to set specific versions for each app on the launchpad does make the single sub account option slightly more feasible I guess. Wouldn’t be my choice though

    (0) 
    1. Jakob Moellers Post author

      Hi Mike, thanks for your comment. Yes, you are right but some of my customers do not use the launchpad. Others might have different trust configurations (especially because group names can differ between environments, so you have different group names between dev, test, and prd), so in those cases, it’s much ‘cleaner’ with separate Sub-Accounts. Cheers, Jakob

      (0) 
  2. Michael Appleby

    Perfect timing as the question of subaccounts and managing different tiers just came up for one of the customers I work with.  Your blog covers the topic rather well and more clearly than the help docs I usually have to work with.

    Greatly appreciate your efforts and presentation of a sometimes confusing topic.

    Cheers, Mike (Moderator)
    SAP Technology RIG

    (1) 
  3. Michael Kaufmann

    Hi Jakob,

    if I understood it right if a customer has two or more Global Accounts his data are in different datacenters / geographies. Is there a kind of replication availabale or a kind of data hub? Otherwise I would loose (in my opinion) exactly what f.i. S/4 HANA with one common datastore (no more distributed data in different ERPs, CRMs, SRMs and so on) promises and I would need a kind of “Cloud-BW” to do for example reporting or planning for a globally operating company.

    Regards,
    Michael

    (0) 
    1. Jakob Moellers Post author

      Hi Michael,
      for those kinds of integration scenarios, I would strongly suggest you familiarize yourself with the following topics:
      – HCP Integration Services (previously known as HCI)
      – SDI and SDA
      – API Management on HCP
      Probably, with these services or tools you can still “synchronize” your data depending on your use case.
      Additionally, I would also recommend you to familiarize yourself with the intended use cases for HCP. I think the examples you mentioned are not really the use cases where HCP fits (or I did not understand your examples, sorry if that is the case!). S/4 Cloud Edition or HEC (where you’d have ERP, CRM, …) might have different solutions for your multiple geographies issue… I am not an expert on these topics. For HCP however, I can tell you that the geography “restriction” actually has many benefits when it comes to compliance questions (“European data has to reside in European datacenters…”) and from my experience, SAP has quite many integration, virtualization, replication, and synchronization solutions that you could use. I’d be confident that something in the portfolio fits your requirements here.
      Cheers, Jakob

      (0) 
    2. Midhun VP

      Hi Michael,

      For the replication of data based on your requirement as Jakob suggested you can use other solutions from SAP. Ex. HCI DS.

      The major reasons for multiple global accounts are:

      1. Data privacy: If the customer has business in different parts of the world and it is important to keep data in respective country or continent of business multiple global accounts are suggested.
      2. Latency Issues: If the users of the app are from different continents like USA and Europe, considering latency issues it make sense to have 2 global accounts – one in USA and other in Europe.
      3. Other business/development reasons: If the company is a large conglomerate, they can have multiple global accounts because businesses or entities are independent to each other.

      Note that customer has to sign multiple contracts to have multiple global account.

      Regards,

      Midhun VP

      SAP Cloud Platform Customer Success Team

       

      (0) 
  4. Srivatsan Sundaravaradan

    Hi  Jacob,

    Good blog on Cloud accounts in HCP.

    If I am using the HCP services like IoT service, Can I configure the services for each sub account?

    Once I have configured the IoT service in Sub-account1, the service doesn’t even show up in Services area of Sub-Account2.

     

    Cheers,

    Srivatsan

    (0) 
    1. Midhun VP

      Srivatsan Sundaravaradan

      You will have only one instance of these services: IOT, Compute Unit, Virtual Machine and HANA DB and Custom Domain. That’s why you are not able to see IOT in your second sub account.

       

      Regards,

      Midhun VP

      SAP Cloud Platform Customer Success Team

       

      (0) 
  5. Bidwan Baruah

    Great Blog Jakob!

    I have a question. When I  rename a existing Sub Account in Cockpit, changes are not reflected in Hana Cloud Connector. Why is that and how to fix it? I tried to Disconnect and Connect again, but still it reflects the old Name.

    Thanks,

    Bidwan

     

     

     

    (0) 
    1. Jakob Moellers Post author

      Hi Bidwan,

      thank you for pointing this out.

      I suspect the Cloud Connector resolves the unique account id (from the hana.ondemand.com-URL) at the time you enter the sub-account’s name when connecting the SCC to a new Sub-Account. Once the connection is established, I suppose the Cloud Connector only uses the id and not the name anymore. Probably, you should open a ticket to report the missing update mechanism for the Sub-Account name.

      Best regards,

      Jakob

      (0) 
    2. Arun Rajamani

      while configuring your sap cp account with Cloud connector you only give

      (0) 
  6. Simen Huuse

    Hi Jakob, this is really a great blog – and I would like to see more on the same topic.

    With an SCP landscape consisting of several sandbox/dev tenants, admin rights are (at least in my case) distributed to several users. Is there a way for admins of the main account to limit the feature of creating more sub accounts without revoking admin rights? It would be quite useful to let someone be admins to an account but without the ability to create more sub-accounts.

    Another thing on my wishlist is the ability to see which users created sub-accounts and for me, as an admin of the main, global account, to access all sub-accounts.

    Maybe others have encountered the same issues – so please comment 🙂

     

    Kind regards,

    @simenhuuse /Simen

    (0) 
    1. Jakob Moellers Post author

      Hi Simen,

      I fully agree to your remarks, such functionality would be very useful. Currently, the permission to create new Sub-Accounts cannot be taken away from administrators. From the current roadmap slides, you can see that there might be a new feature that allows building your own “Global Account Roles”. This could be a way to solve it, but I currently don’t know whether there will be an explicit permission to create Sub-Accounts.

      What you can do is execute the “list-accounts” command from the console client. This will give you a list of Sub-Accounts from your Global Account. When I last tested it, this command gave ALL Sub-Accounts in your Global Account and not only the ones your user has member privileges on. So with this, you could monitor whether users create their own Sub-Accounts without permission.

      Who created the Sub-Account will only be visible in the Member History of a Sub-Account however. The creation time is listed in the Cloud Cockpit or the “list-accounts”-command-output.

      Kind regards,

      Jakob

      (1) 
  7. Andrés Nebel

    Hi Jakob. Regarding the following comment, where can I found more information about transporting between accounts?

    • If you want to transport an application between DEV, QA, and PRD for staged application development, it might make sense to have three Sub-Accounts so you can transport between the Accounts (I will release another blog that deals with transporting)

    Thanks in advance!

     

    (0) 
    1. Jakob Moellers Post author

      Hi Andrés,

      I will write a blog about this, writing is currently in progress. If you want to find more information already, search for “MTA”, “Solutions”, “CTS+”, “Solution Manager with Cloud Platform” or similar…

      Depending on your scenario, there are different methods that might be feasible, so stay tuned for the upcoming blog.

      Kind regards,

      Jakob

      (0) 
  8. Joshua Kneen

    Hi Jakob, in my experience some services do port nicely across accounts whereas some do not (HANA for example) … have we got an illustration, or even a list that defines which services suit being moved across accounts and those that do not? Typically for three tier environments (dev, qa prod)

    (0) 
    1. Jakob Moellers Post author

      Hi Joshua,

      sadly, I am unaware of the existence of such a list. But creating it is a great idea! Maybe that would serve as good content for the next blog 🙂

      Best regards, Jakob

      (1) 
      1. Joshua Kneen

        If you could work on that it would be great …. the majority of queries I get in the UK is about cloud administration as much as it is capability and security. Thanks for the response. Josh

         

        (0) 

Leave a Reply