設計オプションの特定と評価

可能なソリューションとしての設計オプションは、次に説明するとおり、少なくとも2つあります。

オプション1：RESTコネクターソースのデータページ

• オートコンプリートコントロールは、ノードレベルのデータページからデータを取得しますが、そのデータページはRESTコネクターからデータを取得します。
• ノードレベルのデータページは1週間に1回更新されます。

オプション2：ローカルデータソースを使ったデータページ

• Job SchedulerがRESTコネクターの呼び出しを実行し、取得したデータをローカルテーブルで永続化します。
• オートコンプリートコントロールは、ノードレベルのデータページからデータを取得しますが、そのデータページはローカルで永続化されたデータをクエリするレポートディフィニッションからデータを取得します。
• ノードレベルのデータページは、そのデータクエリがローカルに実行されるため、頻繁に更新できます（1日1回など）。
• Job Schedulerは、1つのノードで週に1回実行されるように構成されています。

オプション1では目的を達成でき、導入も簡単です。 オプション2でも目的を達成できますが、オプション1に比べて実装が複雑になります。

オプション1では、各WebTierノードが非常に低速なRESTコネクターを呼び出して自己更新する必要があります。その結果、最初の読み込み時にユーザーエクスペリエンスが低下する可能性があります。 一方オプション2では、非常に低速なRESTコネクターは一度だけ呼び出され、バックグラウンドのプロセスノードで実行されます。 オプション2では、ユーザーのブラウザーが通信するWebTierノードに、読み込みを高速に行うローカルライブデータをクエリしたノードレベルのDPがあるため、WebTierユーザーがこの初期の速度低下を感じることはありません。

この2つの設計オプションは、導入と維持にかかる時間と、ユーザーエクスペリエンスの向上のトレードオフの関係にあります。 どちらの要素がより重要かによって、推奨されるオプションは異なります。 オプション1は、ある程度目的を達成でき、シンプルであることがこのオプションを選ぶ理由になるかもしれません。 オプション2では、初期のユーザーエクスペリエンスの向上が保証されるため、これがこのオプションを選ぶ理由になるかもしれません。

オプション3：

オプション3は、オプション1と似ていますが、Load Data Pageメソッドを利用して、データページの読み込みをプロセスの早い段階で非同期的にリクエストし、データが必要になる前に読み込みを完了するための十分な時間を確保できます。 最悪の場合、これはログイン時に行われます。 先行読み込みは、スマートシェープや類似の方法で行えます。

このオプションでは、次のような結果が得られます。

• 一種のバックグラウンドプロセス（バックグラウンドリクエスターを使用）
• 最適なメモリ管理（ノードにスコープされるデータページの数はオプション1と同じ）
• Pegaでリモートデータを永続化する必要がない
• ノードごとにリモートデータストアへの移動が1回行われる（オプション2はクラスターごとに1回）

オプション4： 

オプション2の変形ですが、すべてのノードでJob Schedulerを実行して、各ノードについて毎週同じ時刻にノードにスコープされたデータページの読み込みが自動的に開始されるようにします（まだ新しいと見なされるデータページをフラッシュした後など（アクティビティと同時に実行可能））。

このオプションでは、次のような結果が得られます。

• オプション1と同じ数のリモートトリップが必要
• ローカルコピーを永続化する必要がなくなる
• オプション2と同じユーザーエクスペリエンスを提供する（ユーザーがデータを必要とする前にデータページが読み込まれることを前提とする）

オプション3と4については、最初の読み込みの問題が解決された場合は2つのオプションの間でユーザーエクスペリエンスにほとんど差がなく、ソリューションの望ましい設計では実装と維持にかかる時間のどちらか一方を優先させることになります。 その他の要因としては、ルールの再利用の可能性やアプリケーションの将来的な進化などが評価の対象となります。