Based on the details you provided, it seems the properties are not correctly identified.
If I remember correctly, each of the properties (.FullName, .FirstName & .LastName) are attributes of the .Candidate data object. So, you should be referencing .Candidate.FullName = .Candidate.FirstName + " " + .Candidate.LastName
Can you confirm this is how the data transform is configured?
Yes that did work, but I got an error when I tried to put the .FullName under the .Candidate context as well, so I had to leave it as .FullName. Why is this? I would've guessed that .FullName is under the same context.
Is there a way to clearly see what the context is of a property?
it won't prove to be an issue (as long as you keep track of it), but FullName should be an attribute of the Candidate data object. It doesn't have to be, it was simply a design choice the authors of the course made when desiging the data model. However, in the rest of the exercises, you will see FullName always referred to as .Candidate.FullName
If your data model is setup so that .FullName is not an atrribute of the Candidate data object, it will be OK. But, you will need to make a note-to-self to remember to refer to it without using .Candidate as a parent.
I'm guessing that I can simply add an "object" type property on another form (Configure Form) in another stage and name it "Candidate" as well and it will simply append any properties I put under it to the original "Candidate" object? Is this how you do it or do I need to add .FullName to the first stage with all of the other properties under the "Candidate" object?
If I am understanding this correctly, you want to add the .FullName property to the .Candidate data object definition. Here is a relatively easy way (you can start this from pretty much anywhere, the key is to set the proper context.
1) I am using the App Explorer, and using a right-click on the .Candidate property
2) Enter a label, and MOST IMPORTANTLY, set the correct context in the Apply to: field. Remember, Candidate is a data object so it's "definition" is maintained in the Org-App-Data- class; and that is where the attributes are defined.
When you have this record set with the appropriate meta data, click the orange "Create and Open" button in the upper right corner.
3) One last sanity check on the last screen - then click Save
You will need to refresh the App Explorer, but when you do you should see the .FullName property in the .Candidate data object now:
I went a different route to experiment first: I re-added the Candidate object to another form and it populated all of the fields for me (First Name, Last Name...etc) then I just appended "First Name" and then removed all of the other properties so I had this:
Now I am getting this error when I try to refresh anything:
<title>PegaRULES Request Status</title>
Cannot restore passivated page 'pyPortal' for Thread STANDARD
Regarding this same exercise. What design choice is better or preferred in practice?
Pull/Ad Hoc: Using the Form Configuration's "Calculated (read-only)" mechanism by providing a simple expression to be automatically calculated - I assume is executed during the "Schedule Interview" step
Push/ASAP: Using the post-processing action part of the "Personal Info" step to SetFullName as described by the textbook solution provided.
One could argue that the latter choice could result in an invalid .FullName when the process grows more complex, i.e. adds a stage and step to update the person's FirstName -- not propagated to the unaware developer.
I also notice that Pega creates properties for any derived fields such as FullName which could be more expensive (for the purpose of just displaying) and lead to clutter in your data model; comparing it to traditional normalized models like implemented in Oracle Database. Could you also elaborate on this observation?