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)
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
@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.
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
@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.
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)
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)
