Azure Logic Apps で Standard ワークフローを使用して PowerShell スクリプトを追加して実行する

適用対象: Azure Logic Apps (Standard)

Azure Logic Apps で Standard ワークフローを使用してインラインでカスタム統合タスクを実行するには、ワークフロー内から PowerShell コードを直接追加して実行できます。 このタスクでは、PowerShell コードの実行という名前のインライン コード アクションを使います。 このアクションは PowerShell コードからの結果を返すので、この出力をワークフローの後続のアクションで使用できます。

この機能には、次の利点があります。

• 複雑な統合の課題を解決できるように、ワークフロー デザイナー内で独自のスクリプトを記述します。 他のサービス プランは必要ありません。

  この利点により、より多くのサービスを管理し、ワークフロー開発を合理化できるため、複雑さとコストが削減されます。

• 専用のコード ファイルを生成します。このファイルは、ワークフロー内でカスタマイズされたスクリプト領域を提供します。

• 高度なタスク実行のための強力な機能と継承を提供する Azure Functions PowerShell 関数と統合します。

• ワークフローと共にスクリプトをデプロイします。

このガイドでは、ワークフローにアクションを追加し、実行する PowerShell コードを追加する方法について説明します。

前提条件

• Azure アカウントとサブスクリプション。 無料の Azure アカウントを取得します。

• PowerShell スクリプトを追加するワークフローを含む Standard ロジック アプリ リソース。

  このワークフローは、トリガーで既に開始されている必要があります。 シナリオには任意のトリガーを使用できますが、例として、このガイドでは HTTP 要求の受信時という名前の要求トリガーと、応答アクションを使用します。 ワークフローは、別のアプリケーションまたはワークフローがトリガーのエンドポイント URL に要求を送信したときに実行されます。 サンプル スクリプトは、コード実行の結果を出力として返しますが、これは、後続のアクションで使用できます。

  ロジック アプリのリソースとワークフローがない場合は、次の手順に従って今すぐ作成します。

  • 標準ロジック アプリ ワークフローを作成する

考慮事項

• Azure portal では、スクリプトは workflow.json ファイルと同じフォルダーに PowerShell スクリプト ファイル (.ps1) として保存されます。これにはワークフローの JSON 定義が格納されており、ワークフロー定義と共にファイルがロジック アプリ リソースにデプロイされます。

  .ps1 ファイル形式を使用すると、"定型" を減らし、PowerShell コードの記述だけに集中できます。 アクションの名前を変更すると、ファイルの名前も変更されますが、その逆は行われません。 ファイルの名前を直接変更すると、名前が変更されたバージョンによって以前のバージョンが上書きされます。 アクション名とファイル名が一致しない場合、アクションはファイルを見つけられず、新しい空のファイルの作成を試みます。

• スクリプトはワークフローに対してローカルです。 他のワークフローで同じスクリプトを使用するには、Kudu コンソールでスクリプト ファイルを表示し、スクリプトをコピーして他のワークフローで再利用します。

制限事項

PowerShell のバージョンを更新する

ロジック アプリ リソースで PowerShell のバージョンを変更するには、アプリケーション設定を編集します。 ただし、アプリをアップグレードする前に、次の考慮事項を確認してください。

• バージョンのアップグレードでは、Azure Functions ランタイムの拡張機能としてホストされているランタイムを使用する Standard ロジック アプリに破壊的変更が加えられる可能性があります。 アップグレードする前に、次の移行ガイド を確認してください。PowerShell 7.4 で実行するように Azure Functions アプリをアップグレードします。

• ロジック アプリで Azure Functions ランタイム (バージョン 4.x) の最新のランタイム バージョンが使用されていることを確認します。 詳細については、「 現在のランタイム バージョンを表示する」を参照してください。

PowerShell バージョンを更新する場所に基づいて、対応する手順に従います。

PowerShell コードの実行アクションを追加する

1. Azure portal で、Standard ロジック アプリ リソースを開きます。

2. リソース サイドバーの [ ワークフロー] で [ ワークフロー] を選択し、空のワークフローを選択します。

