12sprints is part of a new product category called collaborative decision-making. Collaborative decision-making provides tools that bring people together with the latest information and analysis or decision techniques to drive towards a particular outcome. [SOURCE]
12sprints has a REST API that is still in development and which was introduced on SDN recently.
Apache ESME (Enterprise Social Messaging Experiment) is a secure and highly scalable microsharing and micromessaging platform that allows people to discover and meet one another and get controlled access to other sources of information, all in a business process context.
We decided to work on two simple use cases to test out the REST API from 12 sprints. By using ESME’s action framework - in particular using the HTTP Post action- we enabled ESME users to interact with 12sprints via particular message tags. The responses from the 12sprints REST API are then posted to ESME so that users can take the information and use it for later processing.
Both examples might be seen as representing one step in a typical microblogging conversation in the enterprise. There is a discussion about a certain topic that requires a decision. Instead of having to switch to another tool to create this decision, the creation can take place within the microblogging environment. The flow of the initial conversation doesn't have to be broken. Of course, the decision-making process itself takes place outside of the microblogging environment but that initial burst of creativity isn't disturbed.
Note: The authentication for the 12sprints REST API is currently based on basic authentication. The syntax of the authentication is [username]:[password] that is uuencoded
Note: I would love to show screenshots from 12sprints with the created objects but, since 12sprints is still in beta, publication of screenshots isn’t permitted.
Use case 1: Creating an activity
The first use case was the creation of a 12sprints activity from ESME. The action takes the message string and creates a 12sprints activity with the activity title being the message text. The resulting activity id is returned to the user as a message.
The syntax of the action is:
https://[username]%40[password]@beta.12sprints.com/v1/activities
header:Content-Type=text%2fxml
<activity name=”%s”></activity>
Use case 2: Creating a decision
The second use case was the creation of a decision in a particular activity and the idea is the tag of the message is the activity ID which is necessary to create data objects. The message contents are then used as the contents of the decision. The action is fired based on messages that contain the word “choice”.
The syntax of the action is:
https://[username]%40[password]@beta.12sprints.com/v1/activities/%25t/items
header:Content-Type=text%2fxml
<item name=”Decision item from ESME”><method_item>
<method_type name=”Decision”/><decision_item><goal>
<description>%s</description></goal></decision_item></method_item></item>
Current restrictions
This functionality is currently not part of our committed code base. I used a patch from Ethan Jewett to add the action-related functionality to repost the response of the HTTP Post action. It isn’t committed, because we are still working on the optimal functionality that doesn’t compromise our existing concepts.
If you want to play with this integration, it is currently live on our Performance Instance in the cloud
The integration user interface is still relatively crude but shows the basic integration pattern. The fact that the user must manually copy the activity id to be used in later messages is especially irritating but could easily be repaired via a flashier custom UI.
Plans
These two examples were just first steps in our planned deeper integration with 12sprints. We decided to use actions, because they are relatively easy to implement and are easy enough for most end-users to use. For more complicated use cases, we are looking at ESME bots as the more appropriate programming model. For example, we have one idea of taking an ESME conversation and creating a 12sprints activity with all the individuals and messages being transferred to the activity. This is similar to how 12sprints responds when it receives an email as an activity creation point.
Other ideas involve sending status messages from 12sprints (activity changes, etc.) back to ESME so that users can follow activities without having to login on to 12sprints. Another crazy idea is to use “+1″ and “-1″ in ESME to express positive or negative reactions to particular activities.
Why is this particular integration important?
If you look at the evolution of Twitter, one of the most important lessons was the presence of an API that external applications could use. 12sprints is wise to do so as well. If you search on the web for examples of using this 12sprints API, however, you'll find very few examples. To get the momentum going, developers have to start to play with this new functionality. I wanted to start with a few basic examples, so that developers can see how easy it is to integrate with this environment.
The current blog demonstrates two connected events - connected via a common activity id as a tag. This tag also represents a certain decision context that could exist outside of the web UI from 12sprints. Based on this realization, other more powerful integrations are possible.
The integration of other social networks/communities was also a feature request from Srinivas Reddy’s Weblog about 12sprints - so let's just say that we are trying to meet this user requirement.
Note: Another version of this blog was also published on the ESME blog.
