Skip to main content

Dears,

I created a Nintex workflow 2013  that reads data for the current
logged in user (User Profile Query) from ERP oracle DB, store them in a data
collection, then in a for each loop for that collection iterates among the
collection and creates a single item in SharePoint list, this action occurred
in parallel for 6 SQL execution nodes (stores data in a data collection), and a
6 parallel for each items that iterates on these data collections then creating
items in a 6 different lists in SharePoint.

Now the issue is the WF takes around 60 seconds to finalize,
and our end users found it annoying to have a loading page for 60 seconds to
display the data for them. I know it’s long process, but I believe we may speed
it up, I communicated with our Dba and the whole ERP queries are tuned (query took 2 seconds to fetch data), so I’m
thinking if we have the ability to tune the WF itself (if possible).

enabling safe loop, is it a solution, and what are the bad effects of enabling it?

attached in a snap of how the main part of the WF looks like.

Thanks,

This is an oldie but goldie post from Vadim Tabakman​ >>> Nintex Workflow - Safe Looping - Vadim Tabakman where you will see some risks.

You could also solve your time issue developing a Custom Action in Visual Studio.

And remember that this is a workflow and not a transactional application. In some cases I'd feel lucky to execute all those actions in 60 seconds. And also remember that time will increase when your workflow has more items to process.

Have your seen what is the action that takes more time?


Thanks Fernando,

I know 60 seconds cannot be an issue with WF process that includes all of this complexity, but my issue us related to application and end users experience!

This WF will run when the user chooses month and year fron a custom list insertion form, and press submit, this action will fires the WF that reads ERP data and redirect the user to a page with data view that reads from the 6 lists, the issue is the WF will read data from ERP and create list items, so the dara view will be empty till the WF completed, then user needs to refresh to see the results, what i did is creating a middle page with loading gif, and in JS settime out to 60 seconds then i redirect the user to the dataview page and i was happy with that lool.

But our end users were not satisfied to see a loading page with 60 seconds and here is my problem sad.png.

For ur question, i believe creating list items nodes that takes too long, but i will check to more to be accurate.

And also i will ubcheck safe loop for this WF only and i will see the results.

Appreciated.


Another option for that process could be the following:

-The user chooses month and year from a custom list insertion form, and press submit

-The receives a message that says "In the next minute your will receive an email with a link to go on with the process"

-The workflow makes the process you have and then send an email with an URL to your form.


I suggested that, but rejected sad.png.

I can make a custom web part and avoid WF, but i prefered to not work on server side code.


Uncheck safe loop does not make that big change, it takes now around 50 seconds!!

If any other suggestions that would be appreciated.

Thanks all.


Another idea.

You could manage to do a kind of wizard where your form (Part1) is saved and a workflow starts processing the first part, then redirect to another form with the part 2 and another workflow starts, etc. So when you finish saving the last part you will have processed 80-90% of the information.


In my case, the form has two fields, year and month, so there is no need to have multi forms for user inputs!

Could you please explain more.

Thanks


In that case you could have prepared early 12 "datasets" for each year ( perhaps on an auxiliar list ) and then only get the early processed item.


Not sure if i got it sad.png

Do u mean to load data for each user in the lists before using a job?

Then make the form just reading from the lists


I don't know your sql queries , but yes, this is the main idea


Reply