esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: 12sprints integration works
Date Sun, 13 Dec 2009 18:07:01 GMT
Good points. We also have to remember that the user of an action isn't
a developer but a normal user who wants to quickly add simple logic to
his message processing.

Maybe we should have some rule concerning the return value of the HTTP
post action - if you need to access the response then an action is
probably the wrong choice for an integration.  A bot is more likely
the optimal integration method.

How does that sound?

>Another option would be to provide a regular expression matcher for actions,

What would this look like?  Maybe it is a feature for a later release.


On Sun, Dec 13, 2009 at 6:09 PM, Ethan Jewett <> wrote:
> I've thought about this a bit now and I'm also not comfortable with
> the idea of an sending post responses as messages in the way that
> Richard and I have implemented it (which I think should be taken as a
> prototype).
> I see a few major issues:
> 1. It is really really easy to create infinite loops
> 2. Most people won't want posted messages showing up in their timeline
> 3. We can't really do much subsequent processing on messages when they
> come back. (Limitation of actions, currently)
> 4. It's tough to set up the action properly so that it works at all.
> (It took me about 45 minutes, not including putting in Dick's code to
> expand %t in the URL.)
> Just to be completely clear, the use case is something like this:
> 1. Some message shows up that we have decided means that an activity
> needs to be created in 12sprints (or a Tweet, or whatever)
> 2. Activity is created successfully
> 3. Message shows up saying "Activity 23ikcjas successfully created in
> 12sprints! Use tag #12sprints:23ikcjas to send messages to this
> activity."
> Then a couple of things can happen:
> 1. Users can see this message and create messages in ESME that are
> posted to the 12sprints activity (if they have created the proper
> action, or someone else has created said action - maybe a utility
> user)
> 2. A technical system that is integrated with ESME can see the message
> (a BPM system, possibly?) and configure itself so that updates to the
> BPM activity (that initially triggered the ESME message that was
> turned into a 12sprints activity) will have the tag
> #12sprints:23ikcjas
> I'm convinced that this is a very powerful use case, but I'm also
> convinced that the way we have things set up now won't work for this
> use case. It's just too complicated. To meet the use-case, we probably
> need
> 1. A way to specify that a post action will return a message based on
> the response (and possibly the format of the message) - this will
> address issue 2 and partially issue 1
> 2. A way to catch these responses in a fine-grained way and do
> something about them. I'm talking about something more fine-grained
> then simple tag matching. I think there are a couple of options here:
> Match multiple tags and then provide a replacement syntax for these
> tags in the same order they are matched. (e.g. Match "#12sprints &
> #askjfew", and put %t1 and %t2 into my post request, which are
> "#12sprints" and "#askjfew" respectively.) Another option would be to
> provide a regular expression matcher for actions, which would actually
> be quite awesome, come to think of it. This will address issue 3.
> 3. (later) A wizard for creating actions, especially complex actions
> like HTTP POST and RSS/ATOM actions. This will address issue 4.
> With regards to issue 1, I don't see a clear way out of the maze.
> Perhaps an action could attach the action-id to the "via/from"
> metadata of the message, then not act on messages that it created.
> This solves the 1-level-of-indirection part of the problem, which is
> probably 99% of it.
> Ethan
> On Sun, Dec 13, 2009 at 7:50 AM, Richard Hirsch <> wrote:
>> On Sun, Dec 13, 2009 at 2:25 PM, Vassil Dichev <> wrote:
>>> The HTTP POST action already has a somewhat complicated syntax, so
>>> introducing more special cases are going to make both parsing and
>>> understanding more difficult.
>>> Regarding duplicated messages, there is already a mechanism for
>>> avoiding infinite messages when fetching feeds- the Atom feed, for
>>> instance, already has unique ids, so only messages with unique new ids
>>> are sent to the timeline. Does 12sprints offer RSS/Atom feeds of
>>> activities?
>> Don't know if it uses RSS feeds for activities - good idea though .
>> (although there is a REST API call that monitors activity events:,
>>  Right now we are looking at primarily the creation-related REST API
>> calls.
>>> The best chance of eliminating duplicate messages and loops is to have
>>> some unique metadata, which differentiates messages. If any such
>>> metadata is lost, the best chance we got is matching the text strings,
>>> and this has too many disadvantages to use as a general solution.
>> But this doesn't solve the problem that is also present with non
>> ATOM-RSS feeds. You can create an action that resends a message to
>> ESME under a different user id. The action test is messages that
>> contain the string "20". If you follow the second user, then you will
>> create an infinite loop.
>>> Anyway, if I understand correctly, if the user needs to create an ESME
>>> action for each new unique 12sprints activity manually, that's
>>> probably more overhead than going to the 12sprints UI.
>> No - the idea is that after the first activity is created, you take
>> the activity id that was returned in the response and use it as a tag
>> for messages related to that activity. Then you use the %t to create
>> the REST API call that is activity-specific.
>>>> The integration is between ESME and 12sprints which is tool that
>>>> assists in making decisions. The idea is the user creates an activity
>>>> in 12sprints based on a message in ESME. This message should be sent
>>>> to 12sprints via a HTTP Post action.  This works with the current HTTP
>>>> Post action. The problem is that the response from the 12sprints REST
>>>> call includes the activity id. This activity ID is necessary for all
>>>> other activity-related REST API calls. Of course, the user could open
>>>> up the 12sprints UI find out the ID of the activity and return to ESME
>>>> but we were trying to avoid this overhead. That is the idea behind
>>>> sending the HTTP Post action response as a message.
>>>> Of course, it would ideal to add further logic to processing this HTTP
>>>> Post response but I think this would make things too complicated for
>>>> the normal user.
>>>> The ideal use case would be where the user could decide whether the
>>>> HTTP Post response is resent and into which pool.
>>>> Of course, this would either mean that the UI would have to be
>>>> enhanced or that new tags could be added to the action. For example,
>>>> "responseTarget=[poolname]". This flag wouldn't be sent to the HTTP
>>>> Post. If the flag is absent, then the response is not resent. If the
>>>> pool is empty or the user is not part of that pool, then the message
>>>> is sent to the public pool.
>>>> Regarding the infinite loop, this can happen with the current
>>>> implementation as well. The question is how to avoid it?

View raw message