Product Knowledge Base

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

There are at least two different approaches to pass parameters to a ps-script:

  • as command line parameters
  • as environment variables

As an example for both methods we will use a simple script which will list the content of a folder, filtered by a given filename extension. The parameters are defines in an order like this:

 <[http://www.sos-berlin.com/doc/en/scheduler.doc/xml/order.xml order]title="Executes the script ListFilesByExtension.ps1">
    <[http://www.sos-berlin.com/doc/en/scheduler.doc/xml/params.xml params]>
        <[http://www.sos-berlin.com/doc/en/scheduler.doc/xml/param.xml param ]name="Script_Filename"    value="ListFilesByExtension.ps1"/>
        <[http://www.sos-berlin.com/doc/en/scheduler.doc/xml/param.xml param ]name="FolderName"         value="c:\temp"/>
        <[http://www.sos-berlin.com/doc/en/scheduler.doc/xml/param.xml param ]name="FileNameExtension"  value=".txt"/> 
    </params>
    <[http://www.sos-berlin.com/doc/en/scheduler.doc/xml/run_time.xml run_time ]let_run="no"/>
 </order>

'FolderName' ist the name of the folder which has to be listed and 'FileNameExtension' is the value of the extension which will be selected.

The script code, without the initialisation of the parameters, is shown below:

 $Dir = .....
 $Ext = .....
 
 $a = "List $Dir with Extension $Ext `n" + "==========================";
 $a
 
 # Filenames as a list
 GCI $Dir -R | Where \{$_.Extension -EQ $Ext\} | sort-Object -descending Length | Format-List -property *

using command line parameters

using position parameters

  powershell ... -file "%SCHEDULER_PARAM_SCRIPT_FILENAME%" "%SCHEDULER_PARAM_FolderName%" "%SCHEDULER_PARAM_FileNameExtension%"

 $Dir = $args[0]
 $Ext = $args[1]
 .
 ...

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

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

The better approach is to use the parameters by name.

using named parameters

Starting a script like below:

    .\CreateVariablesFromEnvironment -Prefix "SCHEDULER_PARAM_"

and the first statement in the script is the param-statement:

 param ([string] $Prefix)

will fill the variable "Prefix" with the Value "SCHEDULER_PARAM_".

using environment variables

JobScheduler can provide order- and job-parameter as environment variables to the shell.

using explicit variables

The command line, which is used to start the script, has no parameters for the script:

 powershell ... -file "%SCHEDULER_PARAM_SCRIPT_FILENAME%"

The scripts gets the values for the parameters by reading the environment variable for each parameter (see Passing Parameters to shell-jobs):

 $Dir = $env:SCHEDULER_PARAM_FolderName
 $Ext = $env:SCHEDULER_PARAM_FileNameExtension
 .
 ...

Defining all needed variables at the beginning of the script will give one an overview, which variables are used from JobScheduler. In other words, this could be part of an integrated automatic documentation.

using by parsing all environment variables

JobScheduler provide more environment variables as the one which are related to a parameter. it is possible to get all this variables as "internal" named variables into the powerscript.

The script below shows how it works:

 # .SYNOPSIS
 #     Creates global powershell 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_FOLDER_NAME" is then acessible with the script as $FOLDER_NAME. 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 scripts.

related downloads:

see also:

  • No labels