Config best practices- settings vs constants

Note- This post belongs in Advanced forum but I do not have privileges there

My project is currently unorganized in using configs and Orchestrator Assets and I would like to define guidelines for us. One of my more confusing points is what values are recommended to be under settings sheet as opposed to constants sheet?

It seems to me that things from RE Framework like timeout interval and re-trys would make more sense, logically, as settings. I know it makes little difference functionally, but I am talking about best practices.

Also please provide feedback if this is a good outline to follow:

Orchestrator Assets: (Generic config values that can be used across multiple projects or which change frequently)

  • Credentials
    
  • Global Shared Drive Links
    
  • URLs
    
  • Privacy sensitive values
    
  • Stake holder email addresses
    
  • External Config File Path locations (on shared drive)
    

Local Process Config: (process specific settings, variables, and constants that change rarely)
Settings:

  • BusinessProcessName
    
  • Retry, Timeout Interval, Delays
    

Constants:

  • Queue name
    
  • Process specific Shared Drive Links
    
  • Error exception messages
    
  • Debug Level
    

Assets:

  • Orchestrator global asset names
    

External Config: (configurations to grant to Business Unit)

  •  Limited configuration determined to be within BU control. (ex. frequently changing file names and stake holder email addresses)

Hi @rankifyhc

As per my thinking, the constants should include the values that do no change and which are seriously related to the internal use of the project. However, I think we can include the time out and retry counter in settings as they might change over time due to various reasons.

The settings should include the value that usually tend to change. Web URLs, folder paths, shared folder locations, asset names, queue names etc.

But as you have described, we still can break them down into the level where we can have separate sheets for queues assets etc. Something similar to what you propose here. It’s a good thought.

Considering your break down these are my thoughts…

This looks good as a separate sheet in the config

Looks fine. But I would like to have the queue names, custom error messages, shared drive links & debug level in the local process config as they are specific to the process

Aren’t these already mentioned in the first one? If you are thinking of breaking down the orchestrator assets as global and private, then I think you will need to consider removing global shared drive locations from the first and adding it here…

This is just what I think. Others may have different ideas

1 Like

@Lahiru.Fernando good advice, I think I understand settings vs constants a bit better now! Sounds like Settings is better for frequently changing variables (perhaps I will rename my “settings” sheet to “variables” for clarity) and Constants more for rarely changing variables. Based on the RE names I initally thought settings made more sense for system configuration run time variables and constants for business logic variables.

Also what I meant by listing Orchestrator assets in “Assets” tab our current process is to list assets names and descriptions there and leave “Asset” value blank for documentation purposes.

1 Like

You can add/remove tabs from your config as needed. The distinction between Settings, Constants, or any other sheet is completely up to you and whatever makes sense for you & your team for organization and ease-of-use. For example we never use the credentials or assets tabs, so we simply removed them and made sure our reframework template excluded them as well.

Everything else you wrote in the first post is spot-on. Use assets for variables used across multiple processes. Use the config file for process-specific variables

3 Likes

@Dave Yeah I know it can be changed to your liking, but the problem is each of our team member think different things make sense and we loose consistency, so I wanted thoughts on something that would make sense to the majority so we could all follow the same guidelines.

The only thing left to settle on, config related, is where to put process configs. Based on other posts on this site I believe the majority thinks putting process specific configs on a shared drive would be better to avoid re-deploying changes, which on the surface makes sense to me. However is it really wise to deploy a BOT to a customer process that could be broken at any moment by accident? At least with a config wrapped in deployment you have peace of mind everything is fixed until next patch is tested and released.

Then again I guess orchestrator assets can break a deployed BOT too if mistakes are made, so IDK…

To be honest, I don’t necessarily agree with the REF’s config layout. I feel it’s a little confusing.

My opinion is there should be a Framework settings sheet, maybe just call it Settings. Anything related to how the Framework functions should be there. Then, have a Logging sheet for all Log messages you may want to change. Then, a Process sheet for any settings exclusive to the process being deployed. And, a Credentials sheet for any settings related to passwords. Also, keep it open for any extra sheets that may be desired.

Basically, the Init Settings workflow should be capable of handling a dynamic number of sheets no matter what they are named (I know the REF’s version is not capable of this though so disregard these points if you plan not modifying some of the REF components). If it is changed to be more dynamic on the sheets, then it makes it more developer-friendly I think.

I don’t think Orchestrator Assets should be used much at all, except for variables that are used to communicate between multiple processes. I suppose it makes it more global, but I prefer majority of settings to be kept per project.

Storing config files in a network share is always a debatable topic. The pains of deployment is real; you must check in code version, code review pass, test in a dev environment, then upon approve migrate to production… whereas just simply saving the file takes a few seconds. I don’t really have a strong opinion here, but I do believe that keeping the config inside the project is more stable. You can also test the process without impacting the versions that are deployed. It also allows you to keep the config inside the same version control platform, rather than changing whatever setting you want and nothing being documented on the changes.

So those are just some of my thoughts. :smiley:

3 Likes

Conclusion:
After considering all feedback here I think I will recommend to keep process configs deployment static for security reasons and adjust our config sheets to the following format:

Orchestrator Assets :
(Generic config values that can be used across multiple projects or which change frequently)

-Credentials
-Global Shared Drive Links
-URLs
-Privacy sensitive values
-Stake holder email addresses
-Customer External Config File Path (on shared drive)

Local Process Config :
(process specific settings, variables, and constants)

Process Variables:
-Process specific Shared Drive Links
-File Names
-Selectors (excel sheet names, excel read ranges, other hooks)

Settings:
-Queue name
-BusinessProcessName
-Retry, Timeout Interval, Delays
-Debug Level

Logs:
-Error exception messages

Assets:
-Orchestrator global asset names

External Config : (configurations to grant to Business Unit)
Limited configuration determined to be within BU control. (ex. customer dependent file names and stake holder email addresses)

1 Like