incubator-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 12:21:17 GMT

Here is the use case:

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?


On Sun, Dec 13, 2009 at 12:24 PM, Vassil Dichev <> wrote:
> Maybe it's better if we have an overview of the whole use case rather
> than trying to solve things piecemeal. Perhaps there's a better way to
> do this and we don't need the response gymnastics.
> If there's no other way, maybe we can extend the syntax for the HTTP
> POST action so that the user can choose whether they want the response
> as a message or not. But I don't want to impose unsolicited HTTP
> responses on the user's timeline if all they wanted was to repost
> their message somewhere (e.g. Twitter).
> On Sun, Dec 13, 2009 at 1:00 PM, Vassil Dichev <> wrote:
>> I'm wondering how far we can push actions to do something they are not
>> well suited for. Returning the response is fine but then usually it
>> has to be processed in one way or another. The question is: is this
>> something, which would only work in the 12sprints integration
>> scenario, or would it also be useful for other scenarios?
>> In general, when using an HTTP POST, we're not interested in the
>> response. I think this action was conceived only as a way to resend
>> messages to other services, including microblogging ones, like
>> Twitter. I'm not sure folks would be interested in the "200 OK"
>> response always being returned and posted to their timeline. Besides,
>> if this introduces subtle to catch bugs, like infinite loops, we'd
>> better think twice about including such power features.
>> In general, if we're interested in the response, then usually there is
>> complex logic associated with it- conditionals, probably XML/String
>> processing, and that's something not directly related to posting a
>> message.
>> Integration scenarios is something which ESME is good at, but before
>> adding functionality, we have to think it through, so that it doesn't
>> jeopardize stability and increase complexity unnecessarily.
>> On Sat, Dec 12, 2009 at 9:33 PM, Richard Hirsch <> wrote:
>>> Cool.
>>> I'll try it out tomorrow.
>>> I already created such an infinite loop when I was working on the
>>> akibot integration. Had to deactivate the action before it flooded the
>>> systems with messages.
>>> D,
>>> On Sat, Dec 12, 2009 at 8:29 PM, Ethan Jewett <> wrote:
>>>> I've posted a diff to this issue
>>>> ( that does what is
>>>> requested. Please keep in mind that this can pretty easily result in
>>>> an infinite loop of messages, if you are (for example) using an action
>>>> to post all of your messages to a third-party service.
>>>> Ethan
>>>> On Sat, Dec 12, 2009 at 12:00 PM, Richard Hirsch <>
>>>>> I'm been thinking about this integration and I think we need some way
>>>>> to publish the information that is return from a HTTP post action. For
>>>>> example, posting to 12sprints leads to a response that contains the
>>>>> activity ID. Without surfacing this ID, it is impossible to get the ID
>>>>> except by going directly to 12Sprints.
>>>>> To deal with this issue, I think it would useful for the HTTP Post
>>>>> Action to post a message with the result.
>>>>> I've created a JIRA item to deal with this:
>>>>> On Wed, Dec 2, 2009 at 3:05 PM, Richard Hirsch <>
>>>>>> Then you would probably have a problem in that it would the tags
>>>>>> wouldn't be unencoded.
>>>>>> D.
>>>>>> On Wed, Dec 2, 2009 at 2:31 PM, Vassil Dichev <>
>>>>>>> Great, does this issue still make sense? I think you are relying
>>>>>>> the fact that there's a single tag in there. What if you use
>>>>>>> They would be separated with spaces.
>>>>>>> On Wed, Dec 2, 2009 at 3:25 PM, Richard Hirsch <>
>>>>>>>> Fixed this myself:->
>>>>>>>> The integration with 12sprints is now based on dynamic information
>>>>>>>> based on message tags. I set the activity ID in the action
through the
>>>>>>>> message tag.
>>>>>>>> D.
>>>>>>>> On Tue, Dec 1, 2009 at 4:28 PM, Richard Hirsch <>
>>>>>>>>> Unfortunately, I'm stuck now, because I can't use %t
in the HTTP Post
>>>>>>>>> action URL. :-<
>>>>>>>>> I've created a Jira item (
>>>>>>>>> ) describing
>>>>>>>>> problem
>>>>>>>>> D.
>>>>>>>>> On Tue, Dec 1, 2009 at 12:24 PM, Richard Hirsch <>
>>>>>>>>>> I'm asking first on a 12sprints discussion if I can
provide details
>>>>>>>>>> about using the REST API.
>>>>>>>>>> D.
>>>>>>>>>> On Tue, Dec 1, 2009 at 12:13 PM, Vassil Dichev <>
>>>>>>>>>>>> Just created a 12sprints activity via an
ESME action.
>>>>>>>>>>>> Took a bit of time to get the formatting
right but it works now.
>>>>>>>>>>> Great! Can you share an approximate syntax for
the header/body? It is
>>>>>>>>>>> always better to have more info we could document.

View raw message