A few months back, I demonstrated how to build a SQL query against the BizTalk databases which returned application-level activity metrics. Now that the RSSBus Server has moved further along in its release cycle, I went ahead and built a more full-featured RSS feed out of BizTalk.
Within the RSSBus infrastructure, one can build an “.rsb” file, which can be syndicated as RSS.
So what’s contained in this “.rsb” file that makes my RSS feed so exciting? Let’s look. First off, I can specify input parameters to my feed, which are received via the URI itself. Notice that you can also specify a default value, and, a restricted list of values. In my case below, I’m only accepting activity metrics for one, two, seven and fourteen days back.
<rsb:info title="BizTalk Operations" description="BizTalk Operations Feed"> <input name="app" default="App1" desc="This is the name of the BizTalk application to query"> <input name="interval" default="1" desc="The number of historical days to show" values="1,2,7,14"> <input name="servicefilter" default="" desc="Keyword filter of results"> <input name="typefilter" default="all" desc="Show all service types/just messaging/just orchestration" required="false"> </rsb:info>
What I’m trying to do here is have a single “feed” file, which can actually serve RSS data for a wide variety of applications and scenarios. Instead of having to create a new RSS feed for each newly deployed BizTalk “application”, I can simply generate a new URI and not deploy a single new object.
Now arguably the only way this solution will work is if we aren’t actually hitting the BizTalk databases each time a person refreshes their RSS feed. I don’t want that additional load on our production system. So, what are my caching options? As it turns out (thanks to the spectacularly helpful RSSBus techs who helped me out), the caching capabilities are quite robust. Here’s my caching declaration in my “.rsb” file ..
<rsb:cache duration="120" file="cache\\cache_[_input.app | tofilename]_ [_input.interval | tofilename]_[_input.servicefilter | tofilename]_ [_input.typefilter | tofilename].xml" />
The first time this feed is hit (or when the cache duration has been exceeded), a cache file is created and named according to the URI parameters. So if I hit this feed for application “ABC” and a “7 day” duration, filtered by all services with “SOAP” in the name, and only wanted “messaging” services, my cache file on disk would be named “cache_ABC_7_SOAP_messaging.xml”. If someone else makes the same RSS request within the cache duration interval, then RSSBus will return the cached data (stored in the file) instead of actually querying my BizTalk databases again. As you would expect, I have many cache files on my system at any one time to reflect the many RSS query permutations.
Then, within my “.rsb” file, I use the RSSBus “sqlCall” connector and format all the results. The “<rsb:match>” keyword is in place to suppress resulting values that don’t contain the input “service filter” value. I then use the “<rsb:select>” and “<rsb:case>” keywords to do a switch statement based on the “type filter” value. This allows me to show only orchestration services, messaging (send/receive) services, or both.
So what’s the result? To demonstrate the RSSBus server to some colleagues, I utilized our newly deployed MOSS 2007 infrastructure to add RSS data to my personal site. After putting together the RSS query URI just the way I want it, I take that URI and apply it to the RSS webpart on my site.
I chose to show both the feed AND description since I put the BizTalk activity count in the item description. After saving my web part changes, I can now see my RSS data from our “development” server.
Now I can provide URLs to the business owners of our various BizTalk applications and they can see regular performance metrics for their system. RSSBus provides a pretty unique platform for building and maintaining RSS feeds from a wide variety of sources. Providing operational metrics from enterprise systems may be one way that my company actually uses RSS to further business objectives.
My last step is to add security to a given feed query, and the RSSBus folks are helping me through that right now. I’d like to be able to restrict viewership of a given feed based on Active Directory group membership. I’ll report back on the results.
Richard Seroter's Architecture Musings 