posted transaction ID for frame DOES NOT match record
Hello,
using Pega 7.1.8.
While investigating slow request/response times in the Pega application. I saw the following error messages in the log files:
posted transaction id 'xxxxxx' for frame 'pyWorkPage' DOES NOT match record 'yyyyyyy'.
The values for 'xxxxxx' and 'yyyyyyy' are different on each log entry and are not linked between the lines...
I found this on the PDN but speaks of Pega 6.2 and the appropriate hotfix. (because I am using 7.1.8, I didn't think it was an issue)
Is this related / linked with the performance slowness (a symptom, cause or side-effect)?
performance slowness is best described as (click button and wait 3 - 5 seconds before a new subcase is created and new assignment shown)
***Updated by moderator: Lochan to add SR details***
Accepted Solution
Pegasystems
US
Hi,
As Rob mentioned, in his case the four actions in his set were dt (data transform), dt, flow action, dt, and the trans-id-mismatch error occured because the normal commit within the flow action changed the trans id, so the final dt generated an error when it attempted to use the old trans id.
Rob solved his particular problem by removing the final dt from the action set. However, another possible solution is to do the flow action last in the set so that the trans id only gets changed on the last action of the set. (I haven't yet investigated what the effect is of dividing actions into two or more sets all associated with the same button or link).
For others of you facing trans-id-mismatch errors, here's the steps that were used to track down this one that may help you:
1) Run fiddler until you catch the error. If intermittent behavior means you have to run fiddler for a week, make sure you tell fiddler to only save the last 1000 lines or so. Also, of course, make sure you tell fiddler to unencrypt https traffic if you're using https to connect to the application from the browser.
Hi,
As Rob mentioned, in his case the four actions in his set were dt (data transform), dt, flow action, dt, and the trans-id-mismatch error occured because the normal commit within the flow action changed the trans id, so the final dt generated an error when it attempted to use the old trans id.
Rob solved his particular problem by removing the final dt from the action set. However, another possible solution is to do the flow action last in the set so that the trans id only gets changed on the last action of the set. (I haven't yet investigated what the effect is of dividing actions into two or more sets all associated with the same button or link).
For others of you facing trans-id-mismatch errors, here's the steps that were used to track down this one that may help you:
1) Run fiddler until you catch the error. If intermittent behavior means you have to run fiddler for a week, make sure you tell fiddler to only save the last 1000 lines or so. Also, of course, make sure you tell fiddler to unencrypt https traffic if you're using https to connect to the application from the browser.
2) From the time stamp in the Pega log file on the trans-id-mismatch error, which appears as "posted transaction id 'bad-num' for frame 'pyWorkPage' DOES NOT match record 'good-num'" , find the error-record in the fiddler file. It will likely show a response from the server saying "This action is not allowed as it is outside the current transaction".
3) In the inspectors > webforms display in fiddler for that error-record, you can verify that the pzTransactionId field shows bad-num when it should have showed good-num , since in a recent previous record in fiddler, you'll see that good-num was returned as the new pzTransactionID.
4) By highlighting fiddler records in this portion of the fiddler file and choosing Timeline, you'll be able to see that the multiple actions involved were sent to the server within milliseconds of each other.
General guidance about trans id's: When pzTransactionID is passed from the browser TO the server on a transaction, a trans-id-mismatch error is returned if the id is wrong. Any commit that occurs during the transaction, typically because the transaction is the submit of a flow action, will cause the trans-id to change. The pzTransactionID passed back from the server to the browser will show the new trans-id, and that needs to be the one passed to the server on subsequent transactions.
/Eric
Pegasystems Inc.
US
Hi Rob,
Regarding the PDN article SA-27799, BUG-262640 bug has been raised and it has been fixed in v7.2.2 release. So you can raise an SR, so that support team will work on it to provide fix for v7.1.8. Hope this might be helpful to you.
Regards,
Mahesh
Serialized Solutions Inc
CA
@mahesh86
Thank you for the response. I have created an SR to get the hotfix for 7.1.8. I will keep you posted.
thanks,
Rob
Pegasystems Inc.
IN
Hey Rob!
Do you mind letting us know the SR number? This would help us track this post to resolution!
Regards,
Lochan | Community Moderator | Pegasystems Inc.
Serialized Solutions Inc
CA
Feedback from GCS regarding this bug stems from the behaviour related to multiple actions within an action set.
In our case, we had multiple actions as follows:
- Data Transform
- Data Transform
- Local action
- Data Transform
The local action resulted in a commit which results in Pega generating a new transaction ID. With the Data transform logic, the request sent (in item 4 above) is not updated with the new transaction ID (assumption is that the 4 calls are "pre-loaded" with the data to be sent and thus the associated transaction ID as part of the "pre-loaded" request is not updated prior to executing -- which happens immediately after item 3 call returns) that Pega is expecting.
For our scenario, the removal of the Data Transform in item 4 resulted in the message not being posted.
Pegasystems Inc.
IN
Hi Rob,
Thank you for the update! I will mark this post Answered.
Regards,
Lochan | Community Moderator | Pegasystems Inc.
Accepted Solution
Pegasystems
US
Hi,
As Rob mentioned, in his case the four actions in his set were dt (data transform), dt, flow action, dt, and the trans-id-mismatch error occured because the normal commit within the flow action changed the trans id, so the final dt generated an error when it attempted to use the old trans id.
Rob solved his particular problem by removing the final dt from the action set. However, another possible solution is to do the flow action last in the set so that the trans id only gets changed on the last action of the set. (I haven't yet investigated what the effect is of dividing actions into two or more sets all associated with the same button or link).
For others of you facing trans-id-mismatch errors, here's the steps that were used to track down this one that may help you:
1) Run fiddler until you catch the error. If intermittent behavior means you have to run fiddler for a week, make sure you tell fiddler to only save the last 1000 lines or so. Also, of course, make sure you tell fiddler to unencrypt https traffic if you're using https to connect to the application from the browser.
Hi,
As Rob mentioned, in his case the four actions in his set were dt (data transform), dt, flow action, dt, and the trans-id-mismatch error occured because the normal commit within the flow action changed the trans id, so the final dt generated an error when it attempted to use the old trans id.
Rob solved his particular problem by removing the final dt from the action set. However, another possible solution is to do the flow action last in the set so that the trans id only gets changed on the last action of the set. (I haven't yet investigated what the effect is of dividing actions into two or more sets all associated with the same button or link).
For others of you facing trans-id-mismatch errors, here's the steps that were used to track down this one that may help you:
1) Run fiddler until you catch the error. If intermittent behavior means you have to run fiddler for a week, make sure you tell fiddler to only save the last 1000 lines or so. Also, of course, make sure you tell fiddler to unencrypt https traffic if you're using https to connect to the application from the browser.
2) From the time stamp in the Pega log file on the trans-id-mismatch error, which appears as "posted transaction id 'bad-num' for frame 'pyWorkPage' DOES NOT match record 'good-num'" , find the error-record in the fiddler file. It will likely show a response from the server saying "This action is not allowed as it is outside the current transaction".
3) In the inspectors > webforms display in fiddler for that error-record, you can verify that the pzTransactionId field shows bad-num when it should have showed good-num , since in a recent previous record in fiddler, you'll see that good-num was returned as the new pzTransactionID.
4) By highlighting fiddler records in this portion of the fiddler file and choosing Timeline, you'll be able to see that the multiple actions involved were sent to the server within milliseconds of each other.
General guidance about trans id's: When pzTransactionID is passed from the browser TO the server on a transaction, a trans-id-mismatch error is returned if the id is wrong. Any commit that occurs during the transaction, typically because the transaction is the submit of a flow action, will cause the trans-id to change. The pzTransactionID passed back from the server to the browser will show the new trans-id, and that needs to be the one passed to the server on subsequent transactions.
/Eric
Pegasystems Inc.
IN
Hi Eric,
Thank you for adding value to this discussion.
Regards,
Lochan | Community Moderator | Pegasystems Inc.