3. ワークフロー サイドバーの [ ツール] で、デザイナーを選択してワークフローを開きます。

4. アクションを追加する一般的な手順に従って、PowerShell コードの実行という名前のインライン コード操作アクションをワークフローに追加します。

5. アクション情報ペインが開いたら、[パラメーター] タブの [コード ファイル] ボックスで、事前に設定されたサンプル コードを独自のコードで更新します。

   • ワークフローから出力されたデータにアクセスするには、後の「スクリプト内のワークフロー トリガーとアクションの出力にアクセスする」をご覧ください。

   • スクリプトの結果または他のデータをワークフローに返すには、「ワークフローにデータを返す」をご覧ください。

   次の例は、サンプル スクリプト コードを含むアクションの [パラメーター] タブを示しています。

   

   次の例は、サンプル スクリプト コードを示しています。

   # Use the following cmdlets to retrieve outputs from prior steps.
   # $triggerOutput = Get-TriggerOutput
   # $ActionOutput = Get-ActionOutput -ActionName <action-name>
   
   $customResponse =  [PSCustomObject]@{
      Message = "Hello world!"
   }
   
   # Use Write-Debug/Write-Host/Write-Output/ to log messages to Application Insights.
   # Write-Host/Write-Output/Write-Debug and 'return' won't return an output to the workflow.
   # Write-Host "Sending to Application Insight logs"
   
   # Use Push-WorkflowOutput to push outputs into subsequent actions.
   Push-WorkflowOutput -Output $customResponse
   

   次に示すのは、カスタム サンプル スクリプトの例です。

   $action = Get-TriggerOutput
   $results = "Hello from PowerShell!"
   Push-WorkflowOutput -Output $results
   

6. 完了したら、ワークフローを保存します。

ワークフローを実行した後、Application Insights (有効になっている場合) でワークフローの出力を確認できます。 詳しくは、Application Insights での出力の表示に関する記事をご覧ください。

スクリプト内のワークフロー トリガーとアクションの出力にアクセスする

トリガーと前のアクションからの出力値は、複数のパラメーターを持つカスタム オブジェクトを使って返されます。 これらの出力にアクセスし、必要な値を確実に返すには、 Get-TriggerOutput、 Get-ActionOutput、 および Push-WorkflowOutput コマンドレットに加えて、次の表に示す適切なパラメーターを使用します。次に例を示します。

$trigger = Get-TriggerOutput
$statusCode = $trigger.status.ToString();
$action = Get-ActionOutput -ActionName Compose
$actionOutput = $action.outputs['actionOutput'].ToString();
$populatedString = "Send the $statusCode for the trigger status and $actionOutputName."

Push-WorkflowOutput -Output $populatedString

トリガーとアクション応答の出力

次の表に、 Get-ActionOutput または Get-TriggerOutputを呼び出したときに生成される出力を示します。 戻り値は、次の出力を含む PowershellWorkflowOperationResult と呼ばれる複合オブジェクトです。

ワークフローに出力を返す

ワークフローに出力を返すには、 Push-WorkflowOutput コマンドレットを使用する必要があります。

カスタム PowerShell コマンド

PowerShell コードの実行アクションには、ワークフローやワークフロー内の他の操作とやり取りするためのカスタム PowerShell コマンド (コマンドレット)が含まれます。

Get-TriggerOutput

ワークフローのトリガーからの出力を取得します。

構文

Get-TriggerOutput

パラメーター

なし。

Get-ActionOutput

ワークフロー内の別のアクションからの出力を取得し、 PowershellWorkflowOperationResultという名前のオブジェクトを返します。

構文

Get-ActionOutput [ -ActionName <String> ]

パラメーター

Push-WorkflowOutput

PowerShell コードの実行アクションからの出力をワークフローにプッシュします。任意のオブジェクト型を戻すことができます。 戻り値が null の場合、コマンドレットから null オブジェクト エラーが発生します。

構文

Push-WorkflowOutput [-Output <Object>] [-Clobber]

パラメーター

