ESME Blog

Introduction

I have just finished integrating ESME into Apache OFBiz which is an open-source ERP platform.

The Apache Open For Business Project is an open source enterprise automation software project licensed under the Apache License Version 2.0. By open source enterprise automation we mean: Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.

I used OFBiz’s event environment to plug-in ESME functionality.

ECAs are pretty straight forward: when an Event occurs, if the Condition(s) are met then Action(s) are performed. The Events supported currently are Entity (EECA) events which basically correspond to database record CRUD events, Service (SECA) events which correspond the various stages of a given service’s invocation (invoke, validate, commit, return, etc.) and Mail (MECA) events which occur when an email is received.

I used the entity “Facility” as a prototype but any entity would be possible. I also selected that the events would just be sent when new facilities were created but I could have just as easily responded to other entity-related events (deletes, updates, etc.)

My goal was to easily integrate the two environments as quickly as possible. Once I figured out what to do, the integration was relatively easy. I used a local ESME instance that was separate from the OFBiz instance.

Screenshots

Here I create a new facility https://localhost:8443/facility/control/CreateFacility.

Here is the screenshot from ESME that shows the message that was sent in response to the creation of a new facility.

Technical details

Authorization

The use of the ESME REST API requires a token. I’ve manually stored this token in the externalAuthId value of the UserLogin entity. https://localhost:8443/webtools/control/ViewGeneric?entityName=UserLogin&userLoginId=system

I added a token to the system user to be used in the ESME REST API calls.

Message Contents

I’ve selected just three attributes of the Facility entity to be displayed in the ESME message. I looked at the details of the entity and just selected those that were easiest to use. Other attributes could also be used as well. https://localhost:8443/webtools/control/ViewGeneric?entityName=Facility&enableEdit=true

Implementation Details

For details on the implementation, see the Apache ESME wiki page here

Improvements

1. Use of externalAuthId to store the ESME token. The use of SSO would probably be better

2. Use of system as service user. For some reason, the user who fired the event was always “system” rather than the actual user who created the facility.

3. No OFBiz UI. Right now there is no UI in OFBiz to display the ESME messages.

4. Ideally, there should be a common service that sends the message to ESME and entity-specific services that compose the message to be sent.

5. Use of the new Streaming API to send to a specific pool rather than the public pool. Right now, I’m using the Twitter API to send the message. Ideally, the new API should be used to send to a specific pool.

12sprints is a new collaboration tool from SAP that was in stealth mode for a while and now has surfaced with a bang.

12sprints is part of a new product category called collaborative decision-making.  Collaborative decision-making provides tools that bring people together with the latest information and analysis or decision techniques to drive towards a particular outcome.  Unlike products in the market that offer general collaboration platforms like Microsoft SharePoint, Google Wave, or Salesforce Chatter, 12sprints is a specialized application for goal-oriented work that can be used in conjunction with any of these products. [SOURCE]

 12sprints has a REST API that is still in development and which was introduced on SDN recently.

We decided to work on two simple use cases to test out the REST API from 12 sprints.  By using ESME’s action framework  - in particular using the HTTP Post action-  we enabled ESME users to interact with 12sprints via particular message tags.  The responses from the 12sprints REST API are then posted to ESME so that users can take the information and use it for later processing.

Note: The authentication for the 12sprints REST API is currently based on basic authentication. The syntax of the authentication is [username]:[password] that is uuencoded

Note: I would love to show screenshots from 12sprints with the created objects but, since 12sprints is still in beta, publication of screenshots isn’t permitted.

Use case 1:  Creating an activity

The first use case was the creation of a 12sprints activity from ESME.  The action takes the message string and creates a 12sprints activity with the activity title being the message text. The resulting activity id is returned to the user as a message.

The syntax of the action is:

Use case 2: Creating a decision

The second use case was the creation of a decision in a particular activity and the idea is the tag of the message is the activity ID which is necessary to create data objects. The message contents are then used as the contents of the decision.  The action is fired based on messages that contain the word “choice”.

The syntax of the action is:

Current restrictions

This functionality is currently not part of our committed code base. I used a patch from Ethan Jewett to add the action-related functionality to repost the response of the HTTP Post action.  It isn’t committed, because we are still working on the optimal functionality that doesn’t compromise our existing concepts.

If you want to play with this integration, it is currently live on our Performance Instance in the cloud

Plans

These two uses were just first steps in our planned deeper integration with 12sprints. We decided to use to actions, because they are relatively easy to implement and are easy enough for most end-users to use. For more complicated use cases,  we are looking at ESME bots as the more appropriate programming model.  For example, we have one idea of taking an ESME conversation and creating a 12sprints activity with all the individuals and messages  being transferred to the activity.  Other ideas involve sending status messages from 12sprints (activity changes, etc.)  back to ESME so that users can follow activities without having to login on to 12sprints. Another crazy idea is to use “+1″ and “-1″ in ESME to express positive or negative reactions to particular activities.

We are now starting a collaboration with akibot.

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.

What intrigued me about akibot was the semantic analysis of microblogging messages.

