The $.Settings of a Linx solution are constants or static values, which are available to use throughout the entire solution. What happens in some cases is that a user may have a setting value defined, such as a long string like Database connection strings, QuickBooks credentials, etc.
It can however become quite cumbersome when there is a need for regular manual updates of setting values in different parts of your Solution. For example, in the long JSON format of QuickBooks credentials, the AccessToken in development changes daily, which means that a user will have to update the large JSON string regularly.
To get around this tiresome activity, consider the following scenario:
a user may want to define a setting that has placeholders in it and then replace these values at runtime with other values. This ‘replace’ is normally done in the expression editor of the function in question.
For example, you may have a Database connection string defined as a Setting:
Data Source=#Server#;Initial Catalog=#InitialCatalog#;Integrated Security=;User ID=#User#;Password=#Password#;
Note: You don’t have to define the placeholders with ‘#’ - this is a personal style. It is recommended that you choose a placeholder style that will uniquely mark placeholders, i.e. not have them as simple words, because words that match the placeholder names may exist in the value for which you are searching and replacing.
Next, you can have other $.Setting values defined that will be used for the placeholders, like below:
In an ExecuteSQL function (used as an example), the connection string property can be defined as:
This makes use of the .Replace() command, and is created at runtime.
When a user has multiple SQL calls, s/he will need to include the .Replace() command (as above), every time a Database function is used. Although s/he could copy the above expression and use it repeatedly, it still is a bit cumbersome and would be much easier if you could just point to one settings value.
You can achieve the above by doing the ‘replace’ in the $.Setting value itself (although this is a different replacing method than the one done in the Expression Editor).
To do this, you must make use of {} brackets to refer to another setting name, i.e. {#YourOtherSettingNameHere#}
For example:
Setting_1: THIS IS MY OTHER SETTING
Setting_2: This is the setting and {Setting_1}
Result at runtime:
This is the setting and THIS IS MY OTHER SETTING
In our database connection string example (see above), it would look like:
Data Source={Credentials_Server};Initial Catalog={Credentials_InitialCatalog};Integrated Security=;User ID={Credentials_Username};Password={Credentials_Password};
At runtime, the connection string would be:
Data Source=MYSERVER-2019;Initial Catalog=TestTable;Integrated Security=;User ID=MyUser;Password=Password123456;
Once you have set up this dynamic setting correctly, you are able to refer to this setting throughout your solution, instead of using the .Replace() method each time.
