Windows PowerShell: Windows PowerShell スクリプトと Windows PowerShell ワークフローの違い
今年は、Don Jones が Windows PowerShell ワークフローに関する 12 部構成のチュートリアルを毎月 1 部ずつお届けします。2013 年 1 月号から始まるシリーズは順番にお読みいただくことをお勧めします。
Don Jones
ワークフローの外観は、Windows PowerShell の関数やスクリプトのように見えますが、これらは別物です。似ているのは、表面上だけで、その表面上の領域だけを見ても、全部が似ているわけではありません。
Windows PowerShell では、ワークフローを完全に別のテクノロジである Windows Workflow Foundation (WF) に変換しなければならないことを覚えておいてください。つまり、ワークフローでは、WF で複製可能な処理しか実行できません。コードは、独自の規則や制限があるまったく異なる種類の環境で実行されることになります。実際、ワークフローと "標準" のスクリプトは大きく異なります。
1 つの実行空間と多数の実行空間
標準的なスクリプトの場合、スクリプトのすべての処理は、1 つのスコープの階層の 1 つの実行空間で実行されます。実行空間は、Windows PowerShell プロセスとほぼ同じです。Windows PowerShell コンソール ウィンドウを考えてみると、これは 1 つの実行空間です。つまり、1 つの実行空間にあるものは、すべて同じで、整合性と持続性があります。
変数、コマンド、ドライブなど、すべてのものは同じように始まります。これらは変更しない限り同じ状態のままです。同じ実行空間では、あらゆる変更内容が、そのプロセスの間持続します。
ワークフローでは、すべてのアクティビティ (すべてのコマンド、インライン スクリプト ブロックなど) は独自の実行空間を持つことができます。あるアクティビティで変更を追加した場合、その変更は、他のアクティビティでは認識されない可能性があります。ワークフローのある部分で変数を設定した場合、特別な手順を踏まない限り、ワークフローの他の部分に変更は反映されません。
先月号の記事で確認したように、ワークフローの最上位レベルで変数を定義すると、その変数はワークフローを通じて維持されます (この処理は自動的に行われます)。しかし、ワークフロー内のコマンドで変数を作成した場合、この変数をワークフローの他の部分で使用することはできません。
つまり、モジュールの使用方法も異なります。あるポイントでモジュールをインポートしても、必ずしも後続のポイントでコマンドが使用できるようになるとは限りません。1 つのワークフローは本質的に複数の独立したスコープに及ぶ可能性があるため、もう少し注意が必要になります。
構文の違い
ワークフローには、多くの構文の違いが見られます。そのいくつかについては、このシリーズの以前のコラムで紹介しました。
- 位置指定パラメーターは使用できません。すべてのコマンド パラメーターは省略せずに書く必要があります。Dir C:\Windows を実行することに慣れている方は、Get-ChildItem –Path C:\Windows を実行するように学習する必要があります。エイリアス (Dir など) や省略されたパラメーター (–ComputerName 用の –Comput など) は使用することができます。
- ワークフローで、パラメーターを使用することは可能ですが、パラメーター名に含められるのは、文字列、数字、アンダースコア、およびハイフンだけです。これは、標準的な Windows PowerShell スクリプトの規則と異なります。
- ワークフロー セッションにモジュールをインポートすることはできません。実際、コマンドでは、現在のセッションを変更して、後続のコマンドに影響を与えることはできません。ワークフローでモジュールを使用する必要がある場合、–PSRequiredModules アクティビティ パラメーターを使用する必要があります。
- ワークフロー アクティビティを実装している InlineScript アクティビティとコマンドでは、上記の –PSRequiredModules パラメーターを含む、他の多くのコマンド パラメーターが使用できます。
- ワークフローでは、インライン スクリプト ブロック以外で、オブジェクトのメソッドを実行することはできません。メソッドが機能するには、インライン スクリプト ブロックでオブジェクトを作成する必要があります。
- ドット ソース形式でスクリプトを読み込むことはできません。
- 呼び出し演算子 "&" は使用できません。
- Switch コンストラクトには –CaseSensitive パラメーターを含める必要があります。Switch コンストラクトに相当するワークフローでは大文字と小文字がネイティブに区別されます。Switch ステートメントでは定数を使用する必要があります。比較演算子、正規表現、ファイル参照、またはスクリプト ブロックは使用できません。基本的には、Switch コンストラクトは使用しないようにしてください。
- Break ステートメントと Continue ステートメントは使用できません。
- Windows PowerShell のコア プロバイダー (ファイル システム、レジストリ、証明書ストア、環境、関数、変数、および WS-Management) によって追加された PSDrives だけが有効です。モジュールによって作成された PSDrive を使用するには、アクティビティを実行するときに –PSRequiredModules パラメーターでモジュール名を指定します。
このように、Windows PowerShell のスクリプトとワークフローには、多くの違いがあります。注意深い Windows PowerShell のプログラマーであれば、パラメーターの指定など、このような違いのいくつかには気付くでしょうが、ワークフローの記述にかなり詳しくなるまでは、いくつかの違いを忘れてしまうことがあるでしょう。
おまけ
Windows PowerShell ワークフローを使用するうえで、標準的な Windows PowerShell スクリプトとの違いがすべてデメリットになるとは限りません。事実、多数の機能が無料で使用できるようになります。すべてのワークフローでは、次のような組み込みのパラメーターが使用できるようになります。
- –AsJob を使用すると、ワークフローはバックグラウンド ジョブとして実行されます。–JobName を使用してバックグラウンド ジョブにジョブ名を付けることもできます。
- –PSComputerName を使用すると、ワークフローは、Windows PowerShell リモート処理を使用して、指定したコンピューター (複数可) で実行されます。
- –PSCredential と関連するさまざまなパラメーターを使用すると、代替認証の詳細を指定できます。
- –PSPort と他の接続関連のパラメーターを使用すると、ワークフローのリモート処理コンポーネントの代替接続の詳細を指定できます。
これらのパラメーターの多くは –PS で始まっていることにお気付きでしょうか。これは名前空間と呼ばれているものです。–PS で始まる独自のパラメーターを作成しないようにすることをお勧めします。Windows PowerShell の将来のバージョンで新しいパラメーターが追加される場合、パラメーターは –PS で始まる可能性があります。原則として、このプレフィックスを使用しないようにすることで、独自のパラメーター名との競合を回避できます。
優劣ではなく、違いがある
ワークフローは Windows PowerShell スクリプトではないというのが実用的な結論です。これらは別物です。両者には作業を快適にできる違いもあれば、追加の作業が少し必要になる違いもあります。両者の違いを知ることで効果的なワークフローをより迅速に記述し始めることができます。
.jpg)
Don Jones は、Windows PowerShell MVP の受賞者で、TechNet マガジンの寄稿編集者でもあります。彼は、Windows PowerShell と Windows PowerShell リモート処理を使用して HTML 形式のレポートを作成する方法について説明した無料の書籍を含む、Windows PowerShell 3.0 ついて 4 冊の書籍を共同執筆しています。すべての書籍は PowerShellBooks.com (英語) で確認できます。また、PowerShell.org (英語) のディスカッション フォーラムでは、彼に質問することができます。