Jt3kt
commented
4 years ago I think the json preferences is a good place to start.
Perhaps add a component where we define which preference components are requirements for specific functions? I'm sure there's likely a cleaner way to do that.
Could possibly used as a part of a configuration wizard function, go to use a function for the first time while not having the prerequisites met.
"LrDeployment": { "AdminApiBaseUrl": "https://server.domain.com:8501/lr-admin-api", "CaseApiBaseUrl": "https://server.domain.com:8501/lr-case-api", "AieApiUrl": "https://server.domain.com:8501/lr-drilldown-cache-api", "LrApiToken": "", "DefaultLrUserId": 52, "Functions": ["Add-LrAlarmToCase", "Add-LrNoteToCase", "Add-LrPlaybookToCase", ...] }
GeneCupstid
Not long after I began to centralize the reusable components of our various automation scripts, I found the idea of centralizing certain configuration details an attractive proposition to reduce the amount of parameters that need to be passed to and between functions.
Fairly often scripts will require a static environment-specific parameter such as an API token, AD Credential, host name, API Url and so on. Having to pass the same API URL to all the various scripts that integrate with one of your other security products each time is rather unattractive and prone to problems should that URL change.
This becomes unnecessary by introducing a configuration scheme.
A couple of design considerations for discussion: