Most Recent

Blog Post

Fixing non-registering property values in Pega

Fixing non-registering property values in Pega

TL;DR By far the best approach is to never design Section rules that have a duplicate (custom) property referring control on the rule instance. If input control sets turn out to be overlapping, always put them in separate rules -- otherwise follow the workaround below to refactor into unique properties within the same section.

Approach

Construct your section in such way that you only need one reference to each unique property — effectively de-duplicating these refs. This is not always feasible or easy to do i.e. if the order of fields varies. Also have the appropriate "Applies to" class so you only need to refer to properties on the Primary page.

Whenever Section rules are constructed that have (duplicate) controls on some embedded Clipboard page instead of the best practice “Section Include” pattern, issues might occur such as non-registering of changed property values or not-triggering certain event handlers that you have defined on these deeper property controls(!)

Analysis

The issue seems to manifest itself when certain property occurs more than once on the same section rule. Likely living on different parts (Dynamic Layout blocks) and its visibility controlled by some condition. Hidden or not, the control is still there and somehow suffers a name clash during runtime.

This section/scripting bug has plagued the platform since Pega 8 and has yet to be fixed. This article describes a practical workaround, although with the minimal technical debt of a single Data Transform and its event handler to actually run it from the control.

Workaround

The following steps show how to refactor an existing section into having disjunct properties while maintaining the same underlying data model:

  1. Open the section rule and navigate to the control for which the property does not post and save its value.
  2. On the General tab, replace the embedded property reference such as .Postadres.Plaats with .Postadres.pyTempText or similar temporary property.
  3. Optionally have it default to the original property .Postadres.Plaats
  4. Refactoring of duplicate control (General Settings)
  5. Now move over to the Actions tab.
  6. Here define an upon “Change” event handler with first the “Post value” action to get pyTempText value over the line (needed for empty scenario).
  7. Secondly, add another action “Set value” that will assign .Postadres.Plaats=.Postadres.pyTempText in the browser’s client-side space — Otherwise blanking of pyTempText would cause the former value of .Postadres.Plaats to be reinstated after final Submit since it already lives side-side(!)
  8. And thirdly, add yet another action “Other: Run data transform” to bring the Pega server-side in synch. This is the memory commonly referred to as the “Clipboard" and is the space that resides in the Pega Engine JVM.
  9. Always keep the context Page on “Auto” and enter a purposeful name like Set just use the cross-hair to create this new Data Transform rule.
  10. Define a transform step to set the original property to the temporary value like .Postadres.Plaats=.Postadres.pyTempText and save the rule.

In fact, steps 8 though 10 are optional if you make sure to create and hook-up a post-processing data transform that takes care of the same syncing. It can also implement the proper clean-up (see below).

Summary

In summary, upon each change of the control´s value, the implementation will take care of copying the new value from temporary to destination property on both client-side and server-side. This compensates for the fact that Pega doesn´t seem to post the value for some multi-referenced property — or in fact overwrites with the unchanged value of the (other instances of the) duplicated control. This is why (for the time being) you should only work with unique properties; preferable directly on the Primary page (of Applies to class) when constructing Section rules.

Regarding the order of the actions, it should not matter whether you first Post value and then Set value or other way around. These actions do not depend on each other. As long as you have Post value strictly before Run data transform since the latter happens on the server and would obviously need the correct value (as entered at the client) to work with. Setting up event handler actions

Tip: You can also amend this same Data Transform with additional property that do not behave correctly. Consider having an Update page construct if you have multiple embedded setters.

Defining data transform to map pyTemp* values

Remark: If you do NOT jump out of the field so the control losses focus and you immediately click Submit, Pega does not execute the (onChange) event handler so your change will be lost! A dirty fail-safe would be to change the event trigger type from “Change" to “Any key” as event trigger, but that also makes the communication rather chatty (happening at every key stroke). It is better to have post-processing to do the server-side copying to sync-up. You can then cleanup by removing these temporary properties like pyTempText.

  • Finally, create this post-processing Data Transform with the very same assignment as Property or alternatively use the "Apply Data Transform" action type to reuse the existing one.
  • Add a "Remove" step to clean up the pyTempText source property.

Note: Beware you need to have a unique temporary property for each property failing to register. These cannot be easily recycled within the same Section, because you need to do some post-processing to cater for the "immediate submit" scenario.

Documentation

Here follow some template texts that can be used as Description and Usage for the data transforms:

Explicitly sets this property though alternative pyTemp* due to Pega section/scripting issue where controls for duplicate properties do not (always) trigger its event handler(s) upon change.

Configure as compensating "Other: Run data transform" in property control´s change event as well as post-processing.

Note: Must use context Page="Auto"; otherwise the non-executing behavior will result given the very same issue.

Happy low-coding! ;-)

[Edgar] (5/21/2021 9:57:54 AM)

 

Twitter Feed

@edgarverburg

Bio

About Edgar

Edgar is a software engineer with experience in TIBCO Middleware and Pega Case Managemement. He holds a master's degree in Computer Science with a specialization in Data Visualization & Computer Graphics.

In his spare time Edgar reads SOS and Empire, mixes house music, blogs and writes film reviews or goes running.


Currently employed by SynTouch he is specifically looking for a PRPC project. Feel free to contact him for challenging assignments through LinkedIn.