編集

次の方法で共有

Power Automate の大規模なデプロイ

Azure Logic Apps
Microsoft 365
SharePoint
Power Automate
Microsoft Power Platform

このアーキテクチャは、SharePoint 2010 のワークフローを置き換える Power Automate のワークフローと、新しい SharePoint Online サイトのために使用します。 このソリューションでは次のことが可能です。

  • Power Automate のデプロイ、ガバナンス、運用戦略を慎重に計画する。
  • データ所在地の要件、データ損失防止 (DLP)、柔軟性のある最小限のライセンス要件などの組織のニーズを満たす。
  • Power Platform のスケーラブルなしきい値の範囲内に維持する。

アーキテクチャ

ハブアンドスポークを利用した Power Automate デプロイ トポロジを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

このアーキテクチャは、Azure ハブスポーク ネットワーク トポロジに基づいています。 Power Platform ソリューション のフローでは、ソリューションから子フローを呼び出すことができます。 親と子のフローにより、数百件ものステップを含むフローを回避することで、フロー管理が容易になります。

このソリューションにより、SharePoint サイトごとに 1 つの Power Automate "init フロー" ワークフローがプロビジョニングされます。 init フローでは、ユーザーまたはイベントによってワークフローが "開始されます"。 init フローでは、ビジネス ニーズを満たすすべてのアクションを実行する "中央フロー" ワークフローが呼び出されます。

SharePoint Online と Power Platform では、多くの地理的リージョンがサポートされます。 各リージョンには、SharePoint Online サイトのセットがあります。 この "複数地域" の概念は、中央フローにまで及びます。

  1. IT チームは、SharePoint Online サイトごとに init フローをプロビジョニングします。 トリガーに加え、フローには、Call Child Flow を使用して中央フロー ワークフローを呼び出す 1 つのアクションが含まれています。

  2. チームは、SharePoint Online リージョンに対応する各地理的リージョンの中央フローをプロビジョニングします。

  3. init フロー ワークフローが、ユーザーによって開始されるか、イベントによってトリガーされます。 トリガーの種類に応じて、init フローはユーザーのコンテキストまたはメーカー コンテキストで実行できます。

  4. init フローにより、適切なリージョンの中央フローが呼び出されます。 ユーザー コンテキストの場合、init フローはユーザーをアサートするためのユーザー情報を中央フローに確実に渡すことができます。

  5. 中央フローでは、フローを軽量に保つために、必要に応じて追加の子フローを呼び出すことができます。

コンポーネント

このシナリオでは、次のコンポーネントを使用します。

  • Power Automate では、フローを使用して、自動化されたプロセスを構築します。
  • SharePoint Online サイトは、組織がコンテンツ、知識、アプリケーションを共有および管理するのに役立ちます。
  • Power Platform では、データの分析、ソリューションの構築、プロセスの自動化、仮想エージェントの作成が実行されます。
  • Microsoft Entra ID は、ID を管理し、セキュリティで保護するためのユニバーサル プラットフォームです。

代替

  • 中央フローをロジック アプリに置き換えることによって、このアーキテクチャを Azure Logic Apps と一緒に使用できます。 "SharePoint の [選択したファイルの場合] " など、Logic Apps が持たないいくつかのトリガーが存在します。 その場合、Power Automate の init フローでトリガーを使用し、その後ロジック アプリを呼び出すことができます。

    Logic Apps では、使用した分の料金を支払う消費モデルがサポートされています。 また、Power Automate と Logic Apps の両方を使用するハイブリッド モデルも可能です。 しきい値について心配したくない場合は、Logic Apps ソリューションが推奨されます。

  • SharePoint Online サイトごとに 1 つのフローを作成する代わりに、リージョンごとに 1 つの init フローを使用することで、ハブアンドスポーク モデルを改善できます。 この戦略は、フローを手動でトリガーする場合にのみ可能です。 テナント内の任意の SharePoint Online サイトから呼び出すようにフローを調整できます。

シナリオの詳細

Microsoft Power Automate は、ノーコードまたはローコードの Microsoft Power Platform の一部です。 Microsoft 365 を利用するお客様は、ワークフローの自動化とビジネス プロセス フローに Power Automate を使用します。

