データの操作

  • 5 分

プラグインを使用すると、データを変更または拡張するロジックを一元化できます。 インスタント プラグインは、オンデマンドでアクションを完了できるため便利です。 たとえば、コネクタを使用して予約サービスから次に利用可能なサービス スロットを検索できる ScheduleService インスタント プラグインを作成できます。 次に、コネクタは予約を追跡するために要求者に関連するデータ行を作成できます。

自動プラグインは、プライマリ データ行を Dataverse に追加した後でデータを変更したり、関連データ行を追加したりする場合に適しています。 自動プラグインの大きなメリットは、プラグインが行うデータ変更が元のトランザクションの一部であり、システムがすべての変更を完了またはロールバックすることです。 たとえば、プロジェクト データ行を作成し、行の作成時に実行されたプラグインによってプロジェクトに関連するいくつかの初期タスクが作成されるシナリオを考えてみましょう。 これらのタスクの 1 つが無効で作成に失敗した場合、システムはプロジェクトと、作成したタスクをロールバックします。

保存する前にデータを変更する

保存する前にデータを変更するオプションは、作成または更新されたイベントで実行される自動プラグインにのみ適用されます。 どちらの場合も、事前操作中に実行するようにプラグインを設定できます。これにより、データを保存する前に、作成または更新している行のデータを変更する機会が得られます。 このオプションは、いくつかの既定値を設定するシナリオで役立ちます。 さらに、条件付き Power Fx ロジックを使用して、変更している行の他のデータに応じて既定値を設定することもできます。

事前操作でプラグインを実行し、Set 関数を使用してデータ列を変更する必要があります。 この方法では、変更が個別の更新として実行されるのではなく、データ行の保存時に確実に含まれるようになります。これにより、個別の更新が原因で無限ループが発生したり、不要な自動化が実行される可能性があります。

次の例は、Set 関数を使用して、作成中のプロジェクト行の予算列を変更する方法を示しています。

Set(contoso_budget,1000)

この方法は、プラグインをトリガーする行のデータを変更する場合にのみ使用できます。 関連データを添付できるプライマリ行がないため、事前操作の段階では関連データを作成できません。

もう 1 つの一般的なシナリオは、プライマリ データ行に関連するデータを作成する場合です。 このタスクは、インスタント プラグインと自動プラグインを使用して実行できます。これを行うには、Collect 関数を使用してデータを追加します。 たとえば、次の関数は、プロジェクトの作成者を最初のチーム メンバーとして自動的に追加します。

Collect([@'Team Members'],{Name: "David So",'Team Project': ThisRecord })

前述の例では、ThisRecord は、プロジェクト テーブルのエンティティのスコープで設定されたインスタント プラグインに渡されるプロジェクト行、またはプロジェクト テーブルの作成時に自動プラグインに渡されるプロジェクト行です。

一部のシナリオでは、Patch 関数の代わりに Collect 関数を使用する必要があります。 たとえば、Tasks テーブルの Regarding 列を操作するときに Patch 関数を使用すると、システムが Regarding 列を適切に設定できるようになります。 これは、[Regarding] 列がポリモーフィックであり、多くの異なるテーブル行タイプを指すことができるためです。 次の例は、プロジェクトの作成時に実行して、すべてのプロジェクトが持つ一部の初期タスクを追加するように構築されたプラグインを示しています。

Patch([@Tasks], Collect([@Tasks], { Subject : "Review Project"} ),{ Regarding: ThisRecord });
Patch([@Tasks], Collect([@Tasks], { Subject : "Schedule Project Launch"} ),{ Regarding: ThisRecord });
Patch([@Tasks], Collect([@Tasks], { Subject : "Assign Project Lead"} ),{ Regarding: ThisRecord });

前の例では、Patch 関数を Collect 関数と組み合わせて、Regarding 列を更新しています。

もう 1 つの一般的なシナリオは、関連データを条件付きで削除することです。 たとえば、「Cancel Project」という名前のインスタント プラグインを作成できます。 このプラグインには、キャンセルするプロジェクトの EntityReference タイプの入力パラメーターがあります。 次に、プラグインはプロジェクト行を更新してプロジェクトがキャンセルされたことを示していて、開いている作業項目を検索して削除し、キャンセルされたプロジェクトで誰も作業できないようにします。 次のロジックは、プロジェクトに関連するすべての作業項目を検索するための式を示し、ForAll の使用によりループを実行して、作業項目ごとに Remove を呼び出す方法を示しています。

ForAll(Filter([@'Work Items'], 'Team Project'.'Team Project' = Project.'Team Project'),  Remove([@'Work Items'], ThisRecord))