It’s recommended to use Shared local Container/Schema details within the development team while working on the same project or Dependent Data model. The procedure outlined below explains how to access objects from another local container by modifying the YAML file in HANA XSA:
1. If you are the owner of the Source local container/schema (Cont_1), you need to provide access to another developer who intends to consume the object. Use the SQL script provided below to grant access:
Create a local temporary table in the Local Container/schema
- column table <LOCAL_TEMP_CONTAIER>#DI.#ROLES like _SYS_DI.T_NO_SCHEMA_ROLES;
Add the below entry to the temporary table
- INSERT INTO <LOCAL_TEMP_CONTAIER>#DI.#ROLES ( “ROLE_NAME” ,”PRINCIPAL_SCHEMA_NAME”, “PRINCIPAL_NAME” ) VALUES (‘<ROLE_NAME>’,”,<USER_ID> );
- CALL <LOCAL_TEMP_CONTAIER>#DI.GRANT_CONTAINER_SCHEMA_ROLES
- (<LOCAL_TEMP_CONTAIER>#DI.#ROLES,_SYS_DI.T_NO_PARAMETERS, ?, ?, ?);
- DROP TABLE <LOCAL_TEMP_CONTAIER>#DI.#ROLES;
Please replace <LOCAL_TEMP_CONTAIER># with your appropriate Local Container/Schema name. Also, replace <USER_ID> with the username of the developer who requires to access this source container. <ROLE_NAME> can be copied from .hdbrole file as highlighted in below screenshot. If you are the owner of the Source local container, you can skip this step.
Note: You can use the above SQL script to provide access to any BI user to consume your Calculation view for testing the report before deploying the solution at the main Database Level.
2. Build the Source container DB module (Cont_1) in WebIDE for HANA (XSA) and copy the Source service as follows:
- In WebIDE for HANA (XSA), navigate to the Source container (Cont_1).
- Build the Object module.
- Locate the Target service associated with Cont_1 and mak a note of it and the temp container/schema name.
3. Open the Target Container (Cont_2) where you like to consume the object of Cont_1 and edit the YAML file with the Target service copied from Step 2. Follow the steps below:
- Access the YAML file of (Cont_2).
- Modify the YAML file to include the copied Target service from Step 2.
Note: Remember to save the changes made to the YAML file and build the container.
These steps should enable you to access objects from another local container by modifying the YAML file in HANA.
4. As you are aware, to access a new object from another Local container, we need to create Synonyms files (.hdbsynonym and .hdbsynonymconfig) as outlined below. This process will display the target object name in (Cont_2) under the appropriate Target local container/Schema name, as mentioned in Point-2. If the Synonyms files (.hdbsynonym and .hdbsynonymconfig) already exist for the object, you can skip this step.
5. Once development and testing in Cont_2 is completed, the user must reset the YAML file configuration by removing the Target service name before pushing the code to the Remote branch. This ensures that the configuration is not overwritten or misconfigured during the deployment process. By removing the Target service name from the YAML file, you ensure that the deployment process for Cont_2 does not attempt to deploy or reference the objects from Cont_1.
Before deploying the objects from Cont_2, ensure that the Target object from Cont_1 has been successfully deployed to the database. This step is crucial to ensure that the necessary dependencies are in place for Cont_2 to function correctly. Once the Target object from Cont_1 is deployed, you can proceed with deploying the objects from Cont_2. This ensures that the required Target object is already available in the database for Cont_2 to access.
Remember to follow your organization’s deployment processes and best practices when deploying code to the Remote branch.
Different Options to deploy Artifacts/Objects at the Database Level using PACKAGE.JSON in HANA XSA.
When deploying artifacts or objects at the database level in HANA XSA using the PACKAGE.JSON file, you have different options depending on your requirements. Here are three different configurations you can use:
1. Deploys any undeployed objects use below configuration in PACKAGE.JSON file
{
“name”: “deploy”,
“dependencies”: {
“@sap/hdi-deploy”: “^4”
},
“scripts”: {
“start”: “node node_modules/@sap/hdi-deploy/deploy.js”
}
}
2. Sometimes, you may need to forcefully deploy existing objects. This configuration ensures that even unchanged objects are considered modified and deployed then use below configuration in PACKAGE.JSON file.
{
“name”: “deploy”,
“dependencies”: {
“@sap/hdi-deploy”: “^4”
},
“scripts”: {
“start”: “node node_modules/@sap/hdi-deploy/deploy.js –parameter skip_unchanged_expansions=true –treat-unmodified-as-modified”
}
}
3. If you want to deploy only specific objects, you can use this configuration. Modify the include-filter value to specify the path or pattern of the objects you want to deploy. Remember to replace object_path.hdi* with the actual path or pattern of the objects you want to include in the deployment then use the below configuration in PACKAGE.JSON File. Don’t forget to add dependencies like Synonyms files (.hdbsynonym and .hdbsynonymconfig)
{
“name”: “deploy”,
“dependencies”: {
“@sap/hdi-deploy”: “^4”
},
“scripts”: {
“start”: “node node_modules/@sap/hdi-deploy/deploy.js –parameter skip_unchanged_expansions=true –no-treat-unmodified-as-modified –include-filter src/object_path.hdi*”
}
}
No comments:
Post a Comment