Although I was quite happy with my first implementation of my Order Demo (see prior post here that points at videos of completed solution), as BAM is an area of sub-specialization for me and one I feel very strongly about, I wanted to incorporate some BAM tracking in my second version of the demo.

The data I wanted to track was simple: orders that need to be approved or denied get sent to a SharePoint document list, and I wanted to track how long it took someone to act on it, the disposition, etc.

The first way I thought of to implement this was go back to my order schema, and add in some new elements like InterventionStart, InterventionEnd and InterventionDisposition to capture the data. That would have worked, but I really didn’t want to change my source schemas just for this, particularly as there were multiple InfoPath forms built off those schemas that would need to be refreshed. Plus, it would mean carrying around content in a message that may only be used for a specialized activity tracking report. So, I started thinking. there must be a better way. And, I was right.

The way I solved this was by looking at and leveraging the properties surfaced by the SharePoint adapter. For example, timing the duration of an intervention would be a simple matter of tracking “document creation time” (when it was written to the doclist, intervention completed would be the time I picked it up. As a bonus, I could also get other properties, such as what account last modified the document.

The beauty of this approach was that it was completely “touch free”. I didn’t have to go in and modify the document structure, any of the artifacts, nor the InfoPath forms. In fact, I deployed my tracking solution WITHOUT TOUCHING THE ALREADY DEPLOYED AND RUNNING BIZTALK SOLUTION. Pretty cool!

Here’s how the BAM portion of the solution is assembled.

My activity definition looks like this:

My view definition looks like this:


I used the Tracking Profile Editor to do the mapping from the tracking model to the physical data items and their respective collection points. Note that there is no orchestration in the mix, we are doing messaging-only BAM, and the screen shot below shows that I have set the port mapping to be the “ReceiveIntervenedOrders” port, and that the data I am picking up is “InCreated” from the SharePoint adapter properties.


And, that’s all there is to it from the collection standpoint. With the tracking profile deployed, any messages coming in through that receive port get the properties tracked.

Finally, now that we are capturing metrics, I needed to render them, and used my favorite tooling for this: SQL Server Reporting Services hosted in SharePoint. Although I rarely work with SSRS, this is what I was able to quickly cobble together:



A couple of important points to note:

  • in case you missed it above, I implemented tracking intervention duration with no changes to the existing solution
  • both human intervention and the interval tracking is completely asynchronous. There is no orchestration running to time intervention and no corresponding correlation that has to happen. This simplified design means not needing to worry about items deleted from SharePoint, answers that never come, etc
  • because I used Reporting Services to define the report, it would be trivial to set up a subscription to do something else with the report, such as run it every Monday morning and email a PDF to an alias

Elapsed time from the point of having the idea to having something working, only about 5 hours. I then spent a couple of hours tweaking the reports. It would have been faster if I were more familiar with SharePoint and Reporting Services. 

I heard someone say once that good developers are lazy, as laziness makes them strive for the easiest way to solve problems. In this case, my laziness led me to what I see as a very clean and elegant solution pattern that I can see lots of people taking advantage of.

If anyone out there is doing other cool stuff with BAM and SharePoint, please let us know!