ライフサイクル ワークフローのカスタム タスク拡張機能

ライフサイクル ワークフローを使うと、就職者、異動者、または退職者のシナリオに基づいてトリガーできるワークフローを作成できます。 ライフサイクル ワークフローには、ユーザーのライフサイクル全体の一般的なシナリオを自動化する組み込みタスクがいくつか用意されていますが、最終的にはこれらの組み込みタスクの制限に達する可能性があります。 拡張性機能を使用すると、カスタム タスク拡張機能の概念を利用して、ワークフローの一環として外部システムを呼び出すことができます。 たとえば、ユーザーが組織に参加するときに、Teams 番号を割り当てるカスタム タスク拡張機能を含むワークフローを作成したり、ユーザーが離脱したときに、メール アカウントへのアクセスをマネージャーに許可する別のワークフローを作成したりすることができます。 拡張性機能を使用することで、現在ライフサイクル ワークフローでは、Azure Logic Apps を呼び出すカスタム タスク拡張機能を作成できます。

Logic Apps の前提条件

Azure Logic Apps とカスタム タスク拡張機能をリンクするには、次の前提条件を満たしている必要があります。

  • Azure サブスクリプション
  • リソース グループ
  • 新しい従量課金ベースの Logic Apps を作成したり、既存の従量課金ベースの Logic Apps にアクセスしたりするためのアクセス許可

Logic Apps 自体または上位のスコープ (リソース グループ、サブスクリプション、管理グループなど) で、次のいずれかの Azure ロールを割り当てる必要があります。

  • ロジック アプリの共同作成者
  • Contributor
  • 所有者

注意

ロジック アプリのオペレーター ロールでは十分ではありません。

カスタム タスク拡張機能のデプロイ シナリオ

カスタム タスク拡張機能を作成する場合、ライフサイクル ワークフローとの対話方法に関するシナリオとして、次の 2 つの方法のいずれかが考えられます。

Screenshot of custom task deployment scenarios.

  • 起動して完了 - Azure Logic App が開始されると、Azure Logic App からの応答を想定せずに、直ちに次のタスクの実行が続けられます。 このシナリオは、ライフサイクル ワークフローに Azure Logic App からのフィードバック (状態を含む) が必要ない場合に最適です。 ロジック アプリが正常に開始されると、ライフサイクル ワークフローのタスクは成功と見なされます。
  • 起動して待機 - Azure Logic App が開始されると、次のタスクの実行は Logic App からの応答を待機します。 カスタム タスク拡張機能が Azure Logic App からの応答を待機する期間はご自分で入力します。 定義された期間内に応答が受信されなかった場合、タスクは失敗と見なされます。 Screenshot of custom task launch and wait task choice.

Note

応答は必ずしも Logic Apps によって提供される必要はありません。Logic Apps が仲介者としてのみ機能する場合は、サード パーティ システムで応答できます。 これに関する詳細については、「taskProcessingResult: resume」を参照してください。

応答承認

Logic Apps からの応答を待機するカスタム タスク拡張機能を作成するときに、応答を送信できるアプリケーションを定義できます。

Screenshot of custom task extension launch and wait options.

応答は次のいずれかの方法で認可できます。

  • システム割り当てマネージド ID (既定) - この方法では、Logic Apps のシステム割り当てマネージド ID を有効にして利用します。 詳細については、「Azure Logic Apps でマネージド ID を使用して Azure リソースへのアクセスを認証する」を参照してください
  • 認可なし - この方法では、認可は付与されません。アプリケーションのアクセス許可 (LifecycleWorkflows.ReadWrite.All) またはロールの割り当て (ライフサイクル ワークフロー管理者) を個別に割り当てる必要があります。 アプリケーションが応答している場合、最小限の特権の原則に従っていないため、このオプションはお勧めしません。 このオプションは、応答がユーザーの代わりにのみ提供される場合にも使用できます (LifecycleWorkflows.ReadWrite.All の委任されたアクセス許可とライフサイクル ワークフロー管理者ロールの割り当て)
  • 既存のアプリケーション - この方法では、応答する既存のアプリケーションを選択できます。 これは、通常のアプリケーションでも、システムまたはユーザー割り当てマネージド ID でもかまいません。 マネージド ID の種類の詳細については、「マネージド ID の種類」を参照してください。

Azure Logic Apps の大まかな手順を使用したカスタム タスク拡張機能の統合

Azure Logic Apps の統合の大まかな手順は次のとおりです。

Note

Microsoft Entra 管理センターを使用してカスタム タスク拡張機能とロジック アプリを作成する場合、これらの手順のほとんどが自動化されます。 この方法によるカスタム タスク拡張機能の作成については、「カスタム タスク拡張機能に基づいて Logic Apps をトリガーする」を参照してください。

  • 従量課金ベースの Azure Logic App を作成する: カスタム タスク拡張機能から呼び出すために使用される、従量課金ベースの Azure Logic App。
  • ライフサイクル ワークフローと互換性を持つように Azure Logic App を構成する: カスタム タスク拡張機能で使用できるように、従量課金ベースの Azure Logic App を構成します。 詳しくは、「ライフサイクル ワークフローで使用するためにロジック アプリを構成する」を参照してください。
  • Azure Logic App 内でカスタム ビジネス ロジックを構築する: ロジック アプリ デザイナーを使用して Azure Logic App 内でビジネス ロジックを設定します。
  • Azure Logic App に関する必要な情報を保持するライフサイクル ワークフロー customTaskExtension を作成する: 構成された Azure Logic App を参照するカスタム タスク拡張機能を作成します。
  • [Run a custom task extension] (カスタム タスク拡張機能を実行する) タスクを使用してライフサイクル ワークフローを更新または作成し、作成した customTaskExtension を参照する: 新しく作成したカスタム タスク拡張機能を新しいワークフローに追加するか、既存のワークフローに対して情報を更新します。

次のステップ