sergey vasin

Резюме: Microsoft Windows PowerShell MVP Richard Siddaway рассказывает об ограничениях в рабочих процессах Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson на связи. Сегодня мы публикуем второй пост из серии статей об использовании рабочих процессов за авторством Windows PowerShell MVP Richard Siddaway.

Заметка: Первый пост «PowerShell Workflows: Основы» рассказывает об основных концепциях рабочих процессов. Перед чтением этой статьи вам стоит ознакомиться с ним.

Richard Siddaway написал несколько гостевых постов, кроме этого он является автором двух книг по Windows PowerShell. Последняя его книга, PowerShell in Depth написана в соавторстве двумя другими MVP – Don Jones и Jeffrey Hicks.

Итак.

В прошлом посте я рассказал об основах рабочих процессов Windows PowerShell. Я также коснулся нескольких ограничений рабочих процессов. Думаю, пришла пора рассмотреть их поближе и определить обходные пути для их преодоления.

Ограничения рабочих процессов можно разделить на следующие группы:

• Области действия переменных
• Десериализованные объекты
• Командлеты, для которых не было создано активностей
• Неподдерживаемые активности Windows PowerShell

Неподдерживаемые активности Windows PowerShell

Некоторые ключевые слова и используемые техники Windows PowerShell не поддерживаются в рабочих процессах. Они приведены в следующей таблице.

Неподдерживаемые техники Windows PowerShell
Begin,Process,End	Break,Continue	Подвыражения
Множественное назначение переменных	Изменение переменных цикла	Динамические параметры
Задание свойств	Оператор точка	Расширенная валидация   параметров
Позиционные параметры	Выражение Switch	Выражение Trap
Встроенная справка	Задание дисковых переменных	Вызов методов из объектов
Единственнное #requires

Еще одно ограничение которое мне встречалось, это использование пользовательских дисков Windows PowerShell – если они присутствуют, рабочие процессы могут перестать выполняться.

Некоторые их этих ограничений, например использование выражения trap, не такая уж большая проблема. Вместо него вы можете использовать try-catch. Другие ограничения приносят больше неудобств, например невозможность использовать выражение switch. Если вы попробуете использовать switch в рабочем процессе:

workflow testswitch {

   param (

   [string]$os

   )

   switch ($os) {

      «XP» {«Time to upgrade»}

      «Windows7» {«OK — but not the lastest»}

      «Windows 8» {«Latest and greatest»}

   }

}

то вы получите море красных сообщений:

At line:5 char:2

