This blog is a continuation to MTA apps and services Part 1, here we will understand CONTAINER ACCESS services and SERVICE_REPLACMENTS configuration in mta.yaml file. This topic will be explained in 3 different access related scenarios of XSA. If you need an overview of the scenarios, please read this blog. XSA Access scenarios
Let us look at scenarios in detailed,
In order to access the classic DB in XSA HDI objects, an user provided service needs to be created, with that a connection is established between classic DB and HDI container. It is an easy process and this service can be created in XS advanced cockpit, or CUPS command in CL tool.
Note: If you are using HANA 2.0 SP03 or later and latest Web IDE for HANA, you can create this service in MTA DB module context menu., Choose modeling actions -- > Add External HANA service. It does a lot of work for you automatically, it updates the mta.yaml file with the service configurations and wire them to HDI module. But I don’t want the tool to do this configurations for me, I will do it manually to understand better how the services are being created in the project.
So firstly, I created the user provided service in XSA Cockpit. This service is to establish the connection to classic DB, it could be S/4 HANA schema, or BW/4 HANA schema or even native HANA schema from XSC.
After that, we will go to Web IDE project’s mta.yaml file, create a new resource, provide the name of the service/resource, also maintain the parameter and properties of the service in there.
Parameter: It is like an input value to the service, we are giving service name as input and passing to Properties section, so that we can expose the service name everywhere in the project.
Property: $service_name gets the cross schema service name from the parameter. Key value is provided here to expose the service in other places.
Now, attach this resource to the HDI DB module as a required resource, here we will need SERVICE_REPLACEMENTS Group to generate a key value for the service,
So with that we can use this service key name in hdbgrants file to grant the access on objects in XS classic schema, key name will be same for all the developers and also in QA or production space. Because, the service name which is generated during private build and actual deployment in a space is always different, but it is replaced with key value given in SERVICE_REPLACEMENTS GROUP. So it worked as ALIAS to the actual service name. We can see these service name after actual deployment is bound the DB module app in xs command line,
In this scenario, we do not have to create an external service to access container, because both modules/containers are in same project, they are configured in same mta.yaml file, we just need to wire them together to get the access.
In this example, I have 2 containers, BaseDB and DB and I would like to get access on BaseDB hdi container to DB hdi container, So let us take a look the service configuration for Base module of mta,
Here, we can notice that, it is of HDI Container service in the resource section, we do not have to provide any parameter to it, the property key value will hold the $service name and it will be used to expose in other places of project.
Now, this resource/service will be wired to DB hdi module as a required resource. Here also, we will be using SERVICE_REPLACEMENTS Group to get a key value for the service name. This key value will be static and can be used in hdbgrants file and other places.
after private build and actual deployment, you can the service names are different, but key value will be the same which is defined in SERVICE_REPLACEMENTS Group.
Note: the difference between scenario 1 with external service and this scenario 2 is that, here the service is a hdi container service and the $service name will be known by default with in the project. so no need to provide that in the parameter section of the resource.
In this scenario, we will need to create an external service to access the MasterDB in project 1, so the hdi container service must have been created and built before in order to get the access on that. Then we will define that service in yaml file as existing service in resources section of the project 2. Configuration of parameter and properties of this is service is exactly same as user provided service defined in scenario 1. so here, we give the deployed service name project 1 as the value in the parameters section.
After resource/service configuration, wiring it to hdi module with SERVICE_REPLACEMENTS is just same as scenario 1 and scenario 2. So the key value defined here will be used in hdbgrants or any other places where service is used.After private build or actual deployment the service key value will not be changed. With that, access on Container in project 1 is granted to Container in project 2.
Conclusion: So with that, we have gone through service creation for 3 access scenarios and also noticed the build and deployment behavior with SERVICE_REPLACEMENTS group configuration.
Thank you, if you have feedback, please comment, I will update the content accordingly.
Sreekanth
Let us look at scenarios in detailed,
1. Service for Classic DB access : EXTERNAL Service
In order to access the classic DB in XSA HDI objects, an user provided service needs to be created, with that a connection is established between classic DB and HDI container. It is an easy process and this service can be created in XS advanced cockpit, or CUPS command in CL tool.
Note: If you are using HANA 2.0 SP03 or later and latest Web IDE for HANA, you can create this service in MTA DB module context menu., Choose modeling actions -- > Add External HANA service. It does a lot of work for you automatically, it updates the mta.yaml file with the service configurations and wire them to HDI module. But I don’t want the tool to do this configurations for me, I will do it manually to understand better how the services are being created in the project.
So firstly, I created the user provided service in XSA Cockpit. This service is to establish the connection to classic DB, it could be S/4 HANA schema, or BW/4 HANA schema or even native HANA schema from XSC.
After that, we will go to Web IDE project’s mta.yaml file, create a new resource, provide the name of the service/resource, also maintain the parameter and properties of the service in there.
Parameter: It is like an input value to the service, we are giving service name as input and passing to Properties section, so that we can expose the service name everywhere in the project.
Property: $service_name gets the cross schema service name from the parameter. Key value is provided here to expose the service in other places.
Now, attach this resource to the HDI DB module as a required resource, here we will need SERVICE_REPLACEMENTS Group to generate a key value for the service,
So with that we can use this service key name in hdbgrants file to grant the access on objects in XS classic schema, key name will be same for all the developers and also in QA or production space. Because, the service name which is generated during private build and actual deployment in a space is always different, but it is replaced with key value given in SERVICE_REPLACEMENTS GROUP. So it worked as ALIAS to the actual service name. We can see these service name after actual deployment is bound the DB module app in xs command line,
2. Service for CONTAINER access to another CONTAINER in a same project – INTERNAL Service
In this scenario, we do not have to create an external service to access container, because both modules/containers are in same project, they are configured in same mta.yaml file, we just need to wire them together to get the access.
In this example, I have 2 containers, BaseDB and DB and I would like to get access on BaseDB hdi container to DB hdi container, So let us take a look the service configuration for Base module of mta,
Here, we can notice that, it is of HDI Container service in the resource section, we do not have to provide any parameter to it, the property key value will hold the $service name and it will be used to expose in other places of project.
Now, this resource/service will be wired to DB hdi module as a required resource. Here also, we will be using SERVICE_REPLACEMENTS Group to get a key value for the service name. This key value will be static and can be used in hdbgrants file and other places.
after private build and actual deployment, you can the service names are different, but key value will be the same which is defined in SERVICE_REPLACEMENTS Group.
Note: the difference between scenario 1 with external service and this scenario 2 is that, here the service is a hdi container service and the $service name will be known by default with in the project. so no need to provide that in the parameter section of the resource.
3. Service for CONTAINER access to another CONTAINER in a different project - EXTERNAL service
In this scenario, we will need to create an external service to access the MasterDB in project 1, so the hdi container service must have been created and built before in order to get the access on that. Then we will define that service in yaml file as existing service in resources section of the project 2. Configuration of parameter and properties of this is service is exactly same as user provided service defined in scenario 1. so here, we give the deployed service name project 1 as the value in the parameters section.
After resource/service configuration, wiring it to hdi module with SERVICE_REPLACEMENTS is just same as scenario 1 and scenario 2. So the key value defined here will be used in hdbgrants or any other places where service is used.After private build or actual deployment the service key value will not be changed. With that, access on Container in project 1 is granted to Container in project 2.Conclusion: So with that, we have gone through service creation for 3 access scenarios and also noticed the build and deployment behavior with SERVICE_REPLACEMENTS group configuration.
Thank you, if you have feedback, please comment, I will update the content accordingly.
Sreekanth
- SAP Managed Tags:
4 Comments
