Question
TATA CONSULTANCY SERVICES
US
Last activity: 17 Jul 2017 16:44 EDT
Question on Number of Rules that can be migrated to a Production Environment.
Does Pega provide any recommendation on the limit of Number of Rules that we can migrate to a Production Environment ? Reason I ask is that after a recent Rules Migration by a Project to Production environment we had observed multiple issues (like HUNG Threads in JVM's, long running Pega OOTB SQL queries, performance issues, etc). Reference SR#s raised for this issue: SR-A1076 , SR-A1156 . So, finally to circumvent the issue we had to Truncate the Pega cache Tables, Cleared Pega temp directories & Recycled the Servers.
***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.
Pegasystems
US
TATA CONSULTANCY SERVICES
US
Hi Eric,
Your explanation defiently adds up to the situation. Our CPM Portal is used 24X7 by the users & if the related rules which are being migrated accessed by users can cause these type of issues.... I think one of the way to fix this is...not to expose the RULES which are being migrated to the users untill the import & testing completes. (May be this can be achieved by using some kind of 2 db schemas... 1 schema which users point to, 1 schema for importing rules & once testing completes on second schema the users can be switched to the later one.)
Meshies.. Still the question on Number of Rules that can be imported is a Open question. Please share your thoughts/experiences.
Thanks
Hari
Pegasystems
US
Here’s the specific issue we had and how we solved it:
We were importing a trigger rule and a concomitant when-rule, plus the activity the trigger rule would call if the when-rule asserted true.
The trigger was designed to fire whenever a work object was saved, which of course could easily happen during the import process, due to SLA’s running.
We got errors because the trigger fired before the when-rule was imported yet (or maybe it was the activity that was not yet imported).
Anyway, whichever it was, the solution was fairly simple. We merely divided our zip into two zips. We first imported the “rules” zip that contained the when-rule and the activity. THEN we imported the “triggers” zip. That way, by the time the trigger rule was imported, even if it fired almost immediately, the when-rule and activity were already safely imported with sleeves rolled up and ready to work.
/Eric
Asurion
US
Hi Eric,
can we do like this , Even if we import new rule, Rule resolution will pick it only if the application points to that version. we can change the application instance to point the new version after import is done.
I don't know of any limit on number of rules, but if you are migrating rules to production while either SLA activities or interactive users are using related rules to the ones being migrated,issues can occur. For example, suppose you already had activity A which is called by an SLA, and you are importing an updated version of activity A which calls brand new rule-utility-function F, it is quite possible that the new A will be referred to by an SLA while the import is happening but before the required F is imported, and that reference to A will cause it to be assembled, which will generate an error because F is not defined yet. /Eric