BAM Interceptor Vs. Workflow Tracking Service
We are trying to find out is there any advantages/disadvantages using BAM Interceptor for Workflow Tracking versus Workflow Tracking Service? The solution we are looking is a WF solution might use BizTalk not sure on this yet
Few things come to my mind right away are,
BAM provides OOB portal to track data, you can create different views for different users/roles, setup alerts, real-time aggregations, archiving jobs, etc…All this can be achieved without any coding.
I know very little about WF Tracking Service, as far as I know it inserts tracking data into SQL server. It’s up us to create all the functionalities I mentioned above. Is that a valid statement?
One more questions is, if we use BAM Interceptor for WF, can we track every single data that can be tracked using Workflow Tracking Service? Or would we miss something?
As far as development I understand there is no GUI available yet for building WF Interceptor Configuration (IC) file. Will this be a problem when we start building ICs in real time which involves multiple nested WF?
Am I missing any major functionality which I should look into before I pick one over the other.
Thanks
Umar Shareef
Your assumption about creating views for different users/roles, setuping up alerts, and real-time aggregations, archiving jobs, etc are all correct. These are features you get OOB with BAM. WF does not offer these options OOB. You would have to code these features.
WF provides a SQLTrackingProfileService that you can turn on to track Activity Events, Workflow Events, and User Data tracking events (Custom Activity business data and etc). You would have to and could create a "Tracking ASP.NET Web Portal" based on roles, and use the MailEventProvider to send emails, manually query the RTA virtual cubes for RTA, and SQL Tables for the SqlTrackingProfile DataStore.
As far as BAM Interceptor, you already noticed how finicky the IC file can be, however, you can potentially track most of everything that WF can track. If WF implements a custom Tracking Service, or a Custom Activity to add custom private level data to the Tracking profile, then the BAM Interceptor won't be able to do this. AFAIK, BAM interceptor can only track public properties, and User events.
Anything publicly exposed BAM can track and offer OOB. In some cases, the BAM Interceptor can track data, where WF can't if a custom Activity doesn't apply the code to send the data to the Tracking Profile object, which in most programming practices I would say would be bad design. In anycase, currently there is no GUI for building the WF Interceptor, however I have heard rumors of one either being worked on, or maybe event in beta, from someone that monitors this newsgroup, hopefully, they'll respond.
As far as the difficulty with creating multiple versions. Yes, hand coding the config file does lend it self to "Fat Fingering", which is not a real concern because the BAM Management tool does a schema validation before applying the Interceptor. As far as logical errors, this is where you'll find the most difficulty.
Up to this point you find that most developers would rather just code their on TrackingService, when they find themselves not receiving the result they expect, and there are no errors logged to help them out. In all intense purposes, it's somewhat easier to do at this point. However if you have to worry about software policies such as compiling, and deploying based off some type of approved authority, then you may want to bear down and really get a deep understanding of the BAM Interceptor files.
It's quick to set up, easy to use, once you grapple the concept, and know all the tracking points available. You get the intellisense once you move the schema files into the VS.NET schema folder, and the BAM Interceptor has a very good tracing mechanism that allows you to see what going on while the Interceptor is running. It's just a matter of understanding the events you are trying to track, and knowing when to set your filter to catch that event for BAM. At this point, it works like a champ. It can also be used with WCF to intermingle the two technologies together. This will be even more helpful once .NET 3.5 is in place.
HTH
Here is a link for WF Tracking service.
http://msdn2.microsoft.com/en-us/library/bb264458(vs.80).aspx
