0

アクセス制御を使用している場合、レコードの再計算時に [自動レコード許可] フィールド (ルールを含む) が更新されないという問題に直面したことがあるはずです。完全な再計算を開始するか、変更が行われるまでかなりの時間を待つ必要があります。

レコード内の 10 の異なるフィールド値に基づいて、それぞれ 10 の異なるグループに読み取り/編集アクセス権を付与する必要があるというこの問題に直面しています。

例えば：

  • ルール 1 が true の場合、最初のユーザー グループに編集アクセス権を付与する
  • ルール 1 と 2 が真の場合、1 番目と 2 番目のユーザー グループに編集アクセス権を付与します。

Auto RP フィールドで「No Minimum」と「No Maximum」を選択しました。

自動レコード許可フィールドをできるだけ早く更新するにはどうすればよいですか? ここで重要な何かが欠けていますか？

4

1 に答える 1

3

アクセス制御を使用している場合、レコードの再計算時に [自動レコード許可] フィールド (ルールを含む) が更新されないという問題に直面したことがあるはずです。完全な再計算を開始するか、変更が行われるまでかなりの時間を待つ必要があります。

Tanveer、一般的に、これは正しいステートメントではありません。[a] 適切に設計されたアーキテクチャ (アプリケーション間の関係) と [b] アプリケーション内の正しい計算順序では、この問題に直面するべきではありません。

あなたが説明したケースについて。次の可能性を確認して確認することをお勧めします。

1.計算順序。
自動レコード許可 [ここからの ARP] は、計算フィールドと同じ方法で Archer プラットフォームによって処理されます。これは、レコードを保存するときに計算フィールドと自動レコード権限が更新される計算順序を変更できることを意味します。
そのため、ARP のルールで使用する特定の計算フィールドよりも前に、ARP フィールドが計算される可能性があります。たとえば、ARP フィールドに 2 つのルールがあるとします: If
   A>0 then group AAA
   if B>0 then groub BBB
ここで、計算順序が次の場合に問題が発生します:
   "ARP", "A", " B"
[保存] または [適用] をクリックしても ARP は更新されませんが、[保存] または "
計算順序が「A」、「B」、「ARP」の場合、ARP はすぐに再計算されます。

2. 完全な再計算キュー。
ARP は計算フィールドとして扱われるため、ARP を更新する必要があるたびに、バックエンドのアプリケーション サーバーで再計算ジョブが作成されます。また、何らかの理由で計算キューがいっぱいになった場合、レコードのアクセス許可はすぐには更新されません。データ フィードを実行している場合、または手動データ インポートによって大量の再計算がトリガーされた場合、ジョブ エンジンの再計算キューがいっぱいになることがあります。ARP更新に関連する再計算ジョブが作成され、キューに追加されます。再計算ジョブは、ジョブ キューに定義された優先度に基づいて処理されます。Archer コントロール パネル インターフェイスを介して、Archer v5.5 でジョブ キューを監視し、デフォルト ジョブの処理優先度を変更できます。次に ARP 再計算の遅延が発生した場合は、ジョブ キューの状態を確認することをお勧めします。

3. 再計算の「なだれ」
再計算の影響が最小限になるように、アプリケーション間の関係とセキュリティの継承を設計することが重要です。
たとえば、Contacts アプリケーションと Department アプリケーションがあるとします。
- 連絡先アプリケーションのレコードは、部門レコードから継承されたレコード権限を使用してアクセスを継承します。
-部門レコードには自動レコード権限があり、連絡先レコードはそれを継承します。
-ここで最高の部分 - 部門 D1 には 60,000 の連絡先レコードがリンクされており、部門 D2 には 30,000 の連絡先レコードがリンクされています。
説明した問題は、説明した構成で再現可能です。部門レコード D1 に移動し、部門レコードの ARP が強制的に再計算されるように更新します。これにより、ジョブ エンジン キューに 60,000 件のジョブが追加され、D1 レコードにリンクされた 60,000 件の連絡先が再計算されます。ここで待機せずに D2 に移動し、この D2 レコードで ARP を再計算するよう強制的に変更します。レコード D2 を保存した後、D2 を再計算する新しいジョブと他の 30 000 件の連絡先レコードがジョブ エンジン キューに作成されます。ただし、60k レコードの最初のセットがまだ再計算されておらず、D2 レコードの再計算がまだキューにあるため、レコード D2 はすぐには再計算されません。
残念ながら、現時点では適切な解決策はありません。ただし、これはあなたができることです：
- 継承を確認して最小限に抑える
- 1 つのレコードが 1000 以上のレコードを参照するレコード間の関係を確認して最小限に抑えます。
- アーキテクチャを変更し、継承と関係を壊し、可能であれば Archer から Archer へのデータ フィードに置き換えます。
- アプリケーション サーバーに「再計算」機能を追加します。特定の時点まで使用されていない場合は、再計算ジョブを処理するように Web サーバーを構成することもできます。ジョブ スロットを追加します。

Tanveer、これがお役に立てば幸いです。幸運を！

于 2016-03-10T05:06:26.903 に答える