ケース階層の設計

サブプロセス（サブフロー）を持つ単一ケース

単一のEventケースでは、ロックの問題によりプロセスの要件を満たすことができません。 拡張性とレポートの要件は簡単に満たせます。UIの要件は各ホテルを追跡する独立したデータオブジェクトで満たせるかもしれません。 ただし、各ホテルのステータスを更新するためには追加作業が必要です。

データの要件は、設備使用者のデータを難読化することで満たせますが、これはデータを保護するための最適なソリューションではありません。

しかし、ケースがロックされると2人のユーザーが同時にケースを更新することができなくなるため、プロセスの要件は完全には満たせません。 楽観的なロックで問題を改善することはできますが、ケースプロセス中のユーザーエクスペリエンスを損なう可能性があるため、最適ではないかもしれません。 サービスを追加したときに、この問題が悪化する可能性があります。

子ケース（サブケース）を持つ単一ケース

実行可能な代替案としては、Event最上位ケースにサービス（現時点ではWeather、Hotel、Parking）を扱うサブケースを付随させる方法が考えられます。 デフォルトのロック方式を変更してサブケースが親ケースとは別にロックされるようにすると、ロックの問題が解決され、中断のない並列処理が可能になります。 この方法では、サービスを追加した場合でも簡単に対応できるため、設計の拡張性も確保できます。 この設計オプションの候補を使用して、サブケースの完了とメインケースとの調整を行うことを検討してください。 Hotelサブケースはイベント開始前に完了するはずです。Parkingケースは実際のイベント期間中、さらに場合によってはイベント後もアクティブです。 また、将来的にサービスを追加した場合の影響も考慮してください。

複数のケース（サブフロー/プロセスを持つ）

最上位にEventケースを単独で設定するのではなく、Quoteケースを別に作成して当初の見積もりを行うこともできます。 承認されると、ピアEventケースが作成されます。 この方法では、顧客とエグゼクティブが承認した場合にのみ、Eventケースを作成できます。

状況設定最上位ケース（サブフロー/プロセスを持つ）

別の代替案として、マッシュアップチャネルEventケースの状況設定からカスタマーセルフサービス見積もり機能を提示する方法があります。 顧客がCreateステージ内に生成された見積もりを気に入った場合、サブミットするときにEventケースは顧客がアクセスできないQuotationステージに進みます。 顧客が進めたくないと考える場合は、Eventケースを完了するCreateステージ内でキャンセルできます。 Quotationステージでは、セールスエグゼクティブは顧客がサブミットした見積もりを承認または拒否できます。 顧客がサブミットした見積もりをセールスエグゼクティブが承認するときに、顧客と直接話さないのであれば、顧客は、マッシュアップインターフェイスを介して決定を確認するよう求められます。

各設計オプションの長所と短所