Control for lookup of Labels in a Data class
Recently we encountered a requirement of empowering the business to manage the labels for certain data type themselves. While the usual approach of defining a business rule and delegating it as a whole could work, you could argue that this poses an operational risk for the application. For now, control of delegated rule type has limited support to prevent modification without having to resort to pre-define all the allowed options.
The ability to edit a string table — or name-value pairs if you will — would commonly be implemented in Pega with Field Value rules. Such Field Values support the notion of internationalization (i18n) or localization; meaning you can translate those for any of the locale settings you need to adhere to, i.e. en_US or nl_NL. The downside is that these translation values are to be defined at design time. In fact, the values are stored as Rule records in the PegaRULES schema (when running with a split database schema). They are not supposed to change after packaging, export and deployment on a higher environment. Luckily you could build a solution that allows adding and/or editing of records at run-time instead.
Let me describe the approach of creating a class for basic enumeration Data Type with local storage in the PegaDATA schema. Next, I´ll show how to leverage the lookup function to retrieve the corresponding named label for a given key.
Remember: In Pega any [concrete] class can have one or even more keys that make up a unique record. This is identical to the notion of unique key constraints in database table design.
In the following example we will just use a single key for our key-value pairs to keep things simple. Pega classes commonly have two or even three keys. Only if you provide all these keys you could lookup a single specific record.
Enumeration Data Type
- Create a new Data class for your application. This will represent the enumeration data type including the named labels.
- Define both standard pyID and pyLabel text type properties for this new class.
- Create a local storage table in the PegaDATA schema:
Note: Pega should indicate the rocket reuse icon whenever selecting standard property names available given the class hierarchy. Reuse whenever possible to prevent having data table that grow too wide (such as the 8k limit in certain Oracle databases).
You now also have the added benefit of the standard Import/Export feature of Data Type rules with associated table storage.
Tip: Rumor has it that Pega 7.4/7.5 will support a third category of tables next to existing Work- and Data- kinds. These will be more suitable for raw string table implementations like this, because the new table category won´t be burdened with the overhead of the many mandatory columns for PRPC.
From inspecting the standard rule pyInstructionsLabelLookup we learn how to define a basic record lookup for specific class Rule-Obj-FieldValue in JSP:
We could use the very same lookup mechanism for our needs; being the lookup of the pyLabel given the key pyID and a parameter for the class name to make it reusable for any future string table class. These are the steps for constructing our lookup control:
- Create a Control rule with a name like "LabelByID".
- Define a required Text type parameter ClassName on the Parameters tab.
- Implement the following source:
Tip: You can adjust what the control should return between the otherwise-tags.
Using Your Control
You can now start using your string lookup table by adding the control to your Section rules. Just drop the key property onto your canvas and adjust its control to "Other" to select your custom control by the name "LabelByID".
Now we have constructed a editable string table solution with lookup. Note that this lookup pattern can be leverage to retrieve any valuable data field stored in PRPC. Use wisely (if there is no standard rule). We leave the implementation of the table maintenance process to the reader.[Edgar] (5/4/2018 11:50:35 AM)
@edgarverburgTweets by @edgarverburg
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.