Рабочие процессы 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. Они другие. У их имеются отличия, которые могут облегчить вам жизнь. Также есть отличия, которые потребуют от вас незначительно дополнительных усилий. Зная эти отличия, вы можете резвее разрабатывать действенные рабочие процессы.

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

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