Hey all,
We have a little conundrum wherein each environment has over 150 variables configured for OSGi values.
We have a multi-tenant architecture wherein each tenant is prefixed in environment variables with _TENANTX_CM to easily identify the tenant.
However, few environment variables are incorrect and have been fixed - Basically TenantX and TenantY have same environment variable name. This has been fixed in code now.
However, the query is when we deploy this to AEM Cloud, supposedly there is a use case wherein the correct configuration is tagged to incorrect environment variable name - How can we handle that scenario?
For example TenantX and TenantY both have same environment variable name with value "ABC"
Now we are correcting the configs for both by having separate environment variables. But the default values still have to be overridden to point to "ABC" in cloud manager.
Since there are lot of variables is there any way to ensure that the transition is seamless?
I know this is confusing but let me know if I can clarify it further.
Thanks,
Nagesh
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @NageshRaja ,
If you are afraid that after the migration you OSGi config won't take any value you can use any of these approaches:
1) In advance create tenant-specific variables with correct value in the Cloud Manager like TENANTX_ABC and TENANTY_ABC. Assign ABC value to all of them.
2) Add default value when referencing env variable in the OSGi config: $[env.TENANTX_ABC;default=ABC] and $[env.TENANTY_ABC;default=ABC]
In this case, you ensure that OSGi config will take corresponding value.
I don't know the specific of your project, but 150 env variable seems overhead for me. I am not sure that you really need 150 env variables that are considering change in runtime. Usually, variable is exposed as Cloud Manager env variable in 3 cases:
1) You need to store secret (password, token, etc)
2) You need to ensure that this variable can be changed in runtime without deployment.
3) You override AEM OOTB env variables.
If your variable don't match any of points above, you don't need to expose it as Cloud Manager env variable. You need just create 3 OSGi configurations in the repository for runmodes: under config.dev, config.stage, config.prod. In addition, there is a very good practice to use Context-Aware configuration (https://wcm.io/caconfig/ ) that allows to have tenant specific configuration and provides an ability to modify it on environment in runtime by editors.
I would recommend to reconsider your env variables with approaches above. The main cause because there is a limitation for env variables in Cloud Manager - 200 env var per env in total: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/usi....
Best regards,
Kostiantyn Diachenko.
Hi @NageshRaja ,
If you are afraid that after the migration you OSGi config won't take any value you can use any of these approaches:
1) In advance create tenant-specific variables with correct value in the Cloud Manager like TENANTX_ABC and TENANTY_ABC. Assign ABC value to all of them.
2) Add default value when referencing env variable in the OSGi config: $[env.TENANTX_ABC;default=ABC] and $[env.TENANTY_ABC;default=ABC]
In this case, you ensure that OSGi config will take corresponding value.
I don't know the specific of your project, but 150 env variable seems overhead for me. I am not sure that you really need 150 env variables that are considering change in runtime. Usually, variable is exposed as Cloud Manager env variable in 3 cases:
1) You need to store secret (password, token, etc)
2) You need to ensure that this variable can be changed in runtime without deployment.
3) You override AEM OOTB env variables.
If your variable don't match any of points above, you don't need to expose it as Cloud Manager env variable. You need just create 3 OSGi configurations in the repository for runmodes: under config.dev, config.stage, config.prod. In addition, there is a very good practice to use Context-Aware configuration (https://wcm.io/caconfig/ ) that allows to have tenant specific configuration and provides an ability to modify it on environment in runtime by editors.
I would recommend to reconsider your env variables with approaches above. The main cause because there is a limitation for env variables in Cloud Manager - 200 env var per env in total: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/usi....
Best regards,
Kostiantyn Diachenko.
Views
Likes
Replies