Nesting \Wait for the workflow to complete\" Executes Workflows Out of Order"

  • 6 December 2017
  • 8 replies
  • 70 views
MegaJerk
Userlevel 5
Badge +14

Hello there. 

I have an issue that doesn't make a lot of sense to me right now, but I'm hoping one of you might be able to shine some light on what is happening. 

Let us say that I have three individual List Workflows. 

W1, W2, and W3 (creative, right!?). 

The way I have them set up is that, W1 invoked automatically due to start conditions, and based on some workflow logic, might execute W2.

The Start Workflow action used to start W2 has the 'Wait for the workflow to complete before continuing' box checked. 

Inside of W2, there is some logic that will execute W3. Just like the other Start Workflow Action, it too has the 'Wait for the workflow to complete before continuing', buuuuut... that never happens. 

Instead, W2 gets to the Start Workflow Action of W3, starts it, but then STOPS waiting, finishing itself out, which in turn finishes W1 out, while W3 is sent into the 'starting' phase as if it were not executed immediately. It will eventually run and complete around 5 minutes later which indicates that it's probably on the timer service stack. 

What I want to happen is W1 --> start W2 --> start W3 --> finish W3 --> finish W2 --> finish W1

What is happening is W1 --> start W2 --> start W3 --> finish W2 --> finish W1 --> finish W3

Are you not allowed to nest the Start Workflow's 'Wait' command like this, or is there something else that might be terribly wrong? 

8 replies

K
Userlevel 3
Badge +12

Hi,

Ideally, it should work in this sequence, W1 --> start W2 --> start W3 --> finish W3 --> finish W2 --> finish W1.

What you can do is, add "Commit Pending Changes" action at the end of W2 and W3, this makes sure that after executing the "Comming Pending Changes" on W3, it returns to "W2" and executes the "Commint Pending Changes" in W2 and then it returns to "W1".

Thanks,

Krishna.

MegaJerk
Userlevel 5
Badge +14

Sadly adding the Commit Pending Changes to the workflows has no effect, and W2 resolves before W3 is finished. 

Meh. 

Thank you for the suggestion though!

E
Userlevel 5
Badge +14

what environment does this happen on?

does it happen consistently or randomly? (I wonder whether time needed to load and compile workflow might play a role - if it takes too much time start workflow action need not be notified within a timeout)

I'm quite heavily starting workflows in a chain and have never experienced anything like this (NW2013 on-prem)

have you tried to capture workflow instance ID of the workflow being started? does it return anything?

maybe I'd try to remove start workflow action for W3 and add and configure it once again. I've seen cases some action behaved differently then configured, especially if they were copy&pasted.

have you tried to put pause action at the beginning of the (child) workflow(s)?

MegaJerk
Userlevel 5
Badge +14

Yeah... Probably should have included the environment details being that I ask for them from other so often... silly.png 

SharePoint On Premise 2016 

Nintex Workflow / Form 2016, version 4.2.2.0

I went ahead and made a little test list with some test workflows to see if I could replicate what I am experiencing. 

There are two Columns on the list that are important. 

[Toggle], Yes / No
[Option1], Choice (None, Partial, Full) 

211318_pastedImage_22.png

------------------------


I have (3) Workflows that should initiate. The first (1 - Workflow Router) has automatic start options, but will start the second (2 - Process Toggle), which will start the third (3 - Process Option). 

All Start Workflow Actions are configured the same way. 

Start Immediately - Yes

Wait For The Workflow To Complete Before Continuing - Yes

Do Not Start The Workflow If It Is Already Running - Yes

Below is the exact layout of each workflow. 

1 - Workflow Router (Automatic Start Conditions: On Item Creation, On Change When [Toggle](Previous Val) !== [Toggle]

211314_pastedImage_8.png

Note: As shown above, there is technically a 4th workflow called 4 - Toggle Off, but it was just included for completeness and has no bearing on this experiment. 

Start Conditions: 
211315_pastedImage_1.png

2 - Process Toggle

211316_pastedImage_2.png

3 - Process Option

211317_pastedImage_3.png


By Creating a New Item, like: 
211319_pastedImage_29.png

It will kick off the first workflow (1 - Workflow Router). 

However, the history tells the rest of this story:
211320_pastedImage_30.png

Workflow (2 - Process Toggle) is finishing before Workflow (3 - Process Option)! 

Looking at 2 - Process Toggle more closely... 

211321_pastedImage_31.png

It just completely ignores the Wait on the Start Workflow Action! 

211322_pastedImage_32.png

That being said... Let's take a look at Workflow 3 - Process Option's history a bit more closely.
211323_pastedImage_33.png

Not only does the Third Workflow start a full 5 minutes after Workflow 2 has ended (or tried to invoke it), I also notice that the delay Pause For 5 Minutes I threw in there to simulate 'work', actually doesn't resolve until nearly 10 minutes later... 

I'm not sure if this is correct, or if it is indicative of some majorly bad Timer Service mojo, but it might be important information for somebody who knows a lot more than I do about the SharePoint side of things (which I am still grossly under-learned in). 

Another strange thing that I noticed with this test were the Notification Emails that I have coming to me. There were extra notification that, as far as I am aware, should not exist!

211331_pastedImage_35.png

Both of the notifications come from the same Workflow Instance ID, but there is nothing in the log to indicate that it was sent twice, nor are there any additional Notifications that exist on the Workflow... just a 'STARTED' and a 'FINISHED', but for some reason the first one is sending twice... 

Everything for these workflows was made fresh with no copy / paste of actions. 

I'm not sure what you can divine after seeing this, but I certainly don't think that this is an expected behavior. 

My guess is that maybe something in SharePoint proper is disgustingly misconfigured, which makes me extra sad. 

Thank you for your time and help! 

K
Userlevel 3
Badge +12

Hi,

I tried simple way, in SharePoint 2013 on-premise environment, WF1 starts then calls WF2, but WF2 errored out then WF3 is started, WF1 completed and finally WF3 completed.

WF2 workflow error message is - already an instance of a workflow, WF3 is running on same item in the <sitename>. 

I think it is better contact Nintex Support.

MegaJerk
Userlevel 5
Badge +14

Yeah. 

Thanks for trying it out and getting some results! 

I suppose I'll start barking up that tree

E
Userlevel 5
Badge +14

Another strange thing that I noticed with this test were the Notification Emails that I have coming to me. There were extra notification that, as far as I am aware, should not exist!

add pause for... action as a very first action to each workflow. that should resolve it.

this is known problem/'feature'. nintex says it's caused by sharepoint.

workflow started on item creation event is being executed by worker process.

once you put a pause at the beginning, workflow is queued immediately and when pause elapses it is then executed by timer job. for unknown reasons workflows being executed by worker process experience problems like this, whereas once executed by timer service everything is ok.

more on the topic here - Defensive Workflow Design Part 4 - Slow Down and Speed Up 

probably 'Wait For The Workflow To Complete Before Continuing' is influenced/confused by these several workflows being started in parallel as well, and it stops waiting on a false event from not 'proper' instance

‌ ‌ chain of workflows‌ ‌ wait for the workflow to complete before continuing‌ pause for action slow down or speed up 

MegaJerk
Userlevel 5
Badge +14

Yeah. Ultimately it seems like using the Pause For... Action is the only way to approach this. 

It would be nice if I didn't have to artificially hinder the progression of things (because let's be honest... Users want thing to be just as fast and instantaneous as Facebook or any other responsive service), but SharePoint has its particular infrastructure that Nintex can't really ignore, so, Pausing it is! 

Thank you for your help and considerations! 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings