Monday, March 2, 2020

Value Population for dropdowns in Pega : Design Pattern

Scenario:

In Pega, it is quite common scenario to populate multiple drop-downs based on values from external system (via services). Most of the times, we tend to see that the services are expensive and hardly they are readily available in the legacy systems (like SAP,...).

So in  most of the cases, business would give drop-down values to us to incorporate in Pega as a local storage. And it is expected that values would change frequently; so the design should be flexible to accept the changes in future.

To simplify this with an example, there are drop-downs in a section: Severity, Priority. Please click on the below drop-downs to see the list of available values:

    

Severity has drop-down options : Sev-1/Sev-2/Sev-3/Sev-4
Priority has drop-down options : High/Medium/Low

Note: This article describes about only non inter-dependent dropdowns maintainance. Based on the response, will publish on how we can maintain cascading drop-downs (inter-related)

Approaches:



Listed down the possible approaches with the notes corresponding to each approach. The last approach(Approach 4) would be the recommended approach due to advantages it outweigh w.r.t the other approaches


Approach 1:
  • To create property for Severity and make a local list with the given values.
  • To create property for Priority and make a local list with the given values.
  • And while referring these properties on section, map the source to "as defined on property".
Note: This appears as if the requirement is met. But if take a closer look, if business comes up with the changes: developer's intervention is needed to append/delete any options to the drop-down. And this is a total disadvantage with this approach.

Approach 2:
  • Create a single data type with Severity and Priority as columns.
  • Maintain data page D_Severity for Severity which would load only Severity.
  • Reference the data page in the source of the drop-down for property Severity.
  • Maintain data page D_Priority for Priority which would load only Priority
  • Reference the data page in the source of the drop-down for property Priority.
Note: Maintain single data type for two non-interrelated columns will lead to data discrepency. Also row will never make sense.

Approach 3:
  • Create separate data type for Severity where Severity is the only column.
  • Maintain data page D_Severity for Severity which would load Severity.
  • Reference the data page in the source of the drop-down for property Severity.
  • Create separate data type for Priority where Priority is the only column.
  • Maintain data page D_Priority for Priority which would load Priority.
  • Reference the data page in the source of the drop-down for property Priority.
Note: Since we are creating different data type for each drop-down it would end up in creating n number of data types instead of logically grouping them with design pattern.

Approach 4:(Recommended)


  1. Create a data type with columns refDomain, refID, refName (where ref stands for reference). 
  2. This would be generic reference table for all the drop-downs. For example : 
  3. Data type name is AppReference
  4. MyOrg-Data-AppReference  // place at org level if it can reused across applications.
  5. Data Page name is D_AppReferenceList[refDomain:""]
  6. Configure local storage to the data type as below, where every row would make sense. 
  7. Reference the data page in the source of the drop-down for property Severity by passing the appropriate dropdown reference i.e. refDomain="Severity"  i.e. D_AppReferenceList[refDomain:"Severity"]
  8. Reference the data page in the source of the drop-down for property Priority by passing the appropriate dropdown reference i.e. refDomain="Priority"  i.e. D_AppReferenceList[refDomain:"Priority"]
Advantages of refDomain approach:
  • In case of any changes to the existing refDomain, they can be accomodated easily. 
  • In case of any new refDomains, they can be added easily.
  • The above single data type can be delegated to users for updates.
  • Every row in the table would logically make sense, and would form a normalized database table.
  • Since there is no combinations involved, would be easy for storage and retrieval.



7 comments:

  1. How to generate unique ID from Pega ?

    ReplyDelete
    Replies
    1. Hi, There are many ways to achieve this. I usually like this way of calling function: pzGenerateUniqueID by passing the prefix.
      Below is the post which talks about the same: http://www.howtopega.info/2018/09/how-to-generate-unique-id-from-pega.html

      Delete
  2. How to force complete any case-- Please reply

    ReplyDelete
    Replies
    1. There is an activity in Pega: pxForceCaseClose to which you have to pass the parameters with case ID and status and it will do the required. You can give it a try and let me know on how it goes.

      Delete
  3. How to create child cases based on the pagelist we have at parent case.

    ReplyDelete
    Replies
    1. If you are using latest versions on Pega, explore "Create child" smart shape directly from Case lifecycle view or else from the flow: where you have options to create child cases based on the provided pagelist. Give a try, and let me know.

      Delete
  4. I'm new to pega and first approach is what comes to my mind first, but UI does not render options for dropdown when I try that approach.

    ReplyDelete


HowToPega : All rights reserved and the contents are copyrighted to Pavan Kumar Naidu