I read the document and applied before I watch this video, and listened this like a podcast while walking, it nailed the concept to my brain, enlightened the dark corners. You are my go to person about SAP. Thank you for great efforts and all hands on sessions.
Hi Thomas, thank you for putting out this video, really helped to conceptualise the documentation in a visual format to get a better understanding of how this all works. Just a question though, is there a way where we can map our business user from members in our CF space to these technical users that are created when they log into Hana DB Explorer so that they can only see particular containers/access privileges? Or do we just give them the technical user name and password and they have to manually input it when they log into Hana DB Explorer? Thank you in advance!
No. The database explorer is designed to give developers and admins access to any HDI container within a space. The Space is the way you control access. Use separate spaces if you want to restrict access.
Can you please confirm my understanding? For working in a non-CAP scenario, e.g. 1. provide access to a reporting user ( as you illustrate here) 2. provide access to a developer to connect via Jupyter and python to work *as a developer* to an HDI container (create tables, drop tables etc.) Then: NONE of the two users (DT and RT) are the ones to use. Instead i should create a separate user ( as you illustrate here) If not, which one or the two users auto-generated from the hdi-shared , is the most appropriate one for scenario 2? Thank you!
Thanks Thomas, @SAP Developers having a container group and granting admin privilege to another user on the container group is mandatory? Can I just grant Container Specific Admin Privilege also to HDI_ADMIN user directly without going through BROKER_CG? Because we just have 3 containers, can I make HDI_ADMIN as the Global HDI admin and also the Admin on the 3 containers as well?
The usage of container groups is not mandator. It is helpful when you have a larger number of containers and you want to group them together for access control.
Hi Thomas, @sapdevs is there a system table or view that holds the design time and associated runtime object names? When I wanted to delete some runtime objects in HDI container, I will need to add the design time files in undeploy.json, however it is difficult to find the appropriate design time files. I wish if there is any table or view that I can query to get this info.
Thank you@@sapdevs. In the case of design time file lost in Git for any reason like a missing commit or wrong merging then we will end up having a runtime object with no design time artifact for that. In that case, how do I un-deploy the runtime object? manual drop in HDI container gives authorization error.
You can use the --auto-undeploy switch to undeploy any objects missing from the designtime without needing an undeploy.json. www.npmjs.com/package/@sap/hdi-deploy#delta-deployment-and-undeploy-allowlist
Thank you,@@sapdevs so If I add auto un-deploy.json now, is it going to check and clean up the hana objects created in last 1 year that are missing in design time?
Hi Thomas, Thanks for the session. In the DB explorer of Prod, I found several _RT users in there. I don't have many containers in Prod, should be only 2. But I see around 8 or 10 _RT users. I noticed that every time I do a deployment, it creates a new Runtime user for the same container. can you advise how to stop this behavior, mta.yaml setting for something?
" I noticed that every time I do a deployment, it creates a new Runtime user for the same container. " Are you sure it's really the same container. In development systems it will prefix the container name for different developers so they can all have their own container instance copy. This is normal/expected.
I've never observed such a situation, but I don't think that most people pay that close attention to the generated users (nor do you normally have to care that much about them). Are you suspecting that your container is being dropped and recreated instead of injecting changes into the existing container? That shouldn't be happening but that's the only way I can see the generated users getting recreated. But even then if the old container is dropped then it's generated users should be getting deleted as well. [Thomas Jung]
@@sapdevsThanks Thomas, I have tried the deployment again now, the previous RT user got deleted and a new user is created. If this is the case, isn't that risk of Container getting deleted and created on every deployment? The reason, I have paid more attention on the RT user to analyze authorization error on the Container CVs that have analytical privileges in it.
So it's not that your container is getting recreated (which would be bad because that could lead to data loss) but really that your RT users are changing? I would say that you shouldn't be concerned if the RT users do change. You should never directly interact with them. Only via service binding are the RT users accessible. Any grants or authorization adjustments to these users should be done via the design time concepts of HDI.
Hi, we have followed all the steps and seems to be OK, we can do SELECT and read the information, but then we created a calculation view and we are getting this error... user "HANA_CV1_HDI_DB_1#OO" is not allowed to grant (or revoke) the privilege "SELECT" for object "XXXXXXX"."SAP_CAPIRE_BOOKSHOP_AUTHORS" of type "TABLE"HDI Deploy What could we do? why is it requesting for GRANT OPTION into the user HANA_CV1_HDI_DB_1#OO ? i couln't find a way to do a GRANT SELECT ON SCHEMA XXXXXX TO HANA_CV1_HDI_DB_1#OO WITH GRANT OPTION;
Calculation views require grantor rights to the HDI OO user. To grant with grantor rights you have to end the role with a #. See example here github.com/SAP-samples/hana-xsa-opensap-hana7/blob/main/db/cfg/user.hdbgrants and github.com/SAP-samples/hana-xsa-opensap-hana7/blob/main/user_db/src/roles/userOwner.hdbrole
Thank you so much! very very helpful!!!
I read the document and applied before I watch this video, and listened this like a podcast while walking, it nailed the concept to my brain, enlightened the dark corners. You are my go to person about SAP. Thank you for great efforts and all hands on sessions.
Hi Thomas, thank you for putting out this video, really helped to conceptualise the documentation in a visual format to get a better understanding of how this all works. Just a question though, is there a way where we can map our business user from members in our CF space to these technical users that are created when they log into Hana DB Explorer so that they can only see particular containers/access privileges? Or do we just give them the technical user name and password and they have to manually input it when they log into Hana DB Explorer? Thank you in advance!
No. The database explorer is designed to give developers and admins access to any HDI container within a space. The Space is the way you control access. Use separate spaces if you want to restrict access.
Can you please confirm my understanding? For working in a non-CAP scenario,
e.g.
1. provide access to a reporting user ( as you illustrate here)
2. provide access to a developer to connect via Jupyter and python to work *as a developer* to an HDI container (create tables, drop tables etc.)
Then: NONE of the two users (DT and RT) are the ones to use. Instead i should create a separate user ( as you illustrate here)
If not, which one or the two users auto-generated from the hdi-shared , is the most appropriate one for scenario 2?
Thank you!
This is correct. For these scenarios you should create new users. You should never reuse the DT or RT users.
@@sapdevs Thank you!
Thanks Thomas, @SAP Developers having a container group and granting admin privilege to another user on the container group is mandatory? Can I just grant Container Specific Admin Privilege also to HDI_ADMIN user directly without going through BROKER_CG? Because we just have 3 containers, can I make HDI_ADMIN as the Global HDI admin and also the Admin on the 3 containers as well?
The usage of container groups is not mandator. It is helpful when you have a larger number of containers and you want to group them together for access control.
@@sapdevs Thank you.
Hi Thomas, @sapdevs is there a system table or view that holds the design time and associated runtime object names? When I wanted to delete some runtime objects in HDI container, I will need to add the design time files in undeploy.json, however it is difficult to find the appropriate design time files. I wish if there is any table or view that I can query to get this info.
The design time information is not stored within SAP HANA. It only lives within the source control system (I.E. Git).
Thank you@@sapdevs. In the case of design time file lost in Git for any reason like a missing commit or wrong merging then we will end up having a runtime object with no design time artifact for that. In that case, how do I un-deploy the runtime object? manual drop in HDI container gives authorization error.
You can use the --auto-undeploy switch to undeploy any objects missing from the designtime without needing an undeploy.json. www.npmjs.com/package/@sap/hdi-deploy#delta-deployment-and-undeploy-allowlist
Thank you,@@sapdevs so If I add auto un-deploy.json now, is it going to check and clean up the hana objects created in last 1 year that are missing in design time?
Hi Thomas, Thanks for the session. In the DB explorer of Prod, I found several _RT users in there. I don't have many containers in Prod, should be only 2. But I see around 8 or 10 _RT users. I noticed that every time I do a deployment, it creates a new Runtime user for the same container. can you advise how to stop this behavior, mta.yaml setting for something?
" I noticed that every time I do a deployment, it creates a new Runtime user for the same container. " Are you sure it's really the same container. In development systems it will prefix the container name for different developers so they can all have their own container instance copy. This is normal/expected.
@@sapdevs ya, it is the same container. the case I am talking about is in Prod. The runtime user
for a container is changed on each deployment.
I've never observed such a situation, but I don't think that most people pay that close attention to the generated users (nor do you normally have to care that much about them). Are you suspecting that your container is being dropped and recreated instead of injecting changes into the existing container? That shouldn't be happening but that's the only way I can see the generated users getting recreated. But even then if the old container is dropped then it's generated users should be getting deleted as well. [Thomas Jung]
@@sapdevsThanks Thomas, I have tried the deployment again now, the previous RT user got deleted and a new user is created. If this is the case, isn't that risk of Container getting deleted and created on every deployment?
The reason, I have paid more attention on the RT user to analyze authorization error on the Container CVs that have analytical privileges in it.
So it's not that your container is getting recreated (which would be bad because that could lead to data loss) but really that your RT users are changing? I would say that you shouldn't be concerned if the RT users do change. You should never directly interact with them. Only via service binding are the RT users accessible. Any grants or authorization adjustments to these users should be done via the design time concepts of HDI.
Hi, we have followed all the steps and seems to be OK, we can do SELECT and read the information, but then we created a calculation view and we are getting this error... user "HANA_CV1_HDI_DB_1#OO" is not allowed to grant (or revoke) the privilege "SELECT" for object "XXXXXXX"."SAP_CAPIRE_BOOKSHOP_AUTHORS" of type "TABLE"HDI Deploy
What could we do? why is it requesting for GRANT OPTION into the user HANA_CV1_HDI_DB_1#OO ? i couln't find a way to do a GRANT SELECT ON SCHEMA XXXXXX TO HANA_CV1_HDI_DB_1#OO WITH GRANT OPTION;
Calculation views require grantor rights to the HDI OO user. To grant with grantor rights you have to end the role with a #. See example here github.com/SAP-samples/hana-xsa-opensap-hana7/blob/main/db/cfg/user.hdbgrants and github.com/SAP-samples/hana-xsa-opensap-hana7/blob/main/user_db/src/roles/userOwner.hdbrole
Can we call you respecfully as "Barbitas"?