General Use case(Taken from comments from original page) - a A new user visits the ecommerce site
- this This new user enters a microblog message with a question to the administrator of the site.
- One of the system administrators answers the microblog question as quick as possible
- further Further conversation follows.
.Technical PrequisitesTechnical Description- Messages are post in ESME
- ESME sends message to Akibot via HTTP POST
- Akibot acknowledges the message reception by responding the HTTP POST call with an XML response
- Akibot store the message and processes it through its Contextual Analyzer (C>A) module
- If necessary, Akibot makes inquiries the corresponding enterprise (ERP or Groupware) application via HTTP REQUEST
- The enterprise application processes the inquiry
- The enterprise application responds to the inquiry with an XML response
- Akibot processes the enterprise application response with its Directive Processor (DP), which decides if any action is to be taken
- 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
- (Optional) ESME can send back an acknowledge to Akibot letting it know that the message was successfully received
Integration analysis: ESME ActionUse 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 Apache ESME instance (either on a separate server or in the same container).
- You would need at least two users (administrator, newuser) "newuser" would not be 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 DescriptionThe basic idea is that an OFBiz UI will be created to capsule the Apache ESME functionality Apache ESME as separate component Gliffy Diagram |
---|
size | M |
---|
name | ESME - OFBiz collaboration - Separate |
---|
page | ESME as Chat+ in OfBiz |
---|
pageid | 9373498 |
---|
space | ESME |
---|
|
Apache ESME as OFBiz componentAdvantges- let it use the OFBiz authentication
- allows Apache ESME to use essential system functions like system messages and ease of installation
Prototype- Deploy Apache ESME in your existing tomcat
- Create two users in Apache ESME: newuser and administrator.
- Create a very rough OfBiz UI component to read and post Apache ESME messages. This is the UI for new users. Use the token for the new users in this UI
- The administrator could use the same OfBiz UI component but you have to set the token to the administrator user.
- If you don't want to deploy Apache ESME locally, then you could use our test server in the cloud
Thoughts on authenticationObviously, the goal would be to have some sort of a common authentication between Apache ESME and OFBiz. In the basic use case, all you really need are two users - anonymous and administrator. Anonymous would be for those users who are not administrators. Since I'm assuming that chat would be available for all users, this would mean that users would see the conversations between other users and the administrators. This would also mean that all users could participate in such conversations. In future iterations of the OfBiz / Apache ESME collaboration, other options would be available. Currently, Apache ESME has its own user administration and can't use the user administration from the container. We are looking at various means to overcome this gap but we haven't had time to implement them yet. This means that initially there would be a double administration of users. Adding, deleting users and changing user properties would have to occur twice - once in Apache ESME and once in OfBiz. One way to get around this would be to expand our API to deal with such administrative tasks. Since our APis are based on tokens, you would need to store a token in the user object in OFBiz that could later be used when making calls to Apache ESME. |