Cannot get data transform to work
Hello,
I cannot get the data transform example to work, nor can I get the calculated read-only fields to work.
- I have added First Name and Last Name fields to the Personal Info step in the Collect Info stage (1st stage)
- I have added a Full Name field to the Schedule Interview step of the Interview stage (3rd stage)
- I have add a multi-step process AFTER the Personal Info step with a Start and End shape and double clicked the flow connector between them
- I changed "Set Properties" to "Apply Data Transform" with the name "SetFullName" and clicked the little spyglass to open it
- I created a new action as such:
Action: Set
Target: .FullName
Relation: equal to
Source: .FirstName + " " + .LastName
- Save all
Yet when I create a new case and go through the forms, reaching the 3rd Interview stage, the "Full Name" readonly field is empty.
I've also tried created a readonly calcuated field using the same formula: .FirstName + " " + .LastName, but this is not working either.
Thank you,
Caesar
Pegasystems Inc.
US
Cesar,
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?
eddie
new york life
US
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?
Pegasystems Inc.
US
I'm happy to read you sorted it out - that's good news. It can be tricky to keep track of everything.
To answer your question "is there a way to clearly see what the context is..?"
I like to use the App Explorer - I can easily idenitfy simple and complex types.
again, glad it worked out.
eddie
Pegasystems Inc.
US
sorry for the spam - but I wanted to mention:
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.
eddie
new york life
US
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?
I hope that is clear.
Thank you,
Caesar
Pegasystems Inc.
US
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
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:
eddie
new york life
US
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:
.Candidate
|_ .FirstName.
Now I am getting this error when I try to refresh anything:
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:
.Candidate
|_ .FirstName.
Now I am getting this error when I try to refresh anything:
Pegasystems Inc.
US
;)
I was just getting ready to post and tell you this was not related. "Passivated" tells me your session cookie is stale. Easiest thing to do is logout then log back in.
eddie
SynTouch
NL
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
OR
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?
Thank you,
Edgar