I Want a Web Event Broker
Sunday, June 25th 2006 | Ismael Ghalimi
My good friend Charlie Wood at Spanning Partners just released the excellent Spanning Feed Builder 1.0 on the AppExchange. It gives Salesforce.com users the ability to customize RSS feeds for pretty much any object managed by the online application. The tool is great, but it begs the following question: how many feed processing services do we really need? And shouldn’t we use a generic one instead anyway?
Indeed, one could say that a feed is a feed, and as long as you can support multiple feed formats — RSS 1.0, RSS 2.0, Atom — any feed processing service such as FeedDigest could do the job. Things are a little bit more complex though. For one, feed processing should not be confused with feed building. For example, both let you define rules for filtering, but a feed processing service filters what comes out of an existing feed, while a feed builder filters what comes into a new feed. If you need an example for this, just think about what a complete feed for thousands of Salesforce.com contacts would look like? It would be pretty useless, unless you could filter contacts out from the source, and that is precisely what a feed builder such as Spanning Feed Builder does.
Now, once you get the feed you need, you’ll want to do something with it. In some cases, using a feed reader will do just fine. For example, I could get notified whenever we close a new opportunity in Salesforce.com. But in other cases, you might want to automate some actions, such as creating a new entry into a public customer database powered by Dabble DB whenever a sale with a new customer is closed. This is where the concept for what could be called a Web Event Broker comes into play.
I mentioned the need for such an online service in a previous article complaining about the fact that too many gateways are currently required to build a working Office 2.0 setup. The idea is pretty simple: use a generic message broker such as ActiveMQ, provide a set of connectors for standard protocols such as REST, RSS, and SMTP, and expose simple user interfaces that will let users define actions to be executed when receiving an event matching a pre-defined set of rules.
The difficulty in such an exercise is not technical, it is conceptual. In other words, the technical infrastructure is available today, and the real challenge is in developing a simple-enough user interface that will allow non-technical users to specify precise-enough triggering rules and build useful actions fed by data carried by the payload of inbound events, be they emails or RSS entries.
If you have any idea on what such a UI should look like, please let me know.
Entry filed under: Office 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[…] I Want a Web Event Broker: good requirement specification. […]
I’m nowhere near as geeky as you Ismael, but I would have thought something like SELECT -> POST that is done with a series of either radio buttons or drop down inputs fed from a pre-defined selector list would be promising. Or am I talking nonsense?
Dennis,
As far as I can tell, such a solution would only work for synchronous events when a user is sitting in front of a web browser. For asynchronous events, you need some kind of a broker I believe.
[…] Edge stuff. Absolutely. I like edge stuff. The BBC for instance has been running a bunch of excellent ‘edge’ projects but which now need an enterprise makeover for the whole thing to come together in a coherent manner. Especially if they’re serious about leveraging their media assets. Many companies are in a similar position. But. I think there is a hidden danger we’ve yet to understand. Many of these edge projects are trying to leverage XML based technologies of the kind so many (including myself) are getting excited about. Where are the integrations that allow organisations to capitalise on the overall potential value of extending business processes? Which is where enterprises should be going. Ismail certainly knows about this. I’ve recently tip-toed into this discussion with some of my Irregular friends because to be frank I’m out of my depth technically though I do understand the business issues very clearly. […]
[…] Once the sponsorship agreement has been signed, with the optional sending of a W-9 form and invoice, we need to get paid. For this, we’ve used three payment methods: PayPal, wire transfer, and plain old check mailed to our P.O. box. For the PayPal transaction and the wire transfer, we received email notifications, but found no easy way to link that back to a SugarCRM object without having to do some custom programming. This is where I could see a need for a new service that would provide simple wizards to create web services connected to specific email accounts. In fact, I need some kind of a web event broker. […]
We’ve been dealing with this very issue for years. Wait until you have a slew of companies that buy a booth or combination of media products from a constantly-changing CAD file on your site in order to complete your “item” field that generates the invoice/sales order — it gets pretty complicated connecting these annoying gateways, as you said.
Not to plug Salesforce.com, but there are a couple of interesting ways that we do what you describe above through their service. In theory SugarCRM could replicate the connectors like iBiz or Saleslogix that synchronize with your QuickBooks sales orders. QuickBooks (I know, the online version is crap) has the abilitity to generate the invoice from the sales order that Salesforce.com creates and passes to QuickBooks, and then out to the customer. Once the customer gets the invoice via email, they can pay directly inside the invoice securely, and that passes back to your QquickBooks system through a merchant account or PayPal.
Again, it’s a bunch of duct tape to get the gateways talking, but it actually does work for us. For the initial part of signing the documents, it is a big help to have a DocuSign or EchoSign, but invoicing, payment and accounting for it all is a huge pita that we’ve sort of solved. Still making plenty of trips to the P.O. box and bank to do the analog check thing though.
The thing that frustrates me the most is the lack of interest in connecting CRM to accounting data for sales order processing alone. My guess is that accounting types just aren’t as interested in the notion of online data as a salesteam would be — as much as the integration of the two would save them per year. NetSuite is about the only thing out there that is fairly integrated on this front, but has it’s challenges too. It would be awseome if there was a SugarERP or SugarQB in the works to fix this disconnect.
Anayways, great site, and congrats on the success of the show, sounds like it was awesome.
Jon,
I could not agree more.
I will forward to the folks at SugarCRM.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment