The focus on this series has been on Windows PowerShell jobs, including learning about the core job cmdlets, using the
–AsJob<\/b> parameter, running jobs on remote machines, and figuring out how scheduled jobs work. Today, we are going to look at using the Windows PowerShell job engine with Windows PowerShell workflows.<\/p>\n
Workflows are another piece of the Windows PowerShell technology, which (as with Windows PowerShell jobs) is underused. Workflows have a reputation for being difficult to work with and understand. If you’ve not experimented with workflows, I recommend that you read this series of Hey,Scripting Guy! Blog posts that I wrote in 2013:<\/p>\n
1. PowerShell Workflows: The Basics<\/a> 2. PowerShell Workflows: Restrictions<\/a> 3. PowerShell Workflows: Nesting<\/a> 4. PowerShell Workflow: Job Engine<\/a> 5. PowerShell Workflows: Restarting the Computer<\/a> 6. PowerShell Workflows: Using Parameters<\/a> 7. PowerShell Workflows: Design Considerations<\/a> 8. PowerShell Workflows: A Practical Example<\/a> In particular, you should read post 4 about workflows and the Windows PowerShell job engine. That post looked at things from the workflow point of view. Today we’ll look at things from the job engine’s perspective.<\/p>\n Let’s start with a simple workflow:<\/p>\n workflow mysimpleworkflow<\/p>\n {<\/p>\n Get-Process<\/p>\n } <\/p>\n mysimpleworkflow<\/p>\n This produces a list of processes that are running on the computer. It’s important to note that in a workflow, you aren’t dealing with a Windows PowerShell cmdlet, but rather, a workflow activity that functions in a similar way to the cmdlet of the same name.<\/p>\n If you look at the syntax of the workflow:<\/p>\n £> Get-Command mysimpleworkflow -Syntax<\/p>\n mysimpleworkflow [<WorkflowCommonParameters>] [<CommonParameters>]<\/p>\n It would have been nice if I could list the WorkflowCommonParameters, but there are a lot of them. You can read about them in the Help file about_WorkflowCommonParameters<\/a>. If you read the Help file (and I recommend reading all of the workflow-related Help files), you will see that –AsJob<\/b> is the first common parameter and –JobName<\/b> is the second.<\/p>\n What about the workflow activities? Can we run those as a job? If you look at another Help file, about_ActivityCommonParameters<\/a>, you’ll see that there aren’t any job-related parameters for workflow activities. We’ll come back to this in a while.<\/p>\n What happens when we run our workflow as a job?<\/p>\n The workflow was run as a job:<\/p>\n mysimpleworkflow -AsJob -JobName wftest<\/p>\n I previously dot-sourced the Windows PowerShell script that contains the workflow. A job (Id 6) is started. This time, it’s of type PSWorkflowJob<\/b>. You can use the standard job cmdlets Get-Job<\/b>, Receive-Job<\/b>, and Remove-Job<\/b> as shown in the screenshot. Apart from the type, the workflow job is behaving as a standard Windows PowerShell job. Isn’t consistency lovely? Makes our job so much easier.<\/p>\n You may remember that in Part 1 of this series, I mentioned that the Suspend-Job<\/b> and Resume-Job<\/b> cmdlets can only be used with workflow jobs. This is how you use them…<\/p>\n Start by creating a new workflow.<\/p>\n workflow mysuspenableworkflow<\/p>\n {<\/p>\n Start-Sleep -Seconds 10<\/p>\n Suspend-Workflow<\/p>\n Get-Process<\/p>\n }<\/p>\n The workflow will sleep for 10 seconds and then suspend itself. When it resumes, it calls the Get-Process<\/b> activity as in our previous example.<\/p>\n Dot-source and run the workflow. It sleeps for 10 seconds and then suspends. When the workflow suspends itself, a job is created in a suspended state. Notice that the workflow was started without the –AsJob<\/b> parameter. Suspending a workflow will create the job. The type is still PSWorkflowJob.<\/p>\n You use the Resume-Job<\/b> cmdlet to get the job running again. In Windows PowerShell 4.0, resuming a suspended job shows the output in the screenshot with the job’s State<\/b> set to Running<\/b>. In Windows PowerShell 3.0, when you used Resume-Job<\/b>, the State<\/b> was still shown as Suspended<\/b>, and you had to use Get-Job<\/b> to see the true state. After the job has completed, you can view the data and remove it as normal.<\/p>\n There’s one really clever feature of suspending a workflow job: You can access it in a different Windows PowerShell session. Run the workflow again until the job suspends. When you see the message that the job has suspended, close your Windows PowerShell session.<\/p>\n Yep, that’s right. Just go ahead and shut it down.<\/p>\n Open a new Windows PowerShell session (with elevated privileges) and run Get-Job<\/b>. Your suspended job will be visible if you’re using Windows PowerShell 4.0. (In Windows PowerShell 3.0, you have to import the PSWorkflow module first to be able to see the suspended jobs). You can resume the job and proceed.<\/p>\n What happens if you use the –AsJob<\/b> parameter on a workflow that’s going to suspend?<\/p>\n Start the workflow, but this time start it as a job:<\/p>\n mysuspenableworkflow -AsJob -JobName suspendtest<\/p>\n You immediately get a running job that suspends itself after the appropriate amount of time. You can resume the job and proceed as before.<\/p>\n You can also suspend long running jobs from outside the job. Workflows are designed for long running tasks. You can simulate that by using a long sleep interval. This work flow will run for a while before it shows any output:<\/p>\n workflow mylongworkflow<\/p>\n {<\/p>\n Start-Sleep -Seconds 60<\/p>\n Checkpoint-Workflow<\/p>\n Get-Process<\/p>\n }<\/p>\n In this case, we want to start the workflow as a job so that we can suspend it at will.<\/p>\n Suspend the job. Your job goes into a state of Suspending<\/b>. This means that it will run until it hits the CheckPoint-Workflow<\/b> activity which saves a copy of the job’s state to disk and finally suspends the job.<\/p>\n If you are suspending the workflow job from inside the workflow, use the Suspend-Workflow<\/b> activity. If you are going to suspend the workflow job manually, ensure that you have CheckPoint-Workflow<\/b> at suitable points in your workflow so that the workflow can create a checkpoint and suspend.<\/p>\n Resume-Job<\/b> and the other cmdlets work as expected. You could resume the workflow job in a different Windows PowerShell session if required.<\/p>\n We’ve discussed running workflows as jobs. But what about running jobs inside workflows? This will start a job inside a workflow, and then run the workflow:<\/p>\n workflow myjobflow<\/p>\n {<\/p>\n Start-Job -ScriptBlock{Get-Process}<\/p>\n }<\/p>\n The workflow starts, and you can see that it shows a job is created. But if you try Get-Job<\/b>,nothing is returned. The reason is that workflows aren’t run by your Windows PowerShell session. They are handed off to the workflow engine to run in a different process. That process shuts down when the workflow finishes, and you lose the job. I don’t really think there is any advantage to running jobs inside workflows because you have to handle checking that the job is complete, and then return any data from the job while the workflow is still running.<\/p>\n The best strategy is to run the workflow as a job. Then you get the best of both worlds.<\/p>\n That’s it for today. Tomorrow you’ll learn about the processes under which different job types run. Bye for now.<\/p>\n ~Richard<\/p>\n Thanks, Richard. Looking forward to the final posts in this series.<\/p>\n I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n Ed Wilson, Microsoft Scripting Guy<\/b> <\/p>\n","protected":false},"excerpt":{"rendered":" Summary: Richard Siddaway introduces you to using the Windows PowerShell job engine with your Windows PowerShell workflows. Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. This is the fifth in a series of posts that, hopefully, will shine the spotlight on Windows PowerShell jobs, remind people of […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[193,189,4,45],"class_list":["post-1869","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-background-jobs","tag-richard-siddaway","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":" Summary: Richard Siddaway introduces you to using the Windows PowerShell job engine with your Windows PowerShell workflows. Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. This is the fifth in a series of posts that, hopefully, will shine the spotlight on Windows PowerShell jobs, remind people of […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/1869","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=1869"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/1869\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=1869"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=1869"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=1869"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Introduces workflows, key concepts, and keywords.<\/p>\n
Discusses cmdlets that are not available as workflow activities, using in-line script, and using variables.<\/p>\n
Investigates how Windows PowerShell functions and Windows PowerShell workflows can be used inside other workflows.<\/p>\n
Investigates suspending, resuming, checkpoints, and recovery.<\/p>\n
Investigates how workflows can survive a reboot.<\/p>\n
Investigates parameters that are available to workflows and activities, the options for connecting to remote computers, and the workflow cmdlets.<\/p>\n
Investigates design considerations for Windows PowerShell workflows.<\/p>\n
Pulls together the various strands of the series and presents the development of a workflow.<\/p>\n![\"Image](\"https:\/\/msdnshared.blob.core.windows.net\/media\/TNBlogsFS\/prod.evol.blogs.technet.com\/CommunityServer.Blogs.Components.WeblogFiles\/00\/00\/00\/76\/18\/0434.1.PNG\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/msdnshared.blob.core.windows.net\/media\/TNBlogsFS\/prod.evol.blogs.technet.com\/CommunityServer.Blogs.Components.WeblogFiles\/00\/00\/00\/76\/18\/3056.2.PNG\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/msdnshared.blob.core.windows.net\/media\/TNBlogsFS\/prod.evol.blogs.technet.com\/CommunityServer.Blogs.Components.WeblogFiles\/00\/00\/00\/76\/18\/6457.3.PNG\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/msdnshared.blob.core.windows.net\/media\/TNBlogsFS\/prod.evol.blogs.technet.com\/CommunityServer.Blogs.Components.WeblogFiles\/00\/00\/00\/76\/18\/0172.4.PNG\" "\\"Image")
<\/a><\/p>\n![\"Image](\"https:\/\/msdnshared.blob.core.windows.net\/media\/TNBlogsFS\/prod.evol.blogs.technet.com\/CommunityServer.Blogs.Components.WeblogFiles\/00\/00\/00\/76\/18\/8422.5.PNG\" "\\"Image")
<\/a><\/p>\n