Skip to Main Content
InterSystems Ideas
We love hearing from our users. Tell us what you want to see next and upvote ideas from the community.
* Bugs and troubleshooting should as usual go through InterSystems support.
Status Future consideration
Categories InterSystems IRIS
Created by Alex Woodhead
Created on Jun 6, 2023

Envrionment variable support in System Default Settings

Docker commonly passes settings via environment variables.

It could be useful if when resolving settings for production configuration this could also evaluate environment variables instead of deployed static values.

Thus the container drives the behavior of the production.

When productions are packaged and deployed the environment variable names are transprted with the export as with static values for production settings.

Ref: https://docs.intersystems.com/irisforhealth20232/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_deploying

A suggestion from community is for System Default Settings to:

1) First try using the named environment variable if defined

2) Otherwise fallback to a given "Settings Value"

In first case, the REPORT on what settings are in effect should be expanded to indicate is from Operating System Environment Variable. See attached.


  • ADMIN RESPONSE
    Nov 20, 2024

    Thank you for submitting the idea. The status has been changed to "Future consideration".

    Stay tuned!

  • Steve Pisani
    Reply
    |
    Nov 21, 2024

    If the current field 'Settings Value' interpretted and evaluate embedded expression: for example:

    {$System.Util.GetEnviron("iris_production_shutdown_timeout")}

    The original poster's requirement would be met, and, if users want to evaluate the setting based on an expression in order to support multiple instances from one code base - for example, I want all HL7 interfaces' archive path folder to be go to a common folder with subfolders by server and instance, I coudl potentially specify - for archive path:

    //commonUNCPath/hl7Archived/{$TR($System,":","/"}/{$$ItemName}

    $TR($System,":","/") would resolve to hostname/irisinstancename and $$ItemName will resolve to the production components item name resulting in this effecctive setting, calculated during the Initialisation phase of the component Hl7SourceA, running in instance IRIS, on hostname myPCName.

    //commonUNCPath/hl7Archived/myPCName/IRIS/HL7SourceA

    Other special variables like $$ItemName, can be $$ProductionName, $$HostClassName. User defined class methods can also be able to be used, within the expression {}.

  • Admin
    Vadim Aniskin
    Reply
    |
    Nov 15, 2023

    @Alex Woodhead, you have a comment on your idea. Please answer it to help your idea to be promoted.

    2 replies
  • Steve Pisani
    Reply
    |
    Jul 28, 2023
    I always felt that it would be good if one could define apart from a value for a setting, an EXPRESSION to call in order to resolve the value. An expression can invoke a method which can look for an environment variable, and also resolve more complex setting values, for example, where your setting needs the production namespace (eg for centralised archiving : archive path = /archives/($ZN)/.. which will work in all deployments, or other run-time specific values.