More Sharepoint Workflow Babbling
It's been a tough couple weeks. While I've been able to successfully get my demos going in time for all my Proof of Concept demos, it hasn't been the easiest thing. I've just sat and rebuilt my workflow from scratch for the 6th time. That's what I get for trying to get fancy here and there.
Since many of my tasks are really the same basic sequence of events: Create Task, Send an Email to Notify the user of the task, Log the task creation, wait for change, make the change, complete the task, delete the task, log task completion. I tried to create an Activity Class, create the core set of events and then use that over and over again. That was a complete waste of time. I never could figure out how to get the correlation token right for the SendEmail event (since it needs to go to the workflowToken and not the parent sequence token). I finally decided to axe that idea in an effort to get the thing done.
Next I decided to go ahead and create the whole workflow. We've been redoing and redoing the workflow chart and this is currently what my work area looks like:
Since I had the POC working and I knew how to create the tasks. I had the stupid idea of creating the majority of it at one sitting. I have since learned that copying and pasting whole sequences is a BAD BAD idea. I don't quite know why it is a bad idea but everytime I copied a sequence, changed all the properties I would get wierd errors or my entire workflow would break. At one point the whole thing ran, then I changed a line of code which changed the AssignedTo user and BAM the whole thing broke to the point where I couldn't even get the first event to fire again. In fact, I had to rewrite the whole thing in a new project to get it to run again.
Next on the list of gripes is that debugging is really really, well, buggy. Sometimes debugging works as expected. I run a workflow, attach to the workflow process, set my breakpoints and things go as expected... but sometimes, especially as the workflow gets bigger (and, as of right now, I'm unable to debug my workflow at all, I've taken to putting little notes in the workflow history so I know what's happening in the code).. .sometimes I get this mysterious error... the debugger tries to load the workflow designer and get an error about the ClassName.Class not being able to be deserialized so the workflow can't get loaded and the debugger doesn't work. If I click continue the code fires off but it doesn't actually communicate with the server or something 'cause nothing actually happens. Pretty frustrating... and I have no ideas how to solve it hence my backwards thinking push some notes into the workflow history (because as long as I'm not trying to debug things work fine).
Next on the list is I have no idea how to use the BeforeProperties properties of a task. I create my onTaskChanged event, create a new field for the propery BeforeProperties... however when I then go and try to use it the values are the same as the AfterProperties. I've been able to workaround this by creating a variable, setting the variable value as the first line in my onTaskChanged event to the workflowProperties.Item.ExtendedProperties[”myitem”] value and then comparing that variable to the AfterProperties value... I'm unaware if I have to do anything special to the BeforeProperties but it seems like it should be somewhat intuitive to use.
The workflow we are doing our pilot off of is pretty small in comparison to the much larger workflows we have planned... the designer is really really slow as your workflow gets bigger, even if you collapse most of your sequences. After awhile I'm waiting good seconds just for the designer to catch up to me.... and sometimes, for no apparent reason other than to completely freak you out and drop your heart to your feet, the designer will show massive red exclamation points (meaning something in your event is broken) all over the workflow... but if you close the designer and reopen it, they'll go away.
Updating the workflow is much easier than I originally thought. As long as the only thing you've changed is your assembly, you can just re-GAC it and the workflow does, in fact, pick it up. If you've changed your InfoPath task forms or other things, it seems I have to actually deactivate and uninstall the feature, the reinstall and reactivate it. Once you do this, you have to actually add the workflow back to your library.
Next tasks to figure out:
-- I created a list in Sharepoint to maintain some task assignment data. Some of the tasks need to be assigned to a group rather than an individual. I haven't figured out if this is possible.
-- System User. In all of my workflow history event, the UserID is marked as System User. I don't know why and I don't know how to change it.
-- I need to figure out how to log the actual user who “changed“ the task. This will allow me to know who modified data in my workflow but, so far, I haven't been able to get this information. I tried a bunch of stuff with SPContext but to no avail.
-- Find a way for an external process to talk to my Sharepoint Workflow. I'd like to expose an ASP.NET page to an external resource, allow them to fill in some data, then have this data pushed into my workflow via a webservice. I have read about the WebServiceReceive but am not sure exactly how it works with Sharepoint Workflows. My other idea is to have the external data pushed directly into the Sharepoint item somehow but I don't know if the Sharepoint Workflow will recognize that the data is there and then start a new task based on it.
-- Once I have this external data, the last thing I have to do is create a new Word document using all of the workflow data to populate the document, push the document into a separate Sharepoint list linked to the original Sharepoint Workflow Item (or perhaps push it as an attachment to the original Item -- not sure right now which way will be better).
Never one to take on small projects using Beta code am I?