処理中ケースのフロー変更の管理

この方法では、同じフロー内に付属するチケットを設定したり、新しいステージに変更したり、既存のステージを再開したりします。 処理中のアサインメントは、別のアサインメントに進み、更新されたバージョン内で処理が再開されます。

更新の影響を受けるシステム内の、すべての古いアサインメントを検索するバルク処理ジョブを実行する場合を考えます。 影響を受ける各アサインメントについて、バルク処理は、Assign-.OpenAndLockWork に続いてWork-.SetTicket, pxChangeStage、またはpxRestartStageを呼び出す必要があります。 たとえば、ステージを再起動するUtilityシェープを実行できます（pxRestartStage）。

次の例は、SetTicketを使用したバルクアサインメントアクティビティを示しています。

アクティビティを設定した後、更新したフローをデプロイし、バルクアサインメントアクティビティを実行します。

例

この例では、小規模の保険引受支店が1日に約50件のアサインメントを査定し、そのほとんどが2日以内に完了しています。 また、夜間処理も発生しません。 バルク処理を実行できる理由は、未完了のアサインメント数が比較的少なく、必要なロックを夜間に取得できるからです。 Commitメソッドを使用する必要はありません。

ケース固有のルールでは、ダイナミッククラス参照（DCR）を使用して、フローの現在の状態と将来の望ましい状態を区別します。 

ケース作成時に、差別化プロパティであるpxCreateDateTimeの値が即時に確定されます。 差別化の値が設定されていることと合わせて、ケースのpxObjClassが変更されます。 ケースのpyDefaultデータトランスフォームは、以下のロジックを使用して現在の年を決定できます。

<var>Param.CurrentYear</var> = @toInt(@String.substring(@DateTime.CurrentDateTime(),0,4))

続いて、以下のロジックを使用してケースのpxObjClassを変更します。

.pxObjClass => .pxObjClass + "-Y" + Param.CurrentYear

このアプローチでは年ごとにクラスを作成する必要がありますが、as-of-date状況設定と同じ動作はしません。

年ごとにクラスを作成しないようにする方法の1つは、直接の親クラスを指定するときに、その年の間に処理中のケースに影響を与えるフロー変更が行われない場合は、1以上の年をスキップすることです。 常にParam.CurrentYearを使用するのではなく、以下のロジックを使用するデータページで、クラスの特殊化が発生した最新の年を判定できます。

Param.ContractYear = D_ContractYearToUse[ObjClass:Primary.pxObjClass, StartYear:Param.CurrentYear].ContractYear 

.pxObjClass =>.pxObjClass + "-Y" + Param.ContractYear 

D_ContractYearToUse内のロジックには、以下のようなものがあります。

.ContractYear = Param.StartYear

For each page in D_StartsWithClassNameDesc[ObjClass:Param.ObjClass].pxResults 

Param.Year = <the last 4 characters in> pyClassName 

IF (Param.Year only contains digits AND Param.Year <= Param.StartYear) 

THEN Primary.ContractYear = Param.Year 

Exit Transform 

長所：アプリケーションのルールセットスタック内で定義されたクラスは、リクエスターレベルの情報であり、ケースの現在の状態を表示するCase Designerの機能と互換性があります。 これは、アプリケーションルールの「Cases & data」タブの設定方法と連動して実行されます。

上記のように設定されたアプリケーションルールは、設計時および開発時にのみ使用する必要があります。 本番環境では、DCRを使用して、各ケースタイプが使用すべきpxObjClassを確定します。

短所：このアプローチの使用に対しては、いくつか問題点があります。 次の表に、各問題点と対処方法をまとめました。

このアプローチにより、ユーザーはフローを更新せずに既存のアサインメントを処理できます。 以前のアプリケーションバージョンをポイントする新しいアクセスグループを追加します。 次に、オペレーターIDにアクセスグループを追加して、ユーザーポータルから以前のアプリケーションに切り替えたら、既存のアサインメントを完了します。

この例では、あるアプリケーションが大規模な再構築を行うとします。 新しいルールセットバージョンを含むアプリケーションの新しいバージョンが作成されます。 更新には、フローの再構成、意思決定、データ管理機能が含まれます。 フロー更新以外の変更に幅があるため、新しいアクセスグループを作成することになりました。

アプリケーションの新しいバージョンで作成されたケースを古いバージョンで処理したり、その逆を行ったりしないように注意してください。 ケースとアサインメントの両方が、pxApplicationVersionプロパティを所有しています。 Access Denyなどのセキュリティルールを実装することで、現在使用しているアプリケーションのバージョンに対応しないケースやアサインメントへのアクセスを防ぐことができます。

ユーザーのワークリストは、現在使用しているアプリケーションのバージョンに対応するケースのみを表示するように変更することも、アプリケーションのバージョンをワークリストビューの列として分離して表示することも可能です。 同様に、Get Next Workは、現在使用されているアプリケーションのバージョンに対応するワークバスケットアサインメントのみを返すように修正する必要があります。

 このアプローチでは、新しく作成されたケースで、アサインメント、待機、サブプロセス、Split-For-Eachなど、フロー内の特定のシェープが使用されなくなった場合でも、これらのシェープは保持されます。 新しいケースは、以前使われていたシェープに達しないよう、新しいバージョンのフローが再構成されます。 しかし、既存のアサインメントは元のパスを進みます。

この例では、プロセスを再設計して、新しいケースでReviewアサインメントとCorrectアサインメントを利用しないようにしました。 この2つをCreateアサインメントとReview Purchase Requestのアサインメントに置き換えます。 2つのアサインメントを削除するだけなので、最善策は2つのフローのバリエーションを並行して実行することです。

新しいバージョンのフローでは、2つの手順で更新を行います。

まず、ReviewアサインメントとCorrectアサインメントを図の片側にドラッグします。 StartシェープからReviewアサインメントへのコネクターを削除します。 Confirm Requestのコネクターはそのままにしておきます。 これにより、処理中のアサインメントの処理を継続できます。

次に、フローの始めにCreateアサインメントとReview Purchase Requestのアサインメントを挿入します。 Confirm Requestフローアクションを使用して、Review Purchase RequestをCreate Purchase Orderスマートシェープに接続します。

後で、古いアサインメントがまだ処理中かどうかをチェックするレポートを実行できます。 レポートを実行できない場合は、フローの次のバージョンで、古くなったシェープを削除できます。

このアプローチでは、必要な数のルールに状況を設定することで、フローの現在の状態と将来の望ましい状態を区別できます。 このアプローチに適した状況設定の1つを、as-of-date状況設定といいます。 as-of-dateは、ケース内のプロパティが特定される場合（例：pxCreateDateTime）に適しています。 そのプロパティは、日付範囲内のStart Dateとして使用されます。 日付範囲内のEnd Dateは空白のままです。 アプリケーション固有のDateTimeプロパティ（例：.CustomerApprovalDate）を使用することも可能です。