+ switch ($os) {

+ ~~~~~~~~~~~~~~

Case-insensitive switch statements are not supported in a Windows PowerShell workflow. Supply the -CaseSensitive flag, and ensure that case clauses are written appropriately. To write a case-insensitive case statement, first convert the input to either uppercase or lowercase, and update the case clauses to match.

   + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException

   + FullyQualifiedErrorId : SwitchCaseSensitive

Прочитав сообщение об ошибке вы можете подумать, что можно сделать следующее:

workflow testswitchi {

   param (

   [string]$os

   )

   switch -CaseSensitive ($os.ToUpper()) {

      «XP» {«Time to upgrade»}

      «WINDOWS7» {«OK — but not the lastest»}

      «WINDOWS 8» {«Latest and greatest»}

   }

}

Нет, опять ошибка.

At line:5 char:25

+ switch -CaseSensitive ($os.ToUpper()) {

+ ~~~~~~~~~~~~~

Method invocation is not supported in a Windows PowerShell Workflow. To use .NET Framework scripting, place your commands in an inline script:

InlineScript {

}.

   + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException

   + FullyQualifiedErrorId : MethodInvocationNotSupported

Ну что ж, воспользуемся InlineScript.

workflow testswitch {

   param (

  [string]$os

  )

  InlineScript {

    switch ($using:os) {

      «XP» {«Time to upgrade»}

      «Windows7» {«OK — but not the lastest»}

      «Windows 8» {«Latest and greatest»}

    }

  }

}

В этом случае все работает так, как от него ожидается.

Еще одно ограничение, невозможность использования блоков BEGIN, PROCESS и END, которые вы можете использовать в функциях, затрагивает вещи, которые просто не укладываются в концепцию рабочих процессов. Другое ограничение, оказывающее значительное влияние – это невозможность использования справки на основе комментариев. Вы должны использовать XML-файлы. Существует несколько способов генерации этих файлов, один из наиболее простых – это использовать InfoPath, как описывает James O’Neill.

Невозможность валидации параметров может стать значительным неудобством, если ваши рабочие процессы используют большое их число. Для этого ограничения не существует обходных путей кроме написания кода валидации в самом рабочем процессе.

Вы уже видели выражение $using:computer в предыдущем посте и $using:os в скрипте, касающемся использования выражения switch. Этот синтаксис используется для преодоления ограничений, относящихся ко второй группе – области действия переменных.

Области действия переменных

В рабочих процессах существуют следующие ограничения на использование переменных:

• Переменные, определенные в верхней области видны в нижних областях, но не видны в блоках InlineScript
• Невозможно определить переменную в нижней области с именем, совпадающим с переменной в верхней области
• Если определить или переопределить переменную, вы можете вы можете без всяких проблем использовать ее в этой области
• Не существует области $global
• Для использования в блоке InlineScript переменных, определенных в верхней области, нужно указывать «$using»
• Изменение в блоке InlineScript переменной, определенной в верхней области требует использования временной переменной
• Для изменения переменных, определенных в верхней области нужно использовать «$workflow»
• Нельзя использовать подвыражения

Это может показаться несколько запутанным, но демонстрация должна внести некоторую ясность. Я рекомендую вам запустить этот код и рассмотреть полученные результаты.

workflow demo-scope {

   # This is a workflow top-level variable

  $a = 22

  «Initial value of A is: $a»

  # Access $a from Inlinescript (bringing a workflow variable to the Windows PowerShell session) using $using

  inlinescript {«PowerShell variable A is: $a»}

  inlinescript {«Workflow variable A is: $using:a»}

  ## changing a variable value

  $a = InlineScript {$b = $Using:a+5; $b}

  «Workflow variable A after InlineScript change is: $a»

  parallel {

    sequence {

      # Reading a top-level variable (no $workflow: needed)

      «Value of A inside parallel is: $a»

      # Updating a top-level variable with $workflow:

      $workflow:a = 3

    }

  }

  «Updated value of A is: $a»

}

demo-scope

После запуска рабочего процесса вы должны увидеть нечто подобное.

Initial value of A is: 22

PowerShell variable A is:

Workflow variable A is: 22

Workflow variable A after InlineScript change is: 27

Value of A inside parallel is: 27

Updated value of A is: 3

Рабочий процесс начинается с определения переменной, $a=22, затем он выводит ее значение. Если вы попытаетесь получить содержимое переменной, определенной в верхней области, из блока InlineScript, ничего не получится, как показано во второй строке вывода. Для доступа к переменной вам нужно использовать $using. Если вам нужно изменить значение этой переменной, то для этого потребуется использовать вторую переменную и затем возвратить новое значение.

$a = InlineScript {$b = $Using:a+5; $b}

Вывод показывает, что теперь переменная обладает значением 27.

Доступ к переменной из блока parallel происходит без каких-либо сложностей. Если вам нужно изменить значение этой переменной в блоке parallel, потребуется указать $workflow.

Подводя итоги работы с переменными: не переусложняйте скрипт и будьте осторожны.

Десериализация объектов

Третье ограничение заключается в том, что объекты в рабочих процессах десериализованы. Это сродни с удаленным выполнением команд в Windows PowerShell (что неудивительно, так как рабочие процессы используют тот же транспортный механизм). Можно заметить что десериализация объектов встречается все чаще и чаще. Области, где она встречается:

• Удаленная работа в Windows PowerShell
• Удаленный доступ посредством CIM-сессий
• Командлеты WSMAN
• Рабочие процессы

Возможно это становится стандартным подходом к работе в Windows PowerShell.

Десериализованный объект обладает свойствами объекта, но не его методами. Другими словами, он инертный. Огромная часть кода Windows PowerShell делает нечто подобное:

$string = «abcde»

$string.ToUpper()

$os = Get-WmiObject -Class Win32_OperatingSystem

$os.ConvertToDateTime($os.LastBootUpTime)

Однако в случае с рабочими процессами это не сработает.

workflow test2 {

   $string = «abcde»

  $string.ToUpper()

  $os = Get-WmiObject -Class Win32_OperatingSystem

  $os.ConvertToDateTime($os.LastBootUpTime)

}

При попытке запуска появится сообщение об ошибке, указывающее, что вызов методов не поддерживается. Однако, вы можете сделать следующее:

workflow test2 {

  inlinescript {

    $string = «abcde»

    $string.ToUpper()

    $os = Get-WmiObject -Class Win32_OperatingSystem

    $os.ConvertToDateTime($os.LastBootUpTime)

  }

}

Не пытайтесь использовать переменные, содержащие объекты из верхней области действия, для вызова методов – это не сработает.

Подводя итоги, касательно десериализованных объектов – если вам нужно вызвать метод объекта, делайте это из блока InlineScript. Помните, что вы можете вкладывать блоки InlineScript в блоки Parallel.

Командлеты, для которых не было создано активностей

Последнее ограничение касается командлетов, которые не для которых не было создано соответствующих активностей. Как вы помните, в предыдущем посте нам встретилась проблема использования командлетов Format* в рабочих процессах. Это можно обойти, используя InlineScript.

workflow foreachpitest {

   param([string[]]$computers)

  foreach –parallel ($computer in $computers){

    InlineScript {

      Get-WmiObject –Class Win32_OperatingSystem –ComputerName $using:computer |

      Format-List

    }

  }

}

Другие командлеты, которые не могут быть использованы в рабочих процессах приведены в таблице. Вы можете использовать их внутри InlineScript.

Неподдерживаемые командлеты (группы)	Причина
*Alias, *FormatData, *History, *Location, *PSDrive, *Transcript, *TypeDate, *Variable, Connect/Disconnect-Wsman	Вносят изменения только в текущую сессию, поэтому не требуются в рабочих процессах
Show-Command, Show-ControlPanelItem, Get-Credential, Show-EventLog, Out-Gridview, Read-Host, Debug-Process	Рабочие процессы не поддерживают интерактивные командлеты
*BreakPoint, Get-PSCallStack, Set-PSDebug	Рабочие процессы не поддерживают отладку скриптов
*Transaction	Рабочие процессы не поддерживают транзакции
Format*	Отсутствует поддержка форматирования
*PSsession, *PSsessionoption	Удаленный доступ контролируется рабочим процессом
Export-Console,Get-ControlPanelItem, Out-Default, Out-Null, Write-Host, Export-ModuleMember, Add-PSSnapin, Get-PSSnapin, Remove-PSSnapin, Trace-Command

Ниже приведена таблица с командлетами, которые поддерживают только локальное выполнение, при использовании их в рабочем процессе.

Add-Member	Compare-Object	ConvertFrom-Csv	ConvertFrom-Json
ConvertFrom-StringData	Convert-Path	ConvertTo-Csv	ConvertTo-Html
ConvertTo-Json	ConvertTo-Xml	ForEach-Object	Get-Host
Get-Member	Get-Random	Get-Unique	Group-Object
Measure-Command	Measure-Object	New-PSSessionOption	New-PSTransportOption
New-TimeSpan	Out-Default	Out-Host	Out-Null
Out-String	Select-Object	Sort-Object	Update-List
Where-Object	Write-Debug	Write-Error	Write-Host
Write-Output	Write-Progress	Write-Verbose

Если вам нужно запустить их удаленно, как вы наверное уже догадались, используйте InlineScript.

Узнать больше об ограничениях рабочих процессов вы можете в файлах справки:

about_ActivityCommonParameters

about_Checkpoint-Workflow

about_Foreach-Parallel

about_InlineScript

about_Parallel

about_Sequence

about_Suspend-Workflow

about_WorkflowCommonParameters

about_Workflows

Если вы только запустили PowerShell, вы можете их не увидеть. Импортируйте модуль PSWorkflow и они станут доступными.

В этой статье я попытался рассказать об ограничениях, с которыми вы можете встретиться, используя рабочие процессы. Как я сказал в предыдущей статье, «PowerShell Workflows: Основы», если вы не знаете об ограничениях, вы можете здорово о них споткнуться.

В следующей статье мы рассмотрим вложенные рабочие процессы а также использование функций Windows PowerShell с рабочими процессами.

~Richard.

Автор:

Ed Wilson, Microsoft Scripting Guy

Оригинал:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/01/02/powershell-workflows-restrictions.aspx

---

Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell

---