Path variables

A path variable is a variable element that is part of an absolute path. A path variable is substituted (expanded) by actual values at a later time than when it is declared. You can use path variables in 3 contexts:

•Values of task step parameters of type "Folder or File".

•Values of task step parameters of type "SQL Command", subject to conditions.

•Values of SQL Statements contained in upgrade scripts, subject to conditions.

Delivery Manager has 8 path variables. To learn more about the 8 folders represented by a path variable, go to the " Special folders " help topic:

Path variables
$$install	The folder where USoft is installed.
$$previous	The folder where the deliverables of the previous version were released to.
$$release	The folder where the deliverables of the current version are released to.
$$root	The parent folder where deliverables of current and past releases are found.
$$stash	The folder used to stash application data that are in danger of being lost during upgrade.
$$temp	The folder that Delivery Manager uses to store intermediate files during processing.
$$unpack	The folder on a target machine where deliverables are placed before they are deployed ("unpacked").
$$using	The folder where helper files are placed that are needed to compile the database upgrade script and transformations referred to in upgrade scripts.

The $$unpack and $$using path variables are legal only in upgrade scripts, not in "Folder or File" parameters or "SQL Command" parameters.

In addition to path variables, you can also use the $$xsl path placeholder.

Example 1

This example shows a path variable in a SQL statement submitted as a task step parameter of type "SQL Command."

This example shows source-side expansion of a path variable. Source-side expansion means that the generated result does not refer to target machines. Source-side expansion applies to path variables in contexts other than upgrade scripts:

INVOKE XML.EXPORT WITH

SELECT '$$release\custom\initdata\Catalogue.xml' WriteOutputTo

, *

FROM tour

After the path variable has been expanded, the result could look like this:

INVOKE XML.EXPORT WITH

SELECT \\fs\myapp$\Releases\2.1.12\custom\initdata\Catalogue.xml' WriteOutputTo

, *

FROM tour

Example 2

This example shows a path variable in a SQL statement submitted as a SQL Statement contained in an upgrade script.

This example shows target-side expansion of a path variable. Source-side expansion applies to path variables in upgrade scripts. Target-side expansion means that the expanded result refers to individual target machines. This makes it possible for different target machines to process the same information successfully, even though locations between target machines may differ:

INVOKE XML.IMPORT WITH

SELECT '$$unpack\custom\initdata\Catalogue.xml'

After the path variable has been expanded, the result could look like this:

INVOKE XML.IMPORT WITH

SELECT

concat( decode( rulesengine.getproperty( 'ENV COMPUTERNAME' )

, 'COMPUTER_25', 'c:\usd91\udeliver'

, 'COMPUTER_33', 'c:\unpackme' ), '\custom\initdata\Catalogue.xml')

;

Source-side expansion

Path variables are expanded using source-side expansion if the path variable is in a context other than an upgrade script, ie., in a task step parameter of type "Folder or File" or "SQL Command".

The expansion happens when the task is checked or re-checked.

If underlying values change, these changes are automatically applied to source-side expansions that were marked as Correct = Yes. As as example, in the file path:

$$release\custom\mycustomfile.xml

the value represented by the path variable will automatically be re-substituted by a new release version name each time you create a release, even if the task is not re-checked.

Source-side expansion is as follows.