The basic idea is that akibot functionality can complement existing ESME functionality. The ESME community isn’t able to do everything on its own. Therefore, we look for partners who will work with us to further establish microblogging in the enterprise.

I’ve started a wiki page to describe the collaboration. The detail description of the use case that we are currently exploring is also present in the wiki.

As the diagram below illustrates, the use case focuses on the use of akibot’s Contextual Analyzer (C>A) module to semantically analyze messages and provide functionality that is currently not present in ESME’s action framework. The akibot Directive Processor (DP) then decides if additional processing is necessary and what additional actions are required.

Initial tests between ESME and akibot have proven successful and we are now further exploring collaborative options.

ESME has a REST API that is necessary for clients to access data / functionality. There was some degree  of debate / criticism – some of it rather critical  – of this initial interface. Ethan Jewett has blogged about a suggestion for a new REST API for ESME which not only provides an examination of main points of REST-related debate but also the foundation for a new REST API.  Ethan is planning on moving the discussion over to the Apache wiki for further discussion.

Please join us in creating the best possible REST API for ESME.

Note: I don’t currently have the link for the page in Apache wiki with the discussion but I will update this blog when I have the link.

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

One idea that we’ve kicking around is an ESME client that is context-sensitive.  The idea would be that just ESME messages are displayed that reflect the particular contents on the page on which the ESME client is running.

For example, an ESME client is running on an internal blog page that deals with sales problems with a particular customer “Patriot Chairs”. The ideal situation would be that the ESME client shows all messages that are tagged with the words “sales”, “Patriot Chairs”. The idea is those reading the page could get a feeling for the corporate “heart-beat” dealing with these areas.  The blog reader would be able to see other messages relating to the particular customer in question and sales issues in general.  If desired, the blog reader could then interact with those individuals talking about these matters.

To meet these requirements, the ESME client would have to respond to how a particular blog page is tagged. Whether this tag is based on URL-based tags or another mechanism would be implementation-specific and would in all likelihood be based on the details of the integration environment.

This use case would also probably require new REST API functions (for example, “GetFilteredMessages” http://esme.example.com/messages?tag=sales) to be able to search the public timeline for particular tags.  Another option would be to have a client that performs the filtering actions in the JSON transformation.

Daniel Koller has created a  ESME Mailet is a plugin for the Open source Mail Server Apache James which allows users of an ESME infrastructure (both humans and technical systems) to send email messages to an ESME instance using their own identity. Messages sent through the mailet show up as personal messages from these end users, so people following you get them in the respective blogging timeline.  The install guide is available on Google Docs.

This new functionality is especially useful for integrating legacy applications into the ESME environment inasmuch as many such applications might not be able to integrate via the REST API but usually have the ability to send emails. Furthermore, an email interface also allows users to post ESME messages with mobile devices. This is a useful functionality until native ESME clients for mobile platforms are available.

In a recent blog about Enterprise Twitter,  Mike Giotta of the Burton Group described 10 questions that enterprises will ask regarding the use of microblogging tools. One question was “Integration with Microsoft Communicator and IBM Sametime”. At first, I disregarded the idea and thought “who needs an integration? They are two tools based on two different collaborative metaphors”.  After a round of sauna, I started to think about ways that the two might complement one another.  Based on this “heated” discussion with myself, I set out and tried to create use cases for this integration.

Read it all..

In my last blog, I mentioned my tests with the Stax.net cloud as hosting opportunity for ESME.  Well, after fighting various issues dealing with proxies and request timeouts,  I finally got ESME installed at Stax, then logged in via OpenID and posted my first cloud-based ESME message.

I really think the Stax environment is great once you get the hang of it.

To get ESME working, I used the sample application from Stax and then copied the files from the ESME war file from the Google Code site. I copied all the esme files into the “webapp” directory and then did a “stax deploy” command to load it all up into the Stax system.  I had to make some adjustments to the ant build file for the Stax deployment, because I have a limitation on the size of files that I can send via HTTP ( Therefore, the source code currently available in Stax is missing all the Jar files.)  Besides that problem, everything worked out well.

I also was able to use the cloud-database in the Stax environment rather than the existing Derby implementation. If you wanted to use a remote DB (for example, behind the firewall), you just have to change the details.

I just added the following snippet to the web.xml file:

<resource-ref>
<res-ref-name>esme</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

and the following snippet to the stax-application.xml

<resource name=”esme” auth=”Container” type=”javax.sql.DataSource”>
<param name=”username” value=”esme_2″ />
<param name=”password” value=”xxx” /> [password is hidden for this blog]
<param name=”url” value=”jdbc:stax://esme” />
</resource>

Now, that ESME is installed, it is possible to perform operations-related tasks -all from my browser.

Still open

• There are still exceptions dealing with file-based activities.  For example. the search interface via Compass currently doesn’t work, because it uses file. These have to be changed as well to have a fully functional application.
• It would be cool to be able to clone this application(including database)  for others.
• It would be useful to have the ability to restrict access to particular IP addresses (maybe, this is a function for which Stax could charge?)