Hi Scott,

Comments inline

On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray <scott.g...@hotwaxmedia.com> wrote:
> Hi Richard,
>
> Thanks for getting in touch with us, it's always good to hear from other ASF
> projects.
>
> I agree that an integration between the two projects could be quite
> interesting, and could actually be an extremely useful means of facilitating
> system<->user and user<->user communication.  Here's a few thoughts:
> 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.

Can you point me to some more technical documentation regarding EECAs, etc.
>
> 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.

This is also the same pattern that we use in ABAP.  Once you have
sendEsmeMessage piece, you could embed the functionality easily and
then have functionality like SalesForce Chatter.

>
> 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
(http://cwiki.apache.org/confluence/display/ESME/Actions) 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
(http://cwiki.apache.org/confluence/display/ESME/API) to read the
message queue and then create OFBiz events.

The integration via actions is very easy from the ESME side but on the
OFBiz side you would need some sort of mechanism to parse the message
to be able to call the appropriate OFBiz functionality.

>
> Additionally as part of the sending/receiving process we'd probably want to
> store the messages an CommunicationEvent records but that should be pretty
> straightforward using the existing services that are available.  For storing
> each user's ESME address we'd just use the ContactMech entity with a new
> ContactMechType.

Why would you need to store the user's ESME address?  OFBiz would post
messages to ESME in the form of a ESME user (for example,
"OFBizBackend"). Users who were interested in messages would follow
the user and would receive the messages from this user.  If you want
to restrict the access of messages, then you could use ESME's pool
mechanism.


>
> For chat I guess things will be a little more complicated because OFBiz
> would want to play some sort of a role in logging messages

You could probably create an ESME bot that listens to either an entire
group and copies the message into some sort of archive. Ideally, you
would write a bot that creates JMS messages that anyone can store. We
talked about this but have had no time to develop it yet.

> mentioned restricting communication between parties depending on there roles
> and permissions within the system.

ESME has the idea of pools to deal with restricting access.

I'm also assuming that ESME is only
> concerned with sending and receiving messages so the responsibility of
> managing things like this and other chat features (chat buddies, rooms,
> status, etc.) would fall upon the chat client rather than ESME?

Much of this is handled by ESME.  ESME has a variety of clients
available (see the bottom the page on
http://cwiki.apache.org/confluence/display/ESME/Index ) and supports
the twitter API as well (so some existing twiter clients can be used
to access ESME)

>
> But anyway I hope some of this is helpful and although I don't really have
> any time to spare at the moment to work on an integration, I just wanted to
> send something along to let you know that I think an integration would be
> quite useful and that there is some interest among the community.

I'll create a wiki page in the ESME Space to collect our ideas on the
integration.  I can do most of the ESME integration work but I'll ned
some assistance on the OFBiz side.

We have a test instance in the cloud. Is there a test OFBiz instance
where we might test the integration.

D.

>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 27/11/2009, at 9:19 PM, Richard Hirsch wrote:
>
>>> if you would like to work with us to get this implemented, you are very
>>> welcome.
>>
>> Of course.  We have a test server in the cloud that we can use and
>> REST APIs to create messages. We have also various clients
>> (Javascript, AIr client, etc.) that users can also use to view status
>> messages from different sources.
>>
>> What I don't know is how the integration with OFBiz would look like. I
>> read about ECAs but didn't find very many details. Ideal would to use
>> ECAs (when I understand them correctly) to use ESME's REST API to send
>> messages.
>>
>> What are the next steps?  Should I create a wiki page in the ESME wiki
>> space where we  can discuss this?
>>
>> D.
>>
>> On Fri, Nov 27, 2009 at 9:08 AM, Hans Bakker
>> <mailingl...@antwebsystems.com> wrote:
>>>
>>> Yes i have a request from a customer to add a chat function within
>>> ofbiz.
>>>
>>> we are looking at 2 frameworks:
>>> http://sourceforge.net/projects/nfcchat/
>>> the license is not compatible however i have a part confirmation they
>>> are willing to change the license
>>>
>>> and:
>>> https://sourceforge.net/projects/icsc/
>>>
>>> if you would like to work with us to get this implemented, you are very
>>> welcome.
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 2009-11-27 at 05:05 +0100, Richard Hirsch wrote:
>>>>
>>>> Hi,
>>>>
>>>> Has anyone thought about adding social components (ala Chatter in
>>>> SalesForce http://www.salesforce.com/chatter/) - in particular - to
>>>> OFBiz?
>>>>
>>>> I'm one of the Project Leads for the Apache Incubator Project ESME
>>>> (Enterprise Social Messaging Experiment)
>>>> (http://incubator.apache.org/esme/ ) and I was thinking about how ESME
>>>> might be integrated into OFbiz. I'm assuming that ECAs are probably
>>>> the best place to start but I didn't find enough information.
>>>>
>>>> There are various integration possibilities / use cases. A few
>>>> examples: a purchase order is changed and a short message is sent to
>>>> those in ESME who are interested or the user makes an enquiry about a
>>>> particular material and OFBiz sends a short message via ESME with a
>>>> status.
>>>>
>>>> Thanks.
>>>>
>>>> D.
>>>
>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>
>>>
>
>

Reply via email to