Windows PowerShell: Знакомимся с операциями рабочих процессов

При написании рабочего процесса в Windows PowerShell нужно держать в голове о том, что любая команда должна преобразовываться в операцию Windows Workflow Foundation (WF) либо операцию InlineScript.

Сначала, что такое операция? Рабочие процессы Windows PowerShell, в конечном счете, транслируются в нечто, понятное WF. А WF работает с операциями. Операция в WF — это одно действие, выполняемое в рамках рабочего процесса.

Для многих базисных команд Windows PowerShell имеются эквивалентные операции. Эти операции стопроцентно разделены от команд. Другими словами, сотрудникам группы Microsoft пришлось сесть за компы и написать и команды Windows PowerShell, к примеру, Where-Object, и надлежащие им операции WF, делающие то же самое.

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

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

Если операции нет

Если вы сделайте команду, для которой нет эквивалентной операции WF, то Windows PowerShell обернет эту команду неявным блоком InlineScript. InlineScript — операция, интегрированная в WF. На самом деле, она показывает WF, что нужно запустить копию Windows PowerShell, выполнить команду, а потом закрыть эту копию Windows PowerShell.

Так как обертывание блоком InlineScript может происходить неявно, вы сможете не выяснить, что оно вышло, и оно возможно окажется совсем внезапным вам. В сути, в Windows PowerShell 3.0, тяжело выяснить, какие команды имеют WF-эквиваленты, а какие — нет. Вы не всегда можете сказать, когда команда производится как интегрированная операция, а когда она обернута InlineScript. Почти всегда это и не надо знать. Но это может кое на что оказывать влияние.

К примеру, если вы попробуете выполнить последующий код, то он потерпите беду:

Workflow My-Workflow {
Import-Module DHCPServer
Get-DHCPServerv4Scope
}

Рабочий процесс терпит беду, так как для Import-Module нет WF-операции. Любая операция должна производиться в собственном своем процессе (практически всегда). Вспомните, что вы сможете оборвать, а потом возобновить рабочий процесс, означает, любая команда должна без помощи других создавать и завершать сеанс. Ни одна команда не может рассчитывать на код, выполняющийся в той же области памяти либо том же процессе. Windows PowerShell не будет обертывать Import-Module in блоком InlineScript, так как при всем этом открылась бы Windows PowerShell, выполнилась бы операция Import-Module, а потом Windows PowerShell закрылась бы. В итоге произошла бы выгрузка модуля, так что весь этот все эти деяния не имели бы смысла.

Но последующий код будет работать:

Workflow My-Workflow {
InlineScript {
Import-Module DHCPServer
Get-DHCPServerv4Scope
}
}

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

Блоки InlineScript

Наверное, вы сможете для себя представить, сколько рабочих процессов можно было бы разбить на один либо несколько блоков InlineScript. Ведь если в процессе необходимо выполнить более одной команды, при этом эти команды должны обмениваться плодами и выходными данными, то InlineScript — один из вероятных вариантов.

Имейте в виду, что каждый блок InlineScript представляет собой самостоятельный процесс Windows PowerShell. К примеру, последующий код не будет работать:

Workflow My-Workflow {
InlineScript {
Import-Module DHCPServer
$scopes = Get-DHCPServerv4Scope
}
InlineScript {
ForEach ($scope in $scopes) {
Write $scope.IPAddress
}
}
}

Переменная $scopes, сделанная в первом InlineScript, не будет существовать во 2-м. Код закончится с ошибкой, либо просто ничего не сделает. Может быть, вы на данный момент помыслили: «Почему бы просто не поместить все в один блок InlineScript?». Так можно поступить:

Workflow My-Workflow {
InlineScript {
Import-Module DHCPServer
$scopes = Get-DHCPServerv4Scope
ForEach ($scope in $scopes) {
Write $scope.IPAddress
}
}
}

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

Раз уж на то пошло, вы теряете многие достоинства, предоставляемые рабочими процессами. Вам как и раньше доступно удаленное выполнение. Но если б это был долгий многоэтапный процесс, то вы не смогли бы «пережить» его сбой (к примеру, отказ сети либо отключение питания) и возобновить работу с места, где произошел сбой.

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

По правде, от Windows PowerShell Workflow было бы еще больше полезности, если операции могли бы сохранять информацию во наружном хранилище (таком как SQL Server). Тогда другие операции могли бы извлекать и использовать эту информацию. Такое хранилище стало бы неизменным наружным хранилищем переменных.

К огорчению, в Windows PowerShell нет интегрированной поддержки таких хранилищ. Но ничто не мешает вам воплотить их своими силами.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.