Refresh Interface after a!startProcess does not work

Question

Hi, 
 
 We have a simple interface wich contains a refresh button that triggers a a!startProcess() function (to update some fields in Db and then update fields in the GUI). 
 The interface is displayed from a RecordType view. 
 
 The process gets some data and then write simply the current datetime into an updated_on field in the table. 
 
 The problem we met is when we click on the button, the data are not refreshed (or works just the first time). 
 
 When we debug the variables in the interface we can see that the data are still the Old ones despite the fact the data are correct in the Db table. 
 
 If we click again and again, the data are never refreshed. 
 
 I've tried a lot of things : - add a counter in the interface to ensure the save is called when the process ended 
 - all the process nodes are well chained. 
 - I've deleted a lot of nodes in the process so that now it contains only 5 nodes (to be sure, to avoid the 50 nodes issues). 
 - I've created a little testing snippet example and all works fine in another environment (with a Site, a RecordType, a process, a simple Interface and the Vehicle CDT example). 
 Would you have any idea why this problem occurs ? 
 Regards

Mike Schmitt · Accepted Answer

So instead of using refreshAlways, we can just use refreshOnVarChange and pass in a new ri! variable to reference our refreshCounter from the parent. 
 a!localVariables(
 local!cdt: a!refreshVariable(
 value: a!queryEntity(
 entity: cons!AS_DSE_HISTORY,
 query: a!query(
 logicalExpression: a!queryLogicalExpression(
 operator: "AND",
 filters: {
 a!queryFilter(
 field: "history_id",
 operator: "=",
 value: ri!historyId,
 applyWhen: a!isNotNullOrEmpty(ri!historyId)
 ),
 }
 ),
 pagingInfo: a!pagingInfo(
 startIndex: 1, 
 batchSize: - 1,
 sort: a!sortInfo("history_id", true)
 )
 )
 ).data,
 
 refreshOnVarChange: {
 ri!refreshCounter
 }
 ),
 
 local!cdt, /* I just keep this local!var for the Example */
) 
 Then from the parent, instead of having the startProcess onRefresh re-call the expression rule, just pass the refreshCounter in during the original call to the ER in the interface. 
 buttons: {
 a!buttonWidget(
 label: "Update",
 icon: "refresh-alt",
 saveInto: {
 a!startProcess(
 processModel: cons!AS_PM_HISTO,
 processParameters: { projetId: ri!projetId },
 onSuccess: {
 /* a!save(
 local!history,
 rule!as_qe_getHistoryWithFilters(
 projectId: ri!projectId
 )[1]
 ), */
 a!save(
 local!refreshCounter,
 local!refreshCounter + 1
 )
 },
 onError: {
 }
 )
 },
 style: "SECONDARY"
 )
},

Rajesh Pamisetty · Answer

Hi Cedric, 
 Did you try using a!refresh Variable function on the data you are refreshing from DB?

Mike Schmitt · Answer

cedric01 said: Calling the ER from onSuccess 
 Check your ER. If you have any local variables in it, they're probably not set to "refresh always", and therefore won't automatically re-execute even when you think it should (i.e. when called in your onSuccess parameter). One way I've gotten around this in the past is to pass a refresh counter into the ER itself, so it only refreshes when i want it to. That gives you the additional advantage wherein you can just have your onSuccess paramter increment your refresh counter, and use the initial query done in your variable declarations (when applicable).

Mike Schmitt · Answer

you need to consider what the implications of any local variable declared through a!localVariables() is. 
 All variables declared using default settings (i.e. with no refreshVariable override) implicitly assumes that "REFRESH ON REFERENCED VAR CHANGE" will be ON, and that all other refreshes will be OFF. 
 In this way, a local variable works a LITTLE like the legacy LOAD() variables, except that those didn't even refresh on referenced variable change (making many desired operations harder, as they had to be manually refreshed no matter what). 
 The side effect of this is, when you set certain variables in an expression rule, you need to be careful that they wouldn't need to refresh in an interface context - AFAIK, even if you call the same ER multiple times in an interface, the way Appian flattens and caches the loaded data, it's treated as if it's one instance called (but will be re-run in any varying places it's called, but those places will still only call the same cached instance). 
 As I've said, the strongest way to handle this is to anticipate it and pass in a refresh trigger RI to your expression rule, and use it in the "REFRESH ON VAR CHANGE" paramter for some local variable, particularly in cases where refreshing one local variable will cause its value to change and cascade to any other local variable declarations in the rule.

Refresh Interface after a!startProcess does not work

Top Replies