We have a specific portlet implementation in OFBiz.
You can lokk at the MyPortal application to see them in action.

-Bruno


2009/11/28 Richard Hirsch <[email protected]>:
> What do you mean by Portlets? WSRP or OFBiz-specific?
>
> D.
>
> On Sat, Nov 28, 2009 at 11:28 AM, Bruno Busco <[email protected]> wrote:
>> Hi Richard,
>> in OFBiz we have also portlets that can be used to show ESME messages.
>> Portlets can be located by the user on portal pages.
>>
>> -Bruno
>>
>> 2009/11/28 Richard Hirsch <[email protected]>:
>>> I just read about the OFBiz Widget Toolkit
>>> (http://docs.ofbiz.org/display/OFBIZ/Understanding+the+OFBiz+Widget+Toolkit)
>>> . Of course, another idea would be to create a Widget that displays
>>> ESME messages.
>>>
>>> Just thinking aloud.....
>>>
>>> D.
>>>
>>> On Sat, Nov 28, 2009 at 10:32 AM, Richard Hirsch <[email protected]> 
>>> wrote:
>>>> I just created a wiki page for the conversation:
>>>> http://cwiki.apache.org/confluence/display/ESME/Collaboration+with+OFbiz
>>>>
>>>> I moved our initial ideas from this mail thread to this wiki page and
>>>> will continue adding details there.
>>>>
>>>> D.
>>>>
>>>> On Sat, Nov 28, 2009 at 8:43 AM, Richard Hirsch <[email protected]> 
>>>> wrote:
>>>>> Hi Scott,
>>>>>
>>>>> Comments inline
>>>>>
>>>>> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray <[email protected]> 
>>>>> 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
>>>>>>> <[email protected]> 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