ESME Blog

Darren Hague has moved the ESME Client based on the Java Api from the Google Code repository to our Apache repository. He also added additional methods including the critical ”getMessages” method which was previously missing. It is now possible to easily create bots that integrate with existing environments.  Darren has also provided a test application (with code) that shows how to use the API.

The JAVA API is still a work in progress but the most important parts are now present.

I’ve been thinking about how to integrate various collaboration tools into ESME based on the use case that users wish to exploit a particular ESME conversation (starting from a single ESME message to series of related messages) as the basis for another type of collaboration (discussion, wiki entry, document, etc.).  By the way, I’ve discussed such interactions in other contexts  in SAP SDN blogs.

I’ve come up with two basic options:

1. The ESME UI is adapted to add new functionality via a new icon on each message panel.
2.  Use of an ESME bot  that listens for messages with certain tags and then performs various activities on the part of users. 

Of the two options, the first involves changes in the ESME core that might cause problems inasmuch as additional functionality might lead to a cluttered UI which would reduce the ease of use associated with a simple UI. The second option appears to be more applicable to a variety of use cases and doesn’t require UI changes based on every new use case. 

A Concrete Use Case 

I’d like to sketch out the steps associated with the use of such a bot. Let’s focus on the use case where an ESME conversation is being used to create a wiki page with the contents of the conversation

Read it all..

Last night, there was an interesting twitter discussion (including @dan_mcweeney, @mrinalwadhwa, @dhague and myself)  about bots that process ESME messages. Originally, the conversation started with ideas concerning an integration of SAP’s xRPM into ESME.

The following ideas originate from this conversation

• A bot is a ESME client without a UI that is specialized to deal with the processing of one or more tags.
• A bot may be developed in any language that has the ability to perform “long polling”.  Although Adobe AIR might be one choice, ABAP (still untested regarding comet-like “long-polling”) and java appear to be better choices.
• Although actions – set by individuals in their respective ESME clients – might be one option to perform this functionality, if a large number of individuals are using similar actions, then there be a performance impact on the central ESME server instance.  A bot that is just another ESME client may be a better option.
• One example of this functionality would be a bot that tracks a particular tag in messages sent by developers. When messages with this tag appear, the bot submits the messages to xRPM  to track their project accounting for this development team.
• There might be a distinction between light-weight tag processing via actions and heavy-duty tag processing via bots.
• The bot would have a better integration possibilities (via web-services, RFCs, etc) with back-ends than the existing ESME clients with their primitive ”Post” actions”. The bots would also be able to deal more effectively with authentication issues with back-ends.
• One another idea is @dhague’s “ESME federation based on ESME using its own REST API as a client could work for server-to-server. xRPM just implements ESME send_msg API.” This idea probably has to be examined in more detail but definitely has potential.

One thing that the discussion demonstrated to me is the importance of integrating microsharing applications into the entire enterprise landscape.