The two key areas why I think this works is to do with the content that SharePoint hydrates each time a workflow moves into and out of memory. In old-fashioned programmer speak, the program section and data section are saved with each instance of a workflow. In current lingo, I understand Extensible Application Markup Language (XAML) is used to represent SharePoint workflow objects in XML thereby allowing the instances of all the data objects and the program code to be streamed into and out of memory in perpetuity. If you think about how challenging this is to accomplish, you'll understand why I really respect this aspect of SharePoint, and how it adds to the awesomeness of skill displayed by their development team.
Caveat emptor: dehydration and rehydration saves many things about the state of the workflow and the code of the workflow, but there could be nonserializable objects that your workflow may depend on that can change whilst the workflow is dehydrated (out of memory/not running). e.g. SPList is nonserializable. Worst case scenario, you'll have to prepare the business users to restart broken workflows.
Read more details on this in Chapter 9 of David Mann's awesome book Workflow in the 2007 Microsoft Office System - Using workflow in SharePoint and Office 2007 to enforce and enhance business processes. I highly recommend this book for developers doing custom development on SharePoint Workflows. It's very well written, and a fun read (which is always tough with a deeply technical book).
No comments:
Post a Comment
firstly, thanks in advance for your comment - I don't get very many, so I'm sure to follow up if you leave me a way - secondly, come again.