Question
EY
US
Last activity: 29 Dec 2020 17:30 EST
Unable to find FSG-Booking-Data-Contact
Hi,
I'm unable to find the class FSG-Booking-Data-Contact in the following chapter for the PCLSA academy.
Has anyone faced a similar issue?
https://academy.pega.com/challenge/implementing-effective-data-model/v1/in/11776
Pegasystems Inc.
US
That you for pointing this out.
Unlike the 7.3/4 version of the LSA course, the Customer work party was not incorporated in the 8.3 LSA course's version of the Booking application. You could go into Setting -> Participants and enable the Customer party if you want and saying it should be VOE (visible on entry).
Had any Customer class been defined in 8.3, it would be FSG-Data-Contact, not FSG-Booking-Data-Contact.
There is no reason for an Enterprise not to have a default, base definition of what a Contact is and in what schema instances of the class would be created if desired. Best practice is to consider whether a data class can apply to any application. If so, define that class that way. A given application is free to extend the Enterprise data class definition.
If wanting to query who was associated to a case in what PartyRole, the PartyUri Declare Index would be used which writes to the Index-WorkParytUri class to retrieve the data.
If you look at the Data-Party-Person WorkPartyRetrieve activity, you can see that Pega will actually try to Obj-Open a record if the pyWorkPartyUri property is populated.
Were Data-Party instances to be persisted, they would be stored in the pegadata.pr_data table.
What you could do instead is have FSG-Data-Contact extend PegaData-Contact which extends Data-Party-Person. PegaData-Contact is completely flat and stored in the customerdata.p_contact table.
That you for pointing this out.
Unlike the 7.3/4 version of the LSA course, the Customer work party was not incorporated in the 8.3 LSA course's version of the Booking application. You could go into Setting -> Participants and enable the Customer party if you want and saying it should be VOE (visible on entry).
Had any Customer class been defined in 8.3, it would be FSG-Data-Contact, not FSG-Booking-Data-Contact.
There is no reason for an Enterprise not to have a default, base definition of what a Contact is and in what schema instances of the class would be created if desired. Best practice is to consider whether a data class can apply to any application. If so, define that class that way. A given application is free to extend the Enterprise data class definition.
If wanting to query who was associated to a case in what PartyRole, the PartyUri Declare Index would be used which writes to the Index-WorkParytUri class to retrieve the data.
If you look at the Data-Party-Person WorkPartyRetrieve activity, you can see that Pega will actually try to Obj-Open a record if the pyWorkPartyUri property is populated.
Were Data-Party instances to be persisted, they would be stored in the pegadata.pr_data table.
What you could do instead is have FSG-Data-Contact extend PegaData-Contact which extends Data-Party-Person. PegaData-Contact is completely flat and stored in the customerdata.p_contact table.
If deciding to persist FSG-Data-Contact you could have its instances be stored in its own CustomerData schema table.
FSG-Data-Location could reference an FSG-Data-Contact instance using a property .ContactRef.
FSG-Data-Address, which was supposed to be stored in the CustomerData schema but ended up in the PegaData schema by mistake could extend PegaData-Address.
As opposed to using PegaData-Address directly and having it reference PegaData-Contact, you can use the Booking application's solution where FSG-Data-Address references FSG-Data-Location.
A person (contact) or a place is typically associated to one location. A location though can have multiple types of addresses.
Pegasystems Inc.
IN
I am facing a different issue, stuck at the same stage. I am not sure in which of the jars the below classes exist. I am not able find them in the system.
FSG-Data-Shuttle
FSG-Data-ParkingLot
These should be available in the system to be included as data types.
Pegasystems Inc.
US
Please ignore FSG-Data-Shuttle.
The requirements do not have sufficient information to implement a real shuttle service application.
For one, what does "Shuttle" mean? Is it:
- a shuttle organization/company?
- a van with a certain capacity?
- a trip taken between two Locations?
A proper solution would define all three.
FSG-Data-ParkingLot should extend FSG-Data-Location, the same as FSG-Data-Hotel and FSG-Data-Venue
But cars can also be parked in a garage, not just in a lot.
A better class name would be: FSG-Data-ParkingLocation
FSG-Data-ParkingLocation would add properties to FSG-Data-Location such as NumberOfSpaces and ParkingType.
Values for ParkingType would be as "Lot" and "Garage".