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:
Approach 2:
Approach 3:
Approach 4:(Recommended)
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".
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.
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.
Approach 4:(Recommended)
- Create a data type with columns refDomain, refID, refName (where ref stands for reference).
- This would be generic reference table for all the drop-downs. For example :
- Data type name is AppReference
- MyOrg-Data-AppReference // place at org level if it can reused across applications.
- Data Page name is D_AppReferenceList[refDomain:""]
- Configure local storage to the data type as below, where every row would make sense.
- 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"]
- 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"]
- 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.
How to generate unique ID from Pega ?
ReplyDeleteHi, There are many ways to achieve this. I usually like this way of calling function: pzGenerateUniqueID by passing the prefix.
DeleteBelow is the post which talks about the same: http://www.howtopega.info/2018/09/how-to-generate-unique-id-from-pega.html
How to force complete any case-- Please reply
ReplyDeleteThere 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.
DeleteHow to create child cases based on the pagelist we have at parent case.
ReplyDeleteIf 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.
DeleteI'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