PowerShell を使用してマネージド ID でアクセスの認証と認可を行う

マネージド ID を使うと、コードに資格情報を含めなくても、ロジック アプリのリソースとワークフローで、Microsoft Entra 認証をサポートする任意の Azure サービスとリソースへのアクセスの認証と認可を行うことができます。

PowerShell コードの実行アクション内から、マネージド ID を使ってアクセスの認証と認可を行うことができ、アクセスを有効にした他の Azure リソースに対してアクションを実行できます。 たとえば、仮想マシンを再起動したり、別のロジック アプリ ワークフローの実行の詳細を取得したりできます。

PowerShell コードの実行アクション内からマネージド ID を使うには、次の手順のようにする必要があります。

1. ロジック アプリでマネージド ID を設定し、ターゲットの Azure リソースにマネージド ID アクセス権を付与します。 詳細な手順については、「 マネージド ID を使用して Azure リソースへのアクセスと接続を認証する」を参照してください。

   ターゲットの Azure リソースで、次の考慮事項を確認します。

   • [ロール] タブでは、通常、[共同作成者] ロールで十分です。

   • [ロールの割り当ての追加] ページの [メンバー] タブの [アクセスの割り当て先] プロパティで、[マネージド ID] を選んでいることを確認します。

   • [メンバーの選択] を選んだ後、[マネージド ID の選択] ペインで、使うマネージド ID を選びます。

2. PowerShell コードの実行アクションの最初のステートメントとして、次のコードを追加します。

   Connect-AzAccount -Identity
   

3. これで、コマンドレットとモジュールを使って Azure リソースを操作できるようになりました。

スクリプト ファイルを表示する

1. Azure portal で、Standard ロジック アプリ リソースを開きます。

2. リソース サイドバーの [開発ツール] で、[ 高度なツール] を選択します。

3. [ 高度なツール ] ページで [ Go] を選択すると、 Kudu コンソールが開きます。

4. [デバッグ コンソール] メニューを開き、[CMD] を選択します。

5. ロジック アプリのルートの場所 (site/wwwroot) に移動します

6. ワークフローのフォルダーに移動します。このフォルダーには、.ps1 拡張子が 付いたファイルが含まれています。 site/wwwroot/{workflow-name}

7. ファイル名の横にある [編集] を選択して、ファイルを開いて表示します。

Application Insights のログの表示

1. Azure portal のロジック アプリサイドバーの [監視] で、(Insights ではなく) Application Insights を選択します。

2. Application Insights リソースへのリンクを選択します。

3. Application Insights リソースサイドバーの [監視] で、[ログ] を選択します。

4. ワークフローの実行からトレースまたはエラーを検索するクエリを作成します。次に例を示します。

   union traces, errors
   | project TIMESTAMP, message
   

モジュール

PowerShell モジュールは、次のようなさまざまなコンポーネントを含む自己完結型の再利用可能なユニットです。

• コマンドレット: 特定のタスクを実行する個々のコマンド。
• プロバイダー: レジストリやファイル システムなどのデータ ストアに、それらがドライブであるかのようにアクセスできるようにします。
• 関数: 特定のアクションを実行する再利用可能なコード ブロック。
• 変数: モジュール内で使用するデータを格納します。
• その他の種類のリソース。

モジュールは PowerShell コードを整理して、配布しやすくします。 たとえば、独自のモジュールを作成し、関連する機能をパッケージ化して、管理と共有をいっそう容易にすることができます。 PowerShell コードの実行アクションを使うと、パブリックとプライベート両方の PowerShell モジュールをインポートできます。

パブリック モジュール

一般公開されているモジュールを見つけるには、PowerShell ギャラリーにアクセスします。 Standard ロジック アプリ リソースでは、最大 10 個のパブリック モジュールをサポートできます。 パブリック モジュールを使うには、次の手順に従ってこの機能を有効にする必要があります。

1. Azure portal のロジック アプリサイドバーの [開発ツール] で、[高度なツール] を選択します。

2. [高度なツール] ページで、[移動] を選択します。

