Question
AMEX
US
Last activity: 6 Mar 2016 10:33 EST
Dynamically Create Skill Rules - Pega 7.1.8
Our application uses a Skill Based routing technique.
As per the requirement, there should be a portal for manager and should be able to add skills dynamically from the portal.
As each skill is a rule and if rulesets are locked, rule creation is not possible.
Is there any way that we can create such kind of a working environment by creating Skills Dynamically?
Accepted Solution
Updated: 11 Feb 2016 12:44 EST
Pegasystems Inc.
IN
Hi Sumanth, Good morning!
Hi Sumanth, Good morning!
- yes we could use production rulesets for runtime rule creations and update.
- OR could we try with a model skill rule customized/created at run time in private edit version?
- create a base/model skill rule
- perform obj-open on the model skill rule
- copy the required rule form meta data onto temp skill page
- temp skill page initiated with pyDefault data transform (optional)
- set the following properties on temp skill page
- pyRuleSet value to OperatorID.pyUserIdentifier or pxRequestor.pxUserIdentifier (may help at agent use cases)
- pyRuleSetVersion to "01-01-01"
- .pyLabel
- .pyRuleAvailable
- .pyClassName
- .pyPurpose
- ensure the rule name to be unique and can be easily identified as created at run time otherwise
- perform validation of a rule by same name already exits or not...
- ensure the rule name to be unique and can be easily identified as created at run time otherwise
- Issue Obj-Save + Write-Now or commit on temp skill page
- append the newly created skill to pySkills page as you had already done...
- process the business use case as designed.
- OOTB when rules to validate the skill may be referenced to evaluate...
- RULE-OBJ-WHEN DATA-ADMIN-OPERATOR-ID PYUSERHASSKILLS
- RULE-OBJ-WHEN ASSIGN- CURUSERHASREQUIREDSKILLS
- RULE-OBJ-WHEN ASSIGN- CURUSERHASDESIREDSKILLS
- OOTB when rules to validate the skill may be referenced to evaluate...
- delete the newly created skill rule via Obj-Delete-By-Handle
- OR refer to OOTB activities to update the model rules dynamically at runtime...
- RULE-OBJ-ACTIVITY RULE- PZPRIVATECHECKINCONFLICTCHECK
- RULE-OBJ-ACTIVITY RULE- PZPRIVATECHECKOUT
- RULE-OBJ-ACTIVITY RULE- RMACTIONDELETECHECKEDOUT
Please share your thoughts/comments, Thank you!
psahukaru
Virtusa
IN
Hi Venkata,
If your question states that if we can create rules in Run time by end users, then the answer will be yes. But it is not a recommended practice.
Please correct me if my understanding is wrong.
Thanks
Virtusa
IN
Hi Venkata,
Is there any specific reasons that you need to create the rules in the locked version? (in your scenario)
If not you can create the rules in the "production ruleset" of your application, which will be an open ruleset.
Thanks.
Accepted Solution
Updated: 11 Feb 2016 12:44 EST
Pegasystems Inc.
IN
Hi Sumanth, Good morning!
Hi Sumanth, Good morning!
- yes we could use production rulesets for runtime rule creations and update.
- OR could we try with a model skill rule customized/created at run time in private edit version?
- create a base/model skill rule
- perform obj-open on the model skill rule
- copy the required rule form meta data onto temp skill page
- temp skill page initiated with pyDefault data transform (optional)
- set the following properties on temp skill page
- pyRuleSet value to OperatorID.pyUserIdentifier or pxRequestor.pxUserIdentifier (may help at agent use cases)
- pyRuleSetVersion to "01-01-01"
- .pyLabel
- .pyRuleAvailable
- .pyClassName
- .pyPurpose
- ensure the rule name to be unique and can be easily identified as created at run time otherwise
- perform validation of a rule by same name already exits or not...
- ensure the rule name to be unique and can be easily identified as created at run time otherwise
- Issue Obj-Save + Write-Now or commit on temp skill page
- append the newly created skill to pySkills page as you had already done...
- process the business use case as designed.
- OOTB when rules to validate the skill may be referenced to evaluate...
- RULE-OBJ-WHEN DATA-ADMIN-OPERATOR-ID PYUSERHASSKILLS
- RULE-OBJ-WHEN ASSIGN- CURUSERHASREQUIREDSKILLS
- RULE-OBJ-WHEN ASSIGN- CURUSERHASDESIREDSKILLS
- OOTB when rules to validate the skill may be referenced to evaluate...
- delete the newly created skill rule via Obj-Delete-By-Handle
- OR refer to OOTB activities to update the model rules dynamically at runtime...
- RULE-OBJ-ACTIVITY RULE- PZPRIVATECHECKINCONFLICTCHECK
- RULE-OBJ-ACTIVITY RULE- PZPRIVATECHECKOUT
- RULE-OBJ-ACTIVITY RULE- RMACTIONDELETECHECKEDOUT
Please share your thoughts/comments, Thank you!
psahukaru
Pegasystems Inc.
IN
notes...(for reference, please)
- validate private edit conflict
- after successful private checkout ....
- edit the rule
- to save the run time updates
- Call OOTB RULE-OBJ-ACTIVITY @BASECLASS PROCESSRMACTION
- to call RMActionSave (save)
- to call RMActionDelete (delete, regular rule delete)
- Call OOTB RULE-OBJ-ACTIVITY @BASECLASS PROCESSRMACTION
- to delete the private edit rule (RMACTIONDELETECHECKEDOUT)
Virtusa
IN
Hi Venkata,
Yes you can use Production Ruleset.
Te general purpose of a production ruleset is, it will be an open ruleset which will not be locked so that the rules can be changed (eg: delegation rules) by the business users.
You can use the production rueset to create rules.
Thanks.
Updated: 6 Mar 2016 10:33 EST
Pegasystems Inc.
IN
recent learning's...
- best and recommendation is to have production ruleset for any dynamic or creation of rule at run time.
- if unable to maintain rule name unique
- appending the rule name with @DateTime.getCurrentTimeStampUnique() may help to certain extent
- post dynamic rule usage... delete the rule.
- appending the rule name with @DateTime.getCurrentTimeStampUnique() may help to certain extent
- if unable to maintain rule name unique
- having the implementation via private edit option has the following concerns
- operator should be enabled with checkout option
- for an operator of role, we generally disable checkout option
- enabling at run time and resetting to false - doesn't make sense
- for an operator of role, we generally disable checkout option
- the private edit syntax '@' has to be maintained or need to depend on the first item of operator ruleset stack.
- please note: if checkout option is not enabled on the operator rule from
- the first item on the ruleset stack wouldn't have operator private ruleset option
- enabling at run-time wouldn't recompile the ruleset stack unless the page is regenerated.
- or using the java code to dynamically re-arrange the ruleset stack at run time
- and ...
- enabling at run-time wouldn't recompile the ruleset stack unless the page is regenerated.
- the first item on the ruleset stack wouldn't have operator private ruleset option
- please note: if checkout option is not enabled on the operator rule from
- operator should be enabled with checkout option