locked
Transaction service & SQL Tracking service in WF4.0? RRS feed

  • Question

  • Note: I've posted the same question on another forum, but this MSDN forum seems to be more appropriate. sorry for cross-posting!

    I am exploring if Workflow Foundation 4.0 is stable enough to start developing on it but the documentations I've seen so far is mysteriously silent about why there are no built-in Transaction  & SQL Tracking services? They were available in WF 3.5 and seemed to be reasonably stable. Any clues? May be the whole concept was broken in 3.5 that they were scrapped? I know there are lot of links and hints pointing to writing a custom (SQL) tracking participant, but then what is the point of a "framework"?  Moreover there's no way to query the tracked data. And nothing about Transaction service! So how do we keep the WF persistence data & application data consistent? Am i missing something here?


    Some unsatisfactory answers on "missing" SQL tracking in WF4:
    http://stackoverflow.com/questions/2071767/windows-workflow-foundation-4-0-and-tracking
    http://social.msdn.microsoft.com/Forums/en-US/wfprerelease/thread/8cfe598a-a400-4804-92ad-d68aa444d8f3
    http://msdn.microsoft.com/en-us/library/ee622983(VS.100).aspx
    http://msdn.microsoft.com/en-us/magazine/cc163437.aspx

    Any help will be greatly appreciated :)
    Friday, August 6, 2010 10:44 AM

Answers

All replies

  • SQL Tracking isn't as friendly to administrators, so in .Net 4, ETW (Event Log) tracking is the preferred out-of-box path for workflow tracking.

    Transactions are implemented with the TransactionScope activity:

    http://msdn.microsoft.com/en-us/library/system.activities.statements.transactionscope.aspx

    • Marked as answer by Andrew_Zhu Friday, August 13, 2010 2:04 AM
    Friday, August 6, 2010 6:27 PM
  • As, the OP pointed out, the problem with the participant/tracking model is that you cannot guarantee consistency. There is no way that I know of to make the tracking participant take part in the workflow transaction. You can create a custom activity to create custom tracking records and wrap that in a transaction, but there is no guarantee that the participant will then pick that up and e.g. write it to persistent storage.

    Given that participants cannot take part in the workflow transaction, the only way to ensure workflow state/data consistency is to either store the state in a non-workflow database by using a custom activity to store the state and auditing, or use the SQLTrackingService.

    Fortunately, according to MSDN, the SQLTrackingService is still supported in .Net 4 (see the bottom of the below article):

    http://msdn.microsoft.com/en-us/library/system.workflow.runtime.tracking.sqltrackingservice.aspx

    You will have to add references to System.Workflow.Runtime.dll (and probably System.Workflow.ComponentModel.dll) to your project. Make sure you are targeting the full .net 4 framework in your project properties (i.e. not the client .net 4 framework). Both dlls can be found in the v4 framework directory.

    If there is any way to make the tracking participant log status/auditable events as part of the workflow transaction, then I would love to know about it. If it is possible, then it's certainly very poorly documented. I have seen no samples that provide this info.

     

    • Proposed as answer by jimasp Wednesday, December 15, 2010 11:05 AM
    Wednesday, December 15, 2010 10:38 AM
  • P.S. I suppose you could implement a TrackingParticipant save method, and call that from within a PersistenceIOParticipant BeginSave method in order to take part in that transaction, but that would not give you anything out of the box, as you would still need to manually save your state/info in a custom database with a custom stored proc etc. in which case, you may as well have just written a custom activity in the workflow transactionscope, which would be far simpler to write and other devs to understand.

    So as I see it, MS have so far provided nothing better than the SQLTrackingService they provided before, which is probably why they chose to keep it in .Net 4.

    So for data consistency in sync with your workflow, you have 3 options - SQLTrackingService, CustomActivity with SQL calls, or trackingparticipant save wrapped in persistenceioparticipant beginsave call.  The last option seems a bit nasty, and as mentioned doesn't offer much beyond the second except smoke and mirrors. 

    Wednesday, December 15, 2010 1:57 PM