QuickLearn Blog

Over the past month I’ve been working really hard on our new BizTalk Expert Series class for Business Activity Monitoring. I have to say that I’m really excited to start teaching it. In three days, we manage to cover almost everything one could want to know about BAM. The most interesting part of it for me is the data consumption lab. I’ve never been very fond of the BAM Portal. It’s nice, but certainly not something that I’d like to parade in front of a CEO of a big company. Don’t get me wrong, the capabilities are awesome, but the way it looks and some of its behaviors aren’t the best. In the consumption lab, we examine how to create custom consumption models for BAM data using PerformancePoint, SQL Reporting Services, and an AJAX based web site. I’d never worked with PerformancePoint before and I was surprised by how easy it was to create a dashboard based on the BAM OLAP cube.

Last week while teaching the BizTalk Developer Immersion, I was demoing how to resume suspended messages using the BizTalk Group Hub. I submitted six messages while my send port was stopped, so all the messages were suspended. I was foolishly trying to show my students that if I resumed the message, it wouldn’t be processed because the send port was in a stopped state. I resumed the message and it disappeared, actually, it went out through the send port. This confused me, I had six suspended messages, I resumed one and it was processed so I only had five. But why? I couldn’t figure it out, the port is stopped, the message shouldn’t be processed but if one went through why not all of them. I was stumped, then it occurred to me. If I were in production there are dozens of scenarios where I could have dozens or hundreds of messages in the MessageBox waiting for my send port to start, but before I actually start it all up, I want to send a few specific messages as a test. By stopping the port I can see all the messages that the port subscribes to and choose which ones should go through. So now I think it’s pretty cool.