Most Recent

Blog Post

Control for lookup of Labels in a Data class

Control for lookup of Labels in a Data class

Introduction

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.

Field Values

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.

Key-Value Pairs

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.
  • 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).
  • Create a local storage table in the PegaDATA schema:
    Data Type for Priority

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.

Lookup Control

From inspecting the standard rule pyInstructionsLabelLookup we learn how to define a basic record lookup for specific class Rule-Obj-FieldValue in JSP: JSP for pyInstructionspyLabelLookup

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:

  1. Create a Control rule with a name like "LabelByID".
  2. Define a required Text type parameter ClassName on the Parameters tab.
  3. Implement the following source:

JSP for LabelByID

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". JSP for LabelByID

Conclusion

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)

 

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.