Hi,
Discussion posts and replies are publicly visible
Have you applied Channing in the process called under a!startprocess , please do the channing till the db update.
yes, Komalj, as I've wrote all nodes are chained.
It is like if the interface does not succeed to get the fresh data from the Db.
Like a cache issue.
If I close the interface and then reopen it, the data are correct.
Does onSuccess() really executed after the last process node (on the end event) ?
I've finally found a solution:
Using pv!processInfo to get back the last updated data.(Calling the ER from onSuccess() event does not work)
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).
Thank you Mike for your tips. My ER were indeed containing a local!variable.After setting this one to Refresh always = True, it works fine.But is it not a little tricky ? It means any ER without localvariable works like in an implicit always-refresh mode, and when you add a localVar, it works as a default NOT refresh-always mode.
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.
That's very interested.Mike, would you have a little example of what you are describing please ?I'm not sure to understand what type to pass to the ER, and how to configure refreshvariable in ER or Interface.
Sure - if you can post the code for `as_qe_getHistoryWithFilters()` (or a slightly simplified version of it, it doesn't need to be working etc, just need to see the structure), i'll post the revised version i'd suggest which should make it refresh only when triggered from the calling parent interface.
Here it is:
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, refreshAlways: ri!refreshAlways ), local!cdt, /* I just keep this local!var for the Example */ )
May I ask the question of what purpose this local variable has? You can just leave it away and avoid the hassle with the refreshes.
Stefan, I add a little comment to my code, to avoid you to ask this question ;-)this local variable will be used for an updateDictionary needs.
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" ) },
Thanks a lot Mike, I understand better now
I have another refresh problem in exactly the same context (same interface).In this screen I have a button displayed by a Related action.The visibility of that action is linked to the data described above.Now my data are well refreshed, why this button is not refreshed too ?(of course, if I close and reopen the interface back, the button is hided) Is there any way to trigger the refresh of the underlying Record Type?
cedric01 said:button displayed by a Related action.
Can you clarify a bit what you mean by this exactly?