コードでカスタムプロセスアクションを使用する
カスタム プロセス アクション (略名 カスタムアクション) は、Microsoft Dataverse のカスタムメッセージを作成する 2 つの方法の 1 つです。 もう 1 つはカスタム API です。 詳細: カスタム API の作成と使用
これらの機能では、どちらも Web サービスから呼び出すことができる新しいメッセージを作成することができます。 カスタム プロセス アクションは、同期ビジネス ロジックを宣言的に定義するためのコードなしの方法を引き続き提供します。 カスタム プロセス アクションは常に同期の「リアルタイム」ワークフローであるため、Power Automate を使用するために変換するのには適していません。
カスタム プロセス アクションとカスタム API の機能の比較については、カスタム プロセス アクションとカスタム API を比較するを参照してください。
カスタム プロセス アクションのビジネス ロジックには、ワークフローを使用して実行されます。 カスタム プロセス アクションを作成するときは、関連するリアルタイム ワークフローが自動的に登録され、メッセージ実行パイプラインの主要操作ステージで実行されます。
開発者にとって、新しいメッセージの作成は、Web API または .NET 用 SDK のいずれかを使用してコードでメッセージを使用できることを意味します。
- Web API では、カスタム プロセス アクションで作成された新しいメッセージは常に OData アクションです。 Web API を使用したアクションの呼び出しについては、WebAPIアクションを使用するを参照してください。
- カスタム プロセス アクションは、Xrm.WebApi.online.execute メソッド を使うことにより、モデル駆動型アプリのクライアント側 JavaScript で使用できます。
- .NET SDK では、OrganizationRequest クラスを使用するか、 Power Platform CLI pac modelbuilder ビルドコマンド によって生成された早期バインドの要求および応答クラスを使用して、メッセージを一般的に事前バインド スタイルで呼び出すことができます。
ワークフロー デザイナーを使用してカスタム プロセス アクションを作成する方法については、以下を参照してください: カスタム プロセス アクションを作成する
カスタム プロセス アクションを拡張する
コードを使用してカスタム プロセス アクションを拡張するには、カスタム ワークフロー アクティビティを使用する方法と、ステージにプラグインを登録する方法の 2 通りがあります。
ユーザー定義のワークフロー活動
カスタム プロセス アクションはワークフローであるため、ワークフローの一部として、再利用可能なカスタム ワークフロー アクティビティをワークフロー定義に含めることができます。 詳細: ワークフロー拡張
実行パイプラインのステージのプラグイン ステップを登録する
カスタム プロセス アクションはメッセージを作成するため、PreValidation、PreOperation そして PostOperation ステージでプラグインの手順を登録して、カスタム プロセス アクションの動作を変更することができます。 開発者はこれを使用してメッセージのすべてのロジックを定義しており、ワークフロー ロジックをまったく定義していないことがよくあります。 カスタム API 機能は、このコードファースト パターンを簡素化し、カスタム ワークフロー アクティビティでは不可能な他の機能を提供します。
ヒント
プラグインを使用してロジックを実装するためだけにカスタム プロセス アクションを使用している場合は、代わりにカスタム API を使用するように移行することを検討してください。 詳細: カスタム API の作成と使用
カスタム プロセス アクションのメッセージは、それがアクティブ化されていると定義するワークフローでのみ使用できます。 アクティブでないカスタム プロセス アクションのプラグイン ステップを登録することはできません。
カスタム プロセス アクションにプラグイン ステップを登録すると、ソリューションに依存関係が確立され、カスタム プロセス アクションの削除が防止されます。
必要なアクセス許可
アクションのリアルタイム ワークフローをアクティブ化して、実行するには、リアルタイム プロセスのアクティブ化 (prvActivateSynchronousWorkflow) というセキュリティ特権が必要です。 この特権は、ワークフローの作成に必要な特権への追加です。
長時間の操作を監視する
操作のリアルタイム ワークフローの手順の 1 つがユーザー定義ワークフロー活動の場合、そのユーザー定義ワークフロー活動が隔離されたサンドボックス ランタイム環境で実行され、プラグインを管理する場合と同じように、2 分間のタイムアウト制限が課されます。 ただし、操作自体にかかる全体的な時間に特定の制限はありません。 この制限がないことは利点ではありません。 このワークフローを無期限に実行することはできません。 最終的にはさまざまな理由で失敗します。 たとえば、ロールバックが有効で、操作がトランザクションに参加している場合、SQL Server のタイムアウトが適用されます。 カスタム プロセス アクションが、妥当な期間内に明確な成功または失敗を伴って完了できるように注意してください。 2 分より長い場合は、おそらく長すぎます。
既存の Depth プラットフォームのチェックによって、無限ループが発生しないことを確認します。 深さの制限の詳細については、MaxDepth を参照してください。
ヒント
ベスト プラクティスとして、長時間かかる操作は、Power Automate、Logic Apps、Azure が提供するその他の機能を使用して、Dataverse 外で実行することをお勧めします。
関連項目
カスタム プロセス アクションを作成する
アクションの使用
クラシック Dataverse ワークフロー
注意
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。