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

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.

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.

The JAVA API is still a work in progress but the most important parts are now present.

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

 Demand 

1. Based on an ESME conversation, a wiki page should be created in a particular wiki. Users who have contributed to the ESME conversation should have write access to the page.
2. The contents of the ESME conversation should be present on the page in the form of a list.
3. Users who participated in the conversation should receive a link to the wiki page when it is created. 

Assumptions

1. A user has participated in an ESME conversation and would like to create a wiki page based on this conversation.
2. The user adds the tag “create_wiki” and resends the last message
3. The ESME bot receives the message with the tag “create_wiki”
4. The ESME bot uses the conversation id from the tagged message and retrieves the whole conversation via the REST-API
5. The ESME bot creates the wiki page and fills the page with contents from the messages in the conversation
6. The ESME bot sets the permissions on the wiki page based on those user_ids taken from the messages in the conversation
7. The ESME bot sends a message to those users who participated in the conversation with a link to the wiki page.
8. The ESME bot also sends an message to its followers describing the new wiki page [optional] 

Open issues

1. What happens when errors occur?
2. Should users have the ability to track the requests they have sent?

 Note: Since this is obviously a use case related to a workflow, this seems to be perfect opportunity to create a bot that starts a process (perhaps one associated with SAP’s Guided Procedures or SAP’s new BPM environment ).

Other use cases

Other user cases might involve ESME installations that involve interactions with existing and potential customers. The use of bot could be used to create complaints on back-end systems or create opportunities in CRM systems. The idea is that the particular pieces of micro-blogging conversations are not lost but can be followed up / tracked via back-end systems that are more focused on such tasks.

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.

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.

Note: Although I haven’t had the “pleasure” of using the Microsoft Communicator, I was an avid user of Microsoft Messenger until I discovered Twitter.

I’ve created a ton on simple ESME clients (ranging from VBA to PL/SQL to Zoho Creator) and usually the integration focuses on sending messages. An integration of an IM client based on this foundation doesn’t make sense, because both systems are too closely related to one another at this level. A deeper integration might be necessary.  Another possible integration might be one in which groups from Microsoft Communicator might be used to create groups in ESME and vice-versa.

Use Cases

Let’s look at a few more use cases and see where the integration might lead to.

Use Case 1: Basic integration

Assumptions

1. Both systems are present in a large multinational enterprise with multiple divisions.

Steps:

1. A sales person gets a question from a customer about a new product “Lumberjack” from an another division.  The sales person herself has no knowledge about this product.
2. The sales person asks fellow sales reps via an IM session in MS Communicator and they also have no idea about the new product. Thus, the sales person’s own social network is of no help.
3. The sales person opens his ESME pane in the MS Communicator and searches for the word “Lumberjack” in the ESME stream.
4. The sales person sees a list of messages that either contain the word “Lumberjack” or are tagged with the word “Lumberjack”.
5. By clicking on a particular ESME message, the sales person can see the latest ESME messages from this individual.
6. The sales person can then reply via ESME  to individuals who have created the relevant messages.

This loose integration is primarily based on embedding the ESME UI into the UI of the Microsoft Communicator

Use Case 2: Tighter integration

Assumptions

1. ESME and the Microsoft Communicator environments have a common user-id base. Without a common identity pool, the integration isn’t going to work.
2. Both systems are present in a large multinational enterprise with multiple divisions.

Steps:

This use case continues at the end of the first use case.

1. When the sales person selects an ESME message, the user interface also shows communications-relevant information (including presence data) from Microsoft Communicator.  If the user is available, then the sales person could start a video-conference or call that individual via Microsoft Communicator.

The integration is deeper and involves merging the data from ESME and Microsoft Communicator. In all likelihood, this integration would use ESME’s REST-API in a Microsoft development environment.  I had a quick look for details on extending MS Communicator UI functionality but didn’t find anything. I assume that it is there.

There is also a Unified Client Communications API (UCC API) for the Microsoft Communicator which might allow ESME bots to use UCC functionality.

Summary

It is the combination of the two collaborative metaphors that has the greatest value.  As Mike Giotti suggests  there should be movement towards a tighter integration between “unified communications and collaboration platforms” . I’m assuming that many purely micro-blogging platforms will not survive.  I think ESME’s focus on being a white-label microblogging tool that be easily integrated into a variety of platforms and tools (just take a look at posts in the ESME blog about clients) has  in the long term a greater chance for success.

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?)