Clarifications regarding HDI container mechanism

[former_member259926]

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.

Clarifications:-

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.

Questions:-

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.

[thomas_jung · Accepted solution]

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: https://github.com/SAP/com.sap.openSAP.hana5.example/blob/master/mta.yaml

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.

[Former Member · Accepted solution]

Hi Thomas,

We are planning to build Calculation Views in HDB module, these Views will be consumed by reporting tools to create Reports.

While building a reporting solution we need to hit same tables in different calculation views. Could you please help us in below scenario.

1. Developer1 creates a project and develops basic synonyms, Flowgraphs and builds a HDI module an DEV1_HDI container is created.

-> After building the project he runs the Flowgraphs to get data into his/her HDI. By which data will be present in his HDI container.

-> on these tables he/her will create calculation views.

-> Later he moves his/her articafts to Git Repository.

2. Dev2 clones the Git , assigns space and builds the Cloned project. Here one more new Developer specific DEV2_HDI Container is created.

Target tables of Flow graphs are created in this DEV2_HDI but will not have any data.

Approach 1:

Run the flow graphs for getting data into DEV2_HDI Schema. By this redundant data would be present in DEV1_HDI and DEV2_HDI.

Approach 2:

The other was is to create a reference to cross HDI Container and use the tables from DEV1_HDI Container.

With this approach if we are planning to move to downstream systems will this cross HDI Container Reference cause any issue? Because we have same MTA files in GIT Repository?

Could you please let us know if we are going in a correct direction with multiple Developers - if yes which approach is good.

Else is there any other way to handle the situation for creating a reporting Solution. Awaiting your response, Thank you in advance.

Regards,

Arun

[thomas_jung · Accepted solution]

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.