Background

Akibot is the first semantic actionable micro-blogging platform for the enterprise. Akibot not only allows real-time group collaboration and awareness through short, instant messages (like a Twitter for the company), but it also understands those messages and, if applicable, takes action.

A good description is provided by this ReadWriteWeb blog.

Technical Description of the architecture

Akibot works with 2 modules: the front end (the microblog) and the robot (the "brain"). Both modules are completely independent and separate, and they communicate via HTTP POST and XML. When you write a message and post it in the microblog module, it does an HTTP POST call to the robot with the message. The robot gets the message and sends back an XML acknowledging the receipt. 

In the background the robot queues the message for processing. Processing means the message goes through the robot's Contextual Analyzer. The Contextual Analyzer determines the entity (inventory item, vendor, client. contact, marketing campaign, etc. etc.) and the situation (how that entity is being affected in the message/conversation), and, if applicable, makes an HTTP call to inquiry information from the corresponding software (e.g. ERP -SAP; Navision; etc-, Groupware -Exchange, Salesforce, etc. etc).

Once the robot has all this information, it decides if an action is required (usually the action is a response back to the microblog module - but can also be updates, alerts, pushing data to other applications, etc) and proceeds to do so by pushing a message back to the microblog module via HTTP POST (the actions are defined by directives, Akibot comes equipped with some standard directives but you can teach him more that are more specific to your industry).   

Suggested architecture

Collaboration with Akibot

General Use Case

Basically this is how it is working now. The only change would be that Apache ESME would be posting messages to Akibot (robot module, just like the microblog module is doing now) and Akibot would reply back to Apache ESME if needed, and would interface with enterprise software (ERP, Groupware applications).

Integration possibilitites: Overview

There are three basic scenarios

  1.  via an Apache ESME action that posts messages to the Akibot API.
  2. A bot that follows the Apache ESME message stream and either 1) makes a remote call to the RESTAPIlocated on another server or, if the bot was located on the GAE then accesses your API without making a remote call.
  3. Another idea would be to directly embed akibot functionality in Apache ESME as some sort of a plug-in.

Use Cases

Use Messages for Back-end Requests
  • No labels

6 Comments

  1. Ethan Jewett

    I like it.

    I think we should build this integration by improving the HTTP POST ESME action to support a more flexible XML message body, to the point where we can build a message that will be accepted by the Akibot API. This will facilitate integration with other platforms as well.

    We would need a bit more information about Akibot's API. An example message posting would be helpful. Not seeing much on their website at the moment.

    Ethan

    1. Richard Hirsch

      What things do you think are missing from the HTTP POST ESME action?

      D.

      1. Ethan Jewett

        Currently it looks like it only supports the replacement of the message body using %s. We would also need message ID and timestamp. Also, I'm not sure what format the request is in (looks like Akibot request form-encoded). We'd need to look into it.

        If there is a system we are allowed test against, we could definitely start trying it out and filing Jira tickets.

  2. Marcelo Pham

    Here's a proposed layout of the messaging system:

    1. Messages are post in ESME
    2. ESME sends message to Akibot via HTTP POST
    3. Akibot acknowledges the message reception by responding the HTTP POST call with an XML response
    4. Akibot store the message and processes it through its Contextual Analyzer (C>A) module
    5. If necessary, Akibot makes inquiries the corresponding enterprise (ERP or Groupware) application via HTTP REQUEST
    6. The enterprise application processes the inquiry
    7. The enterprise application responds to the inquiry with an XML response
    8. Akibot processes the enterprise application response with its Directive Processor (DP), which decides if any action is to be taken
    9. If Akibot decides that an action needs to be taken (for now, just sending back a message to the microblog) it does so by sending the message via HTTP POST call to ESME
    10. (Optional) ESME can send back an acknowledge to Akibot letting it know that the message was successfully received

    (I will post a use case example that we're working on in a few hours)

    The messaging threads that need standardization are 2, 3, 5, 7, 9 and 10.

    1. Richard Hirsch

      Looks good.

      A few additional points / ideas

      1. What sort of back-end system are we talking about? Are you already using a system that we can re-use for initial tests?
      2. We also have to agree on what sort of message contents (formats, etc.) will be used Are there special words (invoice, etc.) that are necessary.  This is, of course, linked to what sort of back-end you guys are using.
      3. What sort of rules are present in the DP? The obvious one would be to create an ESME message.
      4. Regarding 10, we do respond with a XML response to those submitting messages via REST API
      5. Do you want to use the old REST API or the new "Streaming API" (Ethan's baby :->)?
      6. We just probably use a POST action as Ethan suggests as a first step
      7. You are right about the messaging threads needing standardization (especially 2 and 9). Maybe you can look at my table in the wiki page and tell me about what the parameters mean and whether they are optional or not.  We will have to map them to our fields.
      8. We also have to think about user-ids. Do they need to be synchronized? Probably....

      1. Marcelo Pham

        Hi there,

        1 and 2. Next week we will upload an updated version of the wiki page that will clarify these items
        3. Right now we have only a few directives for the robot, mostly related to inventory. You may see a sample directive entry screen here: http://www.akibot.com/media/custom_directives.html
        We are working on the API control panel where you will be able to add/edit directives, configure feeds, groups, etc. etc. We will give you access as soon as done

        5. Any format you want, we have no problem (wink) just let us know

        7. Sure, we will take a look at the table in the wiki page
        8. Actually on Akibot's side, we only care about companies and groups, we do not check users... we thought it didn't make too much sense, because a user sync will be tough to do (users come and go, change their passwords, etc. etc.) what are your thoughts? having a user-id and/or user nickname provided by the front end is more than enough for us (authentication is already made by api key)

        Thanks