As I posted here, I had the honor of doing an MSDN Geekspeak last month with Lynn Langit and Glen Gordon. It was a lot of fun, a very casual conversation, covering two of my favorite areas of sub-specialization: BizTalk BAM, and ESB.
The recording is now available at http://channel9.msdn.com/ShowPost.aspx?PostID=369700.
As a follow-up, to that presentation, among other things I showed a higher level API I had created over the BAM API. One of the audience members asked if I could publish it, so…. here you go!
Please note that I am *not* trying to re-create a SOA Software or AmberPoint products. Those products both offer a huge powerful toolkit that any enterprise engaged in service adoption should be aware of, and should explore. However, there are times when just simple metrics tracking is enough, or, perhaps you want to surface some real-time data about a subset of the services in your enterprise. If that’s the case, then the API presented here is a perfectly viable option.
The API is, as you can see, really simple, it just serves as a layer of abstraction that makes it easier for service developers to embed trackpoints in their code (without putting in their own BAM API calls, which requires some knowledge of he underlying activity definition). However, you need to ask yourself if that’s what you really want to do. For instance, if you’re using WCF, you could use BizTalk Server 2006 R2’s WCF interceptors instead, which would allow you to track services by annotating the channel. Changes to the tracking strategy would mean configuration changes, not code changes and redeployments. By the same token, if you’re capturing metrics from BizTalk orchestration, putting in API calls is generally not a good thing as it means that should anything change (such as the data you want to track), you will have to revisit each orchestration that calls the API make a code change. If your data originates in an orchestration, it would be preferable to use the Tracking Profile Editor to create the link between the logical tracking profile and the orchestration implementing the service. This way you get “touch-free” tracking, and can change the tracking without code changes. That’s not a generic statement though, there are certainly times when it’s both appropriate and required that you call the BAM API from inside an orchestration. Clear enough? 🙂
The BAM APIs are in the Microsoft.BizTalk.Bam.EventObservation DLLS.
I have provided three methods:
- TrackServiceStart
- TrackServiceEnd
- TrackServiceException
In order for this to work, we need to correlate a service end to a corresponding service start. In order to do that, the TrackServiceStart method returns a GUID that represent the “token” for this instance of service tracking. The subsequent TrackServiceEnd and TrackServiceException methods will present this token so we know what to update.
The TrackServiceStart method is overloaded:
Once a service has started, it SHOULD either end well, or throw an exception (and it it doesn’t end at all, then you need to schedule cleanup jobs that will remove old incomplete instances):
I hope this post helps you get more out of your BAM.