考えられるユース ケース

お客様によって設計された Power Automate ワークフローは、次の 2 つのカテゴリに分類されます。

  • SharePoint サイト所有者は通常、アドホック ワークフローを作成します。 サイト所有者は、ワークフローの設計、デプロイ、およびメンテナンスに対するすべての責任を負います。

  • IT チームは、ワークフローの有効期間を通して完全に所有、管理、サポートするワークフローを作成します。

このアーキテクチャは、IT チームがワークフローとコンポーネントのライフ サイクルを完全に制御するワークフローに適用されます。

考慮事項

このハブアンドスポーク モデルを Power Automate デプロイ環境で採用することには、いくつかの利点があります。

  • ロジックが一元化されているため 1 つの場所で簡単に更新でき、すべてのフローによって最新の更新が自動的に取得されます。

  • SharePoint Online サイトのすべての init フローに Premium ライセンスを割り当てずにすみます。 代わりに、限られた数の中央フローに Premium ライセンスを割り当てることができます。

  • SharePoint Online サイトとフローをそれらの独自のリージョンに分離することで、データ所在地の要件が満たされます。

  • init フローのトリガーに基づき、フローでは開始から中央フローの終了までユーザーのコンテキストを保持することができます。

  • 季節的または定期的な要件を満たすために、このモデルでは柔軟性の高い中央フローでのライセンスのアップグレードとダウングレードが提供されます。

DevOps

  • Power Platform では、ソリューション内のコンポーネントの継続的インテグレーションと継続的デリバリー (CI/CD) がサポートされています。 ソリューションは、パッケージとして Power Platform の複数の環境間およびテナント間でエクスポートおよびインポートできます。

  • 更新プログラムとコンポーネントを実稼働テナントにプッシュする前に更新プログラムを検証する実稼働前テナントを用意することをお勧めします。 中央フローを更新すると、多くの init フローにすぐに影響を与えるため、品質の高い分析と検証を行う必要があります。 実稼働テナントに昇格させる場合は、接続用の環境変数を使用してください。そうすることで、ターゲット テナントに対応するエンドポイントを選択できます。

  • Power Platform では、Azure Pipelines または GitHub Actions.を使用したコンポーネントとワークフローの ALM がサポートされています。

操作

Power Platform 用のセンター オブ エクセレンス (CoE) ツールキットを使用して、フローを一元的に管理し、障害がないか監視します。 CoE ツールキットでは、Power Platform のコンポーネントと、コンポーネント間の依存関係も表示されます。 エラーをキャッチしてログに記録したり、適切なサポートのために誰かに通知したりするように各フローを設計することができます。

セキュリティ

  • ソリューションで作成するフローのエンタイトルメント管理は、ソリューションの外部のフローとは異なります。 ソリューションの外部のフローでは、フローを開始するアクセス許可をSharePoint サイトのリストまたはライブラリに付与できます。 ソリューション内のフローでは、Microsoft Entra グループにマップできる "グループ チーム" と呼ばれる Dataverse 環境ベースのグループにアクセス許可が結び付けられます。 そうすると、Microsoft Entra グループのユーザーを管理できるようになります。

  • 環境管理者を除くすべてのユーザーには、実稼働環境で読み取り/実行専用のアクセス許可を付与する必要があります。そのため、エンド ユーザーはコンポーネントを作成できません。

  • DLP ポリシーは環境レベルで適用できます。これにより、ビジネス要件を満たす柔軟性が向上します。

コスト最適化

次の条件を満たす場合、このシナリオに対して追加料金は発生しません。

  • Power Platform Premium コネクタへの依存性がない。

  • フローが、E3 や E5 などの Microsoft 365 のシード ライセンスのアクション実行しきい値に準拠できる。

それ以外の場合は、中央フローに対してのみ、ユーザーまたはフロー プランごとに Premium ライセンスを購入する必要があります。 価格は、地理的リージョンごとに必要な中央フローの数によって異なる場合があります。 数が多い init フローに Premium ライセンスを割り当てる必要はありません。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順