Question
Virtusa
US
Last activity: 17 Jul 2017 16:33 EDT
Why are the Rule-Application and Rule-Ruleset-Name forms distorted in Pega 7?
RULE-APPLICATION
RULE-RULESET-NAME
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Virtusa
US
Thank you all for your responses.
One of the issue on RULE-RULESET-NAME is now resolved.
Root Cause of the issue was related to CSS file missing. Gnerated the CSS back and it is working fine.
Did Revalidate and save on pzDesignerStudio skin.
Rule-application has a different issue, working with pega.
Thanks,
Khareem
Pegasystems
US
I've experienced the same UI in your second screenshot yesterday when i was in the train with a very spotty internet connection. This looks like the skin style-sheet was not loaded properly. Do you get the same screen all the time? Do all users get the same distorted screen ?
Pegasystems
US
I've noticed this from time to time as well. Things I suggest checking:
- Compare fiddler output between good one and bad. If different, track the difference back to a rule or piece of logic on the server.
- If fiddler output is the same, focus more on browser side. Compatibility mode ?
- What happens if you clear browser cache ?
- What happens with different browser ? ie ? chrome ?
- HEY ! How do I get out of bullet list here in the mesh (on ie).
- I'm hitting enter key without typing anything on the line and I still get another dot . . .
Pegasystems Inc.
GB
Hi Khareem,
Just to make sure we understand the scope of the issue - can you double-check the simple table below - and confirm (or otherwise) this is accurate ?
| Number of Users Affected | Number of Screens Affected | When did it start happening ? |
|---|---|---|
| ALL DEVELOPERS | ONE SCREEN ONLY | UNKNOWN |
From the screenshot you provided - I agree with other replies to this post - that a likely cause of such a screen distortion is CSS-related.
So I would go with Eric's suggestions : and also suggest a couple more tests:
1. Check your App Server HTTP logs for HTTP errors - in particular do you have any HTTP 404 errors? (Make sure you repeat the test scenario).
If you are on Tomcat - you might need to enable your HTTP logs : Instructions are available on the web for this - for instance : http://stackoverflow.com/questions/3017188/java-tomcat-standalone-how-to-log-access-all-the-http-get-requests
2. Run a PRPC TRACER - enable Stream Rules - and trace the opening of the Screen(s?) in question - save a copy of the TRACER XML.
Hi Khareem,
Just to make sure we understand the scope of the issue - can you double-check the simple table below - and confirm (or otherwise) this is accurate ?
| Number of Users Affected | Number of Screens Affected | When did it start happening ? |
|---|---|---|
| ALL DEVELOPERS | ONE SCREEN ONLY | UNKNOWN |
From the screenshot you provided - I agree with other replies to this post - that a likely cause of such a screen distortion is CSS-related.
So I would go with Eric's suggestions : and also suggest a couple more tests:
1. Check your App Server HTTP logs for HTTP errors - in particular do you have any HTTP 404 errors? (Make sure you repeat the test scenario).
If you are on Tomcat - you might need to enable your HTTP logs : Instructions are available on the web for this - for instance : http://stackoverflow.com/questions/3017188/java-tomcat-standalone-how-to-log-access-all-the-http-get-requests
2. Run a PRPC TRACER - enable Stream Rules - and trace the opening of the Screen(s?) in question - save a copy of the TRACER XML.
3. Run a FIDDLER (or similar) test - suggest you perform a full Browser Cache clear before doing this: and save a copy of the .saz file.
NOTE: run the FIDDLER and PRPC TRACER tests *separately* - the TRACER will genereate a lot of HTTP requests and pollute your FIDDER.
4. Run the following SQL - 'spool' the output to txt or csv:
SELECT * from pr4_rule where pzInsKey like '%PZCSS%';
So you should end up with the following artefacts - all spanning a time where you re-tested the scenario:
1. HTTP logs from the App Server.
2. PRPC Tracer File.
3. A FIDDLER Trace
4. A list of CSS-related rows from the back-end DB table pr4_rule.
I would suggest once you have these artifacts - contact GCS support and open an SR - provide the artifacts above - along with the PRPC Log file.
PEG
GB
-Check if the issue is happening after authentication timeout.
-Is this specific to opening some rule type? Check wich Pega thread is used by looking at the Pega thread in the url send by the client using Fiddler.
If a wrong Pega thread name is used (ie a Pega thread which does not exist yet) then you can get all sorts of issue like this.
Pegasystems
US
What Pega version are you using ? A customer using Pega 7.1.6 with Tomcat for Pega server and Apache for load balancing experienced a similar issue. The issue was temporarily fixed by clearing the cookies from the web browser’s cache. The issue was patched in 717.
Pegasystems Inc.
US
You will need HFix-21764 if you are on PRPC 7.1.7. If you are on another earlier version you will have to request a port of this fix. This is a really simple fix as well.
This fix resolves an issue with multiple Pega-RULES cookies being added to requests when using a load balancer, proxy, Cisco F5 etc. There was code incorrectly storing a Pega-RULES cookie at the browser cache level when header names were being modified by traffic components. When you logoff and log back in the file cookie would start to be used after it matched a specific URL. Then you ended up having two Pega-RULES cookies being set with each request to PRPC, one the old requestor value and one the current one. The issue starts to occur when PRPC server reads the old cookie value to static content request.
We use SESSION cookies, not browser level cookies, so this was causing problems. It's also why clearing cookies from the web browser's cache can resolve the problem, for a bit. You should never have to clear browser cookies with PRPC as we only ever should be using SESSION cookies. This has been corrected with this patch.
There is more information in SA-8960.
These types of screen distortions are 100% caused by this issue and is easily replicated with the correct setup. I can for instance replicate this issue in house using WebSEAL, which acts like a proxy server, very easily.
Accepted Solution
Virtusa
US
Thank you all for your responses.
One of the issue on RULE-RULESET-NAME is now resolved.
Root Cause of the issue was related to CSS file missing. Gnerated the CSS back and it is working fine.
Did Revalidate and save on pzDesignerStudio skin.
Rule-application has a different issue, working with pega.
Thanks,
Khareem
ASB
NZ
Hi Khareem.
How did you do the Revalidate and Save? We are on 7.19 and have the same issue but i can't Revalidate and Save because the system will not give me the option of doing this with any Pega ruleset. I can only do it with my application rulesets.
Matt
Pegasystems Inc.
US
Now that Support Articles can be linked to on the PDN, here's a link to the Multiple Pega-RULES cookies with different values article mentioned in this thread.
Unitedhealth Group, Inc.
US
Would you say this is something all PRPC 7.1.7 instances [which are using an F5] should have? (We have a couple...)
This thread seems to talk more about the screen distortions -- something I think I've seen -- but the Support Article focuses more on the cookies aspect only (while that may be the cause, there seems to be more to the "errors to be displayed" than reported)
Also, it sounds like Chris Koyl says this always happens -- is that true? That is, if I'm not seeing this regularly, I shouldn't be worried...