Part of a project we're working on requires the ability to programatically complete tasks in a 2010 environment. We wrote this functionality following the examples from the Nintex Workflow SDK and SharePoint to complete Flexi Tasks and supplying the relevant "Outcome" of the task programatically.
This functionality was working without issue for a period of time and later, without code change, the functionality stopped working. The behaviour was that the task was marked as completed in all of the usual fields (SP + Nintex) but the workflow had not proceed to the next action in the flow. The workflow had an error that the Outcome of the task (the option selected) was not selected or not saved. The actual error received was: Error in task. Value cannot be null
When comparing workflow task items before and after manually completing them via a Nintex Form I discovered that there was a field being set on the task that was not being set when completing the task programatically.
This field, ApproverTaskID, once set correctly would then allow the task to complete without issue and the workflow to continue as per usual. The code to get the value for this field and to set it is:
NintexTask task = NintexTask.RetrieveTask(spTask.ID, web, list);
Approver approver = task.Approvers.GetBySPId(spTask.ID);
spTask["ApproverTaskID"] = approver.ApproverID;
Making this change appears to have resolved the issue entirely with no other code changes. The problem we have is that the usage of this field is not documented anywhere by Nintex or by Microsoft and so we are seeking validation of this solution to this problem. Searching the field on Google returns approx 10 non-related results. Without this field being set the task does not complete and so this problem must be a problem for other people too.
Before pushing this change to production we want to verify that this field is a known issue / known requirement, but we are unable to confirm this.
Any information you can shed on this field would be great, thank you.
Solved! Go to Solution.
You should not have to set the ApproverTaskID to respond to a task action. You should only need to do that in the special case of responding to the task as the sharepoint\system account. If you respond as a regular SharePoint user, setting the fields documented in the SDK should be sufficient. Can you please confirm which user you are using to respond to the task?
I understand what you mean regarding this field and the system account, however the users facing this problem were standard everyday users and the account used for developing and testing the 'solution' were also standard users.
On this particular project in this particular environment we do not even have access to the system account.
I can provide screenshots showing this if it helps.
Thanks for that information.
Can you please provide an error trace from the SharePoint logs. There should be more detail in there that might give me a clue.
The core issue has been discovered. The Web object on the SPListItem had been disposed of by when the Update method was being called on the SPListItem object. The update logic in our code is wrapped in a classic try catch but the catch was not firing as the error was happening out of scope. The error in ULS was:
Detected use of SPRequest for previously closed SPWeb object. Please close SPWeb objects when you are done with all objects obtained from them, but not before.
Interestingly, all the fields set in custom code were correctly saved on the object. I double and triple checked, with this logic/error in place above, setting the ApproverTaskID field does strangely ensure the workflow would continue as per usual (but the ULS would still show errors). The issue with the disposed SPWeb has now been resolved and references to the ApproverTaskID field removed.
The only remaining issue that we have is that when viewing a task that has been completed programatically versus one that was completed manually, the outcome of the Flexi Task is clearly visible on the completed form when it was completed manually but not for the programatically completed one. The field "Outcome" on the item has been set correctly for both but still it doesn't appear - quite bizarre. See screenshot here:
Thanks for your help getting to the bottom of this.
Just thinking on the last point, it may be due to some other entries appearing in the ULS logs. When programatically completing a task and the other SPWeb issue is resolved there are still several Nintex errors appearing.
When doing an update in 1 x SPListItem there are 7 duplicate ULS entries with a CorrelationID followed by a 10 second pause and then another 7 without the CorrelationID:
Error processing item updated event.: System.ArgumentNullException: Value cannot be null. Parameter name: s
at System.IO.StringReader..ctor(String s)
at Nintex.Workflow.PreviousValueRecordCollection.1xk=(String 2Bk=)
at Nintex.Workflow.ConditionalWorkflowStartReceiver.oRY=(SPItemEventProperties wBk=, AutoStartRuleType wRk=, Boolean whk=)
at Nintex.Workflow.ConditionalWorkflowStartReceiver.ItemUpdated(SPItemEventProperties properties) (Build:2401)
Any thoughts on this? If that field isn't saved correctly deep in the Nintex system it may be why the Nintext form cannot display it as the selected choice.
Latest post / topic moved to:
The original issue in this thread has been resolved.
I am working on the functionality to programmatically complete tasks. Could you please share your code?
Thanks so much.