その他のバックグラウンド処理オプション

メール、ファイル、またはインバウンドネットワークのリクエストやメッセージには、リスナーを使用します。 高可用性環境では、ノードタイプを使用して冗長性を確保することにより、リスナーはホストとPega Platformサーバーに分散されます。

ファイルリスナー

別のシステムからのファイル、またはアプリケーションユーザーによって作成されたファイルをインポートして処理するには、ファイルサービスでファイルリスナーを使用します。 たとえば、作業オブジェクトの作成に使用されるデータをインポートできます。

ファイルリスナーはファイルディレクトリーを監視します。 ファイルリスナーの待ち受け対象となっているパターンとファイルが一致すると、リスナーはそれらのファイルをwork_<name of listener>ディレクトリーに移動して、ファイルサービスを呼び出します。 ファイルサービスが解析ルールを使用してファイルを開いて読み取り、各入力レコードを評価して、レコードをフィールドに分割してから、フィールドをクリップボードに書き込むと、サービスアクティビティがデータを処理します。

メールリスナー

メールリスナーは、受信したメールメッセージをメールサービスルール（Rule-Service-Emailルールタイプ）にルーティングするために必要な情報をPega Platformに提供します。 これらの情報は、リスナー、メールアカウント名、監視するメールフォルダーの名前、受信メッセージのメッセージ形式、メッセージのルーティング先のメールサービスルールなどを識別します。

メールリスナーは、ファイルが添付されたメッセージをルーティングするときに、（クラスData-ServiceMessageの）pyAttachmentPageという名前のページを作成し、プロパティpyAttachNamesおよびpyAttachValuesを使用してそのページにファイルを配置します。 Emailウィザードを使用して受信メールを設定すると、生成されたサービスアクティビティは、pyAttachmentPageからファイルを抽出し、それらをワークアイテムの添付ファイルとしてワークアイテムに添付するように設定されます。

JMSリスナーは、Javaメッセージサービス（JMS）メッセージを特定のトピックまたはキューからPega Platform JMSサービス（Rule-Service-JMSルールタイプ）にルーティングするために必要な情報をPega Platformに提供します。 JMSリスナーまたはJMS MDBリスナーのデータインスタンスは、消費されるメッセージが含まれているキューまたはトピックと、メッセージを処理するJMSサービスルールを指定します。

ワークの完了期限はサービスレベルアグリーメントで定められます。 多くの場合、組織はSLAを設定して、期限内の業務実施を徹底します。 これらの義務は、非公式な応答時間の約束から交渉済み契約まで多岐にわたります。

SLAで定義されている時間間隔は、アプリケーションでのワークの解決方法を標準化するために使用されます。 サービスレベルアグリーメントは、ケース、ステージ、ステップ、フロー、およびアサインメントに適用できます。

状況によっては、SLAをエージェントの代わりとして使用できます。 SLAのエスカレーションアクティビティは、新しいエージェントを作成せずにエージェント機能を呼び出すための手段を提供します。 たとえば、将来の特定の時間に条件付きでサブケースを追加するソリューションを提供する必要がある場合は、SLAのエスカレーションアクティビティをアサインメントと組み合わせる並列ステップをメインケースに追加すると、このアクションを実行できます。

SLAは常にケースを考慮に入れて開始する必要があります。 SLAのトリガーが遅れると、エスカレーションアクティビティが適時に実行されなくなります。 ポーリング目的や定期的な更新の際には、SLAを使用しないでください。

SLAの「Assignment Ready」設定を使用すると、アサインメントをSLAエージェントが処理できるようになるタイミングを制御できます。 たとえば、今日アサインメントを作成しておいて、明日それを処理するように設定することが可能です。 ワークリストまたはワークバスケットを介してアサインメントに直接アクセスできる場合、オペレーターはそのアサインメントに引き続きアクセスできます。

Waitシェープは、新しいエージェントを作成したり、SLAを使用したりする代わりに、実行可能なソリューションを提供します。 Waitシェープの適用対象となるのは、フローステップ内にあるケースのうち、フローステップによって進行を許可される前に単一のイベント（時間指定またはケースステータス）を待機する必要のあるケースのみです。 ケースに対して適用されるシングルイベントトリガーは、Waitシェープに最も適したユースケースを表します。 指定された時間またはステータスでの目的のケース機能は、Waitシェープの実行に従います。

