Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column
width70%

General Use case

(Taken from comments from original page)

  1.  a new user visits the ecommerce site
  2. this new user enters a microblog message with a question to the administrator of the site.
  3. One of the system administrators answers the microblog question as quick as possible
  4. further conversation follows.
.

Technical

Prequisites

Technical Description

  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
Integration analysis: ESME Action

Use ESME's existing action architecture to post to akibot via its HTTP POST interface.

We can post to twitter via this mechanism so should also be able to post to you guys as well.

For example,

http://user:password@identi.ca/api/statuses/update.xml
status=%s

The Akibot REST API to send messages has the following parameters:

Name

Description

Type

Optional

Example

Message

Message to be sent

String

 

We're going to launch the Akibot campaign on 11/26/09

Key

Application Key

String

 

 

Message ID

Id of the message to send

 

 

1214

Urgent

Whether message is urgent or not

Number

 

0

Private

Whether message is private or not

Number

 

0

Group ID

ID of group involved

Number

 

1413

User ID

ID of user sending the message

Number

 

1765

User Nick

Nickname of user sending the message

String

 

BobSmith

Message timestamp

Timestamp of message to be sent

Timestamp

 

2009-11-03 10:07:08

We just have to map our parameters to these values.

Prerequisites

  • You would need an ESME instance (either on a separate server or in the same container). 
  • You would need at least two users (administrator, newuser) "newuser" would notbe associated with a particular user but would be more of an anonymous user.  If you had multiple unauthenticated users using the same  e-commerce site, then they would also see / join the same conversation. Depending on the question, they might be able to help the new user as well.

Technical Description

Architecture

ESME as separate component

ESME as OFBiz component

Making ESME an OFBiz component

Advantges

  • let it use the OFBiz authentiation 3. and make a ofbiz userinterface.

Prototype

  1. Deploy ESME in your existing tomcat
  2. Create two users in ESME: newuser and administrator. 
  3. Create a very rough OfBiz UI component to read and post ESME messages. This is the UI for new users. Use the token for the new users in this UI
  4. The administrator could use the same OfBiz UI component but you have to set the token to the administrator user. 
  5. If you don't want to deploy ESME locally, then you could use our test server in the cloud
Column
width30%

Iterations

  1. Use existing akibot infrastructure and attempt to use ESME's action mechanism to post to akibot's REST APIStart changing akibot infrastructure (contextual analyzer, etc) to be more ESME-specificESME as a seprate component
  2. Make ESME an OFBiz component

Questions

  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....