Page History

Starting Situation

• JobScheduler executes jobs asynchroneouslyasynchronously, i.e. the completion of a job or job chain takes place independently from the caller that launched a job or order.
• There are use cases when the calling PowerShell script wants to receive execution results synchroneouslysynchronously:
  • A job is launched and the calling script should wait for completion of the job.
  • An order is launched and the calling script should wait for completion of the job chain.

Use Cases

Wait for

...

completion of a temporary order

Adding ad hoc orders is a frequent use case, e.g. for testing purposesThe following sample show how to wait for completion of an order:

Import-Module JobScheduler
Use-JobSchedulerMaster http://localhost:4444

echo "begin of test script"

$order = Add-JobSchedulerOrder -JobChain /some_path/some_job_chain
While ( ( $order | Get-JobSchedulerOrder -NoCache ).StartTime )
{
	Start-Sleep -Seconds 10
}

$orderHistory = $order | Get-JobSchedulerOrderHistory
echo "order $($orderHistory.Order) completed with state '$($orderHistory.State)' at '$($orderHistory.EndTime)'"


echo "end of test script"

Explanations

• Line 1: The Import-Module statement is used if the JobScheduler CLI module is not loaded from a profile
• Line 2: The Use-JobSchedulerMaster cmdlet is used for standalone scripts only. This is not reqired for use with It should not be used with PowerShell Jobs.
• Line 6: Adds a temporary ad hoc orders order to the specified job chain, see Add-JobSchedulerOrder.
  • The order identification is not specified but is generated by the JobScheduler Master.
  • The resulting $order object contains the order identification.
• Line 7 - 10: Repeated checks are executed in a loop repeatedly checks to verify if the order is completed.
  • The newly added order is piped to the Get-JobSchedulerOrder cmdlet that returns and an object with a StartTime property should the order still be running.
  • A sleep interval reduces the frequency of checks for completion of the current order.
• Line 12: Permanent orders are permanently available from the JobScheduler memory. Temporary ad hoc orders are removed from the JobScheduler memory after completion. Therefore the temporary ad hoc orders order is retrieved from the order history instead of the JobScheduler memory.
• Line 13: The order history provides information about the order's end time and end state that can be used to identify successful or failed execution.

Use a native PowerShell job to wait for completion of a temporary order

The following sample shows how to use native PowerShell jobs to run a number of JobScheduler orders in parallel and to wait for completion of all orders. As orders are executed in parallel by JobScheduler it is more effective to use asynchronous native PowerShell jobs than to wait for each native PowerShell job individually as from the above sampleFor better control of newly added orders it is recommended to create order objects like this:

$orders$jobScript = {
    Param ( 1..10 | Add-JobSchedulerOrder -JobChain /some_folder/some_job_chain -Immediate )
$orders | Remove-JobSchedulerOrder

Explanations

• Line 1 adds 10 temporary ad hoc orders.
  • Consider use of the switch -Immediate to submit each order individually to the JobScheduler Master and to receive the newly created order identification immediately.
  • The result of the Add-JobSchedulerOrder cmdlet is assigned to a variable for later use.
• Line 2 pipes the recently created orders to the Remove-JobSchedulerOrder cmdlet.

Identify temporary orders

Before acting on temporary orders it is recommended to identify the order objects like this:

$orders = Get-JobSchedulerOrder -NoPermanent
$orders.count

Explanations

• Line 1 retrieves exclusively temporary ad hoc orders by use of the -NoPermanent switch.
  • Consider use of additional parameters such as -Directory and -JobChain to further restrict the number of orders.
  • The result of the Get-JobSchedulerOrder cmdlet is assigned to a variable for later use.
• Line 2 displays the number of orders that meet the conditions.

Suspend temporary orders

Suspending temporary orders allows to keep such orders for further investigation. Suspended orders are not carried out by the JobScheduler Master:

Get-JobSchedulerOrder -NoPermanent | Suspend-JobSchedulerOrder

Explanations

• In a pipelined operation temporary orders are retrieved and suspended, see Suspend-JobSchedulerOrder.
• Consider use of additional parameters such as -Directory and -JobChain to further restrict the number of orders.

$orders = Get-JobSchedulerOrder -NoPermanent
$orders.count
$orders
$orders | Suspend-JobSchedulerOrder

Explanations

• Line 1 retrieves exclusively temporary ad hoc orders by use of the -NoPermanent switch.
  • Consider use of additional parameters such as -Directory and -JobChain to further restrict the number of orders.
  • The result of the Get-JobSchedulerOrder cmdlet is assigned to a variable for later use.
• Line 2 displays the number of orders that meet the conditions.
• Line 3 displays the $order variable, i.e. the list of orders.
• Line 4 pipes the list of orders to the Suspend-JobSchedulerOrder cmdlet,

Remove temporary orders

Removing temporary orders prevents JobScheduler Master from executing further job nodes of a job chain for that order.:

Get-JobSchedulerOrder -NoPermanent | Remove-JobSchedulerOrder

Explanations

• In a pipelined operation temporary orders are retrieved and removed, see Remove-JobSchedulerOrder.
• Consider use of additional parameters such as -Directory and -JobChain to further restrict the number of orders.
• Tasks that are currently running for an order are not affected by this operation. Such tasks will continue until completion. Consider use of the Stop-JobSchedulerTask cmdlet to kill running tasks.

 [Uri] $masterUrl, [string] $jobChain, [int] $pollInterval=10 )

    Import-Module JobScheduler
	
	if ( $masterUrl )
	{
		$js = Use-JobSchedulerMaster $masterUrl
	}

    $order = Add-JobSchedulerOrder -JobChain $jobChain
	While ( ( $order | Get-JobSchedulerOrder -NoCache ).StartTime )
	{
		Start-Sleep -Seconds $pollInterval
	}

    $order | Get-JobSchedulerOrderHistory
}

echo "begin of test script"

$jobs = @()
$jobs += Start-Job -ScriptBlock $jobScript -Argumentlist localhost:4444,/some_path/some_job_chain
$jobs += Start-Job -ScriptBlock $jobScript -Argumentlist localhost:4444,/some_path/some_other_job_chain

$orderHistory = $jobs | Wait-Job | Receive-Job

for( $i=0; $i -lt $orderHistory.length; $i++ )
{
	echo "order '$($orderHistory[$i].id)' completed with state '$($orderHistory[$i].State)' at '$($orderHistory[$i].EndTime)'"
}
 
echo "end of test script"

Explanations

• Line 1 - 18: defines the native PowerShell job.
  • The cmdlets used are the same as for the previous sample.
  • The native PowerShell job returns the history for the newly created order.
• Line 23 - 24: Starts the native PowerShell job
• Line 26: Pipes the native PowerShell job to the native Wait-Job cmdlet that forces the script to wait for completion. The result is then piped to the Receive-Job cmdlet that returns the output of the native PowerShell job.
• Line 28 - 31: The job output is retrieved per native PowerShell job.

...