locked
Designing persistence participants and using them as extensions RRS feed

  • General discussion

  • N00b question:  I want to provide an extension to a workflow.  The problem I'm having is that the object used as the extension is being modified inside of some ASP.NET MVC code before being handed off to a WF.  Some flags are turned on/off for example in MVC code. 

    When the WF activity executes, PublishValues is called and the object is rehydrated from the persistence tables, causing any properties that were changed on the object to be reverted back to the state recorded in the database.  

    The WF activity itself is concerned with examining values to determine what actions to take; so if PropertyA = true, then Action B is executed.  So far, the only workaround that I have is to basically not accept any values inside of PublishValues() if a newer one exists.  This leads to a lot of code involving checks as well as property setters that record whether a property was changed or not.  If PublishValues() sees that PropertyA was modified, then it does not accept the value from the database.  

    I guess another approach is to have a non-persistent participant that only records changed values and then is stored as a property on larger param object.  The param object holds the persistence participant and the changed values and then the workflow decides what to do based on comparisons.  If the persistence participant has PropertyA = true, but the change tracker has PropertyA = false, then some logic is executed within the WF activity.  

    Are there other, better designs for handling changes to an object that will be passed off to a WF?  I'm new to WF, so I'm sure that I'm overlooking simpler approaches.  

    • Changed type Andrew_Zhu Friday, April 8, 2011 7:45 AM no reply
    Friday, March 25, 2011 3:08 PM

All replies

  • Hi there,

    The problem seems not well defined.

    I'm really curious as to why you want to persist values with the workflow instance that will just be disregarded later in favor of the 'newer' value from the host extension. Especially if the persisted value came from the host extension in the first place, it would seem like the host extension should always have 'at least newer' information than what is persisted with the workflow.

    Do you have some specific cases where you need to use the persisted value from the workflow, and disregard the host extension value?
    Tim

    Monday, March 28, 2011 11:03 PM