3. Kudu ツール バーの [デバッグ コンソール] メニューで [CMD] を選択します。

4. ディレクトリ構造またはコマンド ラインを使って、ロジック アプリのルート レベル C:\home\site\wwwroot を参照します。

5. ワークフローの host.json ファイルを開き、既定で既に設定されている ManagedDependency.enabled プロパティを true に設定します。

   "managedDependency": {
       "enabled": true
   }
   

6. requirements.psd1 という名前のファイルを開きます。 次の構文を使用して、必要なモジュールの名前とバージョンを含めます: MajorNumber.* または正確なモジュールのバージョンなどです。

   @{
       Az = '1.*'
       SqlServer = '21.1.18147'
   } 
   

パブリック モジュールに関する考慮事項

依存関係の管理を使う場合は、次の考慮事項が適用されます。

• モジュールをダウンロードするため、パブリック モジュールは PowerShell ギャラリーにアクセスする必要があります。

• 現在、マネージド依存関係では、ライセンスを対話的に受け入れるか、-AcceptLicense の実行時に オプションを指定して、ライセンスを受け入れる必要があるモジュールはサポートされていません。

プライベート モジュール

独自のプライベート PowerShell モジュールを生成できます。 初めて PowerShell モジュールを作成するときは、PowerShell スクリプト モジュールの記述に関する記事をご覧ください。

1. Azure portal のロジック アプリ リソース サイドバーの [開発ツール] で、[高度なツール] を選択します。

2. [高度なツール] ページで、[移動] を選択します。

3. Kudu ツール バーの [デバッグ コンソール] メニューで [CMD] を選択します。

4. ディレクトリ構造またはコマンド ラインを使って、ロジック アプリのルート レベル C:\home\site\wwwroot を参照します。

5. Modules という名前のフォルダーを作成します。

6. Modules フォルダーに、プライベート モジュールと同じ名前のサブフォルダーを作成します。

7. プライベート モジュール フォルダーに、 拡張子が .psm1 のプライベート PowerShell モジュール ファイルを追加します。 .psd1 拡張子を持つオプションの PowerShell マニフェスト ファイルを含めることもできます。

終えると、完成したロジック アプリ ファイルの構造は次の例のようになります。

MyLogicApp
-- execute_powershell_script.ps1
-- mytestworkflow.json
Modules
-- MyPrivateModule
--- MyPrivateModule.psd1
--- MyPrivateModule.psm1
-- MyPrivateModule2
--- MyPrivateModule2.psd1
--- MyPrivateModule2.psm1
requirements.psd1
host.json

コンパイル エラー

このリリースでは、Web ベースのエディターに制限付きの IntelliSense サポートが含まれており、引き続き改善中です。 ワークフローを保存するとコンパイル エラーが検出され、Azure Logic Apps ランタイムによってスクリプトがコンパイルされます。 これらのエラーは、Application Insights を介してロジック アプリのエラー ログに表示されます。

実行時エラー

ワークフロー アクションは出力を何も返しません。

Push-WorkflowOutput コマンドレットを使用していることを確認します。

PowerShell コードの実行アクションが失敗する: "用語 '{some-text}' は ... 認識されません"

requirements.psd1 ファイルでパブリック モジュールを誤って参照した場合、またはプライベート モジュールがパス C:\home\site\wwwroot\Modules{module-name} に存在しない場合は、次のエラーが発生します。

"'{some-text}' という用語は、コマンドレット、関数、スクリプト ファイル、または実行可能プログラムの名前として認識されません。 名前のスペルを確認するか、パスが含まれているかどうかを確認し、パスが正しいことを確認して、もう一度やり直してください。

PowerShell コードの実行アクションが失敗する: "null であるため、引数をパラメーター 'Output' にバインドできません。"

このエラーは、null オブジェクトをワークフローにプッシュしようとすると発生します。 Push-WorkflowOutputで送信するオブジェクトが null でないかどうかを確認します。

関連コンテンツ

• JavaScript コード スニペットを追加して実行する
• C# スクリプトを追加して実行する