In the WF 3.5, we were able to track the data in SQL Sever as there was a special service (i.e. SqlTrackingService class) provided for this but in WF 4.0 Beta there is not any service provided for this. Instead there are classes to track the data in Windows Event Viewer and files.
Would the future versions of WF 4.0 provide the option to track the data in SQL server with all those tracking tables which were available in WF 3.5?
- Edited by Pushawart Thursday, June 25, 2009 12:06 PM
I have gone through the examples you mentioned below but they dont have any example for tracking in SQL Server which was provided in WF 3.5 so wanted to know if the same would be provided in WF 4.0 as well. Of course, we can create our own tracking service which can track the data in SQL server but then it would he completely custom service.
As of this moment there will not be a SQL Server tracking sample. You can customize a tracking participant rather than creating a tracking service to log to SQL but there will not be an out of the box solution for you. The tracking samples are based around the ETW (Event Tracing for Windows). Also, you don't have to be using Dublin for WF tracking. It is including in .NET 4.0.
I believe that if you want guaranteed data consistency, then you cannot use the new tracing model, as I know of no way to make a tracking participant take part in a workflow transaction. So if you need full data integrity and consistency with workflow status, then you will need to use the SQLTrackingService.
According to MSDN, the SQLTrackingService is still supported (see the bottom of the below article):
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 anyone knows how to make the tracking participant take part in the transaction such that you can ensure that it e.g. writes state to persistent storage, then please point me at a sample of the code.
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.