FSG Bookingアプリケーションの場合、タイマーWaitシェープの使用が望ましい良い例としては、ユーザーがループバック内での操作の即時実行を必要とするようなループバックポーリング状況が挙げられます。 この例のユーザーは、次回の自動検索が行われるまで待つのではなく、現在の天気予報をポーリングすることができます。 

質問：査定プロセスの一環として、アプリケーションはローンのリスクファクターを生成し、そのリスクファクターをローンケースに挿入する必要があります。 リスクファクターの生成は、実行に数分かかるリソース集約型の計算です。 この計算によって環境が低速化します。 日中の業務時間内の速度低下を回避するため、リスクファクターの計算は午後10:00と午前6:00の間に自動的に実行する必要があります。 この機能をサポートするようソリューションを設計してください。

回答：遅延専用キュープロセッサーを使用します。 処理のDateTimeを午後10:00に設定します。 ケースは、キュープロセッサーが次回の処理のためにフローを再開するのを待ちます。

他の請求処理キュープロセッサーが他のノードで有効になっている場合は、それを利用して、すべてのローンリスク評価の処理を停止するのにかかる時間を短縮できます。

質問：クレームを含んでいるファイルが解析、検証、裁定されるよう、クレーム裁定プロセスを自動化する必要があります。 これらの最初のステップを通過した保険請求は、さらなる処理のために自動的に作成されます。 最大1,000件のクレームを含む単一のファイルが毎日午後5:00前に受信されます。クレームの検証は簡単で、所要時間は数ミリ秒です。 それにもかかわらず、クレームの裁定には最大5分かかる場合があります。

回答：アクティビティで、各クレームに対してQueue-For-Processingメソッドを呼び出します。

ファイルサービスアクティビティは、クレームを検証した後で、タスクをキュープロセッサーにオフロードする場合にのみ使用することをお勧めします。この処理は、取り込みプロセスに大きな影響を与えないためです。 使用可能な場合は、マルチノードおよびスレッド処理を利用することもできます。 さらに、タスクがモジュラー設計になっているため、将来必要になった場合の再利用と拡張が可能です。 ただし、クレームの裁定に同じファイルサービスアクティビティを使用すると、ファイルの処理にかかる時間が長くなります。 処理は単一ノードでのみ実行でき、ファイルサービスの実行中は時間枠をほとんど制御できません。 拡張性の確保とエラー処理もより困難になる場合があります。

キュープロセッサーがタスクを完了するのに要する時間を考慮する必要があります。 たとえば、キュ​​ープロセッサーによるクレームの処理に必要な時間は5,000分（83.33時間）ですが、タスクを完了するために単一ノードで単一キュープロセッサーを実行する場合には適していません。 複数のスレッドを持つ複数のノードでキュープロセッサーが有効になっているシステムは、業務時間外のタスクを実行できます。 別の解決策は、ファイルを細分して、それぞれ異なるキュープロセッサーにスケジュールすることです（各キュープロセッサーがそのタスクを実行するのに十分なCPUが利用可能であることが条件となります）。

質問：ディスカウントワインの販売代理店であるABC Companyは、注文の追跡にPega Platformを使用しています。 毎日最大100件の注文があります。 各注文には、商品と数量を指定する最大40の異なる明細項目があります。 商品リストは絶えず変化しており、リストへのワインの追加とリストからのワインの削除に伴い、最大5,000種類のワインがリストに登録されます。 ABC Companyは、注文追跡アプリケーションの機能を拡張して、注文量の多い上位10商品を毎日記録することによって、最近の売れ筋商品を判別したいと考えています。 この情報はテーブルに入力され、履歴レポートの作成を容易にするために使用されます。

回答：毎日の終業後に実行されるジョブスケジューラーを使用して、次のタスクを実行します。

• その日のすべての注文ケースを開き、商品タイプごとの注文量をテーブルに挿入します。
• 注文量の多い上位10商品を判別して、履歴レポートテーブルに記録します。

このアクティビティでは、1日に注文された商品数を簡単に取得して並べ替えるためにレポートを活用する必要があります。 履歴テーブルに値を記録するときは、コミットおよびエラー処理ステップをアクティビティに含めます。