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.