Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Cocquerel
Active Contributor

Introduction


The HDI Deployer has some mechanisms that allows to dynamically set some configuration parameters at deployment time. (see HDI Configuration Files )

For example, this is useful when the target schema name of a synonym differs depending on development, quality or production system. An other example is for virtual table when the name of the remote source can also differ depending on the system.

In those cases, you need to create some configuration files (.*config) in cfg/ folder like for example,  .hdbsynonymconfig or  .hdbvirtualtableconfig files that some property values will be retrieved dynamically at deployment time from a local user provided service using the following syntax:
"schema.configure": "<MyUserProvidedService>/<MySchemaName>"

or
"remote.configure": "<MyUserProvidedService>/<MyRemoteSourceName>"

This technique is working fine at deployment time but the issue is when you need to change those values after the deployment. Indeed, changing the values in your user provided service will have no effects on the existing synonyms or virtual tables runtime objects. Scenario when you may need to change user provided service values is, for example, after you have refreshed your quality system by your productive ones. An other use case was described here.

This blog will described how to redeploy HDI containers to take into account changes in user provided service.

Wrong solutions


First note that redeploying your .mtar files will not work. Indeed, the HDI Deployer implements a delta-based deployment strategy meaning that just design-time objects that have been modified will be redeployed. In our case, neither the .hdbsynonymconfig nor the  .hdbvirtualtableconfig files have been changed and so, the HDI Deployer will not recreate the synonyms or virtual tables to take into account the change in the user provided service.

The solution to drop your HDI containers and redeploy them from scratch is also not valid because, in this case, you would lose many data like your table contents and roles assignments for examples.

Solution based on HDI APIs


Hopefully, SAP is providing an HDI SQL API called MAKE that allows to force the redeployment of any files.
For redeployment of synonyms and virtual tables, you should redeploy .hdbsynonymconfig , .hdbsynonym, .hdbvirtualtableconfig, .hdbvirtualtable and .hdiconfig files at the same time.

You can get a list of those files of an HDI container using an other HDI SQL API called LIST_DEPLOYED.

The following SQL Script is looping over all existing HDI containers and redeploy all synonyms and virtual tables.
As output, it will give you a list of errors if any.
DO BEGIN
DECLARE VAR_T_NO_FILESFOLDERS TABLE LIKE _SYS_DI.T_NO_FILESFOLDERS;
DECLARE VAR_PARAMETERS TABLE LIKE _SYS_DI.TT_PARAMETERS;
DECLARE VAR_DEPLOY_PATHS _SYS_DI.TT_FILESFOLDERS;
DECLARE VAR_UNDEPLOY_PATHS _SYS_DI.TT_FILESFOLDERS;
DECLARE VAR_PATH_PARAMETERS _SYS_DI.TT_FILESFOLDERS_PARAMETERS;
DECLARE RESULT _SYS_DI.TT_FILESFOLDERS_METADATA;
DECLARE RETURN_CODE INT;
DECLARE REQUEST_ID BIGINT;
DECLARE MESSAGES _SYS_DI.TT_MESSAGES;
DECLARE MESSAGES_ALL _SYS_DI.TT_MESSAGES;

DECLARE CURSOR C_CONTAINER FOR
SELECT CONTAINER_NAME
FROM "_SYS_DI#SYS_XS_HANA_BROKER"."M_CONTAINERS";

FOR CUR_CONTAINER AS C_CONTAINER
DO
VAR_T_NO_FILESFOLDERS = select * from _SYS_DI.T_NO_FILESFOLDERS;
CREATE LOCAL TEMPORARY COLUMN TABLE #PARAMETERS LIKE _SYS_DI.TT_PARAMETERS;
INSERT INTO #PARAMETERS ( KEY, VALUE ) VALUES ('ignore_folders', 'true');
INSERT INTO #PARAMETERS ( KEY, VALUE ) VALUES ('recursive', 'true');
VAR_PARAMETERS = select * from #PARAMETERS;
EXEC 'CALL ' || CUR_CONTAINER.CONTAINER_NAME || '#DI.LIST_DEPLOYED(:VAR_T_NO_FILESFOLDERS, :VAR_PARAMETERS, :RETURN_CODE, :REQUEST_ID, :MESSAGES, :RESULT);' INTO RETURN_CODE, REQUEST_ID, MESSAGES, RESULT USING VAR_T_NO_FILESFOLDERS, VAR_PARAMETERS;
DROP TABLE #PARAMETERS;

VAR_DEPLOY_PATHS = SELECT PATH FROM :RESULT WHERE PATH LIKE '%hdbsynonym' OR PATH LIKE '%hdbsynonymconfig' OR PATH LIKE '%hdiconfig' OR PATH LIKE '%hdbvirtualtableconfig' OR PATH LIKE '%hdbvirtualtable';
CREATE LOCAL TEMPORARY COLUMN TABLE #UNDEPLOY_PATHS LIKE _SYS_DI.TT_FILESFOLDERS;
VAR_UNDEPLOY_PATHS = select * from #UNDEPLOY_PATHS;
CREATE LOCAL TEMPORARY COLUMN TABLE #PATH_PARAMETERS LIKE _SYS_DI.TT_FILESFOLDERS_PARAMETERS;
VAR_PATH_PARAMETERS = select * from #PATH_PARAMETERS;
CREATE LOCAL TEMPORARY COLUMN TABLE #PARAMETERS LIKE _SYS_DI.TT_PARAMETERS;
VAR_PARAMETERS = select * from #PARAMETERS;
EXEC 'CALL ' || CUR_CONTAINER.CONTAINER_NAME || '#DI.MAKE(:VAR_DEPLOY_PATHS, :VAR_UNDEPLOY_PATHS, :VAR_PATH_PARAMETERS, :VAR_PARAMETERS, :RETURN_CODE, :REQUEST_ID, :MESSAGES);' INTO RETURN_CODE, REQUEST_ID, MESSAGES USING VAR_DEPLOY_PATHS, VAR_UNDEPLOY_PATHS, VAR_PATH_PARAMETERS, VAR_PARAMETERS;
DROP TABLE #UNDEPLOY_PATHS;
DROP TABLE #PATH_PARAMETERS;
DROP TABLE #PARAMETERS;
MESSAGES_ALL= SELECT * FROM :MESSAGES_ALL UNION ALL SELECT * FROM :MESSAGES WHERE SEVERITY='ERROR';
END FOR;
SELECT * FROM :MESSAGES_ALL;
END;

Conclusion


Hope this script will be useful for you (in case of system refresh for example). If you have other use cases where such script could be useful, do not hesitate to share in comments.
Labels in this area