Support Article
Changes made in one node does not get picked up on other PR node
SA-5353
Summary
You are facing rule sync up issues post upgrade to PRPC 7.1.6 from PRPC 6.2 SP1 in all the environments for Activity and When rules.
You check out an Activity rule on PRPC Node-A, add one more step at the top and check in the changes. Once the System Pulse agent has been run, you search for this Activity in all the other nodes and find the checked-in changes there. Though at runtime, only at PRPC Node-A the latest activity is getting executed. At all the other nodes, still the old Activity (pre check-in activity without the added step) was getting executed. It seems cache was not getting refreshed and still holding the stale data.
Workaround that you usually follow is, to check out the rule & delete the checkout, on the affected PRPC Node(s). Restarting the affected PRPC Node(s) also resolves the issue.
Error Messages
None
TROUBLESHOOTING
We made a change in an Activity rule on PRPC Node-A as the only rule change. On PRPC Node-B, using SMA>Advanced>Virtual Rule Table Cache Management, we noted the cache entry for this activity. Even after auto run of System Pulse there was no change. We ran the System Pulse Activity manually in PRPC Node-B and traced it using tracer. We did not see any error either in tracer or PegaRULES.log file. On PRPC Node-B, using Virtual Rule Table Cache Management, we noted the cache entry for this activity again but there was no change. Then we reloaded this Activity using Virtual Rule Table Cache Management on PRPC Node-B and noted the cache entry. This time it was different and the issue got resolved.
Running below query in DATA schema does not return any records for any Activity or When rule.
SELECT pzclearcachetype,
TO_CHAR(pzcreatedatetime,'DD/MM/YYYY HH24:MI:SS') AS pzcreatedatetime,
pzkeystring,
pznodename,
pzobjclass,
pzparameters,
pzsystemname
FROM pr_sys_updatescache
WHERE pzclearcachetype ='Cache';
This is an issue of the System Pulse record not being written to the PRPC system table - pr_sys_updatescache. And, that is the reason the other nodes have not been notified of the change, and thus, the issue. Activity rules are stored in PR4_RULE table and Database triggers takes the responsibility of propagating any updates on these rules to other tables or views.
Steps to Reproduce
You checkout an activity rule on PRPC Node-A, add a step for Property-Set where you are changing the value of pyLabel and check-in the changes. Once you see from Agents screen on SMA on node 2 that system pulse has run, you open this activity rule on PRPC Node-B and find that the changes are reflecting. Though at run time, you see (either from Tracer or Clipboard) that the changes are not getting picked up during execution on PRPC Node-B and Clipboard still has old value for pyLabel.
Root Cause
In a working local setup, we see that PR4_RULE table has trigger TRPR4_RULE that gather updates to table and save the information for pulse processing as below.
insert into DATA716.pr_sys_updatescache
(pzKeyString,
pzCreateDateTime,
pzClearCacheType,
pzNodeName,
pzSystemName,
pzObjClass,
pzParameters)
values
(SPtpzInsKey,
sysdate,
'Cache',
SPtpxNodeName,
SPtpxSystemName,
SPtpzObjClass,
SPtpzParameters);
When comparing it with TRPR4_RULE trigger from your environment we find that it is inserting into PR_SYS_UPDATESCACHE of RULES schema instead of DATA schema. And, it is not throwing an error for the same because you have a PR_SYS_UPDATESCACHE table present in RULES schema also leftover from previous PRPC installation.
Resolution
This issue was resolved using the local change - You have correctly qualified PR_SYS_UPDATESCACHE table with DATA schema in your TRPR4_RULE trigger from RULES schema. Now, the Rules checked-in changes are successfully getting updated to other PRPC Nodes at run time.
Published January 31, 2016 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.