Hi Everyone,
I was going through the solution components today and found Environment Variables when clicked on New button after opening the solution.
Explored little bit about it and here are the takeaways.
From ages, we are using custom entities for storing configurations which might differ from environment to environment and using them in Plugins, Workflows, JavaScript and now in Flows and Powerapps as well.
When should we use Environment Variables?
When shouldn’t we use Environment variables?
Let's go ahead and create an Environment Variable to understand it more.
It can handle below datatypes.
Up on creating 'Environment variable', a new record gets added to both OOB 'Environment Variable Definition' entity and 'Environment Variable Values' entities.
'Environment Variable Values' is child to the 'Environment Variable Definition' entity.
What is Default Value?
This field is part of the Environment variable definition entity is not required. Set a default value for the value to be used in production or when the values should remain the same across different environments. The Environment variable definition will be represented in the customizations.xml in your solution file
What is Current Value?
This field is optional and is a part of the “Environment variable value” entity. Also known as a current value or override value. Set this when you’d like to override the default value in your current environment. Remove the value from your solution if you don’t want this value used in the next environment. While it is typically unhealthy to modify solution components in production environments, you may enter a current value in the production environment without introducing unhealthy behaviors to the consuming component or the Environment variable definition. Note: a 1:1 relationship is currently enforced between the Environment variable definition and the Environment variable value. A value also cannot exist without a definition.
Why is there a default value and a value? This allows you to service the definition and default value separately from the current value. It also allows us to extend the functionality in the future to support multiple values scoped to a specific run time context. A separate JSON file added to your solution file that stores the values.
Note: The above is only a recommendation on how to use default values and values. If using both, you will need to handle the logic to determine which value should be used.
To test this, I have created a flow and retrieved Environment Variable Definition by filtering the SchemaName as below.
In the above example, I applied query on "Environment Variable Definition" entity and if you have current values, you have to add one more List Records step in the Loop to query "Environemnt Varialble Value" and in the Filter query, enter _environmentvariabledefinitionid_value eq and add the Environment Variable Definition from the dynamic content list.
We can move these from one environment to other using Solution Import. When we export the solution, you will see a separate JSON added in the solution.
Hope this helps.
--
Happy 365'ing
I was going through the solution components today and found Environment Variables when clicked on New button after opening the solution.
Explored little bit about it and here are the takeaways.
From ages, we are using custom entities for storing configurations which might differ from environment to environment and using them in Plugins, Workflows, JavaScript and now in Flows and Powerapps as well.
When should we use Environment Variables?
- When an input parameter needs to change across environments and should not be hard-coded. For example, a URL that points to a different resource in development and production environments.
- If you’re building a solution where your customer is required to provide an input value.
- When multiple components require the same input. Instead of entering that input multiple times, reference the environment variable. If the value needs to change, make an update in one place.
- If you need to update configuration values without modifying code or if the person managing the configuration is not familiar with coding. For example, a plugin that references a blob store location could be updating without directly modifying the plugin.
When shouldn’t we use Environment variables?
- To transport secure data such as passwords or other secrets.
- If several values are required for one definition.
Let's go ahead and create an Environment Variable to understand it more.
It can handle below datatypes.
Up on creating 'Environment variable', a new record gets added to both OOB 'Environment Variable Definition' entity and 'Environment Variable Values' entities.
'Environment Variable Values' is child to the 'Environment Variable Definition' entity.
What is Default Value?
This field is part of the Environment variable definition entity is not required. Set a default value for the value to be used in production or when the values should remain the same across different environments. The Environment variable definition will be represented in the customizations.xml in your solution file
What is Current Value?
This field is optional and is a part of the “Environment variable value” entity. Also known as a current value or override value. Set this when you’d like to override the default value in your current environment. Remove the value from your solution if you don’t want this value used in the next environment. While it is typically unhealthy to modify solution components in production environments, you may enter a current value in the production environment without introducing unhealthy behaviors to the consuming component or the Environment variable definition. Note: a 1:1 relationship is currently enforced between the Environment variable definition and the Environment variable value. A value also cannot exist without a definition.
Why is there a default value and a value? This allows you to service the definition and default value separately from the current value. It also allows us to extend the functionality in the future to support multiple values scoped to a specific run time context. A separate JSON file added to your solution file that stores the values.
Note: The above is only a recommendation on how to use default values and values. If using both, you will need to handle the logic to determine which value should be used.
To test this, I have created a flow and retrieved Environment Variable Definition by filtering the SchemaName as below.
In the above example, I applied query on "Environment Variable Definition" entity and if you have current values, you have to add one more List Records step in the Loop to query "Environemnt Varialble Value" and in the Filter query, enter _environmentvariabledefinitionid_value eq and add the Environment Variable Definition from the dynamic content list.
We can move these from one environment to other using Solution Import. When we export the solution, you will see a separate JSON added in the solution.
Note: This is still under preview, please check this link for more information.
Hope this helps.
--
Happy 365'ing
Gopinath
No comments:
Post a Comment