Guardrails
Can anyone explain the use of guardrails in pega and how it affect rule sets and releases
Pegasystems Inc.
IN
Hi
You may want to start with these articles
&
Pegasystems
US
If you make your rules "guard-rail compliant", you are more likely to have an easier time migrating your rules to newer releases of the Pega platform. Whenever you save a rule, the system checks and warns you of any aspects of your rule definition that is not guard-rail compliant, making it more clear how to adjust the definition to bring the rule back into compliance. /Eric
Here is another handout (Old) about 10 guardrails https://docs-previous.pega.com/smartbuild-guardrails
To answer your question, guardrails are the best practices that one need to follow while defining rules in PRPC. It reflects on how your overall application looks like from standards perspective. We don't have to really tie this to "RuleSets or releases or any other concepts" and understand. More precisely, if you violate Guardrails, you have rules with warnings. It's always for the benefit of the project (and might make upgrades a nightmare as Eric pointed), these need to be carefully reviewed and corrected or justified with a reason for violating.
Undoubtedly these are a decade old and need to be reformed.
Some may not make sense today.
1) For instance guardrail-4 'Limit Custom Java', which explains to avoid 'Java' steps in activity rules might not make sense when the slogan is 'avoid creating activities'; of-course one might say to apply this guardrail for other java rules like edit-validate, rule utility function etc)
Here is another handout (Old) about 10 guardrails https://docs-previous.pega.com/smartbuild-guardrails
To answer your question, guardrails are the best practices that one need to follow while defining rules in PRPC. It reflects on how your overall application looks like from standards perspective. We don't have to really tie this to "RuleSets or releases or any other concepts" and understand. More precisely, if you violate Guardrails, you have rules with warnings. It's always for the benefit of the project (and might make upgrades a nightmare as Eric pointed), these need to be carefully reviewed and corrected or justified with a reason for violating.
Undoubtedly these are a decade old and need to be reformed.
Some may not make sense today.
1) For instance guardrail-4 'Limit Custom Java', which explains to avoid 'Java' steps in activity rules might not make sense when the slogan is 'avoid creating activities'; of-course one might say to apply this guardrail for other java rules like edit-validate, rule utility function etc)
2) As another example 'Create Easy-to-Read Flows' might be a good fit for the previous generation of process modeling. This might be poor candidate for Pega7 case design (that primarily revolves around Stages and Steps and we might never have a step type 'multi-step process' that really go beyond 15 smart shapes under any circumstance if the best practices of case decomposition are followed.