When the extract marker is deleted and the Pega software starts, the absence of that file causes the function libraries to be rebuilt.
If you did find a way to delete the marker from an activity, are you expecting the deletion to cause the function libraries to immediately be rebuilt even while the Pega software is running ? Or is your intent that you would delete the marker with your activity such that the next time Pega starts, the libraries would be rebuilt ? /Eric
we have been deleting the marker file and restarting the application for major deployments (involving lot of instances) done in pega, the reason is that the development teams had complained in the past that after code deployment they do not see the new rules that have been moved, the new rules are not considered in the rule resolution and few more reasons that i don't remember (we tried clearing the cache in SMA but it didn't fix the issue in most the situations). So it became a standard thing to clear the marker file and restart the application after major deployments.
we have security restrictions in our organization that does not allow us to delete the marker file in higher environments, we have to create a ticket and reach out to another team for the file deletion, since this is time consuming i wanted to know if there is any shortcut to do the file deletion.
>>> we have security restrictions in our organization that does not allow us to delete the marker file in higher environments
The security restrictions are either a good thing or a bad thing. If they are a good thing, then you shouldn't be allowed to delete the marker, regardless of whether it is manually or by an activity. If they are a bad thing, the restriction should get lifted so you are allowed to delete the marker.
Putting it another way, it is not a good idea to have an activity or any other sneaky way to get around a security restriction. It will either cause trouble or get you in trouble. /Eric
>>> the development teams had complained in the past that after code deployment they do not see the new rules that have been moved, the new rules are not considered in the rule resolution
That should not occur. Here are some things to check:
1) If the rule is an activity rule or a rule-application (and some other rule types), it is controlled by the in-memory "vtable" that is updated by the pulse. So it is normal that it takes up to 60 seconds for the deployed activity to be "seen" on other nodes, since the pulse agent runs every 60 seconds.
2) Use the SMA main screen, info screen, and agent screen, to make sure the pulse agent is running on the node on which you are not seeing the deployed rules. The pulse agent is supposed to run on all nodes, every 60 seconds.
3) If the rule is a section rule and is sometimes not being seen after deployment, and you are using a db of type mssql (as opposed to oracle or db2), and you are on Pega 7, a recently-issued hot fix may be applicable for you. The issue was that during deployment, all the db shortcut records that referred to the old rule were supposed to be deleted but only 50 of them were being deleted (due to an inadvertent maxlimit of 50 being applied to the db deletion directive). Again, this issue only occurs on the mssql db type, and is solved by the hot fix.
4) If you are observing newly deployed rules failing to be "seen" or "picked up" after checking the above, we in Pega GCS would like to help you track down the issue. However, to do that, we need to have the Pega temp folder and db cache table entries intact and available, so if you habitually clear those out as a workaround for the issue, it may not be possible for us to assist in tracking down the issue.
It's a crude mechanism and I have advised our team that it is not in fact necessary to do this for most moves. Running revalidation is more important.
This whole mechanism in Pega needs to be overhauled. SMA should not be so complex to wade through. Within the engine, it should be easy enough to provide visibility into which rule is in the cache(s), in the classLoader directly from the ruleform. I raised this point earlier in the year: