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 
Interesting.
Is this something you would be willing to share with me 🙂
I like the idea of using Rss in this way because this is the sort of thing that Department managers can subscribe to through outlook internally to get on demand reports !!!
Happy to chat with you about it. The working solution is the one I created for my employer, but if there’s something specific you’re looking for, I can try and share it.
If im honest with you I find BizTalk a little confusing.
I dont get why it’s all so complex, and i’m having real trouble just getting started trying to develop on it.
I have built a network using VMWare and i’m pretty good with asp.net and building web services ect but this BizTalk stuff has it’s own way of thinking.
I have been thinking about building an enterprise search that lets you specify what are you are looking for (eg a person, case, or project) then a search term, the result would then come back from each system as Rss.
The idea being that Rss can be fed in to just about everything and like most organisations this one has a complete dependancy on outlook which also supports Rss (well 2007 does anyway).
I’m trying to build various functions that allow me to take advantage of this in order to feed user specific data directly in to the application they use most !!!
I’m pretty much on day 1 of my BizTalk experience though so even the most fundamental stuff is getting my head all twisted.
I get the idea it’s just the actual implementation that escapes me.
How did you get started with BizTalk ?
No shame in that. BizTalk (and message-oriented-middleware in general) follows a different paradigm than most developers are used to. At its simplest, you define messages that go through a bus (schemas), and configure adapters to receive data and transmit data. I’ve been working with BizTalk for 9 years now, so much of my knowledge is just from experience. But there are tons more books now (BizTalk Recipes, etc) than there ever were before.
To your use case, RSS sounds like it could be a good case. Have you read through my series on doing this (https://seroter.wordpress.com/2008/09/05/building-enterprise-mashups-using-rssbus-part-i/)? BizTalk may not need to be any part of that equation, unless it’s as a single service that accesses a back-end that RSSBus can’t query.