テーブル リレーションシップのカスケード動作を設定する
一対多の関係にカスケード動作を設定することで、データの整合性を保ち、ビジネス プロセスを自動化することができます。 Web API および .NET 用 SDK の両方は、カスケード動作の構成をサポートしています。
Web API を使用してカスケード動作の構成
Web API の作業をするときは、OneToManyRelationshipMetadata エンティティ タイプを使用して一対多の関連付けを定義することができます。 この定義には、作成される交差テーブルの名前と、AssociatedMenuConfiguration 複合型、ラベル複合型 および LocalizedLabel 複合型を使用して関係がアプリケーションでどう表示されるかが含まれます。
詳細については、Web API を使用して一対多の関連付けを作成する を参照してください。
.NET 用 SDK を使用してカスケード動作を構成する
CreateOneToManyRequest または UpdateRelationshipRequest クラスを使用する場合、OneToManyRelationshipMetadata class クラスのインスタンスを要求の本体に含めます。 そのクラスの CascadeConfiguration プロパティでは、CascadeConfiguration クラスを使用します。
CascadeConfiguration クラスまたは CascadeConfiguration 複合型には、一対多の関係で参照されるテーブルに対して実行されるアクションを表すプロパティが含まれます。 各プロパティには、CascadeType 列挙型の値のいずれかを割り当てることができます。
| 価値 | アプリケーション ラベル | Description |
|---|---|---|
| アクティブです | アクティブにカスケード | 参照されているテーブルレコードに関連するすべてのアクティブな参照テーブル レコードに対してアクションを実行します。 |
| 伝播 | すべてのレコードに伝播 | 参照されているテーブル レコードに関連するすべての参照テーブル レコードに対してアクションを実行します。 |
| NoCascade | 伝播しない | 何もしません。 |
| リンクの解除 | 記事のリンク解除 | 参照されているテーブル レコードに関連するすべての参照テーブル レコードの参照列の値を削除します。 |
| 制限する | 制限する | 参照しているテーブルが存在する場合に、参照しているテーブルのレコードが削除されないようにします。 |
| UserOwned | 同一所有者のレコードのみに伝播 | 参照されているテーブル レコードと同じユーザーが所有するすべての参照テーブル レコードに対してアクションを実行します。 |
カスケード処理の対象となるアクティブなレコード
アクティブなレコードに対するアクションのカスケード処理には、状態コードが "アクティブ" のレコードのみが含まれます。 これらのテーブルの次の状態コードは、アクションのカスケード処理に対してアクティブと見なされます。 異なるテーブルのこの状態コードには、異なるラベル (アクティブ以外) が使用される場合があります。 次のテーブルでこれら以外の値を持つカスタム状態またはステータス コードは、カスケード目的でアクティブ レコードとして処理されません。
| テーブル名 | 状態コード 0 | 状態コード 1 | 状態コード 2 | 状態コード 3 |
|---|---|---|---|---|
| アカウント | x | |||
| BulkOperation | x | |||
| BulkOperation | x | |||
| CampaignResponse | x | |||
| 連絡先 | x | |||
| 電子メール | x | |||
| FAX | x | |||
| インシデント | x | |||
| IncidentResolution | x | |||
| 請求書 | x | |||
| リード | x | |||
| レター | x | |||
| 営業案件 | x | |||
| OpportunityClose | x | |||
| OrderClose | x | |||
| PhoneCall | x | |||
| 受注 | x | |||
| タスク | x | |||
| すべてのカスタム テーブルとカスタム アクティビティ | x | |||
| 見積もり | x | |||
| 契約 | x | |||
| 予定 | x | |||
| ServiceAppointment | x | |||
| RecurringAppointmentMaster | x |
.NET 用 SDK CascadeConfiguration クラスまたは Web API CascadeConfiguration 複合型には、一対多の関係で参照されるテーブルに対して実行されるアクションを表す次のプロパティが含まれます。
| 操作 | 内容 | 有効なオプション |
|---|---|---|
| 割り当てる | 参照されるテーブル レコードの所有者および/または部署が変更されます。 | アクティブです 伝播 NoCascade UserOwned |
| Delete キー | 参照されているテーブルのレコードが削除されます。 注: この操作のオプションは制限されます。 | 伝播 リンクの解除 制限する |
| 結合 | レコードが別のレコードと結合されます。 注意: マージ可能な参照テーブルについては、カスケードが唯一の有効な選択肢となります。 それ以外の場合は NoCascade を使用します。 | Cascade NoCascade |
| リペアレント | 後で リペアレント操作について を参照してください。 | アクティブです 伝播 NoCascade UserOwned |
| 共有 | 参照されているテーブルのレコードを他のユーザーと共有している場合。 | アクティブです 伝播 NoCascade UserOwned |
| 共有の解除 | 参照されたテーブル レコードの共有が解除された場合。 | アクティブです 伝播 NoCascade UserOwned |
注意
次の状況では、割り当て、削除、マージ、リペアレントのアクションは実行されません。
- 元の親レコードと要求されたアクションに同じ値が含まれている場合。 例：割当のトリガーを試行し、すでにレコードの所有者となっている担当者を選択します
- 縦続する処理が既に実行されている親レコードに対して操作の実行を試行する
注意
割り当てを実行すると、レコードで現在アクティブなワークフローまたはビジネ スルールは、再割り当てが行われた際に自動的に非アクティブになります。 レコードの新たな所有者がワークフローまたはビジネス ルールを引き続き使用する場合は、そのワークフローまたはビジネス ルールを再度有効化する必要があります。
割り当てアクションについて
割り当てアクションを使用すると、親レコードが更新されたときに、所有者、所属部署、または所有者と部署の両方の更新をすべての子レコードにカスケードできます。
部署全体のレコードの所有権の許可が有効化されていません
部署全体でレコードの所有権を許可する が有効になっていない場合、レコードの所有者を変更するときに、所属部署列を明示的に更新することはできません。 以下に、親のレコード所有者が更新されたときのカスケード動作を示します。
所有者を更新する場合:
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい所有者の部署に更新された
- 子レコードの所有者が新しい所有者で更新された
- 子レコードの部署が新しい所有者の部署に更新された
- カスケード割り当てがなしに設定
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい所有者の部署に更新された
- 子レコードの所有者は更新されません (カスケードなし)
- 子レコードの部署が更新されていない (カスケードなし)
部署全体のレコードの所有権の許可が有効化されている
部署全体でレコードの所有権を許可する が有効になっている場合、レコードの所有者を変更するときに、所属部署列を明示的に更新できます。 以下に、親のレコードや部署が更新されたときのカスケード動作を示します。
AlwaysMoveRecordToOwnerBusinessUnit は 環境データベースの設定 で設定でき、Microsoft Dynamics CRM の OrgDBOrgSettings ツール を使用して設定できます。
所有者を更新する場合:
AlwaysMoveRecordToOwnerBusinessUnit = true (規定)
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい所有者の部署に更新された
- 子レコードの所有者が新しい所有者で更新された
- 子レコードの部署が新しい所有者の部署に更新された
- カスケード割り当てがなしに設定
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい所有者の部署に更新された
- 子レコードの所有者は更新されません (カスケードなし)
- 子レコードの部署が更新されていない (カスケードなし)
- 既定のカスケード割り当て動作 (すべてカスケード)
部署を更新する場合:
AlwaysMoveRecordToOwnerBusinessUnit = true (規定)
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者は更新されません
- レコード部署が新しい部署に更新された
- 子レコードの所有者が更新されていない
- 子レコードの部署が新しい部署に更新された
- カスケード割り当てがなしに設定
- レコード所有者は更新されません
- レコード部署が新しい部署に更新された
- 子レコードの所有者が更新されていない
- 子レコードの部署が更新されていない
- 既定のカスケード割り当て動作 (すべてカスケード)
所有者と部署を更新する場合:
AlwaysMoveRecordToOwnerBusinessUnit = true (規定)
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい部署に更新された
- 子レコードの所有者が新しい所有者で更新された
- 子レコードの部署が新しい部署に更新された
- カスケード割り当てがなしに設定
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい部署に更新された
- 子レコードの所有者が更新されていない
- 子レコードの部署が更新されていない
- 既定のカスケード割り当て動作 (すべてカスケード)
OrgDBSettings AlwaysMoveRecordToOwnerBusinessUnit でカスケード動作を変更します
AlwaysMoveRecordToOwnerBusinessUnit を偽に設定できます。ユーザー所有のレコードの部署は、新しいユーザーの部署に移動されません。
AlwaysMoveRecordToOwnerBusinessUnit は 環境データベースの設定 で設定でき、Microsoft Dynamics CRM の OrgDBOrgSettings ツール を使用して設定できます。
所有者を更新する場合:
AlwaysMoveRecordToOwnerBusinessUnit = 偽
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者が新しい所有者で更新された
- レコードの部署が更新されていない
- 子レコードの所有者が新しい所有者で更新された
- 子レコードの部署が更新されていない
- カスケード割り当てがなしに設定
- レコード所有者が新しい所有者で更新された
- レコードの部署が更新されていない
- 子レコードの所有者が更新されていない
- 子レコードの部署が更新されていない
- 既定のカスケード割り当て動作 (すべてカスケード)
部署を更新する場合:
AlwaysMoveRecordToOwnerBusinessUnit = 偽
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者は更新されません
- レコード部署が新しい部署に更新された
- 子レコードの所有者が更新されていない
- 子レコードの部署が新しい部署に更新された
- カスケード割り当てがなしに設定
- レコード所有者は更新されません
- レコード部署が新しい部署に更新された
- 子レコードの所有者が更新されていない
- 子レコードの部署が更新されていない
- 既定のカスケード割り当て動作 (すべてカスケード)
所有者と部署を更新する場合:
AlwaysMoveRecordToOwnerBusinessUnit = 偽
- 既定のカスケード割り当て動作 (すべてカスケード)
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい部署に更新された
- 子レコードの所有者が新しい所有者で更新された
- 子レコードの部署が新しい部署に更新された
- カスケード割り当てがなしに設定
- レコード所有者が新しい所有者で更新された
- レコード部署が新しい部署に更新された
- 子レコードの所有者が更新されていない
- 子レコードの部署が更新されていない
- 既定のカスケード割り当て動作 (すべてカスケード)
注意
AlwaysMoveRecordToOwnerBusinessUnit = 偽 の場合
必要な特権
- 親レコードの所有者権限が検証されます。 所有者や部署を更新すると、更新を許可する前に、所有者が部署の権限を持っていることを確認します。
- ただし、子レコードに対するレコードの所有者権限は検証されません。 親レコードの部署を更新し、部署が子レコードにカスケードされている状況に遭遇する可能性があります。子レコードの所有者は自分のレコードにアクセスできなくなる可能性があります。
例 1
親レコードは部署 A の所有者1に属し、部署 B の所有者2に属する子レコードがあります。所有者 1 には部署 A および B からセキュリティ ロールが割り当てられているため、子レコードにアクセスできます。 親レコードが所有者 3 に更新されると、子レコードの所有者も所有者 3 に変更されますが、子レコードは引き続き部署 B に属します。所有者が部署 B でセキュリティ ロールを持っていない限り、所有者 3 はこれらの子レコードにアクセスできません。
例 2
親レコードは部署 A の所有者 1 に属し、部署 B の所有者 2 に属する子レコードがあります。所有者 1 には部署 A、B、および C からセキュリティ ロールが割り当てられているため、子レコードにアクセスできます。 所有部署が部署 C に変更されると、子レコードの部署は部署 C に変更されます。これらの子レコードの所有者 2 は、部署 C からセキュリティ ロールが割り当てられていない限り、レコードにアクセスできません。
リペアレント操作について
リペアレント アクションは、明示的なアクセス権ではなく継承されたアクセス権を扱うという点を除いて、共有アクションと類似しています。 リペアレント アクションは、親関係にある参照列の値を変更する場合です。 リペアレント アクションが発生すると、ReadAccess、WriteAccess、 DeleteAccess、AssignAccess、ShareAccess、AppendAccess および AppendToAccess に対する関連するテーブルの継承されたアクセス権の望ましい範囲が変更される可能性があります。 CreateAccess では変更されません。 リペアレント アクションに関連するカスケード アクションは、テーブル レコードとそれに関連するテーブル レコードに対して上記アクセス権の変更を参照します。
マージ操作について
マージ システム ジョブの実行中に操作セットの一部であるレコードが削除された場合、マージ アクションが完了する際に問題が発生することがあります。 多くの場合、これは、レコードが「異なる親子関係」を示すエラーになるか、子レコードが "親子関係を失う" ことを示すエラーになります。 これが発生し、レコードが見つからなくてもマージを続行する場合は、マージする列を選択する際に親のチェックを無効にすることができます。
注意
2 つのカスタム テーブル間でマージを実行すると、DateTime 値がマージされませんでした。 ターゲット レコードの DateTime は変更されません。
伝播通知
2 つのカスケード非同期通知ヘルパー メッセージを使用して、カスケード非同期ジョブが失敗や成功したときに、ユーザーやログに通知を提供します。 これはカスタム プラグインを作成し、登録することで実現します。このプラグインはメッセージを処理する際に実行され、成功または失敗の通知を提供します。
2 つの通知メッセージは次のとおりです。
| 件名 | Description |
|---|---|
cascadeAsync_FailureAPI |
非同期カスケード ジョブが複数の障害が原因で一時停止した場合、このメッセージが処理 (実行) されます。 既存のプラグインの問題、データの問題、ワークフローの問題についてデータセットを確認すべきことを、これを使用してユーザーに通知できます。 InputParameters: casadeAsyncExceptionDetails: カスケード非同期ジョブの失敗を引き起こした例外の詳細。casadeAsyncJobName:カスケード非同期ジョブの名前です。 |
cascadeAsync_SuccessAPI |
非同期カスケードジョブが正常に完了した場合、このメッセージが処理 (実行) されます。 InputParameters: casadeAsync_JobName: カスケード非同期ジョブの名前です。 |
カスタム プラグインは、操作後のステージで登録し、非同期モードに設定する必要があります。 プラグイン登録ツールを使用したプラグイン登録の例を、次の図に示します。
カスタム プラグインが提供できる通知の種類の例を次に示します。
- 成功時にエントリをランタイム ログに追加する
- 失敗時にはランタイム ログにエントリを追加してから、障害の日時と性質を示すメール (またはその他の通信) を管理者に送信します
- インタラクティブ ユーザーにメッセージを表示する
継承されたアクセス修理
リペアレントまたは共有アクションに対するテーブル関連付けのカスケード動作をカスケードなしに変更すると、システムは現在のテーブル関連付けのカスケード動作に合わせてユーザーの継承アクセス権を調整しようとします。 継承済みアクセス権のクリーンアップに関する詳細情報
ただし、このアプローチが成功しない場合、削除する必要がある関連レコードへのアクセスをユーザーが保持する可能性があります。 問題に対処する手順については、継承されたアクセスのクリーンアップを参照してください。
参照
注意
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示