November Happy Hour will be moved to Thursday December 5th.

Where does a workflow persist its historical information?

Vote:
 

When someone initiates a workflow, and it requires users to input data, where does that data go?

For instance, if I initiate a Request for Feedback workflow and send it to 10 people, those 10 people have to type something in the feedback box.  Where does that data live?

My client wants to persist that.  They want to be able to look back and see what feedback was provided each time this item was sent through workflow.  So, they want some historical record of the workflow -- who it went to, what feedback was provided, etc. They want something like another tab on the Edit Panel for "Workflow History," where they can browse this information a year later or whatever.

Possible?

#45858
Nov 19, 2010 15:54
Vote:
 

EPiServer uses the standard SqlWorkflowPersistenceService which stores the System.Workflow.Runtime.WorkflowInstance instance in the database in a binary serialized format. In addition to this EPiServer stores some metadata (instances of EPiServer.WorkflowFoundation.WorkflowDefinitionInstance) about running instances in the database (in ObjectStore). This metadata contains e.g. an history list related to the running instance. This is what RequestForFeedback uses to store feedback. But when the workflow is either completed or terminated both the workflow instance and the metadata is destroyed.  

If you would like to persist the HistoryData even after the workflow instance is gone you could hookup to WorkflowSystem.WorkflowManager.WorkflowCompleted and WorkflowSystem.WorkflowManager.WorkflowTerminated and in those event handlers call WorkflowSystem.WorkflowMangager.GetInstance to get the metadata for the instance (metadata is still available in these events). Then you could get the History list for the instance and store it persistent somewhere (e.g. DDS). The reason you have to hookup to WorkflowTerminated event is that if the owner of the RequestForFeedback instance chooses to complete it before time has elapsed then a terminate request is sent to runtime. In that case the exception message in WorkflowTerminated event will be "owner request".

#45971
Nov 24, 2010 8:13
Vote:
 

Thanks for the response, Johan.

However, where would I bind that event handler?  I've tried:

  • In a class registered as a PagePlugIn
  • In the Application_Start method of the global.asax
  • In the code-behind of a page I manually called in a browser (to be sure the code ran)

Try as I might, I can't get the event handler to bind.  I run a workflow, complete it, and my event handler does not fire.

#46108
Nov 27, 2010 5:39
Vote:
 

It just occured to me that I may be totally missing the point here -- do workflows even execute in the same space as the Web project?  It strikes me that they probably execute in their own aynschronous thread somewhere, which means my attempt at event binding is pointless.

So, I'm back to the same question: where do I bind this event handler?

#46109
Nov 27, 2010 17:19
Vote:
 

It should not matter where you connect your event handler (the first call to WorkflowSystem.WorkflowManager sets up the singleton instance). Workflow instances are running on background threads but in the web site appdomain so event handlers should be called. You could try to turn on log4net logging (level=All) for the namespace EPiServer.WorkflowFoundation then you will se logentries when worklow instances are e.g. completed or terminated. The log outputs are written in the same context (method) where events are fired so if you see log outputs you should have events raised as well.

#46110
Nov 27, 2010 19:46
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.