Background

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.

Suggested architecture

Integration possibilitites: Initial thoughts

There are two basic scenarios 

  1.  via an ESME action that posts messages to a OfBiz API. The easiest way may be to have ESME just send an email to the OFBiz environment.
  2. A bot that follows the ESME message stream and either 1) makes a remote call to the OfBiz API

The fundamental idea is to use OFBiz Event Condition Action (ECAs) as the basis for the integration.

About ECAs:

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.
Conditions are defined against whatever context is will be available when the event occurs, the record fields for an EECA, the in/out parameters for a SECA and the email contents for a MECA (from, to, subject, etc.)

Actions are just OFBiz services to be invoked when the conditions are met.

Sending event notifications

ECAs are the way to go for this and we'd just define services to be used as actions which send the message to ESME.  You'd probably create a single generic service that is used to send any message and then use that service within other services for sending specific messages e.g. an ECA would invoke sendPurchaseOrderChangeNotification which would prepare the message contents and call sendEsmeMessage to actually send the message.

Receiving messages

For this we could either create a new type of ECA specifically for ESME messages or perhaps even generalize MECAs to support any type of message so that it stands for Message rather then Mail.  ECAs would then be defined and evaluated when an ESME message is received and service actions invoked to handle any processing and responses that need to occur.

The receipt of the message in OFBiz can occur via various means.  If OFBiz has a RESTAPI for ECAs, then you can create an ESME action to send messages to OFBiz when certain ESME events occur.  Or if there some sort of ECA for dealing with email events, then we can also use an action that sends email. If you want a deeper integration, you could have a bot that uses one of our various APIs to read the message queue and then create OFBiz events.

ECAs are only triggered by internal events, as I described above: an OFBiz service invocation, database operation or email receipt.  We don't have a REST API for invoking services, there is basic support via SOAP, JMS or HTTPS (but not what you'd call REST).  Services can also be invoked using HTTP(S) POSTs via our standard request handler (typically used for serving regular web pages and ajax calls) but that requires a little additional legwork in that you have to define request-event-response mappings in our XML based web app controllers.

Use Cases

Send users status information from OfBiz
Use Apache ESME to provide Chat+ functionality
  • No labels

15 Comments

  1. Hans Bakker

    A request from a customer running an OFBiz installation:

    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.

    Is this possible with ESME? If yes, we are willing to spend time creating the interface from OFBiz to ESME in about 2-3 weeks
    can you support that?

    Regards,
    Hans

    1. Richard Hirsch

      I could imagine that such a scenario should work. The use of ESME would mean more of an open communication (ala twitter) rather than a chat restricted to  a few parties.

      • 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 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. 
      • If you had other individuals with ESME users, they could follow the conversation and join in from other clients (iPhone, etc.). They wouldn't necessarily have to be using the e-commerce site to participate in the conversation.

      Why don't we continue to spec out the use case to make sure that we are talking about the same thing.

      What sort of support would you need from us? We have a test instance that is available for testing the collaboration and there are various clientsavailable that you could use as examples. We could provide also support you on more design-related issues.

      D.

      1. Hans Bakker

        Probably next week we can spend time on this.

        What i think of is:
        1. copy the whole ESME in ofbiz as a component.
        2. let it use the OFBiz authentiation
        3. and make a ofbiz userinterface.

        Then with webservices, the messages could be communicated to other OFBiz systems too.
        (we just upgraded Axis1 to Axis2 within OFBiz)

        just found via twitter this wiki again (@hansbak)

        what do you think?

        1. Richard Hirsch

          Re 1: this may be difficult as ESME is scala-based (although java-byte code compatible). May be easier to just let run in the same container (I'm assuming tomcat) that OfBiz uses.

          Re 2: Currently, ESME has its own authentication and can't use container authentication :-<. We use tokens for our APIsand our support of the Twitter API is based on username / password.  There are ways to get around this limitation. I don't know OfBiz authentication well enough to know whether the user or an administrator could add - either manually or automatically - a token to the user object that is later used to ESME REST API calls.

          3. This is no problem. You just have to build a component that uses one of our APIs. There are a variety of examplesto do this

          >Then with webservices, the messages could be communicated to other OFBiz systems too.

          You might be able to meet this requirement with an ESME action using a HTTP Post action. If not, then you could develop an OFBiz component that listens to the ESME message stream and then posts messages via SOAP to other OFBiz systems.

          If I remember correctly, OfBiz uses JDK 1.6 is that correct?

          My suggestion for steps a very fast 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

          1. Hans Bakker

            Thanks for the quick answer, i will have one of my employees look at it... (@chatreesrichart)

            1. Richard Hirsch

              You could also create a bot that reads messages via our API and then sends it to OFBiz via JMS if I remember correctly OFBiz supports that as well

              1. Hans Bakker

                ok, but still if it could be an integral part of ofbiz, that would have our preferences.
                We will also distribute it like that.

                Can ESME instances talk together? (just thinking out load)

                1. Richard Hirsch

                  We've started designing federation but it isn't implemented yet. You could probably use actions for light weight message transfer or a bot for heavy-duty transfers.

                  I think user management might be the most challenging part of the collaboration where we need to sit down and figure out the best option - one that doesn't require high administrative effort and uses the best of both platforms.

    2. Vipul Tailor

      I think that there is no problem as ESME provides JSON (which is helpful when we are implementing such solution on website with the use of javascript), REST (For achieve the same from any other JAVA based or other application gives support for web client). I have not much idea about ofbiz but know that it is extensible and we can modify its code as well.

      I would like to know more about interface from OFBiz to ESME for giving more detailed solution.

      Regards,
      Vipul Tailor

      1. Richard Hirsch

        In Hans' scenario, there is a very loose integration where the ESME engine would exist independently of the OFBiz environment but would use the OFBiz user interface to provide functionality dealing with the communication between new users and administrators.  If a common user administration between OFBiz and ESME is desired, then more design work is necessary.

        In other possible integration scenarios between OfBiz and ESME,  I'd suggest using ECAs.

        @Vipul: What other information would you like to have?

        Regards,

        Dick

      2. Hans Bakker

        we are looking in using the regular forms interface of ofbiz talking with an inbuild ESME component.

  2. Hans Bakker

    Ok, the latest: we just heard that CAS (single signon) support will be added to ESME. That would be really good:

    Ofbiz already supports CAS. If we are using CAS, ESME and CAS can run in the same container or not with ofbiz.
    Because we just upgraded to Axis2 in Ofbiz we could use the REST API or twitter API, streaming (What is best?) to talk to ESME and update the users in CAS.

    It is then really flexible.....either include the ESME/CAS system in OFBiz or running in another container.....

    good stuff.

    1. Richard Hirsch

      I'd suggest using the Streaming API - it is still in progress but we probably aren't going to add any more functionality to the old REST API, so in the long term, the new API is probably your best bet.

      We are also excited about using CAS. We don't have a definite timeline yet when it will be developed but it is high on our priority list.

      How far can you get without having CAS - I would hate the lack of CAS to be a showstopper for you.

      1. Hans Bakker

        The person who will be doing this, first needs to do some other stuff for a week or so.
        Then he can look at the streaming interface.
        So if the CAS interface is there in about 2 weeks it is not a showstopper yet.

        1. Richard Hirsch

          Of course, we also have to examine how CAS will work with our REST API since that is how some people may be interacting with ESME.