ワークを検索するその他の方法

状況判断とGet Next Workのカスタマイズ方法に関する説明を思い出してください。 ワークバスケットアサインメントのpxCreateDateTimeプロパティが、セカンダリーの並べ替えではなく、プライマリーの並べ替えとして使用されているとします。 このような要件が存在している可能性があるのは、最も古いワークバスケットアサインメントを最初に処理しようとするワークグループです。これを先入先出法（FIFO）といいます。 pyGetWorkBasketレポートディフィニッションは、D_WorkBasketリストデータページの背後にあり、ワークバスケットアサインメントを表示するために使用されますが、これは、デフォルトで使用されるpxUrgencyAssignの降順の並べ替えではなく、pxCreateDateTimeの昇順の並べ替えを使用するように修正できます。

pxUrgencyAssignの値は、@CurrentDateTime()とワークキューアサインメントの作成を考慮することで、リバースエンジニアリングにより事後的に導き出すことができます。 pxUrgencyAssign の値は、UIに表示されるまで計算する必要はありません。

Claimケースで、顧客固有のSLA期限までの期間があるとします。 この期間は、各ClaimケースのpxCreateDateTimeに追加され、ケースの期限のDateTimeが設定されます。

そのケースのClaimUnitサブケースはすべて、親Claimケースの期限までに完了する必要があります。 しかし、ClaimUnitケースタイプによって、平均所要時間は異なります。 効率化を図るため、各ClaimUnitタイプの平均所要時間をノードレベルのデータページで利用可能にすることができます。

ワークキューにスピンオフされたClaimUnitは、そのpxGoalTime DateTimeプロパティを、@CurrentDateTime + （顧客期限 - 平均所要時間）と計算できます。 ここで、pxGoalTme はDateTimeを表します。 ClaimUnitはそのワークキューから取得され、ワークの完了に十分な所要時間を確保できるようになります。

Assign-WorkBaset GetNextWork ListViewの状況設定バージョンでは、pxUrgencyAssignの降順の並べ替えを使用するのではなく、pxGoalTimeの昇順の並べ替えを実行できます。 pyGetWorkBasketレポートディフィニッションの状況設定バージョンでも、pxGoalTimeの昇順の並べ替えを実行できます。

また、pxUrgencyAssignのルールデクレアエクスプレッションも、状況設定できます。 次の例は、pxUrgencyAssignが、datetimeプロパティに基づいてその値をリバースエンジニアリングする方法を示しています。

pxUrgencyAssign = min(100, 100 * ((CurrentDateTime – pxCreateDateTime) / (pxGoalTime - pxCreateDateTime)))

式中:  CaseDeadlineDateTime = CaseCreateDateTime + CustomerSLA (Assign-)

  および:  pxGoalTime = CaseDeadlineDateTime – CaseAvgTimeToComplete

分子と分母の時間単位は、分、時間、日のいずれであっても相殺され、無単位比になることに注意してください。 CurrentDateTime = pxGoalTimeの場合は、上記の式において、pxUrgencyAssignの値は100になることがわかると思います。 ここで選択した100という数字は任意です。 80など、どの係数を使用しても構いません。 設定可能な値として定義できます。

pxUrgencyに割り当てられた値を100に切り捨てても、Get Next Workクエリーとワークキューアサインメントリストクエリーの両方が、pxUrgencyAssignの降順ではなく、pxGoalTimeの昇順で並べ替えられていれば、問題はありません。 同じレポートディフィニッションを両方の目的に使用することは可能です。

緊急度が、時間ではなく、距離などの他の要素で判断される場合もあります。 たとえば、シャトルバスの運転手であれば、次のアサインメントは現在地から近い場所にしたいこともあるでしょう。 FSG Bookingアプリケーションソリューションでは、シャトルバスの運転手の位置情報を利用して、イベント参加者が送迎を待っている最寄りのホテルや駐車場を特定します。

Bookingアプリケーションは、SQLコネクターを呼び出して距離を計算します。 Pegaが提供するGetNextWorkの実装に、SQLコネクターの呼び出しを組み込むことは困難です。 さらに、Get Next Workアクションを呼び出せるようにするには、Pegaポータルにアクセスする必要があります。 ブラウザーリクエスターの代わりにアプリケーションリクエスターを使用するRESTサービスの呼び出しなど、別の方法でPegaにアクセスできます。

ボタンをクリックするアクションをOpen assignmentとして設定できます。このアクションには、アサインメントのpzInsKeyが必要ですが、 Assign-WorkBasketデータページにpzInsKeyの入力を求めることができます。

Assign-WorkBasketデータページでは、レポートディフィニッションを呼び出すことができます。 レポートディフィニッションは、pyErrorMessageがNullでないアサインメントを除外できます。 クエリー後のデータトランスフォームは、ワークバスケットの関連するケースがロックされているかどうかを確認し、それをスキップして次のアサインメントに移ることができます。 スキルマッチングは、Index-OperatorSkillsに結合されているIndex-AssignmentSkillsに対して定義されたサブレポートを使用して実行できます。

Get Next Work以外の機能を選択して、ToSkilledWorkBasketアクティビティを使用してワークがルーティングされたスキル指定ワークキューからアサインメントを取得することもできます。

施設コーディネーターポータルに、Parkingケースのアサインメントを表示するUIPagesビューがあるとします。 そのペルソナが駐車スキルを持っていない限り、そのビューには何も表示されません。

このビューは、D_WorkBasketをソースとするワークキューリストに似ています。 違いは、レポートディフィニッションにはアサインメントとオペレーターのスキルを考慮する必要があることです。 次のコードは、これを実行するための擬似SQLです。

Main Report:

          Parkingワークキューアサインメントリスト（D_WorkBasketと同様）

          JOIN to FSG-Booking-Work-Parking (CASE) WHERE pxRefObjectKey = CASE.pzInsKey

Filters:

          pxRequiredSkillCount = COUNT(rows in subreport)

Subreport:

          Index-AssignmentSkills JOIN to Index-OperatorSkills (OPSKILL) WHERE pxRequiredSkill = true AND pxSkillName = OPSKILL.pxSkillName

Subreport filters:

          pxInsIndexedKey = (main report) pzInsKey pxSKillRating <= OPSKILL.pxSKillRating OPSKILL.pyUserIdentifier = OperatorID.pyUserIdentifier