This blog is a continuation to MTA Services blog series Part 1 and Part 2, here we will understand the importance and usage of synonym config file in XSA Web IDE project. Also, go through the relevance and usage of _SYS_BIC and _SYS_BI schemas in XSA analytics scenario.
Synonym Config file:
In XS Advanced application, developer can only access the objects in local schema generated by the application, in order to access the objects outside of container, SYNONYMS are created locally to the external target objects. It applies to all 3 access related scenarios of XSA, for more information on scenarios, check this blog XSA Access.
While we create the .hdbsynonym file, target container service is also provided. But we do not want to hard code the target service name here. So what I do, I will describe the target service in the .hdbsynonymconfig file and service will be know during deployment time. This file has to be configured in cfg folder of db module.
The syntax of the .hdbsynonymconfig file is very similar to the code in .hdbsynonym file. So basically synonym config file will overwrite the target objects mentioned in .hdbsynonym file. If there is no config file defined, then the target objects described in .hdbsynonym file will be applied by default.
Let us take a look at syntax of synonym file,
It is the default setting to create the synonym during deployment. This can be overridden by synonym config file, so let us take a look at the .hdbsynonymconfig file for the above synonym file.
now there is a grantor name provided here, it is the name of the service created for remote container. In case of creating a synonym for accessing a classic schema object, grantor will have the CUPS specified here. But in this example I have shown a service created for a container in another MTA project.
After configuration file, I can leave the actual synonym file as it is, or I can remove the target object setting as shown below.
In this case, target setting is taken from synonym config file to create synonyms in local container.
_SYS_BIC and _SYS_BI schema:
In XS classic, all the repository objects are created under _SYS_BIC and _SYS_BI schema as run time objects like tables, views, procedures, table functions and Calculation view models. In the analytics context, only calculation views are considered as datasources in HANA to perform reporting and analytics in BI tools.
With XSA, these objects are created in HDI container schema instead of _SYS_BIC schema. for example, If I created calculation views in a Sales MTA project, they are owned by Sales MTA HDI container schema but not in _SYS_BIC schema. In order to access these models, database user must have authorization on HDI container schema, it is explained in scenario 4 of this blog Container Access.
In some scenarios, _SYS_BIC schema still be used for the XS classic objects (calculation views) which are not migrated to XSA, wanted to use them XSA modeling by creating CUPS and SYNONYMS for classic db objects under _SYS_BIC schema.
on the other note, _SYS_BI schema has no change in getting the objects created in XSA, BI related meta data of models/objects still be available in this schema. So that BI clients can access as they were doing before. So no action required because all users will have a default role ‘public’ which has the read access on _SYS_BI schema.
Note: there will be no _SYS_REPO user in XSA because all the design time activation is taken place by HDI container user.