Strategies for storing environment specific interface configuration

Hi all,

What are best practices for storing interface configuration that is environment specific and shouldn’t be moved between dev, test, and production environments? By interface configuration, I mean things like database servers to connect to (i.e. information the Lua translator code needs access to but isn’t an Iguana setting). Ideally I’d like to keep this information in configuration files that can be part of the Iguana project and easily updated by uploading a new file through the Iguana GUI (rather than putting them somewhere else in the filesystem where they are harder to access). But this approach means those files get included when exporting/importing channels to a Repo, which I don’t want.

Has anyone used gitignore or other features of Git to suppress moving configuration files? Are there any smart approaches to handling configuration information I’m not aware of?

Thanks!

Hi there,

The best way to do this would be to use environment variables in Iguana.

You can access the values contained in environment variables from within the Translator using the os.getenv() method. For example, if you have set an environment variable named TEST to the value “Hello World!” then calling os.getenv(‘TEST’) would return the string “Hello World!” in the Translator.

This is useful when accessing databases, files, LLP IPs/Ports, or other bits that are configured on an system-by-system basis. Setting this information in the environment variables allows you to use the same code across a development, and production system while only requiring you to change the value of the environment variable in each.

Trevor Hilton
Developer
iNTERFACEWARE Inc.

You can also use environment variables in certain Iguana configuration screens. For example the “Host address” in an LLP client can use the form ${TEST} to evaluate to an IP that’s been set in IguanaEnv.txt. If a field supports this it will show the expanded value under the field before saving and once saved will appear as “${TEST} –> VALUE”.

Thanks! Sounds like that would work nicely, at least for Iguana level settings. It would be nice to be able to do something similar for interface level configuration that’s not shared across all channels.

Greg,

Our customers are doing interface level configurations in other ways as well. Configurations can be stored in local external files that Iguana scripts can import prior to executing any business logic. This is a common strategy.

The downside here is that these files do not get stored as part of version control. So there are a few extra assets to maintain external to Iguana for any one interface. But the tradeoff may be worth it for you.

Casey Trauer,
Director, Client Education
iNTERFACEWARE

Makes sense, thanks for everyone’s input.

Sounds like depending on the nature of the configuration there are different places that make sense for it to live:

Iguana level (i.e. applies to all channels), environment specific: Iguana Environment Variables

Interface level, environment specific: External configuration files (not kept in Iguana and NOT moved with a channel during export/import to Git repo)

Interface level, not environment specific: ‘Internal’ configuration files (kept in Iguana project and moved with a channel during export/import to Git repo)

Hi Guys,

I was thinking of storing a JSON string that represents some config values for a project in one of these environmental variables. Do you think this is a good approach?

I would then add a check that if it could not find the environmental variable name then it would raise an error in the script stating that configuration could not be found etc.

Best regards,
Colin.

There’s something wrong with the forum software. If I edit a post, it disappears. I’m hoping that this will show up …

Original post:

I have a couple of concerns with this approach, but generally speaking, it will work.

The maximum size of an environment variable in Windows is roughly 32KB. And the total size for all environment variables cannot exceed 32K. Unix and Linux also have limits, but they can vary by distribution and even customized (on Linux, at least).
Maintaining the JSON string can be a challenge; you’d probably need to keep a copy in a file, update it there (and ideally perform some sort of validation on it), then paste it into Iguana’s Environment Variables editor.
Editing IguanaEnv.txt directly is possible, but it’s only read at Iguana startup.

My personal preference would be to store the configuration data as JSON in a text file, and write a utility function to read and parse it into a table variable. You can then update the file as necessary and need only to stop/start the channels that use it to activate the settings. As mentioned in previous posts above, though, this file will be outside of Iguana’s version control system and therefore prior versions will not be kept unless you manage that yourself.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

Adding to Jeff’s comments, I would say that Iguana Environmental Variables are most ideal for configurations that are environment specific. In other words, they apply to all your interfaces in that Iguana. I would recommend something more along the lines of what Jeff is recommending for interface-specific configurations.

Casey Trauer,
Director, Client Education
iNTERFACEWARE

Happy Friday and thanks for the feedback.

Jeff,
I hadn’t considered the size restriction on the environmental variable. It makes sense to me to store the configuration items in a separate file so that our code projects do not require editing or access during deployments and movement between development and production environments. This will also allow our process to scale better in the future.

Casey,
I think we will go ahead and identify the instance level config values and only add these to the environmental variables.

Best regards,
Colin.