Skip to Content
avatar image
Former Member

Clarifications regarding HDI container mechanism

Hi All

I am in the process of understanding the process of building database objects using HDI container. Below are few points which I would like to clarify whether my understanding is correct or not , also few questions about which I am unaware of . Request you to share your thoughts.

I am very sorry for listing many points in below , but I thought that all these points are related to the same concept , hence tried to consolidate them in single place.


A project has 3 database modules [HDB modules] , at the runtime we have 3 containers respectively for each schema.

i) Also for each HDB module there will be three schemas created as below

a) container

b) container#DI

c) container#OO

Each container has one Technical user (or) Application user [HDI_USER] & Database user [USER].


For instance if a project has one HDB module , which has a container and users associated with that container . If we are trying to query data from tables part of this container , the technical user [HDI_USER] of the container is being involved to read data from tables part of this container.


When we are trying to access objects outside this container , there are 2 scenarios as below

i) access to tables from other HDI container schemas - In this case we have to create .hdbrole as part of the source container and refer this hdbrole in target HDB module as part of .hdbsynonymgrantor file with necesary privileges as part of the target container,also refer the .hdbrole in required resources in .yaml file of the target HDB module

ii) access to tables from replicated schemas (or) non-HDI container schemas - create user provided service [CUPS] and then assign it to HDI user of this container using .hdbsynonymgrantor file.


In vice- versa case , like accessing the tables of HDI container in non-HDI scenarios we need to create .hdbrole for this container and grant this role to database user (or) call procedure part of container#DI schema to grant necessary authorizations to the non-HDI scenarios.


  1. Is there any way the generated schema (or) container name can change ?
  2. What is the role of database user of a container ?
  3. When we are creating .hdbsynonymgrantor for cross- container scenarios, I came across a syntax where the GUID of source container is specified as part of the file , but if we deploy the same module in quality & production the id might change - correct me if my understanding is wrong.
  4. From a team of developers perspective , if there are mutliple members working in a team each user will have objects as part of thier owne container , but when we have to package a solution to deploy in quality & production systems how does this work the application still will have multiple containers with cross- container access (or) os ther any other way when we are working in a team. 4) Also as per my understanding the container mechanism is introduced to support github , but could not understand how these two are related (or) affect each other , any insights on this would be helpful.
Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Jan 05, 2017 at 02:17 PM

    1. Yes the generated names can change upon transport/creation on a different system. You therefore shouldn't interact directly with the generated names.

    2. The database user is the owner/creator of any objects within the container schema.

    3. You should use the SERVICE_REPLACEMENTS option to use an alias name instead of coding the actual foreign container or user provided service name. See the example of this in the openSAP course:

    4. Why would you have multiple containers? Each person in a team should be creating a separate container really. Each checks out their project and has a separate container instance, but when you merge all the sources back together in Git and then build the MTA, the downstream installation of the application will only have one container.

    Add comment
    10|10000 characters needed characters exceeded

    • I would personally do something like approach 2. I think this is where you should separate any foundation objects (those that get populated with data) and consumption (Calc Views) into separate containers. That way you can deploy the foundation container into the development space and others can test against it with synonyms that aren't pointing to a developers' sandboxed, temporary version of the container.