Full Name property: Declare Expression versus Data Transform
In the candidate excersise the Candidate.FullName property is set using a data transform in the post processing action in the flow action Personal Information. For the Onboarding case the property Employee.FullName is set using a declare expression.
This confuses me on what can be condisered best practise. At first sight a data transform seems more suited as it is part of the Data Category whereas declare experession belong to the Decision category. The big difference is I see is that the declare expression automatically updates the full name on the form without additional configuration whereas for the candidate case the full name is only updated after the form has been submitted..
To make it even more confusing there is also the pyFullName. Looking into the details of the property within Data-Party class I can neither see a data transform or declare expression rule, Nevertheless the usage documentation on the property says: Composed of pyFirstName + pyMiddleInitial + pyLastName + pyNameSuffix.
(1) Any guidelines on what can be considered best practise Data Transform vs Decare Expression.
(2) How and where pyFullName getting populated.
Regards, Erik
Pegasystems Inc.
US
Excellent questions.
1) As you noted, the difference between the two options we presented in these courses is procedural vs declaratively. Using the data transform, we have to configure our application to call for that data transform any place in the application the properties used to calculate .FullName might be changed. Using the declare expression, we set it once and forget about it. Any time the properties used to calculate .FullName change, Pega 7 automatically updates .FullName.
Both options are valid; after all, how often do people change their given names? The take away is recognizing that one is procedural and the other is declarative. Let your use case dictate which option you choose when building an application.
2) .pyFullName is not getting populated; at least not until "you" make it happen. What you are reading in the Usage documentation is mostly what the intent of the Pega-provided property could be used for. Notice on the General tab, there is a comment that reads: Data transforms and other rules may be required to support this workflow.
does this help clarify?
eddie
Pegasystems Inc.
US
Excellent questions.
1) As you noted, the difference between the two options we presented in these courses is procedural vs declaratively. Using the data transform, we have to configure our application to call for that data transform any place in the application the properties used to calculate .FullName might be changed. Using the declare expression, we set it once and forget about it. Any time the properties used to calculate .FullName change, Pega 7 automatically updates .FullName.
Both options are valid; after all, how often do people change their given names? The take away is recognizing that one is procedural and the other is declarative. Let your use case dictate which option you choose when building an application.
2) .pyFullName is not getting populated; at least not until "you" make it happen. What you are reading in the Usage documentation is mostly what the intent of the Pega-provided property could be used for. Notice on the General tab, there is a comment that reads: Data transforms and other rules may be required to support this workflow.
does this help clarify?
eddie
Kivco Consultants Inc.
CA
I have a question dealing with declare expressions.
The exercises suggest to set "HireDate" to be a date, and also to set an SLA on the Benefits enrollment and payroll setup to be 10 days from start date. So as designed, there is a "Wait For Start-Date" step, which means you don't actually have to use HireDate as an input to the SLA. But let's say you wanted the SLA interval on the Benefits Enrollment subcase to key off of the HireDate. You can't because it's a Date and not a DateTime.
It seems an easy way to solve this is to create a HireDateTime property and use a declare expression that converts the HireDate to a datetime (midnight using a local TMZ) and which saves it to HireDateTime. Is that a preferred method, or is there a better way?
Pegasystems Inc.
US
Hi Bram,
As far as converting StartDate to a DateTime data type the approach you suggested is valid. You could also re-create the StartDate property as a DateTime Data Type.
On the other hand OOTB SLA Rules defined in Pega 7 or PRPC cannot be configured to use a user defined property to set the Goal or Deadline intervals. For CaseType Service Level Rules PRPC or Pega 7 uses pxCreateDateTime and for Assignment Service Level Rules PRPC uses pxAssignDateTime.
Regards,
Henry
Pega Academy