Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Depending on the parameters every job has to be different. No general solution for a generic powershell PowerShell job is possible. That will more or less increase the effort for maintenance of jobs.

In Addition, acessing accessing at parameter by its position on the command line can lead into errors when anyone changes the commandline command line without change the script or the same script will be used by different jobs - with at the end - different command lines.

...

Code Block
 # .SYNOPSIS
 #     Creates global powershellPowerShell variables from environment variables
 # .PARAMETER Prefix
 #     Only environment variables with this prefix are converted. The prefix is cut off from
 #     the variable name
 # .Example
 #     .\CreateVariablesFromEnvironment
 #
 #     All environment variables will be converted, e.g. VAR_TEST will become $VAR_TEST
 # .Example
 #     .\CreateVariablesFromEnvironment -Prefix "SCHEDULER_PARAM_"
 #
 #     All environment variables beginning with VAR_ will be converted, e.g. VAR_TEST will become $TEST
 param ([string] $Prefix) 
 # $Prefix = "SCHEDULER_PARAM_"
 
 $envVariables = @(dir env:$Prefix*)
 foreach($envVar in $envVariables)
 \{
     $name = $envVar.Name    
     $name = $name.Substring($Prefix.Length)    
     Set-Variable -name $name -value $envVar.Value -Scope Global
 \}

Executing this script standalone or as part of another script it will parse all environment variables and create for each variable, which name is starting with "SCHEDULER_PARAM_" a powerscript variable. For example, the environment variable "SCHEDULER_PARAM_FOLDERNAME" is then acessible accessible by the script as $FOLDERNAME. This approach is more flexible than the first one, but contrasted to the first one, it is not so easy to find out, which variables from JS are used.

The advantage to use parameters by environment variables is that the access to the parameters is done by the Name of the parameter, not by the position of the name and/or value within the command line. Better: no parameter values on the command line are required.
And this solution will allow the possibility to create an universal (generic) job to run powershell PowerShell scripts.

related downloads:

...

...