Skip to main content

This content is closed to future replies and is no longer being maintained or updated.
Links may no longer function. If you have a similar request, please write a new post.

Question

5
Replies
1010
Views
 Rasaiya Nadar (RasaiyaNadar) Accenture
Accenture
IN
RasaiyaNadar Member since 2013 78 posts
Accenture
Posted: Nov 17, 2015
Last activity: Nov 18, 2015
Posted: 17 Nov 2015 4:34 EST
Last activity: 18 Nov 2015 3:01 EST
Closed

Wrong rules are getting picked post major skim

Report


We performed a major skim and after that we had few releases.

In the last release we found the following issue.

Technical Details;

1. We introduced a new label and a corresponding text box [Kept them visible always]

2. This worked fine in all the environment excpet Production.

Later we found that the latest rule was not getting picked up by the system.

Is there a way to find which rule is getting picked up from backend ?

There must be some entry in some table which rule is getting picked for a particular accessgroup or user.

Where can i find study material regarding such table?

Note: This got solved after we migrated from PRPC 6.2 to Pega 7
Posted: 7 years ago
Posted: 17 Nov 2015 4:53 EST
Santanu Bhattacherjee (Santanu) Senior Manager, Cloud Engineering, Management Plane Services
Pegasystems Inc.
IN
Report

Hi

In cases like this , start with these questions :

1. Have you restarted your server and cleared cache post deploying the changes in prod ? If not , what is the outcome after doing that ?

2. If it is a multinodal environment, then is your pulse agent working fine ? Are you seeing any error in log ?

3. Also, have you updated your application / access group to point to the updated ruleset ?

Now coming to your question of " Is there a way to find which rule is getting picked up from backend " , well ,i would say that tracer should be able to tell you the same.

Coming to the study material, start with understanding caching and system pulse.

http://community.pega.com/node/966

https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm

https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm

Show More

Hi

In cases like this , start with these questions :

1. Have you restarted your server and cleared cache post deploying the changes in prod ? If not , what is the outcome after doing that ?

2. If it is a multinodal environment, then is your pulse agent working fine ? Are you seeing any error in log ?

3. Also, have you updated your application / access group to point to the updated ruleset ?

Now coming to your question of " Is there a way to find which rule is getting picked up from backend " , well ,i would say that tracer should be able to tell you the same.

Coming to the study material, start with understanding caching and system pulse.

http://community.pega.com/node/966

https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm

https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm

https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm

https://community.pega.com/sites/default/files/help_v62/procomhelpmain.htm pulse


Show Less
Posted: 7 years ago
Posted: 17 Nov 2015 8:23 EST
Rasaiya Nadar (RasaiyaNadar) Accenture
Accenture
IN
Report

Thanks Shantanu for the quick reply.

It seems pretty helpfull, will go through this.

Need one more help, as we are not allowed to run tracer in production environment.

Is there a way to find which rule is getting picked up from backend ?
Posted: 7 years ago
Posted: 17 Nov 2015 11:44 EST
Mike Townsend (MikeTownsend_GCS) Director, Technical Support, Customer Service
Pegasystems Inc.
US
Report

Rasaiya,

Without tracing, I don't think so. So many rules are called at runtime that logging them would be impractical (there are rule resolution loggers you can turn on, but I wouldn't recommend doing it in production for very long because of the significant number entries written). If you suspect this is a caching problem (and it sounds like it may be) you should know, that the Rules Assembly cache from 6.2 isn't used at all in Pega 7. Now we use the VTable and ABA cache, depending on the rule type in question. Are you more interested in trying to unravel the issue on 6.2 (there were a number of caching HFixes that you would definitely want on that version) or understand what to look out for if it ever happens again on Pega 7?

Thanks,
Mike
Posted: 7 years ago
Posted: 18 Nov 2015 2:13 EST
Rasaiya Nadar (RasaiyaNadar) Accenture
Accenture
IN
Report

Thanks Mike for the reply ☺

understanding what to look out for if it ever happens again on Pega 7 is my first priority  right now. But later some time will prefer to look for the Pega 6.2 [Not in nearer future unless assigned to 6.2 application ☺]

It seems more like cache issue. What I am concerned about is that in my case it was simply noticeable from UI. What if it is not noticeable, like the case of wrong Activity or any other rule that is not visible from the UI is getting picked.

 

So wanted to build a utility that will tell me for a given access group which all rule will be picked by the system.

I tried to understand the content of the following table 

PR_SYS_CACHE_DEP, PR_SYS_CACHE_ENTRY, PR_SYS_CACHE_IMPL, PR_ASSEMBLEDCLASSES, PR4_RULE_SYSGEN,  PR_SYS_UPDATESCACHE, PR_SYS_RULE_IMPL. But did not found any luck/conclusion there. Got to know there were user specific cache.

 

There was an instance where for a similar ticket the PEGA person was trying to find the entry for a particular rule in PR_SYS_RULE_IMPL, and then did not found an entry there. So he added it from SMA and things started working properly for the same rule.

 

But I found instance where there were no entry in the same table still right rule getting picked up.

Even found instance where there were entry in the same tableand still wrong rule was getting picked up.

    

Show More

Thanks Mike for the reply ☺

understanding what to look out for if it ever happens again on Pega 7 is my first priority  right now. But later some time will prefer to look for the Pega 6.2 [Not in nearer future unless assigned to 6.2 application ☺]

It seems more like cache issue. What I am concerned about is that in my case it was simply noticeable from UI. What if it is not noticeable, like the case of wrong Activity or any other rule that is not visible from the UI is getting picked.

 

So wanted to build a utility that will tell me for a given access group which all rule will be picked by the system.

I tried to understand the content of the following table 

PR_SYS_CACHE_DEP, PR_SYS_CACHE_ENTRY, PR_SYS_CACHE_IMPL, PR_ASSEMBLEDCLASSES, PR4_RULE_SYSGEN,  PR_SYS_UPDATESCACHE, PR_SYS_RULE_IMPL. But did not found any luck/conclusion there. Got to know there were user specific cache.

 

There was an instance where for a similar ticket the PEGA person was trying to find the entry for a particular rule in PR_SYS_RULE_IMPL, and then did not found an entry there. So he added it from SMA and things started working properly for the same rule.

 

But I found instance where there were no entry in the same table still right rule getting picked up.

Even found instance where there were entry in the same tableand still wrong rule was getting picked up.

    

Looking for check point utility that the latest rule is getting picked for any given access group.

    

If i am able to understand the Vtable and ABA cache related table then I m sure there must be a way to find which rule is getting picked for a particular accessgroup. So also looking for any study material if available to understand the content of the cache table.


Show Less

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

Pega Collaboration Center has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice