When rule exception at table layout
Hi,
We have a when rule at edit options of column in a table layout. When rule class is same as class of table (-Transaction). Section is different class (-Order). There is an activity GetFirstSGKDebt onChange Event of the coumn. Inside the activity there is an soap service call activity. When disable this service call activity and enter something, the is no problem, when rule check is being done perfectly.
But whenever we enable service call activity and soap service receives error, then when rule can't find by pega, and we recieve Error exception at the screen, and user must reenter the case. We do error handling soap errors and exceptions, later we cleared the error message but nothing is changing. As you see at the tracer screenshot pega is trying to find when rule at -Order class, not the correct -Transaction class.
Read only is working when we use expression instead of when rule. But the problem is we have around 15 columns and we have many read only conditions, and plus we have many tables according to process types. It will create problems when reading read only options, and trying to add new logics. What is the reason for the problem and what should we do?
Product: Pega Infinity '24.1
Accepted Solution
Updated: 30 Jul 2025 8:52 EDT
ai4process ltd
GB
I understand the confusion of dealing with SOAP calls and nested lists. However it seems the core issue still stems from the use of 'Refresh-Section', which continues to cause the context switching and breaks the rule resolution.
Even if you've moved the activity to the -Transaction class, the moment you trigger a section refresh, Pega re-evaluates the context based on the section's class (-Order), not the row's class.And as you have mentioned the -Order is also a list, which is again adds the complexity of context management for FAURuleAssembly.
When working with Table/ Lists, when you are configuring actions on columns, its always recommended to avoid refresh-section because the refresh-section will switch the context from table's context to section context.
-
Your top-level section renders a table for
OrderList(class-Order). -
Inside each row of
OrderList, you're rendering a nested table forTransactionList(class-Transaction). -
When you trigger a Refresh-Section from within a
TransactionListrow, Pega re-evaluates the section from the top-level context (-Order), not the row-level (-Transaction).
I understand the confusion of dealing with SOAP calls and nested lists. However it seems the core issue still stems from the use of 'Refresh-Section', which continues to cause the context switching and breaks the rule resolution.
Even if you've moved the activity to the -Transaction class, the moment you trigger a section refresh, Pega re-evaluates the context based on the section's class (-Order), not the row's class.And as you have mentioned the -Order is also a list, which is again adds the complexity of context management for FAURuleAssembly.
When working with Table/ Lists, when you are configuring actions on columns, its always recommended to avoid refresh-section because the refresh-section will switch the context from table's context to section context.
-
Your top-level section renders a table for
OrderList(class-Order). -
Inside each row of
OrderList, you're rendering a nested table forTransactionList(class-Transaction). -
When you trigger a Refresh-Section from within a
TransactionListrow, Pega re-evaluates the section from the top-level context (-Order), not the row-level (-Transaction). -
This happens because the section being refreshed belongs to
-Order, and Pega doesn’t retain the nested row context during the refresh. -
As a result, When rules and other logic tied to
-Transactionfail to resolve correctly, leading to the exception you're seeing.
This behavior doesn’t surface when working with a single-level list like OrderList, because the context remains consistent. But in nested scenarios, Refresh-Section overrides the row context with the parent table’s context, which is why you're seeing the rule resolution error.
Recommendation:
To avoid this issue, it's strongly recommended to use Refresh-Current-Row instead of Refresh-Section. This ensures:
-
The refresh is scoped to the row where the event originated.
-
The context remains tied to the correct class (
-Transaction). -
Rule resolution and UI updates behave predictably.
I understand switching all SOAP calls to Data Pages may be a heavy lift, but combining that with Refresh-Current-Row will give you a much more stable and scalable solution. If you dont want to move to a Data page, alternatively you can also invoke the Activity which is performing your SOAP call directly using the 'Run Activity' action. you can move the activity to -Transacction class.
Let me know if you'd like help designing a reusable pattern for nested lists with stable refresh behavior.
Updated: 29 Jul 2025 16:25 EDT
ai4process ltd
GB
There are too many context switches are happening on a single Operation/ Thread.
For instance, your section which is on Class- 'Data-Order' but the Table is rendered using a List of class 'Data-Transaction', where you are performing a Refresh-Section which is running Running an Activity- and as you are refreshing a section, the Activity now switches its runtime context to 'Data-Order' where your Activity is residing and during this operation, when an API call is being made, there is an Integration layer context involved 'Int layer classes' where Parsing and Streaming of XML happening for SOAP operation.
Below are the alternate approaches that you can try-
Approach # 1: If the API response does not have an impact on the UI
1. Invoke an API call using a Data page instead of an Activity with Connect SOAP Method. as irrespective of the Context, as due to the nature of data pages being decalrative, context switching doesnt happen when API is invoked.
2. If UI is independent from the API response, I suggest invoking the Data page asynchronously or even pushing the API call to a Queue and processing it in teh background.
Approach #2: If the API response has an impact on the UI
There are too many context switches are happening on a single Operation/ Thread.
For instance, your section which is on Class- 'Data-Order' but the Table is rendered using a List of class 'Data-Transaction', where you are performing a Refresh-Section which is running Running an Activity- and as you are refreshing a section, the Activity now switches its runtime context to 'Data-Order' where your Activity is residing and during this operation, when an API call is being made, there is an Integration layer context involved 'Int layer classes' where Parsing and Streaming of XML happening for SOAP operation.
Below are the alternate approaches that you can try-
Approach # 1: If the API response does not have an impact on the UI
1. Invoke an API call using a Data page instead of an Activity with Connect SOAP Method. as irrespective of the Context, as due to the nature of data pages being decalrative, context switching doesnt happen when API is invoked.
2. If UI is independent from the API response, I suggest invoking the Data page asynchronously or even pushing the API call to a Queue and processing it in teh background.
Approach #2: If the API response has an impact on the UI
Instead of performing a Refresh Section, change the Action set to--> Run Data transform (running a Data transform on Data-Transaction context.) and Refresh Row (instead of a Section). In this appraoch the DT will be executed on the Primary page, which is the Current Row of the list, and the end of DT can have a flag set onto the Current Row item and your Table can use this flag to conditionally render the column.
Let me know your thoughts on the approach and update if any of those approaches work
Softtech
TR
@RaviChandraThank you for the response. We put run activity method directly at -Transaction Class like at the ne screenshot 2, and remove -Order activity as at new screenshot. But the problem didn't change. Strange thing is Pega is at correct context (.TransactionList(1)) when exception thrown and why Pega is not searching in that context but going up to upper context suddenly and receives exception. We put Primary steppage at last step of -Transaction activity, to return to correct context if it is lost, but didn't change the result.
After soap calls we are updating -Transaction data at clipboard and according to them we are showing / hiding other columns. We have similar 6-7 different soap calls with activity in other columns, and changing all of them to Data Page can be difficult, but we can try it as last hope.
I tried similar soap errors at -Order class Order List, and that exception situation didn't happen. TransactionList is inside each element of OrderList, and it seems second level lists have such a bug.
Accepted Solution
Updated: 30 Jul 2025 8:52 EDT
ai4process ltd
GB
I understand the confusion of dealing with SOAP calls and nested lists. However it seems the core issue still stems from the use of 'Refresh-Section', which continues to cause the context switching and breaks the rule resolution.
Even if you've moved the activity to the -Transaction class, the moment you trigger a section refresh, Pega re-evaluates the context based on the section's class (-Order), not the row's class.And as you have mentioned the -Order is also a list, which is again adds the complexity of context management for FAURuleAssembly.
When working with Table/ Lists, when you are configuring actions on columns, its always recommended to avoid refresh-section because the refresh-section will switch the context from table's context to section context.
-
Your top-level section renders a table for
OrderList(class-Order). -
Inside each row of
OrderList, you're rendering a nested table forTransactionList(class-Transaction). -
When you trigger a Refresh-Section from within a
TransactionListrow, Pega re-evaluates the section from the top-level context (-Order), not the row-level (-Transaction).
I understand the confusion of dealing with SOAP calls and nested lists. However it seems the core issue still stems from the use of 'Refresh-Section', which continues to cause the context switching and breaks the rule resolution.
Even if you've moved the activity to the -Transaction class, the moment you trigger a section refresh, Pega re-evaluates the context based on the section's class (-Order), not the row's class.And as you have mentioned the -Order is also a list, which is again adds the complexity of context management for FAURuleAssembly.
When working with Table/ Lists, when you are configuring actions on columns, its always recommended to avoid refresh-section because the refresh-section will switch the context from table's context to section context.
-
Your top-level section renders a table for
OrderList(class-Order). -
Inside each row of
OrderList, you're rendering a nested table forTransactionList(class-Transaction). -
When you trigger a Refresh-Section from within a
TransactionListrow, Pega re-evaluates the section from the top-level context (-Order), not the row-level (-Transaction). -
This happens because the section being refreshed belongs to
-Order, and Pega doesn’t retain the nested row context during the refresh. -
As a result, When rules and other logic tied to
-Transactionfail to resolve correctly, leading to the exception you're seeing.
This behavior doesn’t surface when working with a single-level list like OrderList, because the context remains consistent. But in nested scenarios, Refresh-Section overrides the row context with the parent table’s context, which is why you're seeing the rule resolution error.
Recommendation:
To avoid this issue, it's strongly recommended to use Refresh-Current-Row instead of Refresh-Section. This ensures:
-
The refresh is scoped to the row where the event originated.
-
The context remains tied to the correct class (
-Transaction). -
Rule resolution and UI updates behave predictably.
I understand switching all SOAP calls to Data Pages may be a heavy lift, but combining that with Refresh-Current-Row will give you a much more stable and scalable solution. If you dont want to move to a Data page, alternatively you can also invoke the Activity which is performing your SOAP call directly using the 'Run Activity' action. you can move the activity to -Transacction class.
Let me know if you'd like help designing a reusable pattern for nested lists with stable refresh behavior.
Softtech
TR
@RaviChandraHi Ravi, Thank you very much all the information, we realized that in the service activity there is a method Page Change Class. It seems this the problem root. We will remove it and try again. And we will use your recommendation and use Refresh Current Row method, instead of refresh section.