Applies to Pega Platform versions 7.2 through 8.5

Symptoms
Errors
Explanation
Suggested Approaches for debugging and enabling loggers
Solutions

Symptoms

Your logs show the Transaction ID mismatch error. You might also see an on-screen error.

Various scenarios can cause these errors as described in Explanation and Solutions.

Errors

This action is not allowed because it is outside the current transaction.

posted transaction id 'b0250000f1e7a68ef6ee7d63f84e090a' for frame 'pyWorkPage' DOES NOT match record '4cc556af3f0ac03a9966098316ad0d42'

posted transaction id '{pzTransactionId_2}' for frame 'historyFrame' DOES NOT match record

Explanation

To prevent the use of the browser Back button during workflow processing in Pega applications, the Transaction ID is generated when a Commit is performed. However, multiple requests and responses can complicate UI behavior and interfere with the transaction-safe UI for which Transaction ID is intended. Stale work or errors processing work can result.

Transaction ID generation when a Commit is performed is achieved with frame-name (pzFromFrame) rather than transaction-id (pzTransactionId) mapping.

Here is an example to illustrate this mapping and the logic for three request scenarios:

1. Request 1: The browser sends the pzFromFrame parameter as pyWorkPage in the processing of flow if a Commit state is reached and data is committed to the database. A transaction-id T1 is generated and markup is generated with transaction-id T1.
2. Request 2: When a user clicks on a button to process the flow, the incoming request server receives pzFromFrame as pyWorkPage and transaction-id T1. The transaction-id matches, and the Pega engine processes the desired activity. If the user performs an explicit Commit in this activity, the Pega engine generates a new transaction-id, for example, T2. Now the mapping is updated with T2 for pyWorkPage frame, but this transaction (T2) is not be updated in the UI.
3. Request 3: The user clicks another button to process the flow, a button different from the button clicked for Request 2. This action sends pyWorkPage as pzFromFrame and T1 as the transaction-id. The UI sends the transaction-id T1 because transaction-id T2 is not reflected in the UI, as explained for Request 2. Because transaction-id T2 is not known to the UI, the Pega engine performs validation on transaction-id, expecting T2, and throws a validation error for T1.

This action is not allowed because it is outside the transaction.

The error message displayed on the screen is not informative. It does not explain what went wrong and how to correct the problem because the issues related to mismatched Transaction IDs manifest themselves in many ways and there is no one root cause. Therefore, you need to debug using Fiddler or, for deeper root cause analysis, enable loggers in the Pega engine.

Suggested Approaches for debugging and enabling loggers

Debug or enable Pega engine loggers to discover the conditions identified in Solutions.

Debugging

1. Run Fiddler to catch the error.
2. Run the flow.
3. Find the error response in the Fiddler network trace.
4. Examine the previous requests in Fiddler and find the request with a good transaction-id and an activity or action that could have resulted in the generation of a new transaction-id.
5. Identify which activity is doing an explicit Commit and fix it by removing the step or reorder the UI actions by moving the action to the last step of the activity.

If you cannot identify the issue using the steps above, use the Fiddler network trace and the Pega engine loggers to identify the root cause of your Transaction ID problem.

Enabling Pega engine loggers

Enable the following loggers:

• com.pega.pegarules.session.internal.mgmt.base.ThreadUITransaction
• com.pega.pegarules.session.internal.mgmt.base.ThreadUITransaction$CommitStackTraceLogger

This second logger helps in printing out the stack trace of the activity that is performing an explicit Commit in the flow processing.

Solutions

Best Practice: Upgrade or update to the latest Pega Platform Patch Release, as prescribed: Keeping current with Pega

Ensure that your flow processes are designed to avoid the following conditions that cause mismatched Transaction IDs.

After debugging or enabling Pega engine loggers, you discover that one or more of the following conditions cause the problem:

• The FinishAssignment activity should occur as the last step in the flow process, after all the configured actions are completed.

Solution: In several Pega Platform Patch Releases, code was corrected to ensure that the Finish Assignment activity is started after all the events are processed. Apply the best practice of upgrading to the latest Pega Platform Patch Release.

• An explicit Commit occurs during the activity that causes the transaction-id to change.

Solution: Avoid this condition by using the option Obj-Save with Queue immediately in the activity.

• Synchronization issues occur between the server and the UI. For example, onClick of a button, if the actions are data-transform execution, flow-action execution, and another data-transform execution, if the second flow-action commits and changes the transaction-id, the next data-transform fails.

Solution: Avoid these synchronization issues when you design flow processes involving data-transform execution, flow-action execution, and another data-transform execution.

On the Resolved Issues page, search for Transaction ID to see the resolved issues for various releases of the Pega Platform.

For additional information, see the Support Articles that were derived from cases reporting mismatched Transaction IDs. Here are a few examples:

SA-14848 Action is not allowed as it is outside the current transaction

SA-25409 Action is not allowed as it is outside the current transaction

SA-94301 Transaction ID mismatch error occurs on submitting a form

SA-32400 Restrict users from clicking the link multiple times