Hi Khuong, tq

I have put the commit, with no luck:

Actually, this is only a simple go to the other screen, although i update the status for closing a human activity by updating a record:

regards

Hi Indra,

First try using RedirectToURL instead.

Another approach is wrap table widget with IF widget and show table when IsDataFetched = True.

If both way not working then just try a simple screen update value and using Destination to go to a List (table widget) as your case but not related to any BPT. If issue still (not refresh when navigation by using Destination as end node) then I think it seems a bug.

Regards,

Khuong

Hi, Truong, thanks

I tried the RedirectURL, but fail also.

regards

Hi Valente,

But it is refreshed when i clicked the refresh button (near the URL input in the browser).

regards and thanks

Thank you for checking.

If you have the fetch at start, then please don't refresh data in an event like OnReady or Init. 

The Commit Transaction is also not necessary.

Your code works on the Sample Accounts Databse, so it has to be the fact you are updating a (human)  Activity, which has triggers to async processes. If so, this is a timing issue, as @Khuong Truong mentioned before.

I debug, after fetch the value is the old one:

but in the database, it is already 6:

The updating in the bpt, and it is async, so the updating not yet complete when the screen fetch happen.

regards 

Since this should work if no BPT is used, i would think the problem lies there.

Can you share your code?

Edit:

https://success.outsystems.com/Documentation/11_x_platform/Developing_an_Application/Use_Processes_(BPT)/Best_Practices_for_Designing_Processes/Separate_Process_Logic_from_Application_Logic

Is the way to close your Human activities.

Ok, thanks, Valente

I think i can guess what is happenning:

1. the updating happens inside bpt

2. when the destination widget is reached at screen action, the updating is not yet finished

3. as they are asynchronous, so there is some kind of race condition and dirty reads.

regards and many thanks all - u are both legends  

I just tried something similar in my testapplication and it updated the screen right away.

You closed this thread, but i am still curious on how you close your human activity in the BPT. Can you send a screen?

But the case is not in that human activity (inside approval process), the updating is happening in the process below the human activity process (End Process). So when the human activity closed, the end process is beginning (and OS create the process in the runtime - not design time - so it takes a bit longer time).

regards.

It's connected to your outpuparameter?

In my example i connect it to the Id i ask when starting the process...

does your process activity closes?

I don't think the update takes longer, because the process activity reacts after the update is finished...

I think something else is not going as intended.

yes, it close. First, i must understand what the parameters means - and it is only filtering which record that can close the activity - in this case i have a variable name LOSWaitAPprovalId - and if you see they are only identifiers (non identifiers will not show up).

in service studio:

That statement tells that your activity will close whenever the record in that entity with the Id you pass on, is updated. 

But you send your parameter that you use as outputparameter for the human activity. don't you have the id as a variable in the process ?

like this:

also: I see 2 different entities: LosApproval and LosWaitApproval ?

The sequence is like this:

1. In the human activity (inside the approval process), it is waiting to close if table LOSWAITApproval is updated

2. IN the screen action, update the LOSWAITApproval, so the human activity is closed, and then the navigation go to the destiny widget, meanwhile the execution thread in bpt is going to another process (end process) that update a LOSWorkflow table.

3. As the LOSWorkflow table is not finished updated in the END PROCESS, the fecth in the destination screen have a dirty read (it is because of asynchronous between the button action and bpt).

regards

Yes!

Now i understand the lag. If it was the same entity you were updating in screen as well as BPT, there would be no lagging.

Ok, thank you.

yes, i assign in the callback ready:

absolutely correct!

I use two tables because one table will be updated many times and it is hard to handle, so i introduce another 'dummy' table just to make the bpt easier to maintain.

thanks

I understand.

I don't really understand why you split the waitworkflow and not use the original entity workflow, but you probably have a good reason to do so.

From what i have seen untill now it probably wasn't necessary. You can use the On close of the human activity if you only want to close when a certain element of your record is updated.

Yes, i have some reason, suppose that one table is updated in a sql editor, it could break the workflow. So, i need the 'dummy'(trivial) one such that the workflow not broken incidentally.

ANd that one table (main) is most likely will be updated in many places those has nothing to do with the workflow.

regards