It seems like changes I make to a process after the initial deployment do not update the server's process. I've had to go back and completely re-create processes from scratch twice because of this. I can completely obliterate the process workflow, and as long as it'll compile, it'll act like it deployed but not actually change the behavior of new incidents when a SmartObject method kicks it off (as outlined in the tutorial). The processes are showing up in the version list in the Workspace, but changes aren't happening. Anyone have any hints here? Thanks!
Processes stop deploying correctly
+1
+9- Nintex Partner
I seem to recall seeing a similar post before about the version number being updated but not the code.
Could you try turning on diagnostic logging for Visual Studio?
(Instructions courtesy of Renier)
- In VS.NET, click Tools > Options
- Expand Projects and Solutions
- Select Build and Run
- The default setting for “MSBuild project build output verbosity” is minimal, change this to “Diagnostic”
- Click OK to save changes
- Open the Output window and attempt the deployment again, once done inspect the output data and look for something suspicions.
+9- Nintex Partner
I believe this to be a known issue when a SmartObject metod calls the Start method of a workflow service to kick off the process. I think the workaround is each time the process is changed and deployd, you need to update the SmartObject and deploy it as well since it is bound to the previous version of the process.
+1Many thanks for the feedback. Unfortunately, no luck so far. The diagnostic logging turned up nothing strange, though I'm not 100% sure on what it's doing in each piece anyway. I am getting errors now for my workflows when I attempt to start one: "Value cannot be null. Parameter name: workflowType" ... this tends to be the indication that a process has broken as I described above.
Shot in the dark, but I'm curious if it's caused by having the SmartObject and the associated workflow in the same project. Maybe if one gets built and then deploys before the other, the association is messed up. When I go into the methods of the SmartObject and try to "Edit" the Start Process method, it comes up with a screen saying I should upgrade the definition to the latest. So I do that, "OK" out of all of the prompts, and rebuild/deploy. I'm thinking that if I update the version to the latest available on the server, and then deploy it, the workflow might deploy first and knock it out of whack, or vice-versa. I'll also test removing the method call and adding it back, so maybe that will be a workaround. Stay tuned, and of course chime in if you have any more ideas.
Thanks!
+1It appears that the workaround is to just delete the offending activity from the workflow and rebuild it. Certainly not ideal, but after messing with it for a solid 8 hours combined, I can't afford to take random guesses at it anymore. If someone finds a quicker fix, please post.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.