Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Maximize rule reuse through parameterization

Updated on February 19, 2016

 This presentation is part of the Reusability and Specialization e-Learning Course.

Transcript

A parameter is a reference or value passed into a routine. Within PRPC, Parameterization allows your activities and flows to be more reusable.  We can parameterize:

  • Values within rules
  • Page names, which avoids explicitly naming pages which prevents rules from being reused 
  • Class names, which is essential when using the PRPC best practice class structure design pattern

Task:Create an activity that opens a work object based on a passed in work object ID and sets its status to Resolved-Completed.

We can all construct this activity, but how do you make this activity a reusable asset?  Initially, we may think to parameterize the work object ID.  However, if we hard-coded the Resolved-Completed status in the rule, this rule becomes less reusable since it can only be used for this single purpose.  If at a later date, a new requirement is identified to open a work object and set its status to Resolved-Rejected, we would have to clone the existing activity, or essentially refactor the activity, and then refactor any activity that calls it. 

For the given task, the rule should accept parameters for both the work ID and the status.  This ensures that our activity can be reused in many other situations.  For every rule you write, consider if parameterizing the rule can make it more reusable in other places.

Only certain rules can be parameterized by PRPC.  Some of the most common rules that support parameterization are:

  • Rule-Obj-Activity
  • Rule-Obj-Flow
  • Rule-HTML-Parameter
  • Rule-Utility-Function, and
  • Rule-Declare-Collection

All have similar, but not exactly the same, parameter pages.  Let's take a look at the parameter page tab of an activity. 

Field             

Description

Name

Holds the name of the parameter shown to the developer when prompted to fill in the parameter when calling this activity

Description

Used for documentation purposes and is key to describing what the parameter does to other developers. 
You should accurately describe what the parameter is used for and provide a list of valid values or an example of values for this field.

Data Type
Required
In/Out

Provide more visibility into how this parameter is meant to be used by other developers

Prompt Default Value

Sets an optional default value

Type for SmartPrompt

Found after expanding the orange triangle to the left of the Name field - allows you to make a parameter show up as a SmartPrompt.  This can be very useful in assisting the developer, who is trying to call your activity

Validate As

Further filters your SmartPrompt options 
One example of this would be if you had a Rule-Obj-FieldValue in your Type for SmartPrompt field  
The Validate As field can be used to contain the Field Name that you want to filter on -   for example pyStatusWork

 

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us