I love that you like PowerShell, it's the best tool an admin could have. I think we had another discussion on its use. Are they related? You are not doing system.update() correct? Are you using RunWithElevatedPrivileges? Are you updating the item from the context of that site? Sometime a AllUnsafeupdates needs to be enabled, but that may not be in play here.
I want to think that there is no issue with using PowerShell to create items and for workflows to start. In my applications I create list items via code on the server side and the workflows start as expected. Also, in some situations, I have applications create an item and also manually start a workflow based on a condition in the code. So the workflow starts on demand, not auto, and no conditions within.
PowerShell is basically the only interface I use to manage SharePoint. But that said... I do have another discussion going on the use of PowerShell together with the "Wait for Item Update" action not detecting the change. I don't know if this is somehow related. The issue I'm discussing there is actually completely blocking the flow of the workflow and basically all workarounds fail, while this error pops up multiple times in the ULS but doesn't do anything to the flow or the execution of actions. So, I'm somewhat confused on the "why" of this error. Regarding your questions:
- I was doing a SystemUpdate($False) but changed this to Update() to make sure all updates are regular updates.
- RunWithElevatedPriviliges... I don't use this in PowerShell. The script is executed as the Admin user.
Workflows do start without issues when items are added through PowerShell. No issues there.
But I have been in contact with support for my "Wait for Item Update" issue and they reviewed my workflow and recommended to add a 1 minute wait action as the first action in my workflow. We are in progress of doing this now and see if it's related.
Good info. And I agree, More admins should be using PowerShell everyday. I just find that most do not know how to use it.
The Wait for Item Update does require a SharePoint commit to evaluate effectively, so a pause can help there. But what I was going to test later, and maybe you can tell me, does the Wait for Item Update "ADD" an event receiver to the list item? I assume it does not. Therefore, if it evaluated on a commit it should still be evaluated in the w3wp process. That is, until a Pause is added. Then it will be evaluated in the OWSTimer. But either one, without an event receiver in play, updating the item with PowerShell should have no recourse.
Each list you creae has 3 event receivers by default:
- "Nintex conditional workflow start" with the type ItemUpdating
- "Nintex conditional workflow start" with the type ItemAdded
- "Nintex conditional workflow start" with the type ItemUpdated
I created a new workflow, added a Wait for Item update but no extra event receivers are created. For me, it seems like everthing is handled in the 3 default eventhandlers.
But this is where I'm getting a little bit worried...
The list where we are working on has 9 (!!!) eventhandlers. 3 ItemUpdating, 3 ItemAdded and 3 ItemUpdated. I'm wondering why. I created a new list where I did nearly the same. It had 3 eventreceivers when I created it. I added 2 workflows with a conditional start and both have a wait for item update action.
When instantiated and "In progress", I still have 3 eventreceivers.
I'm starting to wonder if this is the core of all my issues I have. It is possible to remove those eventreceivers in some "supported" way? I could go in using PowerShell and start to beat the life out of those eventreceivers but I don't want to make matters worse.
OK... getting complicated.
Got word from Support that this might indeed be problematic and they proposed that I just delete the duplicates using PowerShell or SharePoint Manager. I did this but when I started testing again, I noticed that suddenly I had 6 instead of 3 event receivers.
Before deleting the duplicates, I did some more inspection with SharePoint Manager and I noticed that each eventreceiver has a "Data" property which has a specific value (numeric). What I noticed was that each "set" of 3 eventreceivers (ItemUpdating, ItemUpdated, ItemAdded) had the same value for that property.
Now, when I deleted the duplicates, I didn't pay attention to that value.
So, it might be that the 3 unique occurences I retained, were not of the same “set”. I don’t know for sure, but chances are slim that I managed to single out the correct ones by accident.
So, I’m left with the following (the values below represent the Data property values):
ItemAdded ItemUpdated ItemUpdating
1 1 3
It might be (I’m checking this with Nintex Support) that in my case the sets are “incomplete” because:
Set 1 => Missing the ItemUpdating eventreceiver
Set 3 => Missing the ItemAdded and ItemUpdated eventreceiver
And that the system regenerates the missing eventreceivers in this case to have a complete set again, resulting in:
ItemAdded ItemUpdated ItemUpdating
1 1 3
3 3 1
=> 6 eventreceivers or 2 complete sets.
The reason why I’m thinking in this direction is because when I removed the duplicates again when I had 6 eventreceivers, I DID pay attention to those Data values and made sure that the occurences which I retained, all had the same “Data” property.
And now, I only have 3! No new occurences are created.
Anyone with more insights on this?
I'm not sure what the data values are for as for the other list with two workflows did not duplicate the event receivers. So it would not be to mark an instance ID or anything.
I was going to mention to manage using SharePoint Manager, but PowerShell rules!
You've provided some great information for me that I am interested in. It is a good troubleshooting step to review this in the future. But I believe that this would not be the case for the general public to perform this level troubleshooting and should rather contact support.
So what are your results now? You have 3 handlers, but what happens on the Wait? Does the workflow behave?
For the moment it's purring like a kitten, resuming immediately when the condition is met (with or without PowerShell) but this was already the case since we started using a checkbox in our wait condition instead of a choice field. The real issue was (yesterday) still occuring on long-running workflows which are waiting for over 2 days or so. When the condition to proceed was met after 2 days, it didn't continue anymore. So, to know if everything is working as expected... I have to wait until monday. Then I can change some values and see if the workflows resume.
So, I will return with the results on monday.
Concerning the eventreceivers... I have 64 (!!!) WorkflowCompleted eventreceivers on the web level with the name "Created By Nintex Workflow Start Action". Doesn't seem right, does it? But I don't know where these are coming from. I have 1 site workflow. That's it.
The issue with the Waiting for Item Update has been solved! Some things we did:
- include a pause for 1min at the very beginning of the workflow as first action.
- Cleaned up the event receivers on the list
Long-running workflows are now resuming without issues after a value is changed, even if this is not done directly using the UI of SharePoint.
We still see those errors concerning parameter 's' popping up in the ULS multiple times but it doesn't affect the flow or functionality of the workflow at all. So, I'm going to ignore this for now since we have lost already too much time on these kind of things and we really need to get this thing going again.
Awesome, well done!
I'm trying to look back through the sequence of events. I'm wondering if the Pause was an absolute necessity or not. I know the event receiver cleanup was.
The pause, I'm not sure of this actually helped but it solved some other things we were experiencing... We saw 2 strange things when a workflow started (without the pause).
- When we looked at the history, we noticed that some actions were executed multiple times in the beginning.
- When we disabled "Safe Looping", we noticed that the workflow would create tasks multiple times. However, when you clicked any of these tasks, you would get a SharePoint error and a correlation ID which basically said that the object didn't existed. Only the last instance of the task worked. Weird stuff...
Once we added the stuff, these things disappeared.