処理中ケースのフロー変更の管理
すでに本番環境にあるフローを安全に更新するには、いくつか基本的なアプローチがあります。 アプリケーションの構成やビジネス環境はそれぞれ異なるため、状況に応じて最適な方法を選択してください。
注: どの方法を選択するにしても、新しく作成したケースだけでなく、必ず既存のケースでアサインメントをテストしてください。
アプローチ1:既存のアサインメントを移動する
この方法では、同じフロー内に付属するチケットを設定したり、新しいステージに変更したり、既存のステージを再開したりします。 処理中のアサインメントは、別のアサインメントに進み、更新されたバージョン内で処理が再開されます。
更新の影響を受けるシステム内の、すべての古いアサインメントを検索するバルク処理ジョブを実行する場合を考えます。 影響を受ける各アサインメントについて、バルク処理は、Assign-.OpenAndLockWork に続いてWork-.SetTicket, pxChangeStage、またはpxRestartStageを呼び出す必要があります。 たとえば、ステージを再起動するUtilityシェープを実行できます(pxRestartStage)。
次の例は、SetTicketを使用したバルクアサインメントアクティビティを示しています。
アクティビティを設定した後、更新したフローをデプロイし、バルクアサインメントアクティビティを実行します。
注: アクティビティを実行するときは、必ずシステムをオフラインにしてください。
例
この例では、小規模の保険引受支店が1日に約50件のアサインメントを査定し、そのほとんどが2日以内に完了しています。 また、夜間処理も発生しません。 バルク処理を実行できる理由は、未完了のアサインメント数が比較的少なく、必要なロックを夜間に取得できるからです。 Commitメソッドを使用する必要はありません。
長所 |
|
---|---|
短所 |
|
アプローチ2:ダイナミッククラス参照を使用する
ケース固有のルールでは、ダイナミッククラス参照(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」タブの設定方法と連動して実行されます。
Name | Work ID prefix | Implementation class |
BookEvent |
EVENT- |
FSG-Booking-Work-BookEvent-Y2022 |
WeatherPrep |
WPREP- |
FSG-Booking-Work-WeatherPrep-Y2021 |
RoomsRequest |
ROOMS- |
FSG-Booking-Work-RoomsRequest-Y2020 |
上記のように設定されたアプリケーションルールは、設計時および開発時にのみ使用する必要があります。 本番環境では、DCRを使用して、各ケースタイプが使用すべきpxObjClassを確定します。
短所:このアプローチの使用に対しては、いくつか問題点があります。 次の表に、各問題点と対処方法をまとめました。
問題点 | 対処方法 |
---|---|
クラスの作成に余計な時間がかかる | クラスの新規作成や、他クラスへの直接拡張の設定に、ほとんど時間はかかりません。 年に一度だけクラスを作成すればいいのなら、その年に行う他の開発作業と比べて、クラス作成にかかる時間はごくわずかです。 |
継承パスが長くなりすぎたり、ルールレゾリューションのパフォーマンスに影響を及したりする可能性がある | 継承階層の深さに制限はありません。 その他のパフォーマンスに関しては、継承階層が問題になるかなり前から伸び悩んでいます。 |
余分なクラスがあると、将来的にデータベーステーブルの保存の判断が複雑化する | クラスグループ、ワークプール、Data-Admin-DB-Tableレコードが、データの永続化先を決定します。 |
スケーリングができない | 同じデータベーステーブル内の一意のpxObjClass値の数を増やしても、システムアーキテクチャには影響しない。 |
アプローチ3:処理中ケースのアプリケーションバージョンを切り替える
このアプローチにより、ユーザーはフローを更新せずに既存のアサインメントを処理できます。 以前のアプリケーションバージョンをポイントする新しいアクセスグループを追加します。 次に、オペレーターIDにアクセスグループを追加して、ユーザーポータルから以前のアプリケーションに切り替えたら、既存のアサインメントを完了します。
この例では、あるアプリケーションが大規模な再構築を行うとします。 新しいルールセットバージョンを含むアプリケーションの新しいバージョンが作成されます。 更新には、フローの再構成、意思決定、データ管理機能が含まれます。 フロー更新以外の変更に幅があるため、新しいアクセスグループを作成することになりました。
長所 | 新しいバージョンに追加された機能拡張をバックポートしようとしないため、アプリケーションのオリジナルのバージョンと新しいバージョンがそのまま残ります。 |
---|---|
短所 | アプリケーションの新しいバージョンに組み込まれた望ましい修正と改善は、古いバージョンでは利用できません。 |
アプリケーションの新しいバージョンで作成されたケースを古いバージョンで処理したり、その逆を行ったりしないように注意してください。 ケースとアサインメントの両方が、pxApplicationVersionプロパティを所有しています。 Access Denyなどのセキュリティルールを実装することで、現在使用しているアプリケーションのバージョンに対応しないケースやアサインメントへのアクセスを防ぐことができます。
ユーザーのワークリストは、現在使用しているアプリケーションのバージョンに対応するケースのみを表示するように変更することも、アプリケーションのバージョンをワークリストビューの列として分離して表示することも可能です。 同様に、Get Next Workは、現在使用されているアプリケーションのバージョンに対応するワークバスケットアサインメントのみを返すように修正する必要があります。
アプローチ4:新しいフローと並行して既存のアサインメントを処理する
このアプローチでは、新しく作成されたケースで、アサインメント、待機、サブプロセス、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スマートシェープに接続します。
後で、古いアサインメントがまだ処理中かどうかをチェックするレポートを実行できます。 レポートを実行できない場合は、フローの次のバージョンで、古くなったシェープを削除できます。
長所 | すべてのケースが、複数のバージョンで同じルール名を使用します。 |
---|---|
短所 | このアプローチは、構成が変更されると、実行不可能になる場合があります。 さらに、プロセスモデラー図に要素が多くなりすぎる場合もあります。 |
アプローチ5:状況を設定する
このアプローチでは、必要な数のルールに状況を設定することで、フローの現在の状態と将来の望ましい状態を区別できます。 このアプローチに適した状況設定の1つを、as-of-date状況設定といいます。 as-of-dateは、ケース内のプロパティが特定される場合(例:pxCreateDateTime)に適しています。 そのプロパティは、日付範囲内のStart Dateとして使用されます。 日付範囲内のEnd Dateは空白のままです。 アプリケーション固有のDateTimeプロパティ(例:.CustomerApprovalDate)を使用することも可能です。
長所 | 最初はApp Explorerで簡単に実装できます。 アプリケーションを切り替える必要はありません。 |
---|---|
短所 |
状況設定の使用に関する短所は、「特殊性の設計」モジュールに記載されています。 主な短所は、特殊なCase Typeルールのサポートを除いて、状況設定を使用すると、Case Designerが影響を受けることです。 Case TypeルールはDateTimeプロパティで特殊化できず、as-of-date状況設定は許可されません。 この場合は、変更を無期限に繰り越す必要があるという問題が発生します。 Case Designerのスコープはリクエスターレベルであるため、Case Designerにはフローなどの状況設定ルールの基本バージョンしか表示されません。 状況設定されたルールを他のルールから開くと、基本バージョンが表示されます。 基本ルールの正しく状況設定されたバリエーションを検索するには、Action > View siblingsをクリックします。 状況設定されたルールの数が増えるほど、同じように状況設定されたルールと状況設定されていないルールの集合による相互作用を可視化することは難しくなります。 |
このトピックは、下記のモジュールにも含まれています。
If you are having problems with your training, please review the Pega Academy Support FAQs.