Windows PowerShell: Рабочие процессы PowerShell в сравнении со сценариями PowerShell

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

Как вы должны помнить, Windows PowerShell приходится преобразовывать рабочие процессы в код совершенно другой технологии — Windows Workflow Foundation (WF). Значит, вы можете делать только то, что можно продублировать в WF. Ваш код будет выполняться в совершенно другой среде со своими собственными правилами и ограничениями. И в самом деле, отличия между рабочими процессами и «обычными» сценариями могут оказаться существенными.

Одно пространство выполнения и много таких пространств

В обычном сценарии все работает в одном пространстве выполнения с единственной иерархией диапазонов видимости. Пространство выполнения — примерно то же самое, что процесс Windows PowerShell. Если вы представите себе окно консоли Windows PowerShell, то это и будет одно пространство выполнения. Значит, все в нем одинаковое, целостное и постоянное.

Переменные, команды, диски и все остальное ведут себя следующим образом. Они остаются какими были до тех пор, пока вы их не измените. В рамках пространства выполнения любые вносимые вами изменения «фиксируются» на протяжении всего процесса.

В рабочем процессе любая операция — команда, встраиваемый (inline) блок сценария и т.д. — может иметь свое собственное пространство выполнения. Это значит, что если вы внесете изменение в одном пространстве, то это изменение может не отразиться на других пространствах. Присваивание значения переменной в одной части рабочего процесса не повлияет на другую часть рабочего процесса, если только вы не выполните определенные действия для того, чтобы изменить такое поведение.

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

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

Синтаксические отличия

Синтаксис рабочих процессов имеет несколько особенностей, о которых я уже упоминал в предыдущих статьях своей серии:

• Нельзя использовать позиционные параметры. Вы должны вводить имя каждого параметра команды. Если раньше вы могли выполнить команду Dir C:\Windows, то теперь придется освоить вместо нее Get-ChildItem –Path C:\Windows. Вы по-прежнему можете использовать псевдонимы (такие как Dir) или сокращенные имена параметров (например, –Comput вместо –ComputerName).
• Рабочие процессы могут иметь параметры, но их имена могут состоять только из букв, цифр, подчеркиваний и дефисов. В правилах написания обычных сценариев Windows PowerShell другие требования.
• Невозможно импортировать модуль в сеанс рабочего процесса. В самом деле, команды не могут изменить состояние текущего сеанса и повлиять на последующие команды. Если в рабочем процессе необходимо задействовать модуль, воспользуйтесь параметром операции –PSRequiredModules.
• Для операции InlineScript и команд, для которых имеются реализации в виде операций рабочего процесса, доступно множество дополнительных параметров команд, в том числе только что упомянутый параметр –PSRequiredModules.
• Вы не можете запускать методы объектов в рабочем процессе нигде, кроме встраиваемых блоков сценариев. Чтобы метод работал, вы должны создать объект во встраиваемом блоке сценария.
• Нельзя запускать сценарии, предваряя путь к сценарию точкой и пробелом (dot-source).
• Нельзя использовать оператор вызова " &".
• В конструкциях Switch обязательно надо указывать параметр –CaseSensitive. Дело в том, что эквивалент конструкции Switch, используемый рабочими процессами, по своей природе, чувствителен к регистру. В операторах Switch необходимо использовать константы. Нельзя использовать операторы сравнения, регулярные выражения, ссылки на файлы или блоки сценариев. И вообще, старайтесь обойтись без конструкций Switch.
• Нельзя использовать операторы Break и Continue.
• Допустимы только PSDrive, добавленные базовыми провайдерами Windows PowerShell — файловой системой, реестром, хранилищем сертификатов, функциями, переменными оболочки и WS-Management. Чтобы использовать PSDrive, созданный модулем, выполните операцию с параметром –PSRequiredModules и укажите имя модуля.

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

Бонусы

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

• AsJob позволяет запускать рабочий процесс как фоновое задание. Можно присвоить заданию имя с помощью параметра –JobName.
• PSComputerName запускает рабочий процесс на заданном компьютере или компьютерах через Windows PowerShell Remoting.
• PSCredential и ряд связанных с ним параметров позволяют задать альтернативные варианты аутентификации.
• PSPort и другие параметры, относящиеся к соединениям, позволяют задать альтернативные параметры соединения для компонентов рабочего процесса, участвующих в удаленном взаимодействии.

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

Не хуже, не лучше, просто другие

Практический вывод из всего этого: рабочие процессы — не сценарии Windows PowerShell. Они другие. У них имеются отличия, которые могут облегчить вам жизнь. Также есть отличия, которые потребуют от вас немного дополнительных усилий. Зная эти отличия, вы сможете быстрее разрабатывать эффективные рабочие процессы.