question about mime type video/x-flv

2009-11-28 Thread Al Byers
1. Why isn't it in mime-type.xml and where does mime-type.xml get used?

2. I call createDataResource and print out the value of DataResource
and it contains "video/x-flv" in the mimeTypeId, but in the next
service, the value is set to "application/octet-stream" and I cannot
find the seca that changes it. The console.log shows other secas
getting called, but nothing that could set this value.

Can anyone help me on this?

Thanks,

-Al


Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Richard Hirsch
I just created a very simple description of an initial use case (in
the ESME wiki):
http://cwiki.apache.org/ESME/simple-use-case-ofbiz-sends-message-to-esme.html

What don't you take a look at tell me what you think.

If you want, I can set up everything (pool, users, tokens, etc.) on
the ESME side and then send them to someone on the OFbiz side.

If you want to use Java to access the REST API, there is already a
primitive Java client in our SVN
(http://svn.apache.org/viewvc/incubator/esme/trunk/esme-java-client/)
that may come in handy.

Thanks.

D.

On Sat, Nov 28, 2009 at 5:32 PM, Richard Hirsch  wrote:
> I'd heard of Wookie but never thought about making a W3C Widget spec'd
> ESME client. Interesting idea.
>
> D.
>
> On Sat, Nov 28, 2009 at 12:48 PM, Scott Gray  
> wrote:
>> I stumbled across Apache Wookie (http://incubator.apache.org/wookie/) the
>> other day and found it quite interesting, any plans on creating W3C Widget
>> spec'd ESME clients?  I'd be interested in seeing what could be done to add
>> support for W3C Widgets in OFBiz, either standalone or wrapped in our
>> portlets that Bruno mentioned.
>>
>> Regards
>> Scott
>>
>> On 28/11/2009, at 10:45 PM, Richard Hirsch wrote:
>>
>>> 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 
>>> 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 
 wrote:
>
> Hi Scott,
>
> Comments inline
>
> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray 
> 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

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Richard Hirsch
I'd heard of Wookie but never thought about making a W3C Widget spec'd
ESME client. Interesting idea.

D.

On Sat, Nov 28, 2009 at 12:48 PM, Scott Gray  wrote:
> I stumbled across Apache Wookie (http://incubator.apache.org/wookie/) the
> other day and found it quite interesting, any plans on creating W3C Widget
> spec'd ESME clients?  I'd be interested in seeing what could be done to add
> support for W3C Widgets in OFBiz, either standalone or wrapped in our
> portlets that Bruno mentioned.
>
> Regards
> Scott
>
> On 28/11/2009, at 10:45 PM, Richard Hirsch wrote:
>
>> 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 
>> 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 
>>> wrote:

 Hi Scott,

 Comments inline

 On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray 
 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
> ne

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Richard Hirsch
Hi  Scott,

Inline

On Sat, Nov 28, 2009 at 12:40 PM, Scott Gray  wrote:
> Hi Richard,
>
> Inline
>
> On 28/11/2009, at 8:43 PM, Richard Hirsch wrote:
>
>> Hi Scott,
>>
>> Comments inline
>>
>> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray 
>> 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.
>
> This is probably the best we've got:
> http://docs.ofbiz.org/display/OFBTECH/Service+Engine+Guide#ServiceEngineGuide-ecas
> It only relates to SECAs although ECAs are pretty similar, differing mostly
> by the event type that triggers their evaluation.
>
>>>
>>> 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.
>
> 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.

Since this appears to be out-of-box functionality for both parties,
the easiest first step might be to have ESME send an email to OFBiz.

>
>> Or if there some
>> sort of ECA for dealing with email events, then we can also use an
>> action that sends email.
>
> Possible, but I'd prefer:
>>
>> 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.
>
> This sounds like the way to go, I'll take a look at the link as soon as I
> get a chance.

What might be interesting is to create a bot that reads ESME messages
and then sends JMS messages.

> With that said, is there any way to push the messages to OFBiz rather than
> polling a message queue?

Yes. Via our actions.  Actions respond to ESME events and respond
accordingly. For example, you could send a message via email or via
HTTP POST when you received a message with a certain tag or containing
a certain word.

>
>> 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.
>
> Yeah that should be pretty straight forward using an ECA style approach,
> when

Error in product attributes page.

2009-11-28 Thread rohit

Hi,

There seems to be an error in the product attribute page. The 'Add Product
Attribute' has a drop down list for attribute name. if the product does not
already have a existing product, its not possible to add a new attribute,
since the attribute field is a required field but which is blank.

If others find the same problem I will open a Jira issue for it. The error
can be seen in the latest SVN.

Thanks

Rohit
-- 
View this message in context: 
http://n4.nabble.com/Error-in-product-attributes-page-tp887930p887930.html
Sent from the OFBiz - User mailing list archive at Nabble.com.


Re: Adding to the mypage

2009-11-28 Thread advait75

Hi BJ,

Could you please send me the code for the imports that you have mentioned
below? I am looking for help in creating a page, where end users to my site
can upload Excel/CSV files and the data in these files get updated to some
tables.

I do not want end users to have to go to Webtools to perform this task, but
instead would like them to be able to access this import feature from one of
my pages.

I went to the JIRA issue 1939, but am unable to download any of the
attachments.

My email id advait [at] retailwave [dot] com

I appreciate your help.

regards,
Advait




BJ Freeman wrote:
> 
> Looking for a place to put some common imports
> like to put a menu and screens for this in the mypage
> they would only be seen if the person had those import permissions and
> roles.
> Three imports use excel data.
> Supplier Info (mostly for party info and CRUD parties for suppliers)
> Product Info (mostly deals with CRUD Products in mass)
> Supplier Inventory (mostly facilities and inventory data, CRUD)
> 
> This is more than just importing data into ofbiz and is a easier way to
> keep these updated from an end users point of view.
> 
> 
> 

-- 
View this message in context: 
http://n4.nabble.com/Adding-to-the-mypage-tp156244p884909.html
Sent from the OFBiz - User mailing list archive at Nabble.com.


Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Scott Gray
I stumbled across Apache Wookie (http://incubator.apache.org/wookie/)  
the other day and found it quite interesting, any plans on creating  
W3C Widget spec'd ESME clients?  I'd be interested in seeing what  
could be done to add support for W3C Widgets in OFBiz, either  
standalone or wrapped in our portlets that Bruno mentioned.


Regards
Scott

On 28/11/2009, at 10:45 PM, Richard Hirsch wrote:


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 > 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 > wrote:

Hi Scott,

Comments inline

On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray > 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 

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Scott Gray

Hi Richard,

Inline

On 28/11/2009, at 8:43 PM, Richard Hirsch wrote:


Hi Scott,

Comments inline

On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray > 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.


This is probably the best we've got: 
http://docs.ofbiz.org/display/OFBTECH/Service+Engine+Guide#ServiceEngineGuide-ecas
It only relates to SECAs although ECAs are pretty similar, differing  
mostly by the event type that triggers their evaluation.




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.


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.



Or if there some
sort of ECA for dealing with email events, then we can also use an
action that sends email.


Possible, but I'd prefer:

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.


This sounds like the way to go, I'll take a look at the link as soon  
as I get a chance.
With that said, is there any way to push the messages to OFBiz rather  
than polling a message queue?



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.


Yeah that should be pretty straight forward using an ECA style  
approach, whenever a message comes in the ECAs are evaluated.  For the  
conditions against the message bodies we could perhaps start off with  
regex pattern matching conditions and maybe evolve it to conditions  
like "contains-tag" or something like that (I still have reading to  
do, a lot of this is foreign to me having never used twitter).



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

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Bruno Busco
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 :
> What do you mean by Portlets? WSRP or OFBiz-specific?
>
> D.
>
> On Sat, Nov 28, 2009 at 11:28 AM, Bruno Busco  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 :
>>> 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  
>>> 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  
 wrote:
> Hi Scott,
>
> Comments inline
>
> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray  
> 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

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Richard Hirsch
What do you mean by Portlets? WSRP or OFBiz-specific?

D.

On Sat, Nov 28, 2009 at 11:28 AM, Bruno Busco  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 :
>> 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  
>> 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  
>>> wrote:
 Hi Scott,

 Comments inline

 On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray  
 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 

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Bruno Busco
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 :
> 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  
> 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  
>> wrote:
>>> Hi Scott,
>>>
>>> Comments inline
>>>
>>> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray  
>>> 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 proba

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Richard Hirsch
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  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  wrote:
>> Hi Scott,
>>
>> Comments inline
>>
>> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray  
>> 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 th

Re: I'm interested in integrating microblogging into OFBiz

2009-11-28 Thread Richard Hirsch
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  wrote:
> Hi Scott,
>
> Comments inline
>
> On Sat, Nov 28, 2009 at 1:08 AM, Scott Gray  
> 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 handl

Re: Wiki migration

2009-11-28 Thread Jacques Le Roux

Ha yes, forgot about that. It's all good then...

Thanks Bruno

From: "Bruno Busco" 

Jacques.
my changes were only done to test if the wiki was read-only. I guess
David's one also.

-Bruno

2009/11/28 Jacques Le Roux :

Buno, David,

Your last changes will be lost. Except if you backport them yourself when
our new wiki will be available...

Thanks

Jacques

From: "Jacques Le Roux" 


The infra team has now the import from Contegix available to create our
new Confluence wiki on ASF server, 40MB of content, 280MB for attachments
(in my home dir for the moment).
It's not easy to put all Confluence in read-only mode
http://jira.atlassian.com/browse/CONF-6390
http://confluence.atlassian.com/display/DOC/Global+Permissions+overview
http://confluence.atlassian.com/display/DOC/Space+Permissions+Overview

In the meantime, please don't edit/create anything : it will be lost

Jacques

From: "David E Jones" 


I just unchecked a few hundred little permission boxes, but I'm still
able to edit pages with my account. Permissions in Confluence are a little
weird as there is no explicit "edit" permission and it seems like if you
have any permissions, maybe even admin permissions, then you can edit pages.

Could a few other try editing pages and see if you can? Don't bother
updating anything since we've already done the export to move to the ASF
confluence server so further updates on docs.ofbiz.org will not be moved
over.

Thanks,
-David


On Nov 27, 2009, at 9:24 AM, Jacques Le Roux wrote:


We were not able yet to lock (put on read only mode) the wiki yet.
Please don't edit contents, nor add comments, new pages, attachments, etc.

Thanks

Jacques

From: "Jacques Le Roux" 


Hi OFBiz enthusiasts,

We are currently migrating OFBiz wiki (documentation) from Contegix to
ASF server. You may experience some slowness during the migration. At some
point we will lock (put to read only mode) the wiki to avoid having to
migrate data over and over.

Thanks for you interest with OFBiz

Jacques