anybody knows a way to detect when a backend work flow ends ? I think that my case can be very common.
During the initial set-up of my app (new user signing up and creating a company) I need to populate some company specific data taking the content from some generic “default data” and then relate them in a specific way.
Let’s say that I need to create 3 things company specific. I run 3 workflows on a list that read the “default data” and create the company specific things (it’s like duplicate the default data in new things with a filed referenced to current company).
Then the I have to write the relations between the 3 things newly created. But before running any other workflow I must be 100% sure that all the 3 things have been completed.
How is it possible to detect when the wf on a list completed all its tasks ?
For instance, in server logs (advanced search) you can show the “Scheduled task completed” info. But it seems that this is not a condition you can reach in any other way in the workflow itself.
As a workaround I made the following workflows wait a reasonable time (let’s say 30 seconds) in order to be almost sure that, when these workflows (with the cross reference logics) will run, all the data they refer to are already there. But this is not 100% reliable.
Best thing would be of course being able to force workflow to run in a specific sequence. But since alle the wfs run in parallel, any idea how to manage this situation ?
Have you tried using recursive workflows instead of API workflow on a list? Recursive means that instead of asking Bubble to perform a workflow on a list of items, you instead create a workflow that gets passed the full list, performs the workflow on item number X, and then re-schedules itself with a short delay to work on the next item in the list. This way, you can use a condition that checks if the item currently having been processed is the last in the list.
There are different ways to to this, but here’s a simple one. Set up an API workflow with two parameters:
Things - list of things - the list of things you want to process
Number - number - the number currently being processed
You schedule it passing the full list in Things and Number as 1. You make changes to Thing’s list of Thing’s Item #Number, and place a last action in the workflow that re-schedules that same workflow, but set number to Number + 1, and a condition that checks if Thing’s Item# Number is not Thing’s Last item (if so, you’ve reached the end, and the loop stops).
In here, you can also schedule the follow-up workflow you need, with the condition that Thing’s Item # Number is Things’ Last item. Then you know the end has been reached, and you can go on to the next step.
Hope that made sense.
Recursive workflows in general are actually less prone to timeout, etc, so they’re often a safer (but a bit slow) option for processing lists (though with just three you won’t notice anything);.
Hi @petter, I actually tried but couldn’t set them up properly. I think I was missing the concept of iterate based on a number. Now I give it another try based on your suggestion. I’ll post the outcome. Thank you
Quick reminder too that recursive workflows can easily max out your server performance if there’s no delay between them. With 3 entries you’ll be fine, but worth keeping in mind for longer lists.
It took me a few hours to redo all the workflows but at the end it works fine. I have also checked system usage and if I leave 5 seconds between each recursive wf the CPU capacity stays under 20% while the all process it takes about 7 minutes. If I go down to 2 seconds the CPU capacity goes up to about 30% but the all process it takes a little bit more than 3 minutes.
I am certainly a Bubble fan, but I am also negative impressed by how long it takes to write data. In my case I do have table 1 with 23 records, table 2 with 7 records and table 3 with 5 records. It’s true that I also have to perform all the combination between this data in order to keep the right cross referenced relationships between them all, but a 3 to 7 minutes elapsed time it seems really a lot to me …
Yeah, recursive workflows unfortunately leave a lot to be desired in terms of speed, and is one of those things that we have to live with being pretty slow for now. Depending on what you want to do, Keith’s List Shifter plugin can do a lot of different Javascript processing on lists that is not as easy to set up, but lightning fast. You might want to check that out if you’re familiar with how Javascript works.
Does that write to the database? Or is it lighting fast because it keeps everything on the client’s computer?
No, exactly. It let’s you process the list client-side (on the user’s computer), and then you’ll have to save it through a regular workflow. But saving a list is a great deal faster than processing each entry in a recursive workflow.
Thank you