Variables are a feature of MDLink that allow you to define a string value in one place and refer to it in many places throughout your solution. The benefit of using variables is that when you want to change a variable’s value, you only need to change it in one centralized place, rather than track down all of the references and change them one at a time.
Variables are commonly used for values such as port numbers, folder paths, or constant strings that need to appear in your HL7 messages.
Say for example you have twenty File Writer Tasks that all need to write files to the same directory – C:\output. Without variables, you would need to enter “C:\output” into the ‘Directory’ text field of all twenty of these, and then if you wanted to change the folder to D:\output, you would need to go through all twenty and manually change the C:\ to D:\. With variables, instead of entering “C:\output” in the "directory" field, you can enter “$outputDir”, then define a variable named ‘outputDir’ with a value of “C:\output”. When you want to change the directory to D:\output, you only need to edit the value of the variable, rather than edit the directory field of all twenty File Writer Tasks.
You can also use variables to build a longer string. For example you could enter in some of your File Writer Tasks "$outputDir\HL7" and in some "$outputDir\FlatFiles", and when you load your solution these will become C:\output\HL7 and C:\output\FlatFiles respectively. Or if you also defined a variable named "subDir", you could specify "C:\$outputDir\$subDir" in your File Writer Task.
There are two types of variables that are supported by MD Link.
1) Global Variables:
These variables can be referenced in any solution. They are ‘global’ across solutions. To edit global variables, use the editor under the Start Menu or in the solution level properties of the Studio. Global variables are stored under the config folder in a YAML format, so in addition to the GUI editor, you can also edit this file manually. The Server or Studio (wherever the solution is run) needs to be restarted in order for the changes in the Global Variables to take effect.
2) Solution Variables:
Solution variables are stored inside the solution file. Each solution has its own set of solution variables, and cannot access any other solution’s set of solution variables. The editor for solution variables is accessible from the solution level properties of the Studio. For the changes in the solution variables to take effect, the solution must be restarted.
If there is a solution variable and a global variable with the same name, the value of the solution variable will be used.
Within the Variables GUI editor, by right clicking on the table you can add a variable, add an encrypted variable, toggle the encryption of a variable, or delete a variable.
Variable names can start with letters or the underscore and can contain numbers and periods. You can edit the variable name or value by double clicking on it.
There are no such restrictions on variable values, except that multi-line variable values aren't supported.
If you rename a solution variable, MDLink will automatically find all of the references to the variable in the solution and update the name to the new one, so that your solution’s functionality will not be affected by any variable renaming. With global variables however, this is not feasible for MDLink to do, so you will have to track down references to your global variable yourself if you ever want to rename one.
Both global and solution variables can have different profiles. The default profile is always present, and for many use cases, it will be sufficient. If however you would like to maintain two copies of values for a set of variables (for example, one for your test and one for production environments) and switch easily between them, then variable profiles can help you do this.
You could, for example, put all of your general variables (that will not change between test and production) in the default profile, then create two more profiles: one called 'Test' and other as 'Prod'. In ‘Test’ and ‘Prod’ you can then override the particular variables that you need to be different in those environments (such as port numbers or folder paths.) To select the active profile to use, select your desired profile (default, Test, or Prod) in the drop-down box in the variables editor, and restart your solution.
To add a new profile, click the '+' tab, and give your new profile a name. (Unlike variable names, there are no restrictions on the valid characters in profile names – but they still must be unique.) If you want to override a variable in your Test profile, right-click and select ‘override default variables’.
You can delete a profile by clicking the 'x' beside the profile name. To rename or copy a profile, right click on the profile name tab.
The default profile cannot be deleted.
There are two different syntaxes for referencing a variable. Continuing with our output directory example, they are:
${output.dir}
$outputDir
If the variable name contains a period then it has to be referenced with the braces (that is, ${output.dir}) syntax. If there is no period then it can be referenced in either way.
Only the ${} syntax is supported from XSLT code.
You can access variables from Jython scripts with two engine functions, as shown by these example lines of Jython code:
x = engine.getVarVal('outputDir')
print engine.subVarVals('Outputting to the $outputDir\HL7 directory.')
When using the getVarVal function in Jython, do not include the $, {, or } characters. Use only the exact variable name. Only one variable name is allowed.
When using subVarVals however, you must use $ (and optionally {}). Multiple variable names are allowed. Non-variable text can be interspersed with variable references – in this case, the surrounding log message.