$$install	In source-side expansion, $$install is replaced by the value of the "Install folder" attribute of the Current Release. You can view and change this value by choosing Release, Current Release from the menu. The value of the "Install folder" attribute of the Current Release does not necessarily need to equal the actual local installation folder where USoft was (last) installed, but if there is a difference, you cannot run Tasks from the local machine.
$$previous	In source-side expansion, $$previous is replaced by the following combination of values of the "Root folder" and "Previous application version" attributes of the Current Release: root-folder\previous-application-version You can view both these values by choosing Release, Current Release from the menu. You can change the "Root folder" value only by initialising a new release tree. You can change the value of "Previous application version" only implicitly by creating a new release (choose Release, Create New Release from the menu).
$$release	In source-side expansion, $$release is replaced by the value of the "Release folder" attribute of the Current Release: root-folder\previous-application-version You can view both these values by choosing Release, Current Release from the menu. You can view this value by choosing Release, Current Release from the menu. You can change this value only implicitly by creating a new release (choose Release, Create New Release from the menu).
$$root	In source-side expansion, $$root is replaced by the value of the "Root folder" attribute of the Current Release. You can view this value by choosing Release, Current Release from the menu. You can change this value only by initialising a new release tree.
$$stash	In source-side expansion, $$stash is replaced by the value of the "Stash folder" attribute of the Current Release.You can view and change this value by choosing Release, Current Release from the menu.
$$temp	In source-side expansion, $$temp is replaced by the value of the "Temp folder" attribute of the Current Release.You can view and change this value by choosing Release, Current Release from the menu.
$$unpack	Source-side expansion does not apply to $$unpack. This path variable can only be used in upgrade scripts, where it is subject to target-side expansion.
$$using	Source-side expansion does not apply to $$using. This path variable can only be used in upgrade scripts, where it is subject to target-side expansion.

Target-side expansion

Path variables are expanded using target-side expansion if the path variable is in a SQL statement that is part of an upgrade script.

The expansion happens when the script is checked or re-checked.

If underlying values change, these changes are automatically applied to source-side expansions that were marked as Checked = Yes. As as example, if the "Unpack folder" for a target machine changes, this change is automatically reflected in the Output SQL Statement of a SQL Statement that contains:

$$unpack\custom\mycustomfile.xml

even if the script is not re-checked. However, for the change to propagate to physical upgrade scripts released on the file system, you will need to re-run the Release Scripts action.

For successful execution of upgrade scripts, you will need to declare each target machine where you want to run the upgrade as a Computer. To do this, choose Define, Computers from the menu. If you want to test the upgrade scripts by running them on a Development or Test machine, this machine must also be declared as a Computer.

$$install	In target-side expansion, the expression $$install\myfile.xml is replaced by: concat( decode( RulesEngine.GetProperty( 'SystemDir' ), , '\myfile.xml' ) This means that on each target machine, $$install represents the actual folder where USoft was (last) installed, not the value of the "Install folder" Computer attribute for the target machine.
$$previous	Note: Intended use in upgrade scripts is that you refer to unpack folders (using $$unpack) rather than to previous release folders. In target-side expansion, for each declared Computer, the expression $$previous\myfile.xml is replaced by the following pattern: previous-folder\myfile.xml ... ... where RulesEngine.GetProperty( 'ENV COMPUTERNAME' ) = computer where computer and previous-folder are values specified in the Computers window (Define, Computers from the menu) for each target machine, for example: invoke xml.export with select 'c:\Releases\2.0.6\Tours.xml' WriteOutputTo , * from tour where RulesEngine.GetProperty( 'ENV COMPUTERNAME' ) = 'SERVER_1' ; invoke xml.export with select 'c:\MyApp\Tours.xml' WriteOutputTo , * from tour where RulesEngine.GetProperty( 'ENV COMPUTERNAME' ) = 'SERVER_2' ;
$$release	Note: Intended use in upgrade scripts is that you refer to unpack folders (using $$unpack) rather than to release folders. In target-side expansion, the expression $$release\myfile.xml is replaced following the same principle shown for $$previous above.
$$root	Note: Intended use in upgrade scripts is that you refer to unpack folders (using $$unpack) rather than to root folders. In target-side expansion, the expression $$root\myfile.xml is replaced following the same principle shown for $$previous above.
$$stash	In target-side expansion, the expression $$stash\myfile.xml is replaced following the same principle shown for $$previous above.
$$temp	In target-side expansion, the expression $$temp\myfile.xml is replaced following the same principle shown for $$previous above..
$$unpack	In target-side expansion, the expression $$unpack\myfile.xml is replaced following the same principle shown for $$previous above.
$$using	In target-side expansion, the expression $$using\myfile.xml is replaced following the same principle shown for $$previous above.