Since writing my last article for TheNextWeb on Socialcast and my conversation with Tim Young, I’ve been thinking about the bidirectional, actionable activity stream concept. It’s less relevant to human constructed messages and more related to machine generated activity messages, specifically exceptions raised from the system. When a source system generates an exception based message that’s put into an activity stream, then generally they require some action or acknowledgement . This is where things can get interesting.
For example, let’s say there is an expense management system for managing employee expense reports and payments. Employee Joe submits an expense report with $750 in miscellaneous “entertainment” expenses which raises an exception. The expense management system is integrated with an activity stream engine; it posts a new message into a stream alerting Jim of the exception (this is where permissions, users, groups, identity, etc get tricky – ignoring that here).
So that’s well and good, Jim is alerted to the exception but now what? Wouldn’t it be great if Jim could act on the message in context?
For example, he could discuss the exception with Joe in context of message in the activity steam. “@joe I need more details on the $750 entertainment charge, and it better be good!” Joe replies, “whoops! sorry that should have been $75, please reject and I will fix.” Jim then rejects the expense report in context of the stream and inherently passes along the stream conversation back to the expense management system as notes to the expense report.
Traditionally, Jim may have received the exception notification via email. He then would have logged into the expense management system, looked at the expense report and either rejected it, notating his question about the entertainment expense or would have emailed Joe asking for details on the expense. Joe then might have replied to Jim or logged into the expense system to add a note and fix the error. This doesn’t sound that bad in this simple scenario, but Jim is very busy and receives hundreds of emails a day and the notification from the system might likely be passed over or Jim just didn’t have time to interrupt what he was doing to go log into the expense management system.
The exception based activity stream use case is more powerful if it allows action to be taken in context. So how might you handle this? Now I’m no activity stream expert, and I’ve had no involvement with any of the standards like activitystrea.ms; I’m just a guy thinking aloud….
What really got me thinking about this use case was a presentation given by Neal Ford at the last social on Implementing Evolutionary Enterprise Architecture. It was primarily based on the Richardson Maturity Model, a model of breaking down REST into three steps that introduces resources, http verbs and hypermedia controls. A hypermedia service enforces a protocol by advertising legitimate interactions with relevant resources at runtime.
In the context of the machine generated activity stream message, the payload of the message would contain a representation of state with respect to the source system activity and links that define possible interactions.
The point of the hypermedia controls is to tell us what we can do next, and the URI of the resource we need to do it. For example, in the example above. The entry might look something like this, with two links – one for approve and the other for reject.

This is a loosely coupled way to provide actions for a given activity. The activity stream system can present the activity message in the stream with the options made available in the payload of the message and selectable actions. This makes no assumption of what type of interface you are viewing the activity stream message through, be it browser, mobile, API rendered, etc. The activity stream system would likely need to abstract the actions in it’s API allowing calls to be made back through the APIs in proxy to the source system.
You could obviously take this concept much further, adding a sequence of actions based on the previous action taken on an activity. For example, if you approve the expense report, the REST call response might return a new list of actions like “view’ the updated expense report.
Like I alluded to above, there are many complexities to this including authentication/identity, authorization, the capabilities of the source system, the capabilities of the activity stream system, etc.
I really have no bandwidth to pursue this idea, but it’s been on my mind for that last few weeks so I thought I’d write it up and see what people think.







