Case management
In LSA 7.1 course for case management that if there is case A of class Org-App-Work-A and case B of class Org-App-Work-A-B then B has to be always a subcase of A it cannot be an independent case. This is done when there is "is a " relationship between A and B. My question is is this functional statement or technically too we cannot create a stand alone case of B?
Pegasystems Inc.
US
It is not necessary Org-App-Work-A-B to be a subcase of Org-App-Work-A.
An example exists in the 7.3 LSA course's FSG-Hotel-Work-Hotel and FSG-Hotel-Work-Hotel-Proxy case. The HotelProxy case is created remotely using the Pega API -- it is NOT a subcase of Hotel.
Case-level pattern inheritance can be used to simplify maintenance.
If you were to, instead, define the Applies-To class as FSG-Hotel-Work-HotelProxy you would need to duplicate some of the case-level Properties that were Applied-To FSG-Hotel-Work-Hotel, but this is your decision.
For a simple case such as FSG-Hotel-Work-HotelProxy, not pattern-inheriting from FSG-Hotel-Work-Hotel and simply reusing the FSG Enterprise layer's FSG-Data-Hotel-RoomsRequest, et al, data model would be perfectly acceptable, plus be lighter-weight.
It is not necessary Org-App-Work-A-B to be a subcase of Org-App-Work-A.
An example exists in the 7.3 LSA course's FSG-Hotel-Work-Hotel and FSG-Hotel-Work-Hotel-Proxy case. The HotelProxy case is created remotely using the Pega API -- it is NOT a subcase of Hotel.
Case-level pattern inheritance can be used to simplify maintenance.
If you were to, instead, define the Applies-To class as FSG-Hotel-Work-HotelProxy you would need to duplicate some of the case-level Properties that were Applied-To FSG-Hotel-Work-Hotel, but this is your decision.
For a simple case such as FSG-Hotel-Work-HotelProxy, not pattern-inheriting from FSG-Hotel-Work-Hotel and simply reusing the FSG Enterprise layer's FSG-Data-Hotel-RoomsRequest, et al, data model would be perfectly acceptable, plus be lighter-weight.
For the 7.1 course's Warranty application having the Replacement case pattern-extend the Product case plus be a subcase of that Product case is because the Actor changes from Warranty Processor to Replacement Specialist.
The Warranty Process would have to wait for the Replacement Specialist to complete his/her work regardless the case design.
By implementing the Product-Replacement case as a subcase, the Replacement Specialist is able to see only the stages and steps that apply to their role as they work on resolving the warranty for that particular product.