com.pega.pegarules.session.internal.mgmt.base.ThreadUITransaction : ERROR: posted transaction id
com.pega.pegarules.session.internal.mgmt.base.ThreadUITransaction : ERROR: posted transaction id 'b2d8b446e6d056bc1a042ba9c1c9e45b' for frame 'pyWorkPage' DOES NOT match record '06ca6741b8d9a84e892dfde6c8865017'
1) When we will get this exception? what it means exactly?
This is a fairly complex topic, but the good news is that once you master the technique of analyzing this with Fiddler, the problem becomes fairly simple to isolate and resolve.
The pzTransactionID is an artifice used to keep the browser and the server in synch. Every time a new database transaction starts on the server, a new pzTransactionID is created and associated with that database Transaction.
In order for any POST request (like a reloadSection or a FinishAssignment) from the client to be accepted by the server, the client must send a pzTransactionID which matches what the server believes to be the current pzTransactionID. If there is a mismatch, the POST request is rejected, and you see the error message that you show above.
Very simplistically, this prevents an Application from posting something to the database, the user using the browser Back button to return to the previous screen, and resubmitting the same thing. After the first post, the database would commit the data and the pzTransactionID would change. Using the "back" button brings back the previous cached screen, with the (now stale) previous pzTransactionID. When the user tries to POST it again, it is rejected because the transaction id is incorrect.
Commits in flow processing happen automatically after FinishAssignment, and if you use Fiddler to capture the traffic, you will see that in the Response to a FinishAssignment, you usually will receive a new pzTransactionID. It is this ID that will be used in the subsequent POSTS by the Browser.
If you capture all of the traffic in Fiddler and then wait for the error to occur, extract the 2 pzTransactionIDs from the error message. You will almost always see both IDs in the Fiddler trace. It is then up to you to determine why the stale one was used instead of the new one. Common reasons are:
You have a UI action list which sends multiple POSTs, one of which is a FinishAssignment. All the requests will use the same pzTransactionID. If the FinishAssignment processes first, the other POSTS will get rejected because their ID is stale. You need to change your application to avoid the race condition. A timeline view of the concurrent POSTS will reveal the problem. And you should never have anything in a action list which comes after a FinishAssignment.
You have an activity on the server which does an explicit commit. This changes the pzTransactionID. Since you are doing this yourself and not allowing normal flow processing to handle the commit, the new ID is not passed back to the client. Hence the next POST fails, as it uses the old ID
These are almost the only 2 ways this type of issue occurs. But there are literally hundreds of ways you can get into one of those 2 ways. You will need to have some expertise in Fiddler to do the above analysis, but if you have that expertise, this is not a hard exercise to complete.
Almost always the problem is due to a bad design. There have been a few cases where it is due to a defect in the Pega code, but those defects have been very few and far between. It is a mistake to search the PDN, find one such fix, and ask for it. It is very unlikely to fix your issue. You must do the analysis first to determine the root cause.
There is no problem with configuring a FinishAssignment. The problem is if you configure other actions after that FinishAssignment (you should never do that), or if you have other actions which cause race conditions (as seen by using the FIddler timeline feature) which sometimes cause other UI actions which contain the same pzTransactionID being processed out of sequence (after the finishAssignment has changed the pzTransactionID).
Every single one of these scenarios will require you to come up with an individual solution, based upon the requirements and architecture of your application. There is no general solution I can provide to you.
It sounds as if you have not yet used Fiddler to actually capture the error and identify the problem scenario. Until you do that, there is no going forward.
We are also getting same exception when we click on refresh button. We have a case like user submits some updates in screen and wait for background process(Agent) completes. Until get updates, user click on refresh screen to see the new updates.
Once the agent resume case, we have clicked the refresh button. screen showing the exception as "This action is not allowed as it is outside the current transaction."
Please suggest any solution for this.
ERROR: posted transaction id 'a2f2b0ca7fe0454f512e8fd7588e3284' for frame 'pyWorkPage' DOES NOT match record 'c71e6871b27526eaa61042e1d8fc98ea' 1 Options Lines Per Page Number